joeware - never stop exploring... :)

Information about joeware mixed with wild and crazy opinions...

Looking at LDAP Network Traffic on Windows

by @ 3:25 am on 6/7/2008. Filed under tech

A lot of times when people run into issues with LDAP based apps, one of the troubleshooting steps I recommend is to do a network trace and look at the LDAP traffic and then I hear… Hey, I try to but it looks like gibberish and WireShark says it can’t be decoded or something… By this I think they mean it looks something like

Lightweight-Directory-Access-Protocol
    BER Error: Sequence expected but Class:0(UNIVERSAL) PC:0 Tag:0 was unexpected

0000  00 50 8d 91 0b d2 00 0c 29 f4 7b 5e 08 00 45 00   .P……).{^..E.
0010  05 dc 07 ab 40 00 80 06 6b 2e c0 a8 00 78 c0 a8   ….@…k….x..
0020  00 7a 01 85 04 6c e4 78 1a 2e 35 8f ea 5b 50 10   .z…l.x..5..[P.
0030  f7 5d 83 2f 00 00 00 00 0a 9d 01 00 00 00 f5 18   .]./…………
0040  cf 41 7a b3 3f da 01 00 00 00 11 de f4 b8 eb 4c   .Az.?……….L
0050  28 e8 b2 c3 e0 69 20 28 f6 b0 90 1b ec b8 05 4f   (….i (…….O
0060  80 bb 82 75 af a7 26 68 e6 d5 35 2b 56 04 ba 11   …u..&h..5+V…
0070  30 16 00 fe 8d 16 85 e7 da 62 97 d5 86 f9 bb 59   0……..b…..Y
0080  00 d7 59 60 12 36 fe b6 b5 82 bb 2b ec cf 3b 6a   ..Y`.6…..+..;j
0090  42 6b 6b dd d3 a3 e4 63 42 8a 0b ae d1 bc 5a 40   Bkk….cB…..Z@
00a0  46 de 1e 78 01 bc c1 ad ec 36 80 db cc eb c2 f9   F..x…..6……
00b0  ba 85 83 a8 f5 22 bf cc 7b 97 29 9e e0 18 b2 fc   …..”..{.)…..
00c0  c2 bd 01 2a a6 83 33 55 a3 57 e1 21 65 4d f9 08   …*..3U.W.!eM..
00d0  8d ff dc 25 0e 3d 93 cc 4c 34 4c 1f f1 17 39 be   …%.=..L4L…9.
00e0  78 39 42 90 0c 23 65 3d 3b 29 5f 95 c0 d7 cf 2c   x9B..#e=;)_….,
00f0  ae a5 0c 12 94 bc 41 bb 2e f1 33 05 2c 95 20 94   ……A…3.,. .
0100  3c 1f d6 32 9f 73 8b df 4c dc fe 5b cd 2a ac 3a   <..2.s..L..[.*.:

instead of something like

Lightweight-Directory-Access-Protocol
    LDAPMessage searchRequest(7) “DC=test,DC=loc” baseObject
        messageID: 7
        protocolOp: searchRequest (3)
            searchRequest
                baseObject: DC=test,DC=loc
                scope: baseObject (0)
                derefAliases: neverDerefAliases (0)
                sizeLimit: 0
                timeLimit: 120
                typesOnly: False
                Filter: (objectclass=*)
                    present: objectclass
                attributes: 1 item
                    Item: ntsecuritydescriptor
        [Response In: 72]
        controls: 2 items
            Item LDAP_SERVER_SD_FLAGS_OID
                controlType: 1.2.840.113556.1.4.801 (LDAP_SERVER_SD_FLAGS_OID)
                criticality: True
                controlValue: 308400000003020107
            Item LDAP_PAGED_RESULT_OID_STRING
                controlType: 1.2.840.113556.1.4.319 (LDAP_PAGED_RESULT_OID_STRING)
                criticality: True
                controlValue: 308400000006020203E80400

0000  00 a0 c9 ce b2 7b 00 50 8d 91 0b d2 08 00 45 00   …..{.P……E.
0010  00 e0 7a a7 40 00 80 06 fd 9b c0 a8 00 7a c0 a8   ..z.@……..z..
0020  00 0a 0b 74 01 85 f2 eb 1b 1d c0 25 e9 57 50 18   …t…….%.WP.
0030  f6 2e 82 a7 00 00 30 84 00 00 00 b2 02 01 07 63   ……0……..c
0040  84 00 00 00 48 04 0e 44 43 3d 74 65 73 74 2c 44   ….H..DC=test,D
0050  43 3d 6c 6f 63 0a 01 00 0a 01 00 02 01 00 02 01   C=loc………..
0060  78 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73   x…..objectclas
0070  73 30 84 00 00 00 16 04 14 6e 74 73 65 63 75 72   s0…….ntsecur
0080  69 74 79 64 65 73 63 72 69 70 74 6f 72 a0 84 00   itydescriptor…
0090  00 00 5b 30 84 00 00 00 26 04 16 31 2e 32 2e 38   ..[0….&..1.2.8
00a0  34 30 2e 31 31 33 35 35 36 2e 31 2e 34 2e 38 30   40.113556.1.4.80
00b0  31 01 01 ff 04 09 30 84 00 00 00 03 02 01 07 30   1…..0……..0
00c0  84 00 00 00 29 04 16 31 2e 32 2e 38 34 30 2e 31   ….)..1.2.840.1
00d0  31 33 35 35 36 2e 31 2e 34 2e 33 31 39 01 01 ff   13556.1.4.319…
00e0  04 0c 30 84 00 00 00 06 02 02 03 e8 04 00         ..0………..

The second snippet clearly shows an LDAP query of

  • Base DN: DC=test,DC=loc
  • Scope: Base
  • Filter: objectclass=*
  • Return the attribute nTSecurityDescriptor…

The second is very clear and easy to understand. The first… Well not so easy.

This first capture looks the way it does due to a thing called LDAP Client Signing or LDAP Integrity. It “sort of” secures the data passing across LDAP. I say sort of because there are a few ways to get around it.

The first way around is to use the sysinternals tool called Insight for Active Directory. You can get that here… http://technet.microsoft.com/en-us/sysinternals/bb897539.aspx 

This is a pretty cool tool, can be very handy. You used to have to pay for it. But now you don’t. 🙂

 

The second way around is to disable the Client Signing. The current Client Signing setting is maintained in the registry (of course) in the key

hklm\system\currentcontrolset\services\ldap under the value ldapclientintegrity. There are three possible values

0 No signing/sealing
1 Negotiate signing/sealing
2 Require signing/sealing

You will likely see it set to 1 if it is set to anything. If it isn’t set, the default internally is 1 anyway… So if you switch this to 0, you will *generally* start seeing the LDAP traffic in the clear. If not, the issue could very well be that the application is forcing the information to be “encrypted” anyway like the AdFind -kerbenc switch does. At that point you have no choice but to use Insight for AD which hooks the LDAP calls prior to being encoded.

This can also be set through Group Policy so you may find that you set it to 0 and then later it goes back to 1 or even possibly 2. If that happens a GPO was configured to define a value for Computer Configuration | Windows Settings | Security Settings | Local Policies | Security Options | Network Security: LDAP client signing requirements.

     joe

Rating 4.33 out of 5

Comments are closed.

[joeware – never stop exploring… :) is proudly powered by WordPress.]