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
