AD Clients Not Authenticating to its Local Site

Reading Time: 2 minutes

Ever have a Branch Office or Site that has clients that doesn't authenticate to the local dc?  Adminstrators get confused and start looking at the client to try and figure out what is wrong, when it is most likely and incorrectly configured Sites and Services subnet situation.  When a workstation first logs on (Machines log onto the domain, just like users) it sends out a dns query to locate a service record of the closest DC for the subnet this workstation resides on.

There are three possible scenarios for a client to attach to a DC:

  1. The subnet that this machine resides on has been properly defined in Sites and Services
  2. The site this machine belongs to doesn't have a domain controller within its site
  3. This machine's subnet hasn't been defined in Sites and Services

There is no reason to go over scenario one, since everything is working as expected

Scenario two should be working as well, since auto site coverage was implemented in Windows 2003.  Domain Controllers should register their DNS service (SRV) records in nearby sites that contain no DC's.  This action is known as "Automatic Site Coverage" (ASC),  ASC has to factor in the link costs associated with a site to compute the cheapest route for the DC less clients with in the site.

Scenario three is a mistake in the Sites and Services defined topology by the administrator.  Although the client and Domain Controller both exist in the same subnet, the subnet hasn't been defined in Sites and Services.  Therefore when the client machine hatches the DC Locator service, the DC in the local site isn't offered to authenticate the machine or the user.  Instead a Dc from the default-site within Sites and Services is presented to the client.  Also the log file netlogon.log on the authenticating DC is updated with a line noting the missing subnet.  I check this log file weekly to verify that our network crew didn't add any new subnets without our group being notified.

Just run the following from a command prompt on your default-site DC's to see if there are any undefined subnet's:

notepad.exe %systemroot%\Debug\Netlogon.log

You will need to examine each DC to verify that all your sites are defined.

To clear out this log, the NetLogon service needs to be stopped before saving it.

Best Practices – Sites and Services
http://technet.microsoft.com/en-us/library/cc755768(WS.10).aspx

Want to know which site a computer think it belongs to?  Check the registry value at:

HKLM\System\CurrentControlSet\Services\Netlogon\Parameters\DynamicSiteName\

For complete details check out the following URL:
http://blogs.technet.com/b/askds/archive/2008/09/24/domain-locator-across-a-forest-trust.aspx