I am have several end users account locking out after recently resetting there domain password.

Our domain policy is lockout Threshold 3 attempts. They are getting locked out after 1 try. It is kind of strange when I go to see if it is user error I can never get it to do it when I am there "Of course right'

The only thing that I can think of is that they are pressing the enter key on there keyboard to wake there monitor which would end in an blank password.

This this happened to anyone before? What can I do to diagnose deeper?

Log them off their computers then change their passwords. Then have them log back on with the new password.

It could be something running on their computers using cached credentials. It could also be something like an email application like blackberry or other smartphones that is accessing their accounts still trying to use the old password.

If your users move around to different machines, someone may have not noticed that the username was wrong and typed their own password three times, locking out the other persons account. That happens a fair bit around here. Odd that it would happen repeatedly to the same users, so the phone config, or software with hard config'd account info is more likely.

Another longshot: users are at a remote site with it's own DC, and domain replication has not caught-up with changes....

In some cases, I have a couple of users that I've actually had to have them set their password using the AD snap in from my PC to stop the lockouts. I think what sometimes happens is the user SID is cached somewhere before the DC updates or in the case of multiple DC's gets changed on one DC but the others haven't yet replicated...

First of all, your lockout threshold is WAY too low. Here is a write-up I did on the approrpaite lockout threshold and why you shouldn't make it that low.

===============================================================

You should standardize on around 10 failed login attempts threshold for all windows based systems because of the inherent complexities of supporting three primary authentication protocols within the Windows platforms: LM, NTLM and Kerberos. Because Windows supports these authentication protocols, Windows based systems can try any or all of the protocols during a single attempt to authenticate the user however, each attempt would register as a login failure. The net result is that a single failed login can actually register as three failed attempts and result in an account lockout after only one actual failed attempt.

By increasing the threshold to 10 failed logins consistent with the Microsoft Best Practice recommendation, you arrive at a medium that will allow at least two failed logins to occur prior to locking out the account.

Why does the lockout threshold of ten or even 100 not reduce the security of your network?

======================================

The risk imposed by a single or double digit variance of this setting is negligible because the intent of this setting is to provide mitigation for and prevent 'successful' brute force attacks against accounts. Regardless of whether this setting is at 3, 10 or 100, brute forcing of the accounts is still not practical as long as the minimum password length of at least 8 and password complexity is enable to result in the number of possible password permutations for each individual account of a general minimum 218 Trillion permutations that would need to be attempted and would take approximately 7 years to brute force the password assuming a rate of 1 million passwords per second.

Regardless of whether this setting is 3, 10 or 100, the account would be locked out long before a brute force attack could be successfully executed.

=============================================

As to why your users accounts are locking?

The users are fat-fingering the password and you are getting caught by the triple authentication protocol issue noted above.

They have cached the credential

They have a smartphone or other device using the old password (Exchange ActiveSync)

They are logged on to mulitple machines and at least one is using the old password.

Another employee is purposefully mistyping the password to cause the other employee (and you) pain.

Do they have a smart phone? Seen users lock out after change when they neglected to change the password on the phone.

Check this,

Specifically iphone / ipad, I have had a i device lock an account even when the password is correct it still had the old password cached even though a new one was entered. (usually this happens in the matter of seconds).

You should standardize on around 10 failed login attempts threshold for all windows based systems because of the inherent complexities of supporting three primary authentication protocols within the Windows platforms: LM, NTLM and Kerberos.

Very nice segment. You do realise however that running LM & NTLM makes having security measures in place largely irrelevant? It's like running wireless with WEP encryption. Way to easy to break. Unless you're supporting NT 4.0 clients (pre SP4 or specific apps), you should completely disable LM & NTLM.

ThomasTrain wrote:

As to why your users accounts are locking?

The users are fat-fingering the password and you are getting caught by the triple authentication protocol issue noted above.

They have cached the credential

They have a smartphone or other device using the old password (Exchange ActiveSync)

They are logged on to mulitple machines and at least one is using the old password.

Another employee is purposefully mistyping the password to cause the other employee (and you) pain.

So the only way to completely eliminate NTLMv2 is to set "Send NTLMv2 response only\refuse LM & NTLM" on every system.. however, this setting is generally incompatible with any linux based system that integrates with AD: Think anything samba related like NAS servers and such.

If you can use "Send NTLMv2 response only\refuse LM & NTLM" in yur environment, then that would minimize the impact of the tripple protocol lockout but you just need to make sure your network doesn't have any devices that aren't compatibile with it.

Check network drives and printers were not mapped using the Administrator's password, it could be a computer or computers trying to access resources that were set with the Administrator's credentials. Programmers love to do stuff like that.

So the only way to completely eliminate NTLMv2 is to set "Send NTLMv2 response only\refuse LM & NTLM" on every system.. however, this setting is generally incompatible with any linux based system that integrates with AD: Think anything samba related like NAS servers and such.

If you can use "Send NTLMv2 response only\refuse LM & NTLM" in yur environment, then that would minimize the impact of the tripple protocol lockout but you just need to make sure your network doesn't have any devices that aren't compatibile with it.

I don't see why Nix systems need LM/NTLM. After all, Kerberos is an open standard. I've never tried though so I'm just thinking out loud... :)

I have techs being locked out. Here's what I've found in my environment:

Looking at domain controller, I see kerberos events with failure logs prior to account lock. Thankfully the events include IP/workstation name and when I look at the offending computer system logs I see that they have saved their creds on the machine. The tech can then log on and go to control panel - User Accounts - Manage Your Credentials and clean up the mess they have made for themselves.

I see this type of thing from time to time. For me it is normally because the user logs on to their computer on Monday for example, when they leave for work they only lock their computer. On Tuesday they unlock their computer and log onto our Terminal Server. They get prompted to change their password so they do it on the Term Server. eventually the account will get locked out do to their local computer being logged in with the old credentials. The opposite sometimes happens there they have a disconnected session on the Term Server and then change their password on with the local PC.

1st Post

We are having this "Account locked" problem with one of our employees at the moment. His account has been getting locked out almost daily, since he changed his password 10 days ago.

Currently looking into Mapping Drives - as you can ask for a drive to be mapped with a specific username & password. And if the password is the user's *old* Windows password, then this'll cause problems.

One question - if the user just have a shortcut to a network drive on their Windows desktop, but never opens it, would Windows still attempt to restore that connection ? Or does it wait until the user specifically attempts to open that shortcut ?

depends what you mean by "shortcut to network drive". if you mean a shortcut to a mapped drive, then:

windows will leave it alone and be fine. Office, however, will not. If you have a mapped drive that is disconnected, Office 2007 & 2010 will give you problems every time you try to open a document from within the program, as every time it goes out to look for files, it runs through EVERY drive you have mapped. Any drive that fails causes a delay of about 1 minute before it moves on........ REAL pain that one....

if you mean shortcut such as \\server\share\folder then its not going to affect anything else.

I would also make sure that their password meets the minimum requirements such as character length and the special character limit. Also the EU has to be informed that they cannot use passwords they did previously.