16.10 - Working with Service Binds - Teradata Database

Teradata Database Security Administration

Teradata Database
June 2017

Service binds occur between the username submitted by the service (either Teradata Database 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 Database 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 Teradata Databases 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.