I hope this post will become obsolete very soon – the AD engineering group at Microsoft is aware and will provide guidance, workaround, or a fix. I will update this post as the investigation progresses.
TL;DR: If you have an account lockout policy in place and your PDC Emulator has been upgraded to Server 2025, you might see an increase in support calls. Hold off moving the PDCe role to 2025 for now.
What is it all about?
If you run an Active Directory environment with actual users in it, you have probably implemented
- a password policy dictating a minimum password length, complexity and maybe also a maximum lifetime (or not, if you follow the latest NIST recommendations), and
- an account lockout policy to prevent attackers from brute-forcing your passwords until they get lucky.
And hopefully your password policy also enables password history, to prevent folks from using the same password over and over again, even if they are required to change it.
This has worked fairly well in the past (not talking about the general concept of password security here, that’s a topic for another day), partly due to a technique quietly introduced by Microsoft with Server 2003: the N-2 Password History check. Normally, the password verification works like this:
(this picture is taken from Microsoft Learn). If the DC performing authentication has a password (hash) different from the one submitted by the client, and it is not itself the PDCe, it will forward the logon request to the PDCe, in the hopes that the latter may have an updated password that just didn’t get replicated yet. If the PDCe cannot verify the password either, it increments its badPwdCount, sends a message back to the initial DC, upon which it also increments its badPwdCount for the unlucky user. Once the badPwdCount on the PDCe reaches the threshold set in the lockout policy, the PDCe locks the account by writing the Int64 timestamp to the lockoutTime attribute and triggering an urgent replication of that attribute so that all DCs now know that the user is locked out.
Of course, if you change your password at the office, only to realise that you have left your ActiveSync-enabled mobile device at home, your account gets locked out pretty quickly. The same can happen if you forgot to log off a machine, and there is a network share being accessed with your own credentials, especially if NTLM is used (not talking about NTLM either – if your environment is still using it, there is probably a reason for it). Now, depending on the lockout policy set in your organisation, you either have to wait a while (during this time, wrong password attempts continue to arrive) or raise a support request to have your account unlocked (which will also not be for very long, as long as the source of wrong password attempts is still active).
Enter N-2
Microsoft recognised the problem early and provided a fix with Server 2003 that has kept helpdesk folks sane(r) for 22 years: If your password policy includes password history, and the history length is 3 or higher, the last two passwords will not lead to the DCs incrementing badPwdCount while still not allowing for successful authentication, hence N-2. If your history length is set to 2, only the previous password is „forgiven“. This behaviour is documented in the Learn article linked above.
Fast-Forward to 2025
Server 2025 brought several security and performance improvements to Active Directory. And one of them seems to have broken N-2, in that badPwdCount is always incremented, regardless of the password being within the last two slots of the history or not. In terms of practical implementation, the behaviour you’re likely to observe after introducing Server 2025 DCs into your Active Directory, is as follows:
PDCe is 2025
All wrong password attempts, including N-1 and N-2, will increment badPwdCount on the PDCe, causing lockouts like it’s 2000. Server 2025 non-PDCe DCs processing authentication requests will also see badPwdCount increasing faster than usual, which may trip up monitoring based on that attribute.
PDCe is 2016-2022, some of the other DCs are 2025
N-1 and N-2 passwords will not cause badPwdCount increments on the PDCe so no unexpected lockouts will pop up in your Service Desk. However, Server 2025 DCs will still increment badPwdCount on N-1 and N-2, so that you may see values way above the lockout threshold, without users actually getting locked out.
It goes without saying that neither situation makes diagnosing lockouts any easier. But to at least keep the support requests at bay, you should refrain from putting the PDC emulator on Server 2025 for now.
But what if *all* of my DCs are already 2025?
Disable lockout and wait for the fix, or add a Server 2022 DC (if you haven’t already raised the functional level) and move the PDCe role to it.
Happy unlocking!