(2011-01-27) DC Locator – What Does "NO_CLIENT_SITE" Mean In Netlogon.log

When your DCs are logging the "NO_CLIENT_SITE" warning in the NETLOGON.LOG file, it depends on whether you can/should ignore it or not. I will explain the reason through examples by how it works and also the reasoning of why you can ignore it or not.

WHY THE "NO_CLIENT_SITE" ERROR OCCURS…..

When a computer is domain joined it knows for sure of which AD domain it is a member. A domain joined computer may or may not know the AD site it is in. Even if it thinks it knows the AD site, it may not even be in the correct AD site (e.g. because it was moved, or AD site was renamed, etc.). For the remaining part of the text I will just mention "computer" instead of domain joined computer.

Now, the following steps will be taken when the computer starts/boots and:

1. It DOES know the AD site it is in:
   
   1. It queries DNS with "_ldap._tcp.<SITE NAME>._sites.dc._msdcs.<FQDN AD DOMAIN>"
      
   2. DNS returns a list of DCs that have registered the site-wide SRV records for <SITE NAME> (By default this will be done by the RWDCs/RODCs in that AD site OR if the site has no DC, it will be done by RWDCs covering that AD site. How site coverage works can be read here – "Site Coverage Algorithm" section/paragraph.)
      
   3. The computer contacts the first DC (RWDC/RODC) (through LDAP ping, UDP:389) and does whatever it needs to do. It moves to the next DC, when the previous does not respond and if another DC exists. When there are no more site specific DCs, it performs the steps in [2]
      
   4. Based upon the IP Address of the computer (and without using its subnet mask!), the RWDC/RODC will check if it can match the IP address of the computer to an AD subnet (as specific as possible).
      
      1. Assuming the RWDC/RODC can match the IP address to an AD subnet and the AD subnet is linked to an AD site, the RWDC/RODC will tell the computer in which AD site the computer is in, in which AD site the RWDC/RODC is in and the "close proximity bit" specifying if the RWDC/RODC is in the same AD site as the AD client.
         
      2. If the RWDC/RODC cannot match the IP address of the computer to an AD subnet OR if it can match the IP address to an AD subnet but the AD subnet is not linked to an AD site (in this case the AD client moved to a new AD site, got a new IP address, but the AD subnet was not defined yet or the AD subnet was not linked to an AD site), the RWDC/RODC will then service the computer AND log the error "NO_CLIENT_SITE" in the NETLOGON.LOG file (C:\Windows\Debug). In the case of an RODC, it that RODC does not have the password cached of the computer, the RODC will then forward authentication to the RWDC with which the RODC has setup the secure channel
         
2. It DOES NOT know the AD site it is in, OR site specific DCs are not responding
   
   1. It queries DNS with "_ldap._tcp.dc._msdcs.<FQDN AD DOMAIN>"
      
   2. DNS returns a list of DCs that have registered the domain-wide SRV records for <FQDN AD DOMAIN> (By default this will be done by all RWDCs in the AD domain. In scenarios where datacenters are used with branches, it is a best practice to configure RWDCs in the branches not to register domain-wide SRV records. RODCs do not register domain-wide SRV records by default, and again by default register only the site-wide SRV records and also do not perform automatic site coverage.)
      
   3. The computer contacts the RWDC (through LDAP ping, UDP:389).
      
   4. Based upon the IP Address of the computer (and without using its subnet mask!), the RWDC will check if it can match the IP address of the computer to an AD subnet (as specific as possible)
      
      1. Assuming the RWDC can match the IP address to an AD subnet and the AD subnet is linked to an AD site, the RWDC will tell the computer in which AD site the computer is in, in which AD site the RWDC is in and the "close proximity bit" specifying if the RWDC is in the same AD site as the AD client. Assuming it can match the IP address to an AD subnet and the AD subnet is linked to an AD site, the RWDC will tell the computer in which AD site the computer is in, in which AD site the RWDC is in. The computer will then repeat the process as specified in option [1] above.
         
      2. If the RWDC cannot match the IP address of the computer to an AD subnet OR if it can match the IP address to an AD subnet but the AD subnet is not linked to an AD site, the RWDC will then service the computer AND log the error "NO_CLIENT_SITE" in the NETLOGON.LOG file (C:\Windows\Debug)
         

When a user then logs on to the computer, the AD domain information and the AD site information known to the computer will be used to find a DC and authenticate the user. So if the computer knows in which AD site it is in, to authenticate the user it will query DNS with "_ldap._tcp.<SITE NAME>._sites.dc._msdcs.<FQDN AD DOMAIN>" and follow the steps as specified above in [1].

The steps above apply for authentication WITHIN the same AD forest and also BETWEEN AD forests or BETWEEN AD domains in different AD forests.

The following two scenarios exist, for which the steps are very very similar:

• User is logged on to computer in the same AD domain as the user and the user wants to access a resource in a different AD forest/domain (over an AD Forest Trust or an AD External Trust)
  
• User from one AD domain is logging on to a computer in another AD domain (over an AD Forest Trust or an AD External Trust)
  

Taking the first scenario as an example. When a user is logged on to the computer and the user wants to access a resource in another AD forest, it will query DNS with the following query: "_ldap._tcp.<SITE NAME>._sites.dc._msdcs.<FQDN OTHER AD DOMAIN>". Although it uses the FQDN of the AD forest the resource is in, it will use the AD site of the computer it is logged on to. If the AD site also exists in the other AD forest, then the steps as mentioned in step 1 will be used. If the AD site does not exist in that other AD forest, then the steps as mentioned in step 2 will be used, but then using <FQDN AD OTHER DOMAIN>. However, step 2d will be a little bit different. Based upon the IP address of the computer the RWDC of the other AD forest/domain will check if it can match the IP address of the computer to an AD subnet (as specific as possible) in the other AD forest .

[.A.] Assuming it can match the IP address to an AD subnet in the other AD forest and the AD subnet is linked to an AD site in the other AD forest, the RWDC will tell the computer in which AD site the computer is in in the other AD forest, in which AD site the RWDC is in and the "close proximity bit" specifying if the RWDC is in the same AD site as the AD client. The computer will then repeat the process as specified in step [1] above, but using the AD site in the other AD forest, OR…

[.B.] If the RWDC in the other AD forest cannot match the IP address of the computer to an AD subnet in the other AD forest OR if it can match the IP address to an AD subnet in the other AD forest but the AD subnet in the other AD forest is not linked to an AD site in the other AD forest, the RWDC will then service the computer AND log the error "NO_CLIENT_SITE" in the NETLOGON.LOG file (C:\Windows\Debug).

Within the same AD forest, if you get the "NO_CLIENT_SITE" error, it is not recommended to ignore this. To get rid of these errors make sure an AD subnet exists and that it is linked to an AD site. However, between AD forests it is very likely that this error occurs because the AD subnet structure and/or the AD site structure is different. Even if a match can be made, it may not even be the most optimal one to use. as the meaning of each AD site may be different. If you can ignore these errors or not between AD forest depends on the specific scenario.

–

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/ ########
———————————————————————————————