This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Help Analyzing for LDAP/Active Directory Errors

0

Hello - I am a very new user to Wireshark and definitely have no experience in reading or interpreting the capture files.

I am working with a client to find out why an application fails to return/authenticate a user accouunt when installing this application.

The server the application is being installed on is a member server and I am sure there are errors when calling to the Domain Controller. I have done NSLOOKUPS, NETDOM Verify etc tests and have had some failures.

The network department for the client will not offer help until I PROVE thier network is the issue.

The system is a VM system, Windows 2003 server. The network lan is said to be open, no ACL's no port blocks, all routing supposedly correct. All DNS servers supposedly have all SRV records.

So I installed Wireshark and performed the installation of the application with the capture running. I am not sure how to identify the exact information I am looking for.

I have looked through the file and can see some things that look to be some kind of issues with ldap/api calls, but I am not sure.

I would appreciate some help in interpreting this file for my own education and to also give the client's network team specific details of the issues/errors in preventing the system from properly reaching or returning information from the Active Directory.

With Sincere Gratitude. Alina

asked 03 May '11, 05:49

Bluewiskie's gravatar image

Bluewiskie
1112
accept rate: 0%

edited 03 May '11, 05:50


3 Answers:

1

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!

answered 04 May '11, 02:18

packethunter's gravatar image

packethunter
2.1k71548
accept rate: 8%

1

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.

answered 05 May '11, 05:44

packethunter's gravatar image

packethunter
2.1k71548
accept rate: 8%

0

Hello and Thank you for your response.

I actually did perform the trace on a good environment where we are a member server and I did good returns on my NETDOM verify calls and GETUSER Info tests, etc.

And I don't see any of the same information I see on the site that is giving me issues, so I know something is not allowing our API/LDAP calls to perform correctly.

I was able to do some more digging and found another analyzer that helped group the issues found in a better format for reviewing.

There were a number of SMB issues and I did spot the Kerberos issues that I am not familiar with.

false 132 172.16.3.75 165.6.3.109 190 KRB5 KRB Error: KRB5KDC_ERR_BADOPTION NT Status: STATUS_NOT_SUPPORTED 1.556517000 0.000619000 2011-05-03 09:18:07.850668000

false 558 172.16.3.75 165.6.3.109 147 KRB5 KRB Error: KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN 33.172496000 0.000009000 2011-05-03 09:18:39.466647000

false 4322 172.16.3.75 165.6.3.109 124 KRB5 KRB Error: KRB5KRB_ERR_RESPONSE_TOO_BIG 63.545952000 0.001478000 2011-05-03 09:19:09.840103000

Considering it's a 200mb capture file I am not sure I can upload it on to this thread for full review.

I am still searching to check what these specific entries mean, but any help would be greatly appreciated!!

Thank you again. Alina.

answered 04 May '11, 06:14

Bluewiskie's gravatar image

Bluewiskie
1112
accept rate: 0%