Help Analyzing for LDAP/Active Directory Errors

Your posting sounds like a several consulting jobs that we did: "It's the network." Now, in most case it was not the network.

If a Windows domain member (workstation or server) authenticates a user against the AD you would look for Kerberos problems. Now, Kerberos can (and will) show error codes like "Response too big". This is an error that can be ignored, as it tells the Kerberos how to talk to the Kerberos server. The more interesting messages would be "Client Principal unknown" or "Server Principal unknown". Kerberos error messages are easy to find with the display filter kerberos.msg.type == 30

If you suspect a problem with LDAP you want to apply the display filter ldap Analyzing LDAP is not that easy: Depending on your application you will see a bunch of queries. For example when a system boots it searches for information at a specific point and gets less specific with more queries, say first look for policies for a site, then for the domain.

When analyzing your application's LDAP traffic you should understand the LDAP calls made by your application. Alas, we often talk to programmers who don't know what their application is doing to the network (or servers).

Here are a few ideas if you suspect that something is going wrong with LDAP:

• Do you get LDAP error messages?
• Do you get no results (Wireshark would show "[0 results]") from your query?
• If yes: Do you know, why you did not get any results (Just because no information was there, or was it because the query was not properly written)
• Do you make the same queries over and over again?
• If yes: Can you cache the results?
• How fast are your LDAP servers (Statistics -> Service Response Time -> LDAP)

It is probably a good idea to compare your trace with a "known good" sample. If you suspect that something is misconfigured take another trace in your lab and find out where your client installation goes a different path - and find out why (is it a policy thing, a network thing or somehting else).

Good hunting!

The Kerberos snippets from your posting already hint at a few problems:

• The Kerberos errors "bad option" are usually related to the flag "Constrained delegation" in the request. Constrained delegation has to be configured on the client and/or server principal (i. e. the user or application account)
• The Kerberos error "S_PRINCIPAL_UNKNOWN" (Server principal unknown) shows that the Kerberos server does not know about the service for which it should issue a ticket.
• The "Response too big" is just to force the protocol from UDP to TCP and no problem at all, as long as a proper TCP session follows.

The big thing here is the Server principal. Most common reasons are:

1. A host name is misspelled
2. The target host is addressed by IP address, not by host name
3. The target server is not a domain member
4. The target application is not "kerberized" (i. e. not properly configured in the domain so the KRB server can not issue a ticket)

The trace might contain sensitive information like passwords, password hashes, e-Mails or other confidential information. Before posting or otherwise publishing the trace file I recommend to get a written permission (at least per e-mail).

Also, please bear in mind that a thorough analysis of a 200 MB trace is a small project in itself and is hardly done as a freebee.