Fix: Active Directory Domain Controller Could Not Be Contacted

8.4K

This guide explains how to troubleshoot and fix this domain controller connectivity issue.

What does it mean An Active Directory Domain Controller could not be contacted?

When trying to join a Windows computer to an AD domain, you may receive the error “An Active Directory Domain Controller could not be contacted“. The client may be unable to connect to the domain controller due to incorrect network settings (IP, DNS or firewall) or a domain controller failure.

Troubleshooting AD Domain Controller Connectivity

When machine joins AD domain, it goes through multiple stages:

1. DNS-based DC discovery (SRV lookup)
2. Network connectivity to the DC
3. Finally, authentication for the domain join process

This error can produce the same generic error on any stage, so the root cause is not always “DC is unreachable”. It looks like this:

An Active Directory Domain Controller (AD DC) for the domain “theitbros.com” could not be contacted. Ensure that the domain name is typed correctly.

Most common errors when client is unable to connect DC

Click the Details button to view the detailed error description. The most common errors are:

• 0x0000232B — RCODE_NAME_ERROR (“DNS name does not exist”).
• 0x0000267C — DNS_ERROR_NO_DNS_SERVER (“No DNS Servers configured for local system”).
• 0x00002746 — WSAECONNRESET (“An existing connection was forcibly closed by the remote host”).
• 0x000005B4 — ERROR_TIMEOUT (“This operation returned because the timeout period expired”). The DNS servers used by this computer for name resolution are not responding.

Basic checks to troubleshoot the issue

Here are the basic checks you should perform to troubleshoot the issue:

1. Make sure you’ve not mistyped in Active Directory domain name;
2. Check the client IP and DNS settings;
3. Verify the network connectivity to the DC;
4. Check the DC health.

Check the Network Connectivity to the AD Domain Controller from Client

The client Windows machine can connect to the Active Directory if it has properly configured IP address and preferred DNS server set. Open the PowerShell console to perform basic network connection troubleshooting.

Try to resolve the Active Directory domain name and verify its DNS address records:

Resolve-DnsName theitbros.loc

This returns the DNS address records found for the name, including A (IPv4) and AAAA (IPv6) records when they exist. To check a specific record type, query it explicitly:

Resolve-DnsName theitbros.loc -Type A
Resolve-DnsName theitbros.loc -Type AAAA

In case you are facing a “DNS name does not exist” error, you need to check if the client is using internal AD DNS servers and is able to resolve both A records and SRV records for the domain. Note that the issue is not always caused by incorrect DNS IP settings. The problems can be related to missing SRV records, incorrect DNS suffix config, or use of external DNS servers.

The error is not always caused by incorrect DNS server IP config. It may also be caused by:

• Missing/broken SRV records in AD DNS zone
• Incorrect DNS suffix/search list config
• Multiple network adapters sending queries to wrong DNS servers

To list the client DNS config use the command:

Get-DnsClientServerAddress

Use the following commands to check the client’s IPv6 config, default gateway, and DNS servers (you need to pay particular attention to unexpected IPv6 addresses or DNS config on VPN, virtual, or additional network adapters):

Get-NetIPConfiguration

and

Get-NetIPAddress -AddressFamily IPv6

The client must use DNS servers that can resolve the Active Directory DNS namespace and the required AD SRV records. In many environments, these are DNS services running on DCs. You need to check both IPv4 and IPv6 DNS server config when using a dual-stack network. If the public (such as 8.8.8.8 or 1.1.1.1) or non-existent DNS server IP is specified here, change the preferred DNS server in the network adapter properties (ncpa.cpl > Network Adapter Properties > IPv4 Properties > Manually set your DC’s IP address as preferred DNS).

Ensure that there are no manually entered (static) entries in the hosts file for your domain or domain controller names. If there are any such entries, delete them.

get-content C:\Windows\System32\Drivers\etc\hosts

Note. The hosts file does not affect SRV record resolution used for Active Directory DC discovery. However, it can override A/AAAA name resolution (this may cause clients to connect to incorrect IP addresses even when SRV lookup succeeds).

Now clear the DNS resolver cache on the computer:

ipconfig /flushdns

Check you can ping the DC by an IP address:

ping 192.168.158.100

In case you have dual-stack environment, you should also verify IPv6 connectivity to the DC (a successful IPv4 test does not rule out IPv6-related DNS or connectivity problems)^

ping -6 <IPv6-address-of-DC>

If the destination IP is unreachable, check that the computer’s IP address belongs to your AD network:

• If the computer obtains network configuration from a DHCP server, try to renew the IP settings with the commands:
  

  ipconfig /release
  ipconfig /renew

• If you have a static IP address, contact your network administrator to check your current configuration.

After configuring the client’s network settings correctly, make sure you are able to resolve the AD name.

Resolve-DnsName theitbros.loc

Check both A and AAAA records when IPv6 is enabled (an unexpected or unreachable AAAA record can cause clients to attempt communication over IPv6 even when IPv4 connectivity is working):

Resolve-DnsName theitbros.loc -Type A
Resolve-DnsName theitbros.loc -Type AAAA

Ping the domain:

ping theitbros.loc

And discover the AD services in the domain (according the Active Directory sites and services configuration):

nltest /dsgetdc:theitbros.loc

In case the machine was previously joined to the domain and now cannot communicate with the domain correctly, you need to check the domain secure channel. A broken secure channel can occur when the computer’s machine account password is out of sync with the password stored in AD.

Test-ComputerSecureChannel -Verbose

If the command returns False, the secure channel is broken.

To repair the secure channel, run the PowerShell command as Administrator:

Test-ComputerSecureChannel -Repair -Verbose

Alternatively, you can reset the computer’s machine account password against a specific DC:

Reset-ComputerMachinePassword -Server "dc01.contoso.com" -Credential (Get-Credential)

Important. Secure-channel troubleshooting applies to machines that are already joined to the domain. It does not fix a failure during the initial domain join, because a secure channel has not yet been established.

Firewalls can block communication between the client and the DC. On Windows DCs, you should prefer the built-in Windows Defender Firewall rules for Active Directory Domain Services when appropriate instead of manually creating individual port rules. Manual port config may still be required on network firewalls or when a specific environment requires a restricted rule set.

In order to enable the built-in Windows Defender Firewall rules for Active Directory Domain Services on a Windows Server DC, run PowerShell as Administrator:

Enable-NetFirewallRule -DisplayGroup "Active Directory Domain Services"

The command above enables the predefined firewall rules included with Windows Server instead of requiring admins to create individual inbound rules for each AD DS port.

Important. The command mentioned above applies to the local Windows Defender Firewall on the server where it is executed. Keep in mind that it does not config network firewalls, VPN firewalls, or firewalls on other hosts. You should review the existing rule state and security baseline before enabling firewall rules, especially when firewall config is managed through Group Policy, Intune, or another centralized management platform.

The following ports are commonly required for a standard AD domain join (additional ports may be required depending on the AD services, authentication methods, management tools, and legacy protocols used in your environment):

• TCP/UDP 53 — DNS traffic;
• TCP and UDP 88 — Kerberos authentication;
• TCP/UDP 464 — Kerberos password change (when password changes are involved);
• UDP 123 — Windows Sync time with Domain Controller;
• TCP 135 — Remote Procedure Call RPC Locator;
• TCP/UDP 389 — LDAP (unencrypted, used for domain operations and DC discovery);
• TCP 636 — LDAPS (used when secure LDAP over TLS is required);
• TCP 445 — (SMB/CIFS, Net Logon);
  Note. LDAP (389) is used in most standard AD environments. LDAPS (636) is only required when secure LDAP is enforced by policy/external integration.
• TCP 49152–65535 — RPC dynamic ports (default range on modern Windows Server; it may be customized through policy/firewall hardening);
• TCP 3268/3269 — Global Catalog (LDAP/LDAPS); required for applications and operations that query the Global Catalog, but not normally required for a standard domain join.

You may require additional ports for specific AD operations. For example:

• TCP 3268/3269 — used by Global Catalog LDAP/LDAPS;
• TCP 9389 — used by Active Directory Web Services;
• TCP 139 and UDP 137/138 — legacy NetBIOS/SMB traffic, only when required by the environment.

Note. Keep in mind that you won’t need all ports in every environment. The exact set depends on AD config, security policies, and whether legacy protocols (such as NetBIOS) are still in use.

You can use PowerShell to check for open ports. For example, check for open DNS service port 53

Test-NetConnection 192.168.1.11 -port 53

Hint. Another helpful guide that can help you troubleshoot DC connectivity over RPC is “1722 The RPC server is unavailable”.

Check LDAP Signing and Channel Binding Requirements

Note that an open LDAP port does not guarantee that LDAP communication will succeed. DCs may require LDAP signing and LDAP channel binding in hardened AD environments. In case the client does not meet these security requirements, LDAP operations can fail even when TCP 389/TCP 636 is reachable.

LDAP signing

Check the Group Policy setting Domain controller: LDAP server signing requirements by navigating to Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options. If LDAP signing is required, clients must use a compatible signed LDAP authentication method.

Checking LDAP signing

On a DC, you need to check the Directory Service event log for LDAP signing events (especially 2887, 2888, and 2889). These events can help you to identify clients using unsigned LDAP binds.

LDAP channel binding

Also don’t forget to check the Group Policy setting Domain controller: LDAP server channel binding token requirements under the same Security Options path. In case channel binding is enforced, clients and apps must support the required channel binding behavior.

You also should check the Directory Service event log for channel-binding-related events (including 3039 and 3040, when troubleshooting LDAP authentication failures).

But remember that LDAP signing and LDAPS are not the same thing. LDAP signing does not mean that clients must use TCP 636 instead of TCP 389. The required config depends on the authentication method and security policy in the environment.

Warning. Do not disable LDAP signing/channel binding as a permanent workaround! You need to identify incompatible clients and remediate them before changing security requirements in an enterprise environment.

Check for Service DNS Records in Active Directory

If the previous checks haven’t resolved the connection error to the domain controller, and similar issues persist on other devices, it’s crucial to inspect the DNS configuration in Active Directory.

Clients discover the AD controllers using the special SRV records in the Active Directory DNS zone. If such SRV records are missing, the client will not be able to contact the DC.

Run the following commands to query the LDAP SRV record:

nslookup

set type=all

_ldap._tcp.dc._msdcs.your_domain_name.com

Check that the specified DNS server has an SRV record of the following form:

_ldap._tcp.dc._msdcs.your_domain_name.com SRV service location:

Clients discover Active Directory DCs using SRV records, which return the hostname of a DC. The hostname is then resolved to an IP address using a separate A (or AAAA) DNS record:

• _ldap._tcp.dc._msdcs.your_domain.com is an SRV record, it returns the hostname of DC
• The returned hostname is then resolved through A (or AAAA) record to obtain the IP address.

Note that SRV records do not contain IP addresses (they only provide service location like hostname, port, protocol). IP resolution always happens through A/AAAA DNS records.

You can also check SRV records using PowerShell:

Resolve-DnsName -Name "_ldap._tcp.dc._msdcs.theitbros.com" -Type SRV

You can recreate the DNS record manually using the DNS manager snap-in (dnsmgmt.msc) or run the following command on the DC to recreate SRV and A records automatically:

net stop netlogon
net start netlogon
ipconfig /registerdns

Be patient for a while to allow the records to appear in the DNS and replicate across the domain.

If DNS and network are healthy but the issue persists on multiple clients, check AD replication:

repadmin /replsummary
repadmin /showrepl * /errorsonly

Then check the AD health using the dcdiag command:

dcdiag /a /q

Resolve any AD errors you’ve found. After that, you can try to join the Windows workstation to the domain.

Check Microsoft Entra ID Synchronization in Hybrid Environments

In case your AD environment is synced with Microsoft Entra ID, a successful on-premises domain join does not necessarily mean that the corresponding AD object or its attributes have already synced to Microsoft Entra ID.

Microsoft Entra Connect Sync/Microsoft Entra Cloud Sync can have separate sync, scoping, connectivity, or AD replication issues. You should investigate these problems separately after confirming that the client can successfully locate and communicate with an on-premises DC. We recommend troubleshooting sync from the on-premises AD through the sync engine and finally to Microsoft Entra ID.

Microsoft Entra Connect Sync

In case the environment uses Microsoft Entra Connect Sync, first you need to check if the sync service is running. Use the following command:

Get-Service ADSync

Check the sync scheduler:

Get-ADSyncScheduler

If appropriate, you can start a delta sync cycle manually:

Start-ADSyncSyncCycle -PolicyType Delta

If a newly joined computer does not appear in Microsoft Entra ID, you need to check if the computer object is within the configured sync scope and check for sync errors.

Also, you need to verify which DC Microsoft Entra Connect Sync is using to import AD data. If the selected DC has not yet received the latest AD replication changes, Microsoft Entra Connect may import an outdated version of the object. Microsoft specifically recommends checking the DC used for import and verifying AD replication when recently created/modified objects are not synced.

You can check the overall AD replication status with the command:

repadmin /replsummary

For object-level sync problems, you can use the Microsoft Entra Connect troubleshooting task/Synchronization Service Manager to determine whether the object was imported, processed by synchronization rules, and exported to Microsoft Entra ID.

Microsoft Entra Cloud Sync

In case your environment uses Microsoft Entra Cloud Sync instead of Microsoft Entra Connect Sync, you should not use the Microsoft Entra Connect Sync PowerShell commands above as a generic troubleshooting method.

Check the Microsoft Entra provisioning agent and its health in the Microsoft Entra admin center by navigating to Entra ID → Entra Connect → Cloud sync. Here, you need to check if the provisioning agent is installed, running, and shown as healthy.

If a newly joined computer is not synced, then you need to check the Cloud Sync provisioning logs and verify that the object is within the configured sync scope. Microsoft notes that an object may not appear in Microsoft Entra ID because sync has not completed, an error is blocking provisioning, or a scoping rule excludes the object.

Important. Microsoft Entra ID synchronization is not required for a standard on-premises AD domain join. If Windows cannot locate/contact a DC during the initial domain join, troubleshoot DNS, DC Locator, network connectivity, Kerberos, LDAP/RPC, firewall rules, and AD health first.

Hybrid identity troubleshooting becomes relevant when the on-premises domain join succeeds but the computer object or its attributes do not appear/update correctly in Microsoft Entra ID.