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.
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 ................
.
.
.