Active Directory (AD) is a complex product and requires a complex chain of communications for proper operation. There are really a few basic, common sequences of communication:
Additional traffic can occur when clients attempt to look up cross-domain references by contacting a Global Catalog (GC) server. Clients might contact GCs for other reasons, such as during the logon process, to resolve Exchange 200x Address Book lookups, and more.
Troubleshooting this traffic can be difficult. Kerberos traffic, for example, is always encrypted using temporary encryption keys established between the Key Distribution Center (KDC— domain controller) and clients. Even simple Lightweight Directory Access Protocol (LDAP) queries to GC servers or domain controllers are generally encrypted by Secure Sockets Layer (SSL) encryption, particularly in Windows Server 2003, in which LDAP over SSL is the default.
The only way to effectively troubleshoot AD communications is to use Network Monitor. Although other utilities are very good at troubleshooting AD's operations, they don't get into low-level communications. You'll need to know what to expect, then you can see what traffic is actually being transmitted.
Keep in mind that Microsoft makes two versions of Network Monitor. The one that comes with Windows is restricted and can only capture traffic coming to and going from the local computer. If this version is the only one you have access to, you'll need to run it on the domain controller that you're troubleshooting.
The other version comes with Systems Management Server (SMS) and can capture any traffic on the local segment, even if the computer running Network Monitor isn't involved in the communication.
The one caveat you'll need to be aware of with Network Monitor is that it doesn't have built-in parsers for most of the traffic AD uses, including Kerberos. That's OK; you don't need a parser to troubleshoot traffic, you just need to know what you're doing. Network Monitor might not, for example, recognize Kerberos traffic when it sees it (because the tool lacks a parser), but I'll show you what to look for so you'll recognize the traffic.
Figure 34.1 shows a typical Network Monitor capture. In the top pane are all the capture frames of traffic; the bottom pane shows a breakdown of the frame selected in the top pane. Notice that the protocol in this case is listed as TCP. Network Monitor will show the Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) for most AD traffic. To determine the actual traffic type, you'll need to look at the packet's details.
Figure 34.1: Typical Network Monitor capture.
In this example, the packet has a source (src) port of 80 and a destination (dst) port of 4254. I can see that the source address was a server and the destination was a client, so I can presume that this is a reply. That means the server's source port is the same port that the client originally used to contact the server: port 80. Port 80 is HTTP traffic, although Network Monitor obviously didn't recognize this frame as a traditional HTTP packet. The destination port was randomly chosen by the client when the client initiated the communication session.
Most AD communications will appear as TCP, and you'll need to look at the source port used by the server or the destination port used by the client to determine the traffic. Expect to see the following TCP and/or UDP ports:
The exact sequence of packets will differ from environment to environment, especially because AD traffic is usually interleaved with many other, unrelated forms of communication. If you're experiencing any form of problem, check the following items (these don't require you to memorize complex sequences of communications):
One way that Network Monitor can help draw out the AD traffic from everything else on your network is with filters. When viewing a capture, click Filter. You'll see a dialog box similar to the one that Figure 34.2 shows.
Figure 34.2: Viewing filters in Network Monitor.
Click Expression to add a filter expression. As Figure 34.3 shows, create an expression that filters for packets having a specific destination port. In this example, the filter will eliminate all traffic except Kerberos traffic, which uses UDP and TCP 88.
Figure 34.3: Filtering for TCP port 88.
Be sure to create filters that allow for a source or destination port so that you'll capture both the client and server sides of the exchange. You can use the Or button on the filter dialog box to ensure that any packets meeting any one of your criteria will be included in the display. Figure 34.4 shows an example of the configured filters.
Figure 34.4: Configured display filters.
Filtering for specific types of traffic will help you focus on different areas to be sure they're working properly without having to manually wade through all of the packets that Network Monitor may have captured. You can load and save filters for later use, making it easier to quickly look at Kerberos traffic, DNS traffic, LDAP queries, and so forth.
Network Monitor won't allow you to directly fix any problems. However, it can point the way to what's broken. For example, if capturing packets from each side of a firewall reveals that Kerberos (port 88) packets aren't making it through, you'll know that you need to reconfigure the firewall. If DNS queries contain incorrect IP addresses, you'll need to fix the DNS zone database. If traffic seems to be repeating itself, there's something wrong or misconfigured within the traffic itself (such as a username or password contained within the traffic), and you'll need to closely examine the configuration of the computers involved.