Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
    
You probably know the sequence of events, but just in case...how do you know that the auth attempts are even reaching the DCs? What error(s) are the clients getting? What do the security logs in the DCs show when they are attempting a login? Anything? If you run Wireshark on a mirrored port of their computer are you able to determine that traffic is going back and forth to the DC for the login attempts? –  TheCleaner May 15 '13 at 19:04
    
I have not done any packet inspection. However, my current diagnosis method is to have a user attempt to log in with a deliberately bad password; this attempt reaches the server, increments the fail count. I then have the user try the password they think it is. They observe identical results (rejection by email/webmail/computer/sharepoint/whatever). On my end, I observe the failure count FAIL to increase. I can see authentication failure events in the log of the DC. But the count didn't rise, because that was the correct password. 3/4 login problem calls currently are caused by this issue. –  Myrddin Emrys May 16 '13 at 0:19
    
can you post the DC security log failure events here as well as the error message/screen that clients get when they observe these results? Without those, it sounds like your best recourse would be to open a ticket with MS support and have them work through the issue with you. –  TheCleaner May 16 '13 at 1:56
    
The user error doesn't really matter, because this is system agnostic. They get rejected by email, computer, IIS, the VPN... any system authenticating via AD can raise this, and each system communicates a password failure differently. The DCs are reporting an authentication failure to whatever service attempts the login; how the service shows that to the user varies. The DC error logs are identical (to the best of my ability to compare) between a legit and a glitched authentication failure, but I'll try to post an example. –  Myrddin Emrys May 16 '13 at 2:03
    
I'm with @TheCleaner on this, post one of the failed logon events from the DC security log. It will give us an idea of why the DC might have rejected the attempt –  Mathias R. Jessen May 16 '13 at 15:46

2 Answers 2

up vote 7 down vote accepted
+300

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 badPwdCount will 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.

share|improve this answer
    
We do have password history enabled. I had no idea that badPwdCount did not increment in this case! This means there is no problem at all... just users forgetting that they changed their password! Thank you! Testing to see if this explains symptoms now... –  Myrddin Emrys May 16 '13 at 17:40
    
YES! Woohoo! Months of confusion solved! I love you Charles! –  Myrddin Emrys May 16 '13 at 17:45
1  
That's great to hear. Was it really as simple as users attempting to use previous passwords? I thought you mentioned failures on brand new accounts. –  charleswj81 May 17 '13 at 1:07
    
I did mention failures on brand new accounts. In fact, the one on a new account was my proof that it was 'real'. But what I suspect is this: Account created with initial password. User emails IT, someone resets to a different than standard password. User calls IT, talk to me, I try the default password... and the failure does not increment (because it is in the password history). So it was new, but not untouched, and I didn't realize. –  Myrddin Emrys May 17 '13 at 2:50

This smells like a problem with either your replication or the DC that has the PDC Emulator role.

Can you run netdom query fsmo on 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 of dcdiag and see what it has to say. Also, verify replication with repadmin /showrepl against 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.

share|improve this answer
    
Should all these commands work on a 2003 DC? I am not sure if the path is just wrong, or if these are 2008 only commands... –  Myrddin Emrys Jan 11 '13 at 23:49
    
I'm not 100% sure of netdom, but the others should. Alternately you can run them all from a W7 workstation with RSAT and the AD command line tools enabled –  MDMarra Jan 12 '13 at 0:13
    
I never updated this question, but unfortunately this did not turn out to help; all of our DCs are accurately configured with the correct PDC. Any other recommendations you can provide? –  Myrddin Emrys Apr 3 '13 at 20:01
    
What about the outputs of the dcdiag and repadmin commands that I specified above? –  MDMarra May 10 '13 at 18:54
    
repadmin reports no replication issues (we also set a monitor to auto-recheck, and none ever pop up), and dcdiag reports no issues either. But accounts are still getting messed up... and this was not a single incident in the past, it is a persistent thing that glitches new users. –  Myrddin Emrys May 14 '13 at 18:37

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.