16.10 - Example: tdgssauth Debugging LDAP - Teradata Database

Teradata Database Security Administration

prodname
Teradata Database
vrm_release
16.10
created_date
June 2017
category
Administration
Security
featnum
B035-1100-161K

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's 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 says to perform a test mode initialization. The -i option specifies the IP address from which the user will connect. 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   ................  

                         .
                         .
                         .