asked on
Domain Accounts locking
After much troubleshooting, I've concluded my issue to be something on my network that I need help finding. My network is a Microsoft single domain 2012 environment - something is running/brute-forcing all domain accounts passwords. When my GPO under Computer-Policies-Windows Settings-Security Settings- Account Policies/Password Policy-Acct. Lockout duration is set for 10 minutes and Account lockout threshold is set for 5 invalid login attempts, the phones don't stop ringing for 200 users; everyone gets locked out. If I alter the settings to a Lockout duration set for 2 minutes and Account lockout threshold set for 200 invalid login attempts, the calls/lockouts stop but I still have the issue. I'm verify this using the lockoutstatus.exe 1.0.0.60 provided by the Windows Resource Kit by looking at the last bad password time. They are all within the last 24 hours for all user accounts. Luckily, the domain Administrator account is never effected but all others are.
I have 1 physical Domain Controller. I have virus protection on every node and server. Everything is clean according to my Anti-virus service.
Question - What software program can I purchase that will help pin-point the issue or what other methods are available that can help pin-point the issue?
I have 1 physical Domain Controller. I have virus protection on every node and server. Everything is clean according to my Anti-virus service.
Question - What software program can I purchase that will help pin-point the issue or what other methods are available that can help pin-point the issue?
Windows OSWindows Server 2012Active DirectoryNetworkingSecurity
Last Comment
Brad Knight
the lockout status tool will tell you what domain controller is locking them out and at what time. Go to that domain controller and open the security events log. Look for the entry that coincides with the date and time of the lock out. It will tell you the ip address of the machine that is locking you out
Usually this is a some service being accessible to the outside world, and hackers "rattling the locks" If you have an FTP site, then this is quite normal.
Please have a look at the guide to investigate account lockouts
https://www.experts-exchange.com/articles/29305/Active-Directory-Locked-Account-Investigation-Process.html
https://www.experts-exchange.com/articles/29305/Active-Directory-Locked-Account-Investigation-Process.html
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
Hi,
Andry has right
the lockout status tool will give you the details to find the source of the problem
Also Security event logs can give you info to investigate your problem.
You can disable the GPO and enable it in after work hours to investigate without has the phone to ring without stop.
Andry has right
the lockout status tool will give you the details to find the source of the problem
Also Security event logs can give you info to investigate your problem.
You can disable the GPO and enable it in after work hours to investigate without has the phone to ring without stop.
Download the account lockout tools and management pack to help resolve the issue:
https://www.microsoft.com/en-us/download/details.aspx?id=18465
How to track and troubleshoot User Account Lockouts with LepideAuditor:
https://www.lepide.com/how-to/track-and-troubleshoot-user-account-lockouts-with-lepideauditor.html
How to Detect Source of Account Lockouts in Active Directory:
https://www.lepide.com/how-to/identify-the-source-of-account-lockouts-in-active-directory.html
https://www.microsoft.com/en-us/download/details.aspx?id=18465
How to track and troubleshoot User Account Lockouts with LepideAuditor:
https://www.lepide.com/how-to/track-and-troubleshoot-user-account-lockouts-with-lepideauditor.html
How to Detect Source of Account Lockouts in Active Directory:
https://www.lepide.com/how-to/identify-the-source-of-account-lockouts-in-active-directory.html
Which systems that are tied to AD are remotely accessible? This includes workstations.
ASKER
Thanks to all that has replied. I've been away and I apologize for the later than usual response.
Andy B. - I have a single Domain Controller so the server is known and as I stated I've been using the lockout status tool. I've searched the Event security logs for IP addresses and can not find them. Can you be more specific as to how to find the IP address of the source.
Mal - I will check to see if we have FTP enabled and disabled it if we can. We do use and need IIS on the DC for the Intranet site.
Shawn - Will check the link out. Just responding right now. Thanks.
Naveem - Thanks for the links. I will check them out.
Arnold - I may not have the right GPO's enabled in Auditing. Having trouble finding events for the lockouts. The company uses Hosted Exchange (Intermedia) with DirectoryLink enabled. We thought this was the culprit and disabled DirectoryLink. But it's still happening. So DirectoryLink is still disabled during this time. Directory Link is a One-way Sync from the C to the Hosted Exchange server for AD. I'm currently researching the right GPO's to put in place in the Advanced Auditing GPO.
Kostas - The Lockoutstatus tool does not help finding the source except for knowing the times when the account locks. Again, I've searched in the Event security logs within the time frame of the lockout and can not find anything that can help me find the source IP/machine that is locking the account. We are a 24/7 shop and my only scheduled down time is 6pm - 6am on Saturdays and Sundays.
Masnrock - domain is behind a Sonicwall with Global VPN enabled with Sonicwall user accounts. RDP is open on a few clients inside the network.
Thank you for all the input thus far. I will check on the links and report back.
B. Knight
Andy B. - I have a single Domain Controller so the server is known and as I stated I've been using the lockout status tool. I've searched the Event security logs for IP addresses and can not find them. Can you be more specific as to how to find the IP address of the source.
Mal - I will check to see if we have FTP enabled and disabled it if we can. We do use and need IIS on the DC for the Intranet site.
Shawn - Will check the link out. Just responding right now. Thanks.
Naveem - Thanks for the links. I will check them out.
Arnold - I may not have the right GPO's enabled in Auditing. Having trouble finding events for the lockouts. The company uses Hosted Exchange (Intermedia) with DirectoryLink enabled. We thought this was the culprit and disabled DirectoryLink. But it's still happening. So DirectoryLink is still disabled during this time. Directory Link is a One-way Sync from the C to the Hosted Exchange server for AD. I'm currently researching the right GPO's to put in place in the Advanced Auditing GPO.
Kostas - The Lockoutstatus tool does not help finding the source except for knowing the times when the account locks. Again, I've searched in the Event security logs within the time frame of the lockout and can not find anything that can help me find the source IP/machine that is locking the account. We are a 24/7 shop and my only scheduled down time is 6pm - 6am on Saturdays and Sundays.
Masnrock - domain is behind a Sonicwall with Global VPN enabled with Sonicwall user accounts. RDP is open on a few clients inside the network.
Thank you for all the input thus far. I will check on the links and report back.
B. Knight
ASKER
All:
Very frustrated. I've reconfigured my domain GPO to do the auditing suggested by Shaun's link above. I've cleared the security log and ran gpudate /force on all test workstations and domain controller. I've intentionally locked a domain account from a workstation and nothing is logged in the security log of the DC. If I intentionally lock the account on the DC, the security log on the DC has entries. But this method does not help because I'm trying to find which network device is locking my AD accounts. If a workstation locks the domain account, is there anythign logged in the security log of the DC?
FTP is not enabled on the DC.
Any other suggestions?
Very frustrated. I've reconfigured my domain GPO to do the auditing suggested by Shaun's link above. I've cleared the security log and ran gpudate /force on all test workstations and domain controller. I've intentionally locked a domain account from a workstation and nothing is logged in the security log of the DC. If I intentionally lock the account on the DC, the security log on the DC has entries. But this method does not help because I'm trying to find which network device is locking my AD accounts. If a workstation locks the domain account, is there anythign logged in the security log of the DC?
FTP is not enabled on the DC.
Any other suggestions?
The default domain control policy is to audit all security login/logout events.
The domain controller OU is separated from the Default domain policy.
clearing a security log is unnecessary.
Check the space you allocate to the security log on the DC to make sure it is has the amount of space needed to store events for a few weeks without being overwritten.
Make sure you are not getting frequent events that leads to the clearing of the log, i.e. older items being overwritten by newer one.
the security log on the workstation will reflect failed/successful login requests if that is the GPO auditing login/logout event you set.
The workstation as it is not the one locking, will not have account locking event, it would have a failed login message whose cause is that the account is locked out.
If you could, post the auditing GPO settings you added.
computer auditing GPO settings change requires a reboot as it \applies to the system.
To identify the locking, you first Identify the DC that locked the account using the accountlockout tool.
Then you look at the security log on the DC that locked the account, for the Account Lock event along with the login events.
Once you identify the time when the account locked, the login attempt immediately preceeding it for the user would include the source that submitted the request to authorize/authenticate the user.
With this in hand, you would go to the system, workstation identified to see what is going on there. I.e. if server, does it have a specific task, function, purpose. ....
Terminal Servers/RDS where users left disconnected session will lead to lockouts after the user changes their password. the disconnected session retains the old token and periodically will try to re-validate access to whatever the session has i.e. mapped drives, etc. several attempts and based on your lockout policy the account will be locked.
The domain controller OU is separated from the Default domain policy.
clearing a security log is unnecessary.
Check the space you allocate to the security log on the DC to make sure it is has the amount of space needed to store events for a few weeks without being overwritten.
Make sure you are not getting frequent events that leads to the clearing of the log, i.e. older items being overwritten by newer one.
the security log on the workstation will reflect failed/successful login requests if that is the GPO auditing login/logout event you set.
The workstation as it is not the one locking, will not have account locking event, it would have a failed login message whose cause is that the account is locked out.
If you could, post the auditing GPO settings you added.
computer auditing GPO settings change requires a reboot as it \applies to the system.
To identify the locking, you first Identify the DC that locked the account using the accountlockout tool.
Then you look at the security log on the DC that locked the account, for the Account Lock event along with the login events.
Once you identify the time when the account locked, the login attempt immediately preceeding it for the user would include the source that submitted the request to authorize/authenticate the user.
With this in hand, you would go to the system, workstation identified to see what is going on there. I.e. if server, does it have a specific task, function, purpose. ....
Terminal Servers/RDS where users left disconnected session will lead to lockouts after the user changes their password. the disconnected session retains the old token and periodically will try to re-validate access to whatever the session has i.e. mapped drives, etc. several attempts and based on your lockout policy the account will be locked.
ASKER
I ended up using the AD Audit tool which I downloaded and it was able to pinpoint the system(s) that were locking my user accounts on my domain. Never really found what it was on the systems that were locking because of time and resources. I just re-imaged these systems and the problems were rectified. The logs never was a resource in finding my issues which was a disappointment. I will try to figure out why later down the road. I have GPO and auditing enabled I'm thinking but it obviously isn't setup right because the logs never provided the codes that were mentioned above. The AD Audit tool was available free for 30 days. This provided enough information to find the problem. I'm looking at purchasing this tool now for the future.
Thanks for everyone's input.
Thanks for everyone's input.