Random Account Lockout (How to trace source?)
In Windows 2003 server native domain environment: XP Pro machines have no issues, but all ~10 PCs that have Win7 Pro (in different offices) have their domain accounts locked out randomly throughout the day. Workstations have no passwords listed in credentials management. Suspect it is something on the workstations that is sending incorrect logon and triggering the invalid password lockout limit on domain policy. Found MSFT tools to trace in XP, but nothing for Win7. Does anyone know how to use Procmon or similiar tool to trace such source on the workstations? Thank you. (Procmon.exe from systernals)
May 6th, 2010 7:27pm

Did you try Account Lockout and Management Tools? http://www.microsoft.com/downloads/details.aspx?FamilyId=7AF2E69C-91F3-4E63-8629-B999ADDE0B9E&displaylang=en Santhosh Sivarajan | MCTS, MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, Network+ Houston, TX http://blogs.sivarajan.com/ http://publications.sivarajan.com/ This posting is provided "AS IS" with no warranties, and confers no rights.
Free Windows Admin Tool Kit Click here and download it now
May 7th, 2010 7:31am

Yes, tried it, but unfortunately it didn't produce any results logs under Windows 7. It only supported Operating Systems: Windows 2000; Windows NT; Windows Server 2003
May 7th, 2010 8:16am

Hi, · The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested. We can run the LockoutStatus.exe on domain controller to identify and investigate the account lockout issue. Troubleshooting tools: By using this tool, we can gather and displays information about the specified user account including the domain admin's account from all the domain controllers in the domain. In addition, the tool displays the user's badPwdCount value on each domain controller. The domain controllers that have a badPwdCount value that reflects the bad password threshold setting for the domain are the domain controllers that are involved in the lockout. These domain controllers always include the PDC emulator operations master. You may download the tool from the link Download Account Lockout Status (LockoutStatus.exe) http://www.microsoft.com/downloads/details.aspx?familyid=D1A5ED1D-CD55-4829-A189-99515B0E90F7&displaylang=en Once we confirm the problematic computer, we can perform further research to locate the root cause. Actually, there are many possible causes for bad password, such as cached password, schedule task, mapped drives, services, etc. Please remove the previous password cache which may be used by some applications and therefore cause the account lockout problem. Troubleshooting steps: 1. Click Start, click Run, type "control userpasswords2" (without the quotation marks), and then click OK. 2. Click the Advanced tab. 3. Click the "Manage Password" button. 4. Check to see if these domain account's passwords are cached. If so, remove them. 5. Check if the problem has been resolved now. If there is any application or service is running as the problematic user account, please disable it and then check whether the problem occurs. For your convenience, I'd like to list the common troubleshooting steps and resolutions for account lockouts as the following: Common Causes for Account Lockouts 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. 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 Knowledge Base. 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 Change" in the Microsoft Knowledge Base. For more information, please refer to the following link: Troubleshooting Account Lockout http://technet.microsoft.com/en-us/library/cc773155.aspx Account Passwords and Policies in Windows Server 2003 http://technet.microsoft.com/en-us/library/cc783860.aspx Hope this helps! Novak
Free Windows Admin Tool Kit Click here and download it now
May 12th, 2010 11:43am

This doesn't help. I read, re-read this troubleshooting tips but no luck. Still searching for solution.
September 14th, 2011 11:43pm

Same problem. Did everything as suggested. Took my account off the offending PC and removed all mapped drives and then put them in under users account and checked box making the user log in. Checked credentials and found none. Looked for my user name in the registry and found nothing. Cleared my profile as well a local profile that I used during setup where I might have accessed a server that would need my domain account credentials. Cleared everything out of IE. ran all the lock out tools that I could find trying to ID what process or service is connecting to the AD server with the wrong password. If only I could tell what process is attempting to log on I might stand a chance of resolving this problem. As it is I get locked out of the domain several times a day.
Free Windows Admin Tool Kit Click here and download it now
November 27th, 2011 12:11pm

The above might have solved the problem... I'll report it back NOVAK
November 27th, 2011 2:38pm

This post marked as "answer" by moderator does not explain how to trace back to the origin of the account lockout. Microsoft needs to remove the ability of moderators to mark answers. Only the original poster should be able to confirm whether a post was an answer and provided a solution to the problem. Day after day I find posts marked as "Answered" by a moderator with absolutely no confirmation from the original poster whether it actually solved their problem
Free Windows Admin Tool Kit Click here and download it now
February 28th, 2012 11:27am

The first place to check unexpected account lockoff issues would be the security log of the server before starting to use any tools. Often these messages contain also a workstation name or an IP address used by the offending account (which can be interactive login or an account used to login a service or run a scheduled task forgotten with a password change). I agree in the context, that a moderator should not be able to mark his own post as answer, at least not that short after posting. But in general it helps to have a thread marked as answered and closed, even if the answer is not always fully perfect and fitting for each solution. (I'm moderator in some forums myself.) Best greetings Olaf
February 28th, 2012 12:50pm

Hello, When our organization began rolling out Windows 7 unexpected lockouts started to occur. The folks getting locked out were using their smartcards to logon. I found that a Citrix Online Plug-in was in the Startup of the baseline configuration and the Citrix server is not configured to accept smartcard credentials. Each time a user logged on to their workstation the Citrix plug-in would attempt to sign on to the configured Citrix server. Because the server was not configured to accept smartcards the attempt counted as one failed attempt to logon using the Active Directory account. Most occurrences took place after receiving assistance from the helpdesk which caused a few reboots. After the third reboot and subsequent logon, the Active Directory account was locked due to meeting the incorrect logon threshhold. While that is not likely the case for you, it may assist in leading you to the cause. Hopefully that helped some. MagikD
Free Windows Admin Tool Kit Click here and download it now
February 29th, 2012 12:48pm

i disagree. the OP already knows that his machine is the offender. the MS answer does not address the question that the OP is asking. please also note that noone has particular found the response to be very helpful. If there's nothing that can be done to help troubleshoot on the client side, just say so and tell us that it's something you are working on or something to that effect.
April 18th, 2012 1:47pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics