Example: tdgssauth Verifying a Mapped User Parameters Using LDAP - Analytics Database - Teradata Vantage

Security Administration

Analytics Database
Teradata Vantage
Release Number
June 2022
English (United States)
Last Update
Product Category
Teradata Vantage™

This example shows how to verify mapped user properties using LDAP from a given IP address. Run:

tdgssauth -u diperm01 -m ldap -i

The user name (-u) is as specified in a bteq .logon command. The -m option specifies the logon mechanism to use (LDAP in this case). The -i option specifies the IP address from which the user will connect.


 1> Please enter a password: 
 2>                        Status: authenticated, not authorized
 3>                 Database user: perm01 [permanent user]
 4>                       Profile: profperm01
 5>                External roles: extrole01perm01, extrole02perm01, extrole03perm01 
 6>            Authenticated user: ldap://example.com:389/CN=diperm01,OU=people,DC=example,dc=com
 7>        Audit trail identifier: diperm01
 8>     Actual mechanism employed: ldap [OID]
 9>       Mechanism specific data: diperm01
11> Security context capabilities: replay detection
12>                                out of sequence detection
13>                                confidentiality
14>                                integrity
15>                                protection ready
16>                                exportable security context
18> Minimum quality of protection: none
19>                       Options: none

In this example, we see that the directory user diperm01 maps to the permanent Vantage user perm01 on line 3.

The following explains the output from the command:

Line Number Description
1> Please enter a password When prompted, enter the user password for the specified mechanism. In this example, the user LDAP password is entered because the specified mechanism is LDAP. If KRB5 is the specified mechanism, enter the user KRB5 password.
It is not recommended to specify the user password with -w on the command line.
2> Status: authenticated, not authorized The user authenticated successfully and is not unmapped to a Teradata object.
3> Database user: perm01 [permanent user] The database user to which the directory user is mapped. Notice that the directory user, diperm01, maps to the permanent database user, perm01.
4> Profile: profperm01 The user has the profperm01 profile associated with the session.
5> External roles: extrole01perm01, extrole02perm01, extrole03perm01 The user is permitted to occupy the three external roles, extrole01perm01, extrole02perm01, and extrole03perm01. The DBA must create those roles in the database and grant them rights.
6 > Authenticated user: ldap://example.com:389/CN=diperm01,OU=people,DC=example,dc=com The identity of the user in the directory server and the server that authenticated the user.
7> Audit trail identifier: diperm01 The user audit trail identifier used in event logs caused by a session logged on as this user.
8> Actual mechanism employed: ldap [OID] The name and Object Identifier (OID) of the actual authentication mechanism used to authenticate the user.
The TDNEGO mechanism reports the actual mechanism that it selected to authenticate the user. Other explicitly named mechanisms report themselves here.
9> Mechanism specific data: diperm01 The mechanism specific data. This data is used by other parts of the system during the logon process and is not used by TDGSS. In most, if not all cases, this simply provides the name of the user from the -u command line option.
11 - 16> Security context capabilities: replay detection, ..., exportable security context These lines show what a particular security context provides. The security context is the one established for the named user using the specified mechanism.
18> Minimum quality of protection: None The minimum quality of protection (QoP) that the user is required to use for the life of the session. In this example, during the life of a session this user can use any QoP including no QoP at all.
19> Options: none The connection options in effect for the user. In this case, the word none indicates that this is a normal connection. This value may contain has-policy or no-direct-connect. The has-policy value says that the user must use only a plaintext connection to the database and is used for very specialized purposes. The no-direct-connect value says that the user is not permitted to connect directly to the database.