You can specify the DN of a tdatUser object, or in some cases the DN of a directory principal object, as a member of a policy to apply the policy to the user.
The DN specification requirements depend on how the user is authenticated and authorized, regardless of policy type.
|Authentication Mechanism||Member Definition|
|TD2||The DN must be an existing Teradata user object in the directory with a cn that matches a Teradata Database user name.|
|KRB5 (AuthorizationSupported=no)||The DN must be an existing Teradata user object in the directory with a cn that matches Kerberos domain user name.|
|LDAP (AuthorizationSupported=no)||The DN must be an existing Teradata user object in the directory with a cn matches the LDAP log on name for the user.|
|KRB5 or LDAP with (AuthorizationSupported=yes)||Must be either:
The choice of user object is subject to the following rules:
If the directory principal is mapped to a Teradata user object, use the DN of the Teradata user object for the member attribute.
If the directory principal is not mapped to a Teradata user object, use the DN of the directory principal for the member attribute.
|PROXY||The PROXY mechanism is only used by the Unity server for logging on to connected Teradata Database systems.
If users logging on through Unity are externally authenticated, PROXY must be configured. If PROXY is configured, Unity also uses the PROXY mechanism for TD2 sessions.
If PROXY is configured, create a PROXY mechanism policy and assign policy membership to the Unity user for each server, to ensure the security of Unity connections to the database,
Do not assign a PROXY policy to any other user.