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

http://www.microsoft.com/downloads/details.aspx?FamilyID=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en

 Trovato su:

http://www.mail.nih.gov/user/faq/AccountLockouts.htm