24

As I was putting together a presentation for beginning Windows administration, I was struck with a question that I'm amazed I haven't asked sooner.

I know that:

  • AD is logically setup in sites to aid in replication and decreasing the latency of domain-necessary communications between client computers and domain services.
  • Sites are defined by the subnets applied to them
  • the _msdcs subdomain contains a hierarchy of SRV records for general lookup (_tcp) and for site-specific lookup (_sites)
  • Computers somehow know what site they are in, or the domain controller decides transparently in some magic of DNS... or does it?

This blog post hints that client computers in an AD network can "know" what site they are a member of. My question is, if this is the case, how do they find it out?

If the client itself doesn't know, how does the DC aid the machine in the process of selecting the closest AD services to that client computer?

Improve this question

2 Answers 2

Reset to default
34

The answer is that the first time a client ever authenticates to Active Directory, it doesn't know what site it is in.

When first joining the domain, the client makes general DNS and LDAP queries and gets a list of all the domain controllers in the domain, and it goes down the list, trying LDAP binds, and the first successful DC that it binds to - that is the first DC it authenticates with.

After the client has joined the domain, Active Directory will tell the client which site it belongs to. Active Directory knows this because the administrator has put the IP subnet of the client in AD Sites & Services and associated it to a Site.

Active Directory tells the client what its AD site is, and the client stores that in its own registry in the HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName registry value. That way, the next time the client boots up, it knows what site-specific DNS query to make so that it gets only the DCs that are in that site.

Of course the full behavior is documented in KB247811, but if you want to see it for yourself, you could run Wireshark or NetMon and do a packet trace, and then join a domain while the trace is running. You will see the exact sequence of DNS queries and LDAP binds. Subsequent DNS queries and LDAP binds are made to the site-specific sub-zones because the client has been told by AD what site it belongs to.

The Netlogon service will periodically refresh its AD site info, so if you move to a different network, your client will get its new site automatically. This can be adjusted in the HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SiteNameTimeout registry value. (Link)

Improve this answer
5
  • GAH! You beat me to it!
    – MDMarra
    Commented Mar 11, 2013 at 2:58
  • 4
    @MDMarra It's a rare occurence mister.
    – Ryan Ries
    Commented Mar 11, 2013 at 3:00
  • Out of curiosity, is the netlogon check ever re-done? For instance, what if I had a system that was in Site1 and then moved the person and equipment to Site2, would the machine still identify and continue to talk to Site1?
    – Peter Grace
    Commented Mar 11, 2013 at 16:34
  • Actually I take that back. Netlogon can update the dynamic site name without restarting: technet.microsoft.com/en-us/library/cc958488.aspx
    – Ryan Ries
    Commented Mar 11, 2013 at 16:59
  • @RyanRies if you'd like to pop that into your answer text, that'd be awesome, otherwise I'll edit the answer to incorporate it.
    – Peter Grace
    Commented Mar 11, 2013 at 19:37
8

There actually several inter-related functions/API's. Even though they are long, it's actually some of the more interesting Active Directory reading.

Regardless of the explanation below, there are two things that you need to be aware of:

  • If a DC in the local site does not respond for any reason, it is expected that the client will contact any domain controller in the domain. This is normal, and it's always been the default behavior. Sometimes it is not apparent why it is occurring.

  • That can be suboptimal. Consider the following scenario: Three sites: New York City ( hub/datacener - fast), Los Angeles (spoke to NYC - fast), and Kazakhstan (spoke to NYC - definitely not fast). If your client in the LA site cannot contact it's local DC for whatever reason, it's not inconceivable that it will authenticate with Kazakhstan.

There are a couple of solutions. You can do either or both.

  • Microsoft created the Group Policy/registry setting aptly named TryNextClosestSite. That means the LA client should try NYC before roaming the planet looking for DC's. Brilliant! It took eight years, but we finally got that with Vista/2008. Remember, not enabled by default, you need to create a GPO to enable this.

  • For spoke sites where you really don't want that DC to serve clients in other sites, you can create a Group Policy/registry setting that specifies which DNS records should not be registered. This is referred to as DNS Mnemonics.

Finding a Domain Controller in the Closest Site (DsGetSiteName API)
http://technet.microsoft.com/en-us/library/cc978016.aspx

Mapping IP Addresses to Site Names

"During Net Logon startup, the Net Logon service on each domain controller enumerates the site objects in the Configuration container. Net Logon on each domain controller is also notified of any changes made to the site objects. Net Logon uses the site information to build an in-memory structure that is used to map IP addresses to site names.

"When a client that is searching for a domain controller receives the list of domain controller IP addresses from DNS, the client begins querying the domain controllers in turn to find out which domain controller is available and appropriate. Active Directory intercepts the query, which contains the IP address of the client, and passes it to Net Logon on the domain controller. Net Logon looks up the client IP address in its subnet-to-site mapping table by finding the subnet object that most closely matches the client IP address and then returns the following information:

  • The name of the site in which the client is located, or the site that most closely matches the client IP address.

  • The name of the site in which the current domain controller is located.

  • A bit that indicates whether the found domain controller is located (bit is set) or not located (bit is not set) in the site closest to the client.

"The domain controller returns the information to the client. The response also contains various other pieces of information that describe the domain controller. The client inspects the information to determine whether to try to find a better domain controller. The decision is made as follows:

"If the returned domain controller is in the closest site (the returned bit is set), the client uses this domain controller.

"If the client has already tried to find a domain controller in the site in which the domain controller claims the client is located, the client uses this domain controller.

"If the domain controller is not in the closest site, the client updates its site information and sends a new DNS query to find a new domain controller in the site. If the second query is successful, the new domain controller is used. If the second query fails, the original domain controller is used.

"If the domain that is being queried by a computer is the same as the domain to which the computer is joined, the site in which the computer resides (as reported by a domain controller) is stored in the computer registry. The client stores this site name in the DynamicSiteName registry entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ Netlogon\Parameters. Therefore, the DsGetSiteName API returns the site in which the computer is located."

DsGetDcName function
http://msdn.microsoft.com/en-us/library/ms675983%28VS.85%29.aspx

Types of Locators
http://technet.microsoft.com/en-us/library/cc978019.aspx

Directory Service Functions
http://technet.microsoft.com/en-us/subscriptions/ms675900%28v=vs.85%29.aspx

How DNS Support for Active Directory Works
http://technet.microsoft.com/en-us/library/cc759550%28v=ws.10%29.aspx

How to optimize the location of a domain controller that resides outside of a client's site
http://support.microsoft.com/kb/306602

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .