An interesting issue happened at one of our
customers the other day. They had two offices and a DC, all connected with 1Gb
redundant lines with two DCs in each site. The network topology was hub and
spoke and AD logical topology consisted of a single forest with a single
domain.
The problem they had was that whenever a user
reset their password, they were locked out immediately after which was a bit of
fun AD troubleshooting for me but not so much fun for the customer.
ALTools is a handy troubleshooting tool for
account lockout issues which you can download here.
It tells you where passwords are reset or accounts locked out for a particular
user and you can trace the replication of this information across your domain
controllers.
To reproduce the issue, I logged into a test
account in one of the hub sites and reset my password. Outlook then prompted
for login credentials so I put in the new password which then failed and
eventually the account was locked out. After analysing with ALTools, I could
see that the password had not replicated to the DCs in the hub site where
Exchange was located.
Let’s pause here and just recap on what’s meant
to happen in this scenario. When a user changes their password, what happens is
that this change is made on the PDC emulator so when a user authenticates
against a DC that has not yet received the updated password, what should happen
is that the password is checked against the PDC before a login failure is
passed to the user. Clearly this wasn’t happening so I focused in on the PDC
which was also in the hub site.
Although the PDC was running and accessible by
all DCs in the forest, this issue remained, even after a PDC restart.
Replication tests using DCDIAG and Repadmin
were successful however the DCDIAG DNS test showed that there was a missing SRV
record for the PDC FSMO role although no other SRV records were missing. On
checking DNS, the highlighted records were missing:
The next question is how did this happen and
why? After a bit more investigation I found that the tick box “Register this
connection’s addresses in DNS” was unticked. See below.
Once ticked and the server restarted, the PDC
SRV records were recreated and after AD replicated the DNS zone to the other
sites the issue was resolved.
To check propagation of the SRV record across all
the sites in your domain, run the below which will check each DC for the PDC
SRV record:
(Get-ADGroup “domain controllers” |
Get-ADGroupMember).Name | % {Write-Host $_ -ForegroundColor Green;
Resolve-DnsName _ldap._tcp.pdc._msdcs.domain.com -Server $_ -ErrorAction
SilentlyContinue }