Client authentication happens on a DC in a different site!?

Okay, this is a request I read over and over in the Forums and the Newsgroups:

“Why is it that my clients authentication on a DC in a different site although they have a DC in their local site?”

A quite interesting variation of the question is:

“Clients don’t use the RODC to authenticate in their site. They contact a hub site DC!”

In order to understand how clients pick a Domain Controller for authentication, you need to know what the DC Locator Process is and how it works. The best explaination I’ve read so far is from Jorge (http://blogs.dirteam.com/blogs/jorge/archive/2007/07/02/dc-locator-process-in-w2k-w2k3-r2-and-w2k8-part-1.aspx).

Since the process relies on DNS, chances are that data in DNS is wrong and the client contacts the “wrong” DC based on false information. So one (common) approach to solve this issue is to check the client’s configuration and check whether it gets the correct answer from DNS. That way, we have a proof that DNS data is correct (or not).

First off, we’re calling nltest to check whether we still get the “wrong” DC advertised. We do that with

nltest /DSGETDC:<domain name>





The output should get us a list with a DC in our site. If that’s not the case (see “DC site name” and “Our site name”), then there’s probably something wrong in DNS. To be sure, we should create a DNS query using NSLookup, that matches the one client’s create upon logon. In NSLookup, first set the query type to “SRV” for SRV records (set q=SRV) and then query for site specific LDAP servers:

set q=SRV

_ldap._tcp.<site name>._sites.dc._msdcs.domain.tld





You can use the site name that you’ve already found in /DSGETDC. That’s supposed to be the client’s site. If DCs from other (close) sites register their SRV records for other sites in DNS, one of the following happened:

(1) There was no site-local DC installed before and a DC from the next closest site performed auto-site coverage (see John’s posting http://policelli.com/blog/?p=35) and ever since, the SRV record persists, probably because DNS isn’t configured to age and scavenge entries.

(2) The local site has a RODC and the next closest (cost-wise) site (from an Sites&Services standpoint) contains 2003 DCs.

Fixing (1) involves checking the correct DNS zone and its subfolders. For example:





You see that there are DCs from other sites registered. The quick fix is to delete the SRV records you don’t want there. That won’t help you if the DC that registered them thinks that’s correct – it’ll just re-register them. But at least you have the evidence that, if it re-registers them, there’s something wrong with your “AD Sites and Services” configuration and you need to give that a closer look.

Fixing (2) isn’t as easy. Since Windows Server 2003 was built before the introduction of RODCs in Server 2008, they simply don’t know that RODCs exist. When looking for DCs in the RODC-site, they don’t query for a RODC presence and therefore register their SRV records for the site – just to make sure clients in that site have a DC to authenticate.

There are potential fixes for this:

Deploy the RODC compatibility pack on the 2003-DCs in the hub site: http://support.microsoft.com/kb/944043 (Issue 10)

Migrate all 2003-DCs to Server 2008 (R2) – probably not an option

Disable automatic site coverage on the 2003-DCs in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters, create a new DWORD “AutoSiteCoverage” and set it to 0 to disable it – not an option to, as that would mean that _all_ site coverage for other sites is disabled, too.

That leaves you with the RODC compatibility pack that, besides the auto-coverage-issue fixes a bunch of other issues, too.

Pls refer to http://www.frickelsoft.net/blog/?p=270