First published on CloudBlogs on Jul, 28 2007
Some readers may scoff a little when I talk about how under appreciated the whole Active Directory scheme is. Not schem
a
but scheme. I’m talking about the entire client and server interaction and how they work together to provide all of the distributed services that make up Active Directory and user logon.
That’s a bold statement, you may say. Let me back it up with some general facts.
If you are going to have a secure business environment then you need to have a secure client computer (workstation) for your information worker to use. We have that in Windows Vista and earlier. These operating systems provide a logon mechanism to that workstation which can allow user identity verification by way of a network discussion with a centralized repository that keeps track of users and passwords and things like that. Without a validated logon in this manner no user shell is created, no Explorer will run, no access to resources in the environment can take place in an authenticated user’s context. Without things being done comprehensively in that context guaranteeing security for files, other objects and actions that can be done on that computer and on the network.
Of course that central repository is the Active Directory database. Think of this interaction as a symphony of various types of network traffic, each representing another part of the secure user logon experience our products provide which comes together as a harmonic to give to you the entire Microsoft Directory Services suite. Poetic, ain’t it?
So let’s go over a few of the types of network communication you’ll see when a domain computer starts up and a user logs on.
Finding a domain controller as the computer starts up is an important piece of things. If the domain client computer doesn’t know where to send its requests then nothing else will happen well. So Microsoft client computers, when they are joined to the domain, know that they can query the DNS zone which for that domain. Service, or SRV records, will answer DNS queries from the client computer with the IP address of a server that has LDAP, GC, Time and other services based on the closest site.
User logon (and the computer being authenticated at startup) with authentication of the user in a secure encrypted manner is provided by Kerberos network traffic from workstation to domain controller. You’ll see this in UDP and TCP traffic along port 88. Most parsers filter Kerberos easily (Wireshark.exe for example will identify all such traffic by typing Kerberos in the parsing line) and in a manner that shows not just the ticket requests and responses but also the various transport protocols which negotiate using Kerberos.
User logon with roaming profiles is basically comprised of a short query to a domain controller for location and then a whole lot of SMB traffic as the files are compared with anything that is already present on the client computer and then pulled down across the network. Depending on the size of the profile, and the use of folder redirection and client side caching, that can mean a lot of traffic.
Group Policy processing will first use LDAP queries to assess all of the policies which would apply to the user (or computer earlier on) based on where the user object is located in AD and what GPOs are linked to that object. This is followed by a client side assessment of whether the user has permissions to the GPO, and if it’s got the applicable type of settings (user or computer).
There will later be group policy traffic as the settings which the GPOs are giving are passed to the appropriate client side extensions for processing (scripts, folder redirection, software installation, registry, security, disk quota, EFS, Internet Explorer, and IP Security). These various CSEs, if they are going to process based on whether the GPOs say they should and if they haven’t already, will each use their own types of network traffic based on the remote resources they need to connect to in order to get their job done. Here’s a little not-so-secret: CSEs have their own logging to see what’s happening under the hood.
For Windows Server 2003, XP and 2000 you could see this on the client computer, with time indices, in the userenv log if you had it enabled. This was a pretty comprehensive way to see all that was happening on the client computer and when used in conjunction with a network trace you can really have a good understanding of what is happening on your client computer at computer startup or user logon. Let me confess, ahem, that Windows Vista and Server 2008 have this logging as well but it is not as easy for you, the customer, to gather useful data from it. That’s a topic for another day, but rest assured that Microsoft support is there for you to help glean data from it when needed.
Finally, let me end this diatribe by bringing some relevant links that may be useful to you when it comes to understanding and troubleshooting user logon…
How to enable user environment debug logging in retail builds of Windows
http://support.microsoft.com/kb/221833
Troubleshooting Group Policy Client-Side Extension Behavior
http://support.microsoft.com
/kb/216358
And one of my favorite articles that is still largely applicable even in newer operating system releases:
Windows 2000 Startup and Logon Traffic Analysis
http://www.microsoft.com/technet/prodtechnol/windows2000serv/deploy/confeat/w2kstart.mspx
