none
Account lockout

    Question

  • Hi, 

    We are having a windows 2008 environment. 

    In our forest we are facing issues with Event ID 4740 (account lockout). 

    1)When a user account is locked the event ID is captured but after sometimes the captured event ID been disappearing. 

    2)The factor is once we looking into the archived logs we could see the event ID for unlocking the same account and events occured before the account locking, But we could not find the logs for account locked out. 

    Could anyone suggest us where we went wrong... 

    Thanks in advance... 
    Monday, November 14, 2011 6:38 PM

Answers

    • Marked as answer by Elytis ChengModerator Monday, November 21, 2011 2:16 AM
    • Edited by Shakti Prasad Mishra Tuesday, January 27, 2015 9:12 PM Modified netwrix's URL to HTTPS on the request of Netwrix-TechNet@netwrix.com
    Monday, November 14, 2011 7:45 PM
  • You can use tool like eventcombMT to connect log on other dc's and look for particular event ID.The account lockout can happen due to saved password in mobile devices, mapped drives etc. Also, can you verify there is no conficker worm in your network. 

    Netwrix has got good tool to find the account lockout source.

    Troubleshooting account lockout issues

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/cddbf977-b98f-4783-8226-ebddab54d002/ 

     

    Regards


    Awinish Vishwakarma

    MY BLOG:  http://awinish.wordpress.com/


    This posting is provided AS-IS with no warranties/guarantees and confers no rights.
    Monday, November 14, 2011 8:01 PM
    Moderator
  • As you have mentioned that events are gettting disappear it seems that the events are getting overwritten.

    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?Family-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.

     Please download the Account Lockout and Management Tools:

     Account Lockout and Management Tools

    http://www.microsoft.com/downloads/details.aspx?familyid=7af2e69c-91f3-4e63-8629-b999adde0b9e&displaylang=en

     Please Note: Aloinfo.exe included in the above package helps display all local services and the account used to start them.

     Please logon the problematic client computer as the Local Administrator and run the following command:

     Aloinfo.exe  /stored  >C:\CachedAcc.txt

     Then check the C:\CachedAcc.txt file. 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

    Also go through the below link and download the EventCombMT tool

    http://support.microsoft.com/kb/824209

    Then go to Serches-----> Built in searches ---> Account lockouts

    Then add the user id which is going frequently lock out in the text ..  then search.

    You will get the details which systems get the lockout.Their may be virus on the one system which is locout the account.

     Hope this helps!

    Regards,
    Sandesh Dubey.
    -------------------------------
    MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator
    My Blog: http://sandeshdubey.wordpress.com
    This posting is provided AS IS with no warranties, and confers no rights.

    Tuesday, November 15, 2011 1:13 AM
  • In addition,

    See this for account lockout troubleshooting.

    http://social.technet.microsoft.com/wiki/contents/articles/account-locked-out-troubleshooting.aspx


    Best regards Biswajit Biswas Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin
    Tuesday, November 15, 2011 5:14 AM

All replies

    • Marked as answer by Elytis ChengModerator Monday, November 21, 2011 2:16 AM
    • Edited by Shakti Prasad Mishra Tuesday, January 27, 2015 9:12 PM Modified netwrix's URL to HTTPS on the request of Netwrix-TechNet@netwrix.com
    Monday, November 14, 2011 7:45 PM
  • What do you mean the event ID has been disappearing?  Are your logs being over written (check the size) or do you think they are being deleted?  Start looking into that problem first as security event log entries should not be randomly disappearing.

     

    Thanks

     

    Mike


    http://adisfun.blogspot.com
    Follow @mekline
    Monday, November 14, 2011 7:58 PM
  • You can use tool like eventcombMT to connect log on other dc's and look for particular event ID.The account lockout can happen due to saved password in mobile devices, mapped drives etc. Also, can you verify there is no conficker worm in your network. 

    Netwrix has got good tool to find the account lockout source.

    Troubleshooting account lockout issues

    http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/cddbf977-b98f-4783-8226-ebddab54d002/ 

     

    Regards


    Awinish Vishwakarma

    MY BLOG:  http://awinish.wordpress.com/


    This posting is provided AS-IS with no warranties/guarantees and confers no rights.
    Monday, November 14, 2011 8:01 PM
    Moderator
  • As you have mentioned that events are gettting disappear it seems that the events are getting overwritten.

    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?Family-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.

     Please download the Account Lockout and Management Tools:

     Account Lockout and Management Tools

    http://www.microsoft.com/downloads/details.aspx?familyid=7af2e69c-91f3-4e63-8629-b999adde0b9e&displaylang=en

     Please Note: Aloinfo.exe included in the above package helps display all local services and the account used to start them.

     Please logon the problematic client computer as the Local Administrator and run the following command:

     Aloinfo.exe  /stored  >C:\CachedAcc.txt

     Then check the C:\CachedAcc.txt file. 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

    Also go through the below link and download the EventCombMT tool

    http://support.microsoft.com/kb/824209

    Then go to Serches-----> Built in searches ---> Account lockouts

    Then add the user id which is going frequently lock out in the text ..  then search.

    You will get the details which systems get the lockout.Their may be virus on the one system which is locout the account.

     Hope this helps!

    Regards,
    Sandesh Dubey.
    -------------------------------
    MCSE|MCSA:Messaging|MCTS|MCITP:Enterprise Adminitrator
    My Blog: http://sandeshdubey.wordpress.com
    This posting is provided AS IS with no warranties, and confers no rights.

    Tuesday, November 15, 2011 1:13 AM
  • Hello Mike,

    Thank you for your reply. We checked and found the logs are not being overwritten and is there any possibility for a particular event (4740) to get deleted.

    Tuesday, November 15, 2011 4:41 AM
  • In addition,

    See this for account lockout troubleshooting.

    http://social.technet.microsoft.com/wiki/contents/articles/account-locked-out-troubleshooting.aspx


    Best regards Biswajit Biswas Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights. MCP 2003,MCSA 2003, MCSA:M 2003, CCNA, MCTS, Enterprise Admin
    Tuesday, November 15, 2011 5:14 AM
  • Hello everyone,

    I know this disc was ended longback on nov-15th, but my case is similar to this so I am posting it here. I am a domain admin in one of the Windows based domain, and I have just 8 months of experience with windows administration and I have a certification in 2008 Network Infrastructure and Configuration.My issue is, my account gets locked very periodically like for every 5 to 10mins and i keep unlocking it. The thing is I know from which comp its locking my account through events. I have to let you know that I installed MS Sql Server 2008 R2 in those machines and out of lack of knowledge I have used my credentials instead of a consistent domain admin or local admin account because of which I am getting locked up as the services are using my old passwords all the time. I have logged into that machine with my latest password but no luck. Uninstalled the software and reinstalled using a local admin account but no luck. If i solve in one machine it starts locking from other machine and this continues to about 10 machines approx. Can anyone suggest me , a way to get rid of this? May be I may find a solution only when I manually go and uninstall all the softwares for which I used my account and then only I can get out of this. But this may not be possible practically bcos its hard for me to do them. Am finding it very hard to unlock my acc regularly. any help would be truly appreciated. Thanks in advance.

    -Sreekar.

    Thursday, February 23, 2012 9:59 AM
  • Hello Gentleman,

    Can anyone please help me out with the above issue?

    Thanks,

    Sreekar.

    Wednesday, February 29, 2012 6:30 AM
  • Please raise your own new thread along with the details of the issues you are facing. This is old thread and marked as an answer.


    Awinish Vishwakarma - MVP-DS

    My Blog: awinish.wordpress.com

    Disclaimer This posting is provided AS-IS with no warranties/guarantees and confers no rights.

    Wednesday, February 29, 2012 6:48 AM
    Moderator