AD Logons and Network Traffic

Last week we looked at a number of introductory issues on using the Wireshark tool. Now I’d like to turn our attention to some Windows-specific issues. One of the areas that always seems to interest users and administrators alike is logging on, so let’s take a look at some of the traffic types that can occur when a user logs on to a Server 2003 or 2008 domain. (The actual traffic in any given network will vary depending on many factors, so although the protocols and sequences mentioned here are fairly typical, they probably will not match exactly what you see on your network.) Now you might ask “how am I going to capture network traffic before I even log on” given that in our examples so far, you’ve been running Wireshark on the PC itself, and need to be logged on to start the program. This might not be a bad time to mention that you can run Wireshark in many different configurations. For example, you can connect a laptop running the sniffer to a port on a full-duplex “aggregating” switch. You can also install the tool on a server and use a capture filter to limit captured traffic to a specific workstation. And you can run Wireshark in one logon session on a workstation and then use the “switch user” capability of (say) Vista to capture logon traffic associated with a second user on the same workstation. The traffic that you’re likely to see during a domain logon spans several protocols. Early in the process you are likely to see some Kerberos traffic (protocol KRB5 for example) which has to do with authentication and the issuance of “tickets” that grant access to the network. A bit later you may see some SMB traffic (Server Message Block) that sets up network drive mappings for the client. Around this time you may also see some DNS traffic designed to retrieve information about Active Directory site configuration. Some LDAP traffic will also show up, for example, so that the client can learn about the various “naming contexts” it should use when communicating with AD; you’ll need to do a lot of drilling down to find the “meat” of some of these LDAP requests and responses. (You may also see CLDAP which stands for “connectionless” LDAP.) Then, towards the end of the logon process, you’re likely to see some more SMB messages connecting to the SYSVOL share on the domain controller and checking the version numbers of Group Policy objects, so that the client knows which GPO’s have changed and might therefore need to be reapplied. Give it a try and spend a few minutes noodling around with a Wireshark capture of an AD logon. You’ll gain a new understanding of what is going on behind the scenes, and you’ll prepare yourself for troubleshooting logon problems in the future – for example, by identifying unusual delays at different points in the logon process.