Wednesday, 12 August 2015

AD account locked out after password reset

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 }

No comments:

Post a Comment