Active Directory Naming Information Could Not Be Located Because…

Sometimes when you open an Active Directory tool, you might get hit with the “Active Directory Naming Information Could Not Be Located” error message. The error does not provide more information as to what “Naming Information” the tool is referring to. And also, there’s nothing in the event logs to let you know more about the error so you can troubleshoot the issue. What you may not know is, there is a process which active directory tools or utility have to follow to contact a domain controller to get the naming information for an active directory domain. I’ll explain this process in this blog post.

The following active directory tools will throw this error message:

  • Active Directory Users and Computers
  • Active Directory Trusts and Domains
  • Active Directory Sites and Services
  • Schema Admin
  • ADSIEdit tool
  • Group Policy Management Console (GPMC)
  • NTDSUTIL tool
  • All Active Directory DS Tools (DSQuery, DSMod, DSGet, DSAdd, and so on)
  • Domain Controller Diagnostic tools such as DCDiag, Repadmin, etc.

The above mentioned active directory tools, when opened, will try to contact an available domain controller for fetching Active Directory database (NTDS.DIT) and displaying the database information in the tool’s console. In a nutshell, the query to find an available domain controller is sent to the DNS Server which is configured in the TCP/IP property of the local machine. Any active directory tool written must initiate two operations; (1) connecting to a DNS Server to get a list domain controllers and (2) connecting to a domain controller from the list to populate the NTDS database information in the consoles. There are several other steps performed as part of these operations which are explained a little later.

Based in the TCP/IP configuration on the local machine, an active directory tool will use one of two calls; RPC or LPC. Remote Procedure Call (RPC) is initiated when connecting to the “DNS Server” service on the remote computer. On the opposite side, Local Procedure Call is used if the connection needs to be made with the “DNS Server” service running on the local computer. In any case, the DNS Server should be able to return a list of domain controllers the tools can use to connect to and populate the Active Directory database (NTDS) in the console. You will receive the above error message if tool is not able to perform these two steps successfully.

To explain the steps in more detail, the active directory tools will take the following actions:

  1. An active directory tool calls the DC Locator component to find an available domain controller.
  2. DC Locator executes “DcGetDCName” API call.
  3. As part of the “DcGetDCName” API call, the following actions are taken:
    1. Build a DNS Query to be sent out to DNS Server. There are two types of DNS queries “DC Locator” component can build and send; “Site-Specific DNS Query” and “Global DNS Query“.

To build the DNS Query, DC Locator component uses the following strategy:

                                                                                  i.       Checks to see which active directory site the local computer belongs to by querying the DynamicSiteName registry entry at “HKLM\System\CurrentControlSet\Services\Netlogon\Parameters” key.

                                                                                ii.       If registry is found then build the DNS Query with site name added to it.

                                                                              iii.       If this is the first attempt by the tool to get a list of domain controllers from DNS Server, or if local computer does not have the DynamicSiteName registry entry created, then build a general DNS Query to find domain controllers.

  1. Based on the above results, DC Locator builds the DNS Query and sends out it to DNS Server to find a list of domain controllers.
  2. DNS Server receives the query and responds back with a list of domain controllers.
  3. DC Locator receives the list and pings to make sure domain controller is available and contactable.
  4. If the domain controller is available, allow the active directory tools to execute other calls to connect to the active directory database to be displayed in the tool’s console.
  5. DC Locator stores the site information for the computer in above registry entry.
  6. On the other hand, if no domain controller is available then that “error” message will be displayed.

Note: In the case of a domain controller going down for maintenance purposes, the tool will not know and will fail to connect. This was an issue with domain controllers running on Windows Server 2003 and earlier versions. The DC Locator component was improved to perform checks on domain controller’s availability in the domain controllers running on Windows Server 2008 and later versions.

There are several reasons as to why the DC Locator might fail to connect to a domain controller to get the naming information. These reasons are mentioned below:

  1. SRV records for Active directory domain controllers are not registered in the same Domain DNS Zone as the local computer.
  2. The DNS Server is not reachable for some reason.
  3. LDAP Port 389 is not opened or not listening on the destination Domain Controller.
  4. A (Host) record for Domain Controller is missing in the Domain DNS Zone.
  5. The NetLogon service on Domain Controller is not running.
  6. The local machine is pointing to the wrong DNS Server.
  7. Network port issues if local machine and DNS Server/domain controllers are located in different sites.
  8. DNS Server can’t be contacted because of network congestion.
  9. DNS Servers or Domain Controllers are heavily loaded.

As discussed above, for any Active Directory tool to successfully populate the NTDS information in the console, they need to call DcGetDCName API call. This API function is responsible for gathering the list of available Domain Controllers for a domain from the DNS Server. DNS Server returns this list from the Domain DNS Zone in which all the domain controllers have registered their presence in the form of SRV records. These SRV records are registered with specific network port numbers for each domain controller providing that service. For example, a SRV record for a domain controller is registered in DNS Domain Zone which provides LDAP services (authentication) to the network applications.

There are two places in the DNS Server in where a domain controller must register its SRV records:

  • _TCP.SiteName._Sites.DomainDNSZone.
  • _TCP.DomainDNSZone

“_TCP.SiteName._Sites.DomainDNSZone” folder contains the SRV records for all the domain controllers in that domain as shown in the screenshot below: This folder is queried by the DNS Server to return a list of domain controllers in the site specified by the “DC Locator” component when executing “Site-Specific DNS Query” as discussed above.

Figure 1.0 – Site Specific SRV records registered by Domain Controllers

On the other hand, “_TCP.DomainDNSZone” folder contains the SRV records for all the domain controllers in the active directory forest as shown in the below figure 1.1. This folder is queried by the DNS Server to return a list of domain controllers in the active directory forest specified by the DC Locator component when executing “Global DNS Query”.

Figure 1.1 – Global SRV records registered by Domain Controllers

No “Naming Information” failure can happen due to a fault with a single component. The error must happen somewhere within the process which doesn’t allow the active directory tool to conntect to a domain controller. The error message is still vague, but if you encounter it now, I hope this post will help point you in the direction of where to look to solve it.