Common Causes for Account Lockouts
To avoid false lockouts, 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 security 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 invalid passwords. Microsoft recommends that you leave this
value at its default value of 10. The nih.gov
domain's password policy is set to the default value of 10.
• 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.
Note: Computers
running Windows XP or a member of the Windows Server 2003 family automatically
detect when the users password has changed and prompt the user to lock and
unlock the computer to obtain the current password. No logon and logoff is
required for users using these computers.
• Stored
user names and passwords retains 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 on Stored User Names and Passwords, see online help
in Windows XP and the Windows Server 2003 family.
Note: Computers that are running Windows
95, Windows 98, or Windows Millennium Edition do not have a Stored User Names
and Passwords file. Instead, you should delete the users
.pwl file. This file is named Username.pwl,
where Username is the users logon name. The
file is stored in the Systemroot folder.
• 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, 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.
Note: You can use the System Information
tool to create a list of services and the accounts that were used to start
them. To start the System Information tool, click Start, click Run,
type winmsd, and then click OK.
Other Potential Issues
Some additional considerations
regarding account lockout are described in the following sections.
Account Lockout for Remote
Connections
The account lockout feature that is
discussed in this paper is independent of the account lockout feature for
remote connections, such as in the Routing and Remote Access service and
Microsoft Internet Information Services (IIS). These services and programs may
provide their own unrelated account lockout features.
Internet Information Services
By default, IIS uses a token-caching
mechanism that locally caches user account authentication information. If
lockouts are limited to users who try to gain access to Exchange mailboxes
through Outlook Web Access and IIS, you can resolve the lockout by resetting
the IIS token cache. For more information, see "Mailbox Access via OWA
Depends on IIS Token Cache" in the Microsoft KnowledgeBase.
MSN Messenger and Microsoft Outlook
If a user changes their domain
password through Microsoft Outlook and the computer is running MSN Messenger,
the client may become locked out. To resolve this behavior, see "MSN
Messenger May Cause Domain Account Lockout After a
Password" in the Microsoft
Knowledge Base.
After you determine the pattern for
the account lockouts and narrow down your scope to a specific client computer
or member server, you should gather detailed information about all of the
programs and services that are running on that computer. Some of the
information that you should obtain includes:
• Mapped
network drives
• Logon
scripts that map network drives
• RunAs shortcuts
• Accounts
that are used for service account logons
• Processes
on the client computers
• Programs
that may pass user credentials to a centralized network program or middle-tier
application layer
How Domain Controllers Verify Passwords
1.
The client computer presents the user logon information to a domain
controller. This includes the users account name and a cryptographic hash of
their password. This information can be sent to any domain controller and is
typically sent to the domain controller that is identified as the closest
domain controller to the client computer.
2.
When a domain controller detects that an authentication attempt did not
work and a condition of STATUS_WRONG_PASSWORD, STATUS_PASSWORD_EXPIRED,
STATUS_PASSWORD_MUST_CHANGE, or STATUS_ACCOUNT_LOCKED_OUT is returned, the
domain controller forwards the authentication attempt to the primary domain
controller (PDC) emulator operations master. Essentially, the domain controller
queries the PDC to authoritatively determine if the password is current. The
domain controller queries the PDC for this information because the domain
controller may not have the most current password for the user but, by design,
the PDC emulator operations master always has the most current password.
3.
The authentication request is retried by the PDC emulator operations
master to verify that the password is correct. If the PDC emulator operations
master rejects the bad password, the PDC emulator operations master increments
the badPwdCount attribute for that user
object. The PDC is the authority on the user's password validity.
4.
The failed logon result information is sent by the PDC emulator
operations master to the authenticating domain controller.
5.
The authenticating domain controller also increments its
copy of the badPwdCount attribute for
the user object.
6.
The authenticating domain controller then sends a response to the client
computer that notifies the domain controller that the logon attempt did not
work.
In a Windows 2000/2003 domain, the
PDC emulator role holder retains the following functions:
·
Password
changes performed by other DCs in the domain are
replicated preferentially to the PDC emulator.
·
Authentication
failures that occur at a given DC in a domain because of an incorrect password
are forwarded to the PDC emulator before a bad password failure message is
reported to the user.
·
Account
lockout is processed on the PDC emulator.
Service Packs and Hotfixes That Are Available to
Resolve Account Lockout Issues
http://support.microsoft.com/?id=817701
Account Lockout and Management Tools