Service binds occur between the username submitted by the service (either Teradata Vantage or Teradata Unity) and a bindable directory object. All LDAPv3-compliant directories support bindable objects. Requirements for bindable objects vary among directories, but all bindable objects include a userPassword attribute.
- You can use Teradata system-level objects for service bindable objects, for example:
- Directories that use Teradata schema extensions can use a tdatSystem object.
- Directories that use only native directory schema can use a system object.
Do not use existing Teradata system-level objects, the parents of other Teradata directory objects, as service bindable objects. Create new system-level objects for use in service binds, or use other bindable directory objects, according to your directory policy.
- For sites with multiple Teradata Vantage systems:, create a bindable object for each system, and for the Unity server, if users log on through Unity.
- If site policy requires unique authentication of each service, create a bindable object for each system, and for the Unity server, if used. The LdapServiceFQDN property on each system names its unique bindable object.
- If site policy views multiple Vantage systems and the Unity server as a single network service, then the individual systems can all point to a single common bindable object in the directory.
- If systems are authenticated in different directories, then each directory must contain the necessary bindable object(s).
- Teradata requires only that the service DN for the object is bindable.