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
edited 03 May '11, 05:50
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:
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).
answered 04 May '11, 02:18
The Kerberos snippets from your posting already hint at a few problems:
The big thing here is the Server principal. Most common reasons are:
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
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 18.104.22.168 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 22.214.171.124 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 126.96.36.199 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