<

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x

Active Directory Locked Account Investigation Process

Published on
61,147 Points
4,947 Views
17 Endorsements
Last Modified:
Approved
Community Pick
Shaun Vermaak
My name is Shaun Vermaak and I have always been fascinated with technology and how we use it to enhance our lives and business.
This article outlines the process to identify and resolve account lockout in an Active Directory environment.

Process

Process1.png 

1) Change lockout policy according to Microsoft Recommendation


The lockout policy's ultimate goal is to protect against automated password guessing (brute-force attack) and as such, the value should be high enough so that accounts are not accidentally locked out by an end user or incorrect saved password.


As per the following articles, I would recommend the following lockout settings


  • Account lockout threshold 50
  • Reset account lockout counter after 10 minutes

 

https://technet.microsoft.com/en-us/library/cc671957(v=ws.10).aspx

https://technet.microsoft.com/en-us/library/hh994574(v=ws.11).aspx


Lockout-Policy.png


2) Enabling Auditing


Identifying the source of the account lockouts in a complex environment will be virtually impossible without auditing enabled.


Please note: Only events that occurred after enabling auditing will be logged. It also might be necessary to increase Security log file size



In addition to the above, the following might provide some extra clues to the source of the lockout. After setting these values, additional logs can be found in Event Viewer, Applications and Services Log/Microsoft/Windows/NTLM


Path: Computer Configuration\Windows Settings\Local Policies\Security Options
Setting: Network Security: Restrict NTLM: Audit Incoming NTLM Traffic
Value: Enable auditing for all accounts
Setting: Network security: Restrict NTLM: Audit NTLM authentication in this domain
Value:    Enable All


3) Identify source device that lockout occurred on

 

3.1) Event Comb


Part of Account Lockout and Management Tools https://www.microsoft.com/en-us/download/details.aspx?id=18465


Still a useful tool in a pinch.

Please note: Built-in search for account lockout is not using the newer event IDs. To search newer IDs, add 4625 4740 4771 4768 4776 to the list


For details on these events, see

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=529

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4625

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=644

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4740

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=675

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4771

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=676

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4768

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=681

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventid=4776


EventCombMT-1.pngEventCombMT-2.png


All gathered events from selected domain controllers will be saved into text files in the temp folderevent.png


3.2) Lockout Status


Part of Account Lockout and Management Tools https://www.microsoft.com/en-us/download/details.aspx?id=18465


When you start tool you specify the user account to inspect.


Please note: If the lock device is a Domain Controller, you have to follow the trail until you get to the actual source device name


LockoutStatus.png


3.3) AD Audit


See https://www.manageengine.com/products/active-directory-audit


My personal favorite, AD Audit makes finding the source account that locks device super easy, just use built-in reports


ADAudit.jpg


4.1) Powershell

 

FindUserBadPwdAttempts

https://gallery.technet.microsoft.com/Troubleshoot-Account-Bad-4bf47940


Get-LockedOutLocation

https://gallery.technet.microsoft.com/scriptcenter/Get-LockedOutLocation-b2fd0cab


lock1.png 

4) Identify the source process that locked the account


4.1) NetWrix Account Lockout Examiner


See https://www.netwrix.com/account_lockout_examiner.html


Install NetWrix Account Lockout Examiner on another computer. After that run it and point to the device that generates lockouts.


Lockout.JPG


4.2) ADAudit


See https://www.manageengine.com/products/active-directory-audit


As I said before, my personal favorite. After finding source account that locks device using built-in reports, the Account Lockout Analyzer can show the source process that locks accounts


ADAudit3.jpg


5) Implement processes to prevent future lockouts


5.1 Windows Services, Scheduled Tasks and COM Objects

Utilize service accounts with strong non-expiring passwords or managed service accounts.

5.2 Drive Mappings

Do not map drives with explicit username and password. Utilize Group Policy User Drive Map Preference to map the drive mappings.

Drive-Map-1.png
Drive-Map-2.png


5.3 Logon Sessions

Implement RDP inactive/idling session logoff.


5.4 LAN Manager Authentication Level


Ensure that your LAN Manager Authentication Level is at the required level for your clients and authentication used.


5.5 Externally Exposed RDP


Install a tool such as RDP Guard to automatically block external brute-force attacks or better yet, set up a secure VPN and access RDP from within this VPN


5.6 Credential Manager


Disable the Credential Manager service. This will prevent users from saving/using stored passwords


Credential-Manager.jpg


5.7 Cached Credential


Remove cached credentials for both user and SYSTEM accounts 


For user accounts

rundll32.exe keymgr.dll,KRShowKeyMgr


For SYSTEM accounts

psexec -s -i -d rundll32.exe keymgr.dll,KRShowKeyMgr


Tips

If your account that you are using for the investigation is locking, rename your username for the duration of the investigation


Please do not forget to press the "Thumbs Up" button if this article was helpful and valuable for EE members.

It also provides me with positive feedback. Thank you!

17
  • 8
  • 6
  • 2
  • +3
19 Comments
LVL 46

Expert Comment

by:Mahesh
@ Shaun:

From where you get the recommendation of 50 unsuccessful account lockout threshold
I seen the TechNet article as well, its not recommending value of 50, it just taking arbitrary value as assigned value, its not recommended

The value should not be more than 5 for standard users and for VIP users you should deploy FGPP

Mahesh.
0
LVL 49

Author Comment

by:Shaun Vermaak
Firstly, the MS recommendation is not to have a lockout policy and to have a system to monitor bad logins. This prevents DoS
Configure the Account lockout threshold setting to 0. This configuration ensures that accounts will not be locked, and it will prevent a DoS attack that intentionally attempts to lock accounts. This configuration also helps reduce Help Desk calls because users cannot accidentally lock themselves out of their accounts. Because it does not prevent a brute force attack, this configuration should be chosen only if both of the following criteria are explicitly met:

  •        The password policy setting requires all users to have complex passwords of 8 or more characters.
  •        A robust audit mechanism is in place to alert administrators when a series of failed sign-ins occur in the environment.

If you have to implement a lockout policy the following is recommended

Configure the Account lockout threshold policy setting to a sufficiently high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack still locks the account.

  • A good recommendation for such a configuration is 50 invalid sign-in attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but does not prevent a DoS attack. We recommend this option if your organization cannot implement complex password requirements and an audit policy that alerts administrators to a series of failed sign-in attempts.
  • Using this type of policy must be accompanied by a process to unlock locked accounts. It must be possible to implement this policy whenever it is needed to help mitigate massive lockouts caused by an attack on your systems.
0
LVL 46

Expert Comment

by:Mahesh
Firstly, the MS recommendation is not to have a lockout policy and to have a system to monitor bad logins. This prevents DoS
This is not recommendation by MS
U should make threshold to 0 only if your all users are suffered with account lockout frequently because of viruses or any other reason
if you don't want your admins to notified about account lockout, then above setting can be set to 0, that make sense

If you have to implement a lockout policy the following is recommended
setting up 50 invalid attempts are recommended **only if** complex password policy and auditing cannot be set, this is conditional / workaround thing and not recommendation

Recommendation could be:
Set threshold to 10 and after that account should be locked out for indefinite time until admin unlock account


When there is brute force attack / virus attack or any other saviors issues, you can turn off policy, but not having policy is definitely not a recommendation
0
Check Out How Miercom Evaluates Wi-Fi Security!

It's not just about Wi-Fi connectivity anymore. A wireless security breach can cost your business large amounts of time, trouble, and expense. Plus, hear first-hand from Miercom on how WatchGuard's Wi-Fi security stacks up against the competition plus a LIVE demo!

LVL 49

Author Comment

by:Shaun Vermaak
This is not recommendation by MS
U should make threshold to 0 only if your all users are suffered with account lockout frequently because of viruses or any other reason
if you don't want your admins to notified about account lockout, then above setting can be set to 0, that make sense
Nope, you set it to 0 if you have a robust audit mechanism is in place to alert administrators when a series of failed sign-ins occur in the environment.

Recommendation could be:
Set threshold to 10 and after that account should be locked out for indefinite time until admin unlock account
Nope, too low in a multi-device and technology world

until admin unlock account
I would never set it to lock indefinitely
0
LVL 46

Expert Comment

by:Mahesh
If you run in situation where all users accounts are getting locked frequently what option you have ?
U r setting up threshold to 0?
I have faced this issue during conflicker B virus in year 2008
its not that u could make value 0 if you have robust auditing mechanism

U r looking from unlocking account perspective and not from security perspective

If anybody else from EE can validate your recommendations............
1
LVL 49

Author Comment

by:Shaun Vermaak
If you run in situation where all users accounts are getting locked frequently what option you have ?
U r setting up threshold to 0?
I have faced this issue during conflicker B virus in year 2008
its not that u could make value 0 if you have robust auditing mechanism
Audit tool reports these bad logins and you action it. By having an account lockout policy you open yourself to a DoS (such as conflicker/downadup)
By raising the value to 50 you are reducing support for accidental lockouts while still blocking brute-force attacks.

U r looking from unlocking account perspective and not from security perspective

If anybody else from EE can validate your recommendations............
No, I am not. There is no security implication by changing the value from 3 to 50. Brute-force attacks generation thousands of bad logins per minute. If you have passwords that can be guessed in three tries, you have bigger issues

This a strength test against password "MyDog712". As you can see it has 2 billion combinations in the pattern. The "crack in one day" is when doing offline cracking on hash, not against system.
pass.png
0
LVL 17

Expert Comment

by:Ajit Singh
Nice article! You have really done a good job with article. Here is another how-to article related to track Active Directory account lockouts sources: https://community.spiceworks.com/how_to/128213-identify-the-source-of-account-lockouts-in-active-directory

Both Netwrix and ManageEngine tools are looking promising. BTW, I would also like to add another tool here for AD lockout troubleshooting and i.e. Active Directory auditor from Lepide.

lockout.jpg
Thanks,
0
LVL 46

Expert Comment

by:Mahesh
I appreciate your detailed explanation. Thanks for that

I have checked few other articles / blogs as well.

However still I offen see account lockout policies are set to 5 attempts or 10 attempts max. Specially all financial institutions use account lockout policies
They don't want to allow / provide chance to user to try / guess more and more passwords (may be for other users as well) and same time brute force attacks get failed because of limited logon attempts allowed. Only fact they can't stop DoS attacks, but they do have some kind of 3rd party auditing solutions / IDM solutions which actually try to kill the source of DoS if detected
Possibility of DoS attack is rare in corporate network unless some application is exposed on internet without proper firewall / security system
Hence account lockout policy should be set with 10 attempts which at least stop brute force attacks and to keep user tries in limit
In case of savior issues, you can remove account lockout policy for time being.
1
LVL 49

Author Comment

by:Shaun Vermaak
However still I offen see account lockout policies are set to 5 attempts or 10 attempts max. Specially all financial institutions use account lockout policies
Only because Auditors force them to use setting that were appropriate 10 years ago

They don't want to allow / provide chance to user to try / guess more and more passwords (may be for other users as well) and same time brute force attacks get failed because of limited logon attempts allowed. Only fact they can't stop DoS attacks, but they do have some kind of 3rd party auditing solutions / IDM solutions which actually try to kill the source of DoS if detected
Hence the MS recommendation of a system to check bad logins.

Possibility of DoS attack is rare in corporate network unless some application is exposed on internet without proper firewall / security system
Hence account lockout policy should be set with 10 attempts which at least stop brute force attacks and to keep user tries in limit
In case of savior issues, you can remove account lockout policy for time being.
Not true. Most threats are executed from inside the network
2
LVL 49

Author Comment

by:Shaun Vermaak
Additional motivation from David Sutton
http://ravingroo.com/295/active-directory-account-lockout-policy-threshold-counter-strong-password/
The biggest argument in favor of applying an Account Lockout Policy is to impede brute force attacks. For that reason, common account lockout settings like 5 or 6 failed tries until the account locks will likely lead to increased help desk calls instead of increased security. Since a brute force attack will result in many more failed logon attempts than a user will ever generate, it’s not unreasonable to set the “Account lockout threshold” to a fairly high number. Instead of the usual 5 or 6, why not go with 50, or 100? Even 500 would suffice for this purpose. (Keep in mind the highest value for this setting is 999.) Again, the purpose here is to thwart a brute force attempt, not increase your help desk call log. And the reason I think you should set the threshold to a high value is not because users will manually attempt to logon with a bad password 30 times, it’s because of the above mentioned background services that can trip up your lockout policy. You’d be surprised how high the “bad password count” can get.
1
LVL 46

Expert Comment

by:Mahesh
Ok
Thanks
0
LVL 49

Author Comment

by:Shaun Vermaak
I will continue to research and update as I find information. You comments/interest is appreciated
0
LVL 49

Author Comment

by:Shaun Vermaak
From AD RAP
lockout1.jpg
3
LVL 46

Expert Comment

by:Mahesh
Thanks Shaun.

Your observation and information is correct

I got same inputs from another source

https://blogs.technet.microsoft.com/abizerh/2013/04/21/how-an-incorrectly-configured-account-lockout-policy-can-give-more-pain-than-security/

As a consultant / architect, I use to suggest older way of lockout policy, now that view is changed

Thanks

Mahesh.
2
LVL 11

Expert Comment

by:Senior IT System Engineer
This is awesome article :-)
Thanks for sharing !
0
LVL 32

Expert Comment

by:Blue Street Tech
+1 great article and follow-up Shaun!
0
LVL 2

Expert Comment

by:Tarik M. Zwain
Absolutely great article!
I constantly debate with colleagues about password and lockout policies and how most hinder productivity and provide less security.  I sure wish I'd had your article to reference.  I do now.
1
LVL 11

Expert Comment

by:Senior IT System Engineer
@Shaun,

Regarding the Resetting the cached Creds for SYSTEM accounts
psexec -s -i -d....

Open in new window


Why do you need to use PSExec if you can do it using the cmd prompt RunDLL32.exe ?

Disable the Credential Manager service.
Does that can also reset or clear the currently saved credentials within the local OS or just Microsoft Application only?
0
LVL 49

Author Comment

by:Shaun Vermaak
The one is for the current user and the psexec is for system

No, it does not clear existing saved credentials
1

Featured Post

Powerful Yet Easy-to-Use Network Monitoring

Identify excessive bandwidth utilization or unexpected application traffic with SolarWinds Bandwidth Analyzer Pack.

The Email Laundry PDF encryption service allows companies to send confidential encrypted  emails to anybody. The PDF document can also contain attachments that are embedded in the encrypted PDF. The password is randomly generated by The Email Laundr…
Sometimes it takes a new vantage point, apart from our everyday security practices, to truly see our Active Directory (AD) vulnerabilities. We get used to implementing the same techniques and checking the same areas for a breach. This pattern can re…

Keep in touch with Experts Exchange

Tech news and trends delivered to your inbox every month