17.10 - Working with Service Binds - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - Advanced SQL Engine Security Administration

Advanced SQL Engine
Teradata Database
Release Number
July 2021
English (United States)
Last Update

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.