Example: tdgssauth Debugging LDAP - 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™

The example shows how to use the -V option to debug LDAP. The example shows all the message exchanges between TDGSS and the directory server. Run:

tdgssauth -u userconflow -m ldap -t -i 198.51.100.20 -V 2

The user name (-u) is the same as it is specified in a bteq .logon command. The -m option specifies the logon mechanism to use (LDAP in this case). The -t option specifies to perform a test mode initialization. The -i option specifies the IP address from which the user connects. The -V option requests verbose output.

First, a series of message dumps headed by ldap_read and ldap_write are output. These are the actual message exchanges between TDGSS and the directory server. These messages happen when TDGSS is initialized, once per process lifetime. The gateway will cause TDGSS to generate this message when coming up after a TPA reset. These are not per-session messages.

The output includes the user's password and the database service password. Both the character interpretation and dumped hex need to be changed before sharing this trace information.

Result: Typically, this command produces pages of output, which is shortened here.

   0000:  30 39 02 01 01 60 34 02  01 03 04 27 63 6e 3d 64   09...`4....'cn=d  
  0010:  62 73 73 76 63 2c 6f 75  3d 73 65 72 76 69 63 65   bssvc,ou=service  
  0020:  73 2c 64 63 3d 65 78 61  6d 70 6c 65 2c 64 63 3d   s,dc=example,dc=  
  0030:  63 6f 6d 80 06 73 65 63  72 65 74                  com..SECRETPASSWORD        
ldap_read: want=8, got=8
  0000:  30 0c 02 01 01 61 07 0a                            0....a..          
ldap_read: want=6, got=6
  0000:  01 00 04 00 04 00                                  ......            
ldap_write: want=165, written=165
  0000:  30 81 a2 02 01 02 63 81  9c 04 00 0a 01 00 0a 01   0.....c.........  
  0010:  00 02 01 00 02 01 00 01  01 00 87 0b 6f 62 6a 65   ............obje  
  0020:  63 74 43 6c 61 73 73 30  7c 04 0b 6f 62 6a 65 63   ctClass0|..objec  
  0030:  74 43 6c 61 73 73 04 15  73 75 70 70 6f 72 74 65   tClass..supporte  
  0040:  64 43 61 70 61 62 69 6c  69 74 69 65 73 04 14 64   dCapabilities..d  
  0050:  65 66 61 75 6c 74 4e 61  6d 69 6e 67 43 6f 6e 74   efaultNamingCont  
  0060:  65 78 74 04 10 6e 65 74  73 63 61 70 65 6d 64 73   ext..netscapemds  
  0070:  75 66 66 69 78 04 12 73  75 70 70 6f 72 74 65 64   uffix..supported  
  0080:  45 78 74 65 6e 73 69 6f  6e 04 1a 63 6f 6e 66 69   Extension..confi  
  0090:  67 75 72 61 74 69 6f 6e  4e 61 6d 69 6e 67 43 6f   gurationNamingCo  
  00a0:  6e 74 65 78 74                                     ntext             
ldap_read: want=8, got=8

                         .
                         .
                         .

Next, tdgssauth prompts for a password. After entering the password, a series of dumps, headed by "Client's token" and "Server's token," are output. These are the actual tokens that the client side and server side of TDGSS exchange to authenticate and authorize the user.

Please enter a password: 

Client's token:
  00000000: 01 01 01 00 00 00 00 74 00 00 00 0d 00 00 00 00 *.......t........*
  00000010: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................*
  00000020: 00 00 00 00 00 00 00 34 00 00 00 00 00 00 00 00 *.......4........*
  00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................*
  00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................*
  00000050: e1 32 e2 18 d0 01 02 d3 01 01 d3 01 03 d4 01 04 *.2..............*
  00000060: d5 02 00 80 d5 02 00 c0 d5 02 01 00 e2 03 d1 01 *................*
  00000070: 04 e2 03 d1 01 06 e2 03 d1 01 07 e2 07 d2 01 05 *................*
  00000080: d6 02 08 00 06 0c 2b 06 01 04 01 81 3f 01 87 74 *......+.....?..t*
  00000090: 01 14 46 08 00 01 81 00 03 00 00 00 01 00 00 00 *..F.............*
  000000a0: 1e 01                                           *..*

Server's token:
  00000000: 03 02 01 01 00 00 03 a6 00 00 00 0d 00 00 00 00 *................*
  00000010: 01 00 00 00 00 00 01 00 00 00 01 00 00 00 01 00 *................*
  00000020: 00 00 00 00 00 00 00 66 00 00 00 00 00 00 00 00 *.......f........*
  00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................*
  00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 *................*
  00000050: 8a b3 f8 6e 8d 37 4b 78 2f 31 da d5 f2 7d 6a fd *...n.7Kx/1...}j.*
  00000060: a3 01 50 c1 1a 20 cf 63 46 71 2a e2 d2 c6 b7 0a *..P.. .cFq*.....*
  00000070: 5b 79 d4 5d 4c 0c 23 2a 06 5b 20 7b 12 1b 2c 33 *[y.]L.#*.[ {..,3*
  00000080: e1 47 b5 98 3c 38 a1 08 7f 27 27 03 b0 b8 39 cb *.G..<8...''...9.*
  00000090: a6 f7 1c 5d 0e b5 1e c8 90 93 4e ac f2 c7 dd 2a *...]......N....**

                         .
                         .
                         .

For the last token, more ldap_read and ldap_write dumps are output. These are the messages exchanged between the database and the directory server to authenticate and authorize the user. The user's password may appear in the dump if simple binding is used. Simple binding is used when the service or LDAP mechanism LdapClientMechanism property is set to the value "simple."

                        Status: authenticated, not authorized
                 Database user: userconflow [permanent user]
            Authenticated user: ldap://10.25.67.159:389/uid=userconflow,ou=principals,dc=example,dc=com
        Audit trail identifier: userconflow
        Authenticating service: dbssvc
     Actual mechanism employed: ldap [OID 1.3.6.1.4.1.191.1.1012.1.20]
       Mechanism specific data: userconflow

 Security context capabilities: replay detection
                                out of sequence detection
                                confidentiality
                                integrity
                                protection ready
                                exportable security context
ldap_write: want=59, written=59
  0000:  30 39 02 01 01 60 34 02  01 03 04 27 63 6e 3d 64   09...`4....'cn=d  
  0010:  62 73 73 76 63 2c 6f 75  3d 73 65 72 76 69 63 65   bssvc,ou=service  
  0020:  73 2c 64 63 3d 65 78 61  6d 70 6c 65 2c 64 63 3d   s,dc=example,dc=  
  0030:  63 6f 6d 80 06 73 65 63  72 65 74                  com..secret       
ldap_read: want=8, got=8
  0000:  30 0c 02 01 01 61 07 0a                            0....a..          
ldap_read: want=6, got=6
  0000:  01 00 04 00 04 00                                  ......            
ldap_write: want=574, written=574
  0000:  30 82 02 3a 02 01 02 63  82 02 33 04 30 63 6e 3d   0..:...c..3.0cn=  
  0010:  70 6f 6c 69 63 79 2c 63  6e 3d 54 65 72 61 64 61   policy,cn=Terada  
  0020:  74 61 20 50 6f 6c 69 63  69 65 73 2c 64 63 3d 65   ta Policies,dc=e  
  0030:  78 61 6d 70 6c 65 2c 64  63 3d 63 6f 6d 0a 01 02   xample,dc=com...  
  0040:  0a 01 00 02 01 00 02 01  00 01 01 00 a1 82 01 db   ................  

                         .
                         .
                         .

Using tdgssauth with ldapexplain

Using tdgssauth with the ldapexplain tool converts the hexadecimal dump to a byte array that is human-readable. The following code examples are two ways to run the tool. The first example is more secure because the tool suppresses the display of the user’s plaintext password. The first example is the recommended way to use ldapexplain.
ldapexplain tdgssauth -m ldap -u username -V 2
The ldapexplain tool can also be used as follows. Using the tool this way can expose the user password in plain text. Teradata recommends using the following commands only when the LDAP traces need to be preserved and further examined or a trace file has been captured and needs analysis.
$ tdgssauth -V 2 -m ldap -u username 2>ldap.log
$ ldapexplain <ldap.log