Example Identity Search - Advanced SQL Engine - Teradata Database

Security Administration

Product
Advanced SQL Engine
Teradata Database
Release Number
17.05
17.00
Published
September 2020
Language
English (United States)
Last Update
2021-01-23
dita:mapPath
ied1556235912841.ditamap
dita:ditavalPath
lze1555437562152.ditaval
dita:id
B035-1100
lifecycle
previous
Product Category
Teradata Vantage™

In this example, users log on to Vantage using the NT-style logon td/ab111222.

</Mechanism>
<Mechanism Name="ldap">
    <MechanismProperties
        ...
        />
    <IdentitySearch
      Match="[Tt][Dd]\\(.+)"
      Base="ou=user accounts,dc=td,dc=teradata,dc=com"
      Scope="subtree"
      Filter="(&(objectClass=user)(sAMAccountName=${1}))"/>
      BindName="${result}"
      DatabaseName="${1}"/>
</Mechanism>

The IdentitySearch element contains attributes that define the parameters of a directory search, and cause TDGSS to conduct the search for each directory user logon:

Attribute Name Attribute Value Description
Match

(required)

"[Tt][Dd]\\(.+)" A regular Posix expression that matches the username (authcid).
Base

(required)

"ou=user accounts,dc=td,dc=teradata,dc=com" A pattern into which the search substitutes substrings from the Match attribute value and constructs the DN that it uses as the search base.
Scope

(required)

"subtree" A string that defines the search scope, from among these options:
  • "base" requests a search of the object named in the Base attribute.
  • "one level" requests a search of the children of the Base object.
  • "subtree" subtree requests a search of the entire subtree, starting with Base.
Filter

(required)

"(&(objectClass=user)(sAMAccountName=${1}))" A pattern into which the identity search substitutes substrings from the Match attribute value, and which the search uses for the search filter, as defined in IETF RFC 2254.
BindName

(optional)

"${result}" Defines how the system rewrites the username to bind to the directory.

The default, BindName="${result}" , maintains backward compatibility with older configurations.

You can change to default based on directory requirements. For example, when using DIGEST-MD5 binding with directory services that require the DIGEST-MD5 user name to be "dn:" followed by the user's DN (common to many services), you can specify BindName="dn:${result}" to prepend dn to the outcome of the Identity Search.
The DIGEST-MD5 authentication protocol used by LDAP is deprecated. Teradata strongly recommends you use simple binding with TLS protection, and stop using DIGEST-MD5.
DatabaseName

(optional)

"${1}" Defines how the system rewrites the username so that the database can identify the user in a particular form.

The value ${1} identifies the user in the database using only the uid portion of the logon, and drops the ${2}, ${3}, and ${4} portions of the username.

Search Results:

Based upon a Windows domain TD, the existence of users ab111222 and xy333444 in the directory, and the search base and scope specified in the previous example, the identity search generates the following searches and results.

Username Filter $(result)
td\ab111222 (&(objectClass=user) (sAMAccountName=ab111222)) CN=ab111222,OU=NorthAmerica,OU=User Accounts,DC=TD, DC=CORP,DC=COM
td\xy333444 (&(objectClass=user) (sAMAccountName=xy333444)) CN=xy333444,OU=NorthAmerica,OU=User Accounts,DC=TD, DC=CORP,DC=COM
td\user1234 (&(objectClass=user) (sAMAccountName=user1234)) The search returns no results, which indicates that the user does not exist in the directory.