Working with Service Binds - Analytics Database - Teradata Vantage

Security Administration

Deployment
VantageCloud
VantageCore
Edition
Enterprise
IntelliFlex
VMware
Product
Analytics Database
Teradata Vantage
Release Number
17.20
Published
June 2022
Language
English (United States)
Last Update
2024-04-05
dita:mapPath
hjo1628096075471.ditamap
dita:ditavalPath
qkf1628213546010.ditaval
dita:id
zuy1472246340572
lifecycle
latest
Product Category
Teradata Vantageā„¢

Service binds occur between the username submitted by the Teradata Vantage service 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 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.
    • If site policy requires unique authentication of each service, create a bindable object for each system. The LdapServiceFQDN property on each system names its unique bindable object.
    • If site policy views multiple Vantage systems 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 objects.
  • Teradata requires only that the service DN for the object is bindable.