Account locked out event id is 4740
Event ID 4740 is generated on domain controllers, Windows servers, and workstations every time an account gets locked out.
Monitoring AD Account Lock-Out Events With Powershell
Unlocking AD account is one of the basic task for every system administrator.
It’s very easy to underestimate it, in fact, this operation isn’t perceived not just by users, but more importantly by junior engineers not important at all! Frequently providing some general feedback to the user on this issue or simply a response that this issue is now it’s been fixed.
On top of that, I’ve found that in some situation finding the root cause it requires a bit of investigation and experience not just to guess what more likely is causing it and not many of us are willing to take this effort.
But I like to explain and document what happened to the user, to me it’s absolutely key to raise the awareness and trust people and processes involved in the IT System.
How to unlock AD Accounts?
AD User and Computers or RSAT (Remote Server Administration Tool) and more specifically ADAC (Active Directory Administrative Center) are the go-to choices for most sysadmins, it offers a neat and very intuitive interface that it’s very easy to become familiar with the interface.
But, again, what I think is more effective is Powershell for the lockout events analysis and solution in all phases. Let me explain why.
First of all, every issue, not just simple user support request have these 5 usual steps:
- Mitigate
- Investigate/ Root Cause Analysis
- Solve
- Document
- Monitor
Let me show you how to achieve all these steps with Powershell, if you like you can also glue all these scripts together in one, for example for this unlocking an account (unlock the account, investigate on the root cause, send an email to the user with the findings and keep it monitor for another hour).
Unlock the account
A simple AD Account lock-out event can be perceived differently and the impact on productivity can be subjective, in any case, our intent in case this event was triggered by the legitimate user by mistake our goal is to limit this access outage to be shorter as possible and protecting our environment at the same time.
So let’s start with the first step search for a locked out account (these cmd-lets requires the ActiveDirectory module).
If you know the user you can search it using the display name attribute
So the action to mitigate is simply using the cmd-let:
And if we have an AD User object or list of object we can pipe the commands :
In this example, we unlocked all locked-out users. It’s a good idea to use the arguments -confirm, -whatif or -verbose to show a little bit more output on the shell session.
Investigate / Find the root cause of Lockout Event
Users have a limited knowledge of the security policies involved in the IT Systems. An account locked out it’s a good opportunity of for the user to know what he needs to prevent for happening again and for the system administrator to measure the user awareness of how the IT systems work.
AAA of the security: Authentication, Authorization and Accounting
All user are sometimes familiar with AD password complexity and requirements, but not on the security policies that apply to the authentication process.
So let’s show them what rules are applied for each user password with this simple cmd-let according to the Group Policies of your AD domain:
All keys and value are easy to explain the important values here are mainly 3:
- LockoutThreshold (5)
- LockoutObservationWindow (15minutes)
- LockoutDuration (15minutes)
The way that I simply explain this security policy with an example like this:
It’s implicit that even with the right password if the account is still locked out every authentication process will fail. The lockout will last just 15 minutes, then the user will be able to log in again.
To unlock it manually the required permissions are delegated to a support security group or performed directly by a Domain Admin.
Not all users are aware of what is a brute-force attack, or a dictionary attack, for this reason, in order to prevent these risks we need security policies to mitigate or make these types of attacks more visible for the admins and expensive for the attacker.
Ok, now we know the why and what policies that are applied in our organization. But what happened to that user account?
User authentication attempts on devices, computers or servers joined to the domain are requested to a Domain Controller. These requests are logged and with event viewer, we can filter the Windows Logs, Security and filter the ID 4740:
With powershell, we can even perform this operation remotely and against more ADDC.
In case you have multiple DC you can simply pipe the list to the same one-liner
I’m just interested in the newest 5 events. The Message field contains also the Caller ID, the source hostname of the authentication request that caused the lockout.
There is also an interesting function on the powershell gallery called Get-LockedOutLocation
Document
The common root cause for a lockout can be simple or more complicated according to the experience of the user, but in general, a user change password and then there are some authentication attempts:
- from application or clients with an old password saved
- a shared folder mount persistently
- script or service running with an old password
Especially for junior developers service accounts usage is sometimes avoided or left as the last step. But using user accounts instead of service accounts or storing that credential is some scripts are all bad practices that’s better to stop from the start.
Service Accounts benefits
Service accounts have limited access (according to least privilege principle), a strong credential, the password can be set to never expire and the password can’t be changed.
Document all these steps can be a simple script that collects all the previous commands, a brief description of the security policies and can be pasted on the support request or emailed back to the user.
Lock-out Events can be rare, but when the change credential and there is a first lockout event, can happen again triggered by some other request. For this reason after the first attempt can be useful to monitor lockout events.
Monitoring: Active Directory account LockOut
I’ve created this ad-hoc script that whenever an AD User is being locked out it displays a toast message with the username.
This is a sample of the notification message using BurntToast:
BurntToast it’s really nice if you haven’t tried it already please do! It’s flexible and easy to use.
Let’s prove that works with a test account.
In this last part I wrap up on a powershell script a way to prove all that I’ve explained creating a test account and locking out and search for the caller id:
It’s a long article, I hope that you’ll find it useful. As always all these scripts are available on my github repository.
No comments:
Post a Comment