There is a strange and confusing (to me and to users) issue plaguing authentication. I do not know how long it has been occurring, but I believe it to be quite a while. Only recently, with the use of the Account Lockout tool have I realized that these authentication issues are sometimes caused by a glitch in the system rather than user error.
What happens is that a user authenticates correctly, but the system rejects their password. I wish to repeat: they log in with the correct username, password, and domain. This is not fat-fingering; it is not a client issue; it is not user error; it is not an expired password; it is not specific to any service.
The behavior when a user correctly authenticates is that the DC resets the ‘failed login’ count back to 0. When they fail, it increments it and sets the ‘last fail’ time. But when this glitch occurs, neither happens; the authentication attempt is rejected, but the count does not go up by 1, nor does it reset, and the last fail time does not change.
The issue occurs across multiple devices and services. Today I had a student fail to log in on multiple computers, as well as webmail. I compared the event logs from the computer and the DC; I con see no difference between the events when the user was wrongly rejected (and the failure count did not go up) and when she was correctly rejected because I had her mistype the password on purpose.
I have done this myself, attempting to log in to a student’s freshly created account (using a known password scheme). I have had it happen to users on many of the services that authenticate through AD. It has happened to staff, faculty and students. As far as I can tell, this is an authentication issue directly on the DCs; something wonky with the account, but not one of the typical culprits of expired password, disabled, etc.
Resetting the password fixes the issue. The problem just goes away. But the frequency of the issue (about 8-10 cases just this week, out of at most 100 network password resets) leads me to believe it is a serious problem.
I do not know how long this issue has been occurring. Without using the Account Lockout tool, I would never have seen that the error count was failing to increment, and thus assumed that the user was wrong about knowing the password. I have had many occurrences where users swore they knew their login, and it ‘worked yesterday’. I do not know how many of these times it was true, if ever. Even after getting the tool, it has taken multiple occurrences and several months of the issue occurring before I believed it was a real problem. Not till I actually had it happen to me, typing the student’s initial password, and seeing the failure count fail to rise, did I really believe it.
Our AD environment is mostly on Windows server 2008. Some DCs are still Server 2003. The environment is a single domain. If there are any other relevant technical details necessary for troubleshooting, please let me know.
Edit: As the accepted answer shows, it really was user error. The event that 'proved' to me that it was a real problem was when I logged in to a newly created account and it failed without incrementing the bad password count. We have standards for new accounts and what to reset passwords to. Likely another admin ignored the standard and reset this user's password to something else. When I attempted to log in to the new user, and the bad password failed to increment (yet I was rejected), I thought it was proof of an issue. Much Googling failed to find a page describing the situations under which the Bad Password Count fails to rise... hopefully this answer will help someone else in the future.
Do you have password history enabled? If the password entered matches either of the two last passwords for the account, the auth will be rejected but
badPwdCountwill not be incremented. I'm trying to wrap my head around the rest of your description, but that would at least explain the "missing" bad password increment.EDIT
Rereading your question, it sounds like administratively resetting passwords always has positive results, correct? Also wondering what OS your PDCe is on (2003, 2008). Are there any firewalls potentially blocking access to the PDCe (or any other DCs for that matter)? Keep in mind that while end-user password changes communicated from the client to the local DC via the kpasswd protocol (TCP/464), PDCe notification of password changes are via an RPC call. The destination ports will have changed from 2003 to 2008.
This smells like a problem with either your replication or the DC that has the PDC Emulator role.
Can you run
netdom query fsmoon each DC and compare the results from each? Make sure they all think the same server holds the PDC Emulator role. Next, take a look at the output ofdcdiagand see what it has to say. Also, verify replication withrepadmin /showreplagainst each DC.If I had to take a completely blind guess, I'd say that there's either an inconsistency in who the DCs think hold the PDC Emulator role, or the server that once held it was improperly decommissioned and the role was never moved.
This is not an issue, this is a feature: Enhancements were introduced for domains at Windows Server 2003 functional level and above. When the bad password matches either of the two most recent entries in password history, the badPwdCount attribute is not incremented and the badPasswordTime attribute is not updated. This means that normal users can make more attempts before they are locked out. Their bad password attempts are more likely to be passwords they recently used.
The meaning of the lockoutObservationWindow attribute is the same. But because badPasswordTime is not updated for every bad password attempt, it affects the number of attempts users are allowed in some cases. The badPwdCount is more likely to reset when a user attempts with an old password.
This new feature is sometimes called password history n-2. The most recent previous password is referred as n-1. The next most recent are n-2. Not all authentication types will take advantage of this new feature. Kerberos and NTLM authentication protocols support password history n-2. These protocols are used when either a password or smart card is used for interactive login. Other protocols, such as RADIUS and PEAP, may or may not increment badPwdCount when a bad password is attempted. Some protocols do not forward bad password attempts to the PDC Emulator. That might explain why phone users can get locked out if the phone attempts repeatedly to authenticate with a bad password.
In addition, the system can only know about the previous 2 passwords in history if pwdHistoryLength is at least 3. With that setting, the user can rotate through 3 passwords, so the previous 2 are retained in password history. If pwdHistoryLength is 2, the user can alternate between two passwords. The only password attempt that will not increment badPwdCount, in that case, is the previous one. The system does not retain the second most recent password.