Jorge's Quest For Knowledge!

All You Need To Know About Identity And Security On-Premises And In The Cloud. It's Just Like An Addiction, The More You Have, The More You Want To Have!

(2007-06-30) DC Locator Process In W2K, W2K3(R2) And W2K8 – PART 1

Posted by Jorge on 2007-06-30


This is the 1st part of "DC Locator Process in W2K, W2K3(R2) and W2K8"

By default a client that knows in what AD site it is in, will ask for a DC in that same site by querying DNS with:

  • _ldap._tcp.<SITE>._sites.dc._msdcs.<DOMAIN>.<TLD>

By default all DCs in AD site <SITE> will register that DNS SRV record. If no DCs are in that AD Site, the DCs in the nearest AD site will cover that AD site by registering their records in the DC-less AD site. The DCs in the site list are in a random order and provided by the DNS round robin mechanism.

If a client does not know in what site it is in, it will ask for a DC in that same domain by querying DNS with:

  • _ldap._tcp.dc._msdcs. <DOMAIN>.<TLD>

By default all writable DCs in AD domain <DOMAIN> will register that DNS SRV record. The writable DCs in the domain list are in a random order and provided by the DNS round robin mechanism. Read-Only DCs (RODCs) in Windows Server 2008 will not register domain-wide SRV records. RODCs only register SRV records for the AD site they are in.

To determine the AD site of a client:

  • NLTEST /DSGETSITE

To determine a DC within a set of DC of DCs in the client’s AD site that could authenticate/service the client:

  • NLTEST /DSGETDC:<FQDN DOMAIN>

So if you look at the situation where a client queries for a DC in the domain because it does not know in what AD site it is in, it can be somewhat interesting when you find out the client is communicating with some DC on the other side of the world. Not really efficient! In HUB and SPOKE environments this can be a problem. It can be really annoying when some client in branch office X is authenticating to a DC in branch office Y, while then WAN links between both branch offices (SPOKES) and the datacenter (HUB) are not that fast. To prevent that situation, it is a best practice to allow the DCs in the datacenters (HUB) register whatever SRV record and allowing the DCs in the branch offices (SPOKES) to register only their site specific SRV records. That way when a client queries for a DC in the domain it will be serviced by one of the DCs in the datacenter (HUB) and NOT in some branch office far far way!

This same situation occurs when a client is joined to the domain using the GUI. At that moment the client does not know its site and it will thus query for A DC in the domain to create its computer account. Guess what, after the clients reboots you might experience authentication problems because the computer account was created at a DC in branch office X while the client is in branch office Y. The issues will go away as soon as the computer account replicates from branch office X to the datacenter and from the datacenter to branch office Y. How long that takes depends on your AD site and replication topology. By using the configuration explained above, the computer account will be created on a DC in the datacenter. That way it only needs to replicate from the datacenter to the branch office. To target the correct AD site where the client will based it is better to use the command-line tool NETDOM. Using that command-line tool you can specify a DC in the AD site where the client will based AND you can specify in what OU the computer account should be placed. The syntax is:

  • NETDOM JOIN %COMPUTERNAME% /DOMAIN:<DOMAIN><DC> /OU:<distinguished name of OU> /USERD:<DOMAIN><USER> /PASSWORDD:<PASSWORD>
    • REMARK: I specify %COMPUTERNAME% instead of the computername because this command needs to be executed locally on the client/server that needs to be joined to a domain

Because DCs by default register all SRV records, you need to configure the branch office NOT to register certain records. W2K DCs do not have a GPO setting to do the configuration, so you need to configure the registry locally. To prevent that you can still create your own ADM file. W2K3 DCs do have a special GPO setting to make the configuration.

To Configure Domain Controllers or global catalogs to Not Register Generic (domain wide) Records

  • For W2K DCs
    • Registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
    • Registry value name: DnsAvoidRegisterRecords
    • Registry value type: REG_MULTI_SZ
    • Registry value data: <list of ENTER-delimited mnemonics>
  • For W2K3(R2)/W2K8 DCs and later:
    • GPO setting path: "Computer Configuration\Administrative Templates\System\Net Logon\DC Locator DNS Records"
    • GPO setting: "DC Locator DNS records not registered by the DCs"
    • GPO setting mode: Enabled
    • GPO setting value: <list of SPACE-delimited mnemonics>

List of "mnemonics" that should not be registered by branch office DCs:

  • Dc
  • DcByGuid
  • Gc
  • GcIpAddress
  • GenericGc
  • Kdc
  • Ldap
  • LdapIpAddress
  • Rfc1510Kdc
  • Rfc1510Kpwd
  • Rfc1510UdpKdc
  • Rfc1510UdpKpwd

UPDATE:

If you have configured your branch office DCs to not register domain-wide specific records, the clients will use those DCs and fail over to the datacenter if the local DC becomes unavailable. However if the local DC comes back online the client keeps using the datacenter DC until the client is restarted or the datacenter DCs become unavailable for some reason. Apparently it does not rediscover its local DC is available again. MS-KBQ939252 provides a hotfix and registry configuration for Windows XP (SP1 & SP2) and Windows Server 2003 (SP1 & SP2). The registry configuration is the ability to configure a discovery interval for the locator process. Make sure you also see MS-KBQ247811, as there it mentions: "After the client locates a domain controller, the domain controller entry is cached. If the domain controller is not in the optimal site, the client flushes the cache after fifteen minutes and discards the cache entry. It then attempts to find an optimal domain controller in the same site as the client."

Continued in part 2 of the "DC Locator Process in W2K, W2K3(R2) and W2K8"

For additional information, make sure to have a look at:

Additional interesting links:

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER:
https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
#########
http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

6 Responses to “(2007-06-30) DC Locator Process In W2K, W2K3(R2) And W2K8 – PART 1”

  1. Hello Jorge,
    First, Happy Aniiversary ! :o)
    Second. There is one thing i do not understand.
    In MS-KBQ247811 that applies to w2k only, the rediscovery process seems to be smarter than w2k3 in the way that w2k3 is unable to proceed to the rediscover process, w2k does.
    Is this true ? Will the w2k3 has lost this functionnality ?
    Thx for clarification,
    Yann

  2. Hi,

    Does the client check if the DC is online when DNS responds with a DC name?

    Thanks.

  3. Jorge said

    yes, through LDAP PING

  4. Excuseme but NETDOM use NETBIOS to resolve domain name?

  5. […] DC Locator Process In W2K, W2K3(R2) And W2K8 – PART 1 […]

  6. […] DC Locator Process In W2K, W2K3(R2) And W2K8 – PART 1 […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
%d bloggers like this: