How can I use Wireshark to analyze slow Active Directory logins?

Question

This page seems to imply that Wireshark can only begin capturing after boot, but it looks like someone else has run into this problem before and didn't get anywhere.

It doesn't necessarily have to be Wireshark, I just need to figure out why some AD logins on my network are so slow and to do so I believe I have to look at what's actually happening over the network.

Solution 1

Capturing login information can be tricky. There are a couple of ways of getting at this information, but part of it depends on how replicable the problem is. If it is wide-spread, spinning up a virtual-machine and doing the sniffing on the host-machine will get you what you need. If it is limited to certain areas or certain machines, you'll probably have to set up a span-port on your network switch and sniff from another machine on the same switch. I've done it both ways.

Another method is possible, and that's to run the sniffer on all of your domain controllers with a capture filter of the IP address of the machine in question. It isn't as optimal as using a span-port would, but it would at least profile machine/DC communication.

Microsoft Netmon is a pretty powerful tool for capturing Microsoft login problems, though in my opinion Wireshark's decode suite is better equipped overall.

Solution 2

Concentrating on the client-end of the capture is probably going to bear the most fruit since capturing on the domain controller end is going to mean running captures on all the DCs in the network. (If you only have a single DC then you might be better off capturing on the DC end if the problem w/ the clients is intermittent.)

Running Wireshark during boot on the client strikes me as the wrong tool for the job. Running software on the client potentially upsets the client computer's configuration and might influence the results. I'd try and capture the traffic w/o creating any influence on the client computer's behavior.

If you have administrative access to the switch the client is connected to configure a "monitor" session ("port mirror", "SPAN" port, etc) and capture from another computer on the dedicated monitor port.

If you don't have administrative access to the switch, consider connecting a dedicated capture computer between the client computer and the LAN. Your dedicated capture computer will need two physical interfaces, which you would bridge. Then you'd capture on either the bridge virtual interface or one of he physical NICs on the dedicated capture machine.

Doing this capturing on either a Windows-based or Linux-based machine is pretty easy. On a Windows machine it just involves putting two NICs in the capture machine, bridging them w/ the built-in bridging functionality in the Windows GUI, and capturing on the bridge interface. The situation is similar on Linux, albeit w/o the pretty GUI in a lot of distributions.

I tend to think that you'll find something sniffing, but you need to have an understanding of what happens during boot and logon (DNS being used to locate a DC, how AD site membership affects DNS and LDAP queries, what Group Policy application looks like, etc) in order to interpret the results. Comparing a "working" machine with a "non-working" machine is a valid strategy if the difference between "working" and "non-working" doesn't skew the results too far (i.e. in different AD sites, different OUs w/ different GPOs applying, etc).

Don't discount the possibility of performing non-network traces on problem client computers using the Microsoft/SysInternals tool "Process Monitor". It can be setup to run at boot and can provide an extremely detailed log. If you're having a problem as a result of a delay in a Group Policy Client Side Extension, for example, a ProcMon trace is probably going to give you better information than a network capture.

Solution 3

It's quite possible that you won't find any answers by watching the traffic. While there are a number of reasons logons can be slow I've found that most of the time it's due to various kinds of network mappings that are unavailable at logon. The most common being a network share that no longer exists. While you might be able to observe this through a sniffer it's going to be very hard to recognise. Regardless, I wish you luck solving this all too common problem.

Solution 4

http://blogs.technet.com/b/askds/archive/2009/09/23/so-you-have-a-slow-logon-part-1.aspx

There's a part two also, if you search that blog you'll find it. Can't post two links here.

View more solutions

Comments

[Philip]

If you haven't already: double, triple, and quadruple check DNS. 99%+ of AD access issues are DNS related IME.

[David Corsalini]

agreed and upvoted - slow AD logins are almost always DNS related

[user65712]

It looks like there was info for an old, decommissioned DNS server being sent out via DHCP. I fixed that.