When you open tools such as Group Policy Management or AD Users and Computers, it might happen that these tools do not find the domain. Network problems in general and DNS problems in particular are almost always responsible for this. The IPv6 configuration plays a special role here.

If you are confronted with the message that a program cannot connect to the domain, you should first rule out a few obvious causes. This includes checking the availability of a domain controller, for example, with ping.

Management tools such as the Group Policy Management Console will report an error if no DC is reachable

Management tools such as the Group Policy Management Console will report an error if no DC is reachable

If the DC is accessible, then take a look at the hosts file to see whether there is an invalid entry for the domain or a DC. If everything is okay so far, then you should turn your attention to the DNS configuration.

Check the DNS server

A common cause of connection problems to a DC is that an invalid (public) DNS server has been assigned to the computer. This then lacks the SRV entries for the Active Directory DCs.

Using the following command, your first step can be to verify whether the name of the domain can be resolved:

Test-NetConnection -TraceRoute <name-of-domain>
If the name of the domain cannot be resolved this indicates an incorrect DNS configuration

If the name of the domain cannot be resolved this indicates an incorrect DNS configuration

If this test fails, you can use nslookup to verify that the SRV entries mentioned are missing. To do so, enter the following commands:

nslookup
set type=all
_ldap._tcp.dc._msdcs.<DomainName>
quit

In the third line, you must, of course, use your own domain.

Use nslookup to look for the SRV record for the DCs

Use nslookup to look for the SRV record for the DCs

Query assigned DNS servers

If the suspicion that the client is using the wrong DNS server is confirmed, check the corresponding entry in the IP settings. You can do this with the PowerShell cmdlet

Get-DnsClientServerAddress | Format-List
or with
ipconfig /all
Display assigned DNS servers with ipconfig

Display assigned DNS servers with ipconfig

Determining the origin of the DNS configuration

If the correct DNS servers are not entered here, you now have to find out where the computer gets this configuration from. You should not only check the configuration of IPv4 but also of IPv6.

Even if the IPv4 settings are OK, the domain cannot be found if the IPv6 setting for the DNS server is invalid because Windows prioritizes IPv6 by default.

With the help of the commands

netsh interface ipv4 show dnsservers
and
netsh interface ipv6 show dnsservers

it is possible to determine whether the DNS servers were assigned manually or via DHCP.

Netsh shows whether a DNS server has been assigned manually or dynamically

Netsh shows whether a DNS server has been assigned manually or dynamically

Alternatively, the GUI for the adapter settings is also available for this purpose.

Correcting the DHCP configuration

If the manual configuration of the DNS server is incorrect, it can be corrected on the spot. If the interface obtains its settings for the DNS server via DHCP, then you should check option 006 for the relevant IPv4 scope and correct it if necessary.

Check the DNS server assignment in the DHCP options for the relevant address range

Check the DNS server assignment in the DHCP options for the relevant address range

With IPv6, the case is a bit more complicated because there, DHCP is not necessary as an alternative to a manual configuration. Instead, the IPv6 clients can create a basic configuration for themselves using stateless address autoconfiguration (SLAAC). Each host then gets the global prefix and the IPv6 address of the DNS server via the router (RDNSS option).

Especially in smaller networks, you might not want to switch to a stateful address configuration to explicitly assign the IPv6 settings to the clients. In this case, one solution is to prioritize IPv4 over IPv6.

To do so, you need to create a registry key called DisabledComponents under HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters. The easiest way to do this is to save the following code in a file with the extension .reg and execute it by double-clicking it:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters]
"DisabledComponents"=dword:00000020

Microsoft, on the other hand, advises against disabling IPv6 altogether because it could affect the functioning of the system. Prioritizing IPv4 should be sufficient to allow clients to reach a domain controller again.

Summary

In most cases, the lack of connectivity to an AD domain is due to a network problem. Once you have ruled out some simple causes, such as whether a DC is online, then you can move on to analyzing the DNS configuration.

Subscribe to 4sysops newsletter!

An incorrectly assigned DNS server without SRV records for the DCs may then prove to be the culprit. It is not enough if the IPv4 settings are OK because Windows prefers IPv6. In this case, it helps to prioritize IPv4 over IPv6.

avataravataravatar
2 Comments
  1. Vignesh Mudliar (Rank 3) 11 months ago

    Handy troubleshooting steps. Thank you!

    avatar
  2. Igor 2 months ago

    It is the PDC role holder that is a default target domain controller for Group Policy updates.
    So when we troubleshoot, we need to check for

    _ldap._tcp.pdc._msdcs. – “pdc” instead of “dc”.

    If it resolves into another server, other than your actual PDC, then that is your problem.

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2023

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account