Not all interactions between two machines within an AD infrastructure are as complicated or lengthy as the process I've described. Although this process seems fairly involved, the interaction results in a small number of network packets. On my network, the workstation processed three to four GPOs; a typical startup sequence involved about 300 packets and took approximately 35 seconds to complete. If I enabled NetBIOS on the client (but not the server), the packet count increased by approximately 80. This count was the result of additional NetBIOS-related services, including WINS lookups, machine registrations in WINS and registration with the browser service, and SMB sessions that used TCP port 139 in addition to port 445. Nevertheless, the overall delta between pure IP and NetBIOS/TCP was less than I would have expected.
We've covered the process a workstation or member server uses to boot and authenticate to an AD domain, and you can use this information for troubleshooting. For example, suppose you find that your workstations are registering in the wrong AD site. Using the list of DCs obtained in Step 2, you can verify entries in the DNS server, your AD sites, and the registry to figure out what's happening. Similarly, suppose some member servers on a network that has a secure demilitarized zone (DMZ) are having trouble authenticating with an AD domain in the trusted network. You can use the information in the trace to determine which ports and protocols need to pass through your firewalls so that authentication can be successful.
DC-to-DC Synchronization
Now, let's look at the replication process between two AD DCs. This process is less complicated than the logon process but still provides some interesting observations. Again, I disabled all NetBIOS traffic, so the process I describe is pure IP-based DC synchronization. Also, I used DCs on different sites, and I used the ReplMon utility from the Win2K Support Tools to force intersite replication.
First, let's review a couple of concepts. Win2K uses two protocols to support intersite AD synchronization. You can use RPC over TCP/IP for both intra- and intersite replication, or you can use SMTP for intersite replication. My network uses RPC over TCP/IP; I didn't enable SMTP replication. Also, keep in mind that one AD connection object performs one-way pull replication. For example, if a connection object goes from DC1 to DC2, DC2 will pull data from DC1 during replication.
With that groundwork, let's look at what a replication event looks like on the network. Let's assume that DC2 has a one-way replication connection from DC1. So, if I add a new AD object on DC1, during the next intersite replication, DC2 will initiate the replication event and pull the new information from DC1.
- First, DC2 gets the appropriate Kerberos tickets so that it can authenticate to domain resources, specifically DC1. Because DC2 is a DC and runs the Kerberos Key Distribution Center (KDC) service, it can get a valid Kerberos ticket for the domain without venturing onto the network.
- DC2 then makes a DNS request to its DNS server to locate a Service Principal Name (SPN) entry for DC1. The entry, which looks like a GUID followed by a DNS name (e.g., db4dd6e7-9b40-4c97-83f5-6e68b1ebcf47._msdcs.mycompany.com), is unique for each server and isn't the same as the object GUID by which AD identifies the server. An SPN is what the name implies—it identifies a service running on a system. The DNS server returns the name of the server referred to by this SPN (the SPN is a DNS alias to the corresponding server), in this case DC1.
- Next, DC2 makes an RPC port mapper request (TCP port 135) to DC1 to start an RPC communication.
- DC2 gets a response from DC1 to the requested RPC endpoint, which in this case is for the interface GUID e3514235-4b06-11d1-ab04-00c04fc2dcd2. This GUID corresponds to the AD replicator service. DC2 returns a port (in the range above 1023) to use, and DC1 then initiates an RPC connection, with DC2 passing the Kerberos session data it retrieved in Step 1 to DC1.
- DC1 and DC2 then exchange a set of RPC requests and responses to replicate the directory data from DC2 to DC1. This traffic is encrypted, so you can't directly view the directory data as it's updated. Figure 3 shows proof of a replication event in a directory services event-log entry. This log entry shows a new user object called Jane Finance being created on the destination server. To view such verbose AD replication logging, you need to enable it on your DC's registry. (For instructions, see the Microsoft article "How to Enable Diagnostic Event Logging for Active Directory Services," http://support.microsoft.com/?kbid=220940.)
DC replication is simple and to the point. For this article, I created new users and groups and added a new user to a new group. I also ran several password-reset scenarios. In all cases, the interchange between DCs involved no more than 40 packets and about 15KB of data on the network.
This article looked at two AD network interactions that systems administrators are likely to encounter on a daily basis. Armed with this information, you can troubleshoot problems with DNS name resolution and protocol transport through firewalls and ensure that your infrastructure has everything it needs for fast and efficient data interchange.
End of Article
Prev. page
1
[2]
next page -->
