Weird GPOs - Netlogon_AvoidPdcOnWan

I had previously written about the differences between account lockouts vs account being disabled in AD, and briefly mentioned that the LastBadPasswordAttempt is not replicated between domain controllers, and that replication for other attributes isn’t as quick as one would think.

Coincidentally, you may have noticed sometimes when you use the wrong password when logging into a domain joined host on a remote network, it can take a long time for a fat-fingered/wrong password to prompt you with the dreaded ‘invalid username/password’ prompt, which sometimes can seemingly take forever. This is due to how bad passwords are checked, and is a feature designed to allow password changes that haven’t propogated to remote sites, to still be useable.

The LastBadPasswordAttempt will always be synchronised with the domain controller that happens to be the Primary Domain Controller Emulator, but when this is not available the domain controller handling the request will usually take a while to report a failed login to the user.

But when the PDCe is not available, what happens? This could be a result of either a network outage, the PDCe host going down, or configuration.

There is a group policy setting which can turn this off called Netlogon_AvoidPdcOnWan, but it’s unclear how useful that would be from a security perspective; i.e. Does the LastBadPasswordAttempt counter no longer increment on the PDCe for example, allowing an attacker to just try against every domain controller?

In the case of things like OWA, or knowing a targets branch offices are internet reachable, this could lead to some curious circumstances, such as being able to spray passwords and ignore password policies, as long as you don’t lock out an account on any individual domain controller.

Given this is referenced as a recommendation for minimising WAN traffic, this might be more prevelent than one would think.

Food for thought.