Why Are Clients Authenticating to the Wrong Domain Controller?
If you’re troubleshooting odd logon behaviour across your network, one common culprit is clients talking to the wrong domain controller. It’s easy to assume DNS or replication is to blame, but often, it comes down to a misconfigured subnet in Active Directory Sites and Services.
When your IP address can’t be mapped to a defined Subnet, domain controllers can’t determine which site you belong to. Without site information, your client can’t locate the nearest DC - so you might end up authenticating against a DC in a completely different location (further away), even if there’s one right next door.
You’ll typically notice this when users complain about slow logons, access delays, or when group policy isn’t applying properly. Dig a little deeper, and you might spot machines authenticating against a DC in a different physical location - even if there’s a local one right next door.
The smoking gun is in each DC’s netlogon.log file (C:\Windows\Debug). When a client authenticates from an IP that doesn’t match any defined subnet, you’ll see NO_CLIENT_SITE entries.
However, manually checking every DC is tedious, so we can use PowerShell to scan them all and pull out those entries. Once you’ve got the list of stray IP Addresses, add the missing subnets to Sites and Services, link them to the right sites, and clients will start correctly hitting their local DCs.
The PowerShell Script
Here’s a script that queries all domain controllers and extracts NO_CLIENT_SITE entries from their netlogon.log files:
# Get all domain controllers in the forest
$AllDCs = (Get-ADForest).Domains | ForEach-Object {
Get-ADDomainController -Filter * -Server $_
} | Select-Object -ExpandProperty HostName
# Initialize results array
$Results = @()
# Query each DC
foreach ($DC in $AllDCs) {
Write-Host "Checking $DC..." -ForegroundColor Cyan
# Define the remote path to netlogon.log
$LogPath = "\\$DC\C$\Windows\debug\netlogon.log"
# Check if file exists and is accessible
if (Test-Path $LogPath) {
# Read the log file and filter for NO_CLIENT_SITE entries
$NoClientSiteEntries = Get-Content $LogPath |
Where-Object { $_ -match "NO_CLIENT_SITE" }
# Parse each entry
foreach ($Entry in $NoClientSiteEntries) {
$Parts = $Entry -split '\s+'
$Results += [PSCustomObject]@{
DomainController = $DC
ComputerName = $Parts[-2]
IPAddress = $Parts[-1]
LogEntry = $Entry
}
}
}
else {
Write-Warning "Cannot access netlogon.log on $DC"
}
}
# Display results grouped by IP address
$Results | Group-Object IPAddress |
Select-Object Count, Name, @{Name='Computers';Expression={($_.Group.ComputerName | Select-Object -Unique) -join ', '}} |
Sort-Object Count -Descending |
Format-Table -AutoSize
The script connects to each DC, reads the netlogon.log file, and extracts any entries where clients authenticated from IP addresses that don’t match a defined subnet. It then groups the results by IP address so you can see which subnets are causing the most issues.
Once you’ve got the list of IPs, cross-reference them with your network documentation to figure out which subnets need to be added to AD Sites and Services, and which site they should be associated with.