To avoid false lockouts, please check each computer on which a lockout occurred for the following behaviors:
Programs:
Many programs cache credentials or keep active threads that retain the credentials after a user changes their password.
Service accounts:
Service
account passwords are cached by the service control manager on member
computers that use the account as well as domain controllers. If you
reset the password for a service account and you do not reset the
password in the service control manager, account lockouts for the
service account occur. This is because the computers that use this
account typically retry logon authentication by using the previous
password. To determine whether this is occurring, look for a pattern in
the Netlogon log files and in the event log files on member computers.
You can then configure the service control manager to use the new
password and avoid future account lockouts.
Bad Password Threshold is set too low:
This
is one of the most common misconfiguration issues. Many companies set
the Bad Password Threshold registry value to a value lower than the
default value of 10. If you set this value too low, false lockouts occur
when programs automatically retry passwords that are not valid.
Microsoft recommends that you leave this value at its default value of
10. For more information, see "Choosing Account Lockout Settings for
Your Deployment" in this document.
User logging on to multiple computers:
A
user may log onto multiple computers at one time. Programs that are
running on those computers may access network resources with the user
credentials of that user who is currently logged on. If the user changes
their password on one of the computers, programs that are running on
the other computers may continue to use the original password. Because
those programs authenticate when they request access to network
resources, the old password continues to be used and the users account
becomes locked out. To ensure that this behavior does not occur, users
should log off of all computers, change the password from a single
location, and then log off and back on.
Stored user names and passwords retain redundant credentials:
If
any of the saved credentials are the same as the logon credential, you
should delete those credentials. The credentials are redundant because
Windows tries the logon credentials when explicit credentials are not
found. To delete logon credentials, use the Stored User Names and
Passwords tool. For more information about Stored User Names and
Passwords, see online help in Windows XP and the Windows Server 2003
family.
Scheduled tasks:
Scheduled processes may be configured to using credentials that have expired.
Persistent drive mappings:
Persistent
drives may have been established with credentials that subsequently
expired. If the user types explicit credentials when they try to connect
to a share, the credential is not persistent unless it is explicitly
saved by Stored User Names and Passwords. Every time that the user logs
off the network, logs on to the network, or restarts the computer, the
authentication attempt fails when Windows attempts to restore the
connection because there are no stored credentials. To avoid this
behavior, configure net use so that is does not make persistent
connections. To do this, at a command prompt, please type net use
/persistent:no. Alternately, to ensure current credentials are used for
persistent drives, disconnect and reconnect the persistent drive.
Active Directory replication:
User
properties must replicate between domain controllers to ensure that
account lockout information is processed properly. You should verify
that proper Active Directory replication is occurring.
Disconnected Terminal Server sessions:
Disconnected
Terminal Server sessions may be running a process that accesses network
resources with outdated authentication information. A disconnected
session can have the same effect as a user with multiple interactive
logons and cause account lockout by using the outdated credentials. The
only difference between a disconnected session and a user who is logged
onto multiple computers is that the source of the lockout comes from a
single computer that is running Terminal Services.
Service accounts:
By
default, most computer services are configured to start in the security
context of the Local System account. However, you can manually
configure a service to use a specific user account and password. If you
configure a service to start with a specific user account and that
accounts password is changed, the service logon property must be updated
with the new password or that service may lock out the account.
