Active Directory: Account Lockouts - Locating the Source (Bonus: Account Modifications)
Article Updated: 8/20/2021
Note: Due to the difficulty of maintaining multiple copies of this article, this LinkedIn version will no longer be updated. Please visit YuenX.com for the latest content.
-------------------------
If you are in IT, you are more than likely aware of issues that can arise from account lockouts, especially on a service account in use by a critical application or infrastructure component.
A lockout can prevent you, an application, or the business from continuing work. So, how do you go about in finding the source of the lockout?
I will dive into why lockouts occur, share troubleshooting steps, look at helpful tools, and guide you into interpreting logs so that the problem can be resolved as quickly as possible.
NOTE
This article was originally published at www.yuenx.com. Formatting capabilities on LinkedIn are limited. Please visit the site instead for the best experience and presentation.
Related:?Visualize Account Lockout events (above screenshot) with my?AD Lockout Splunk Dashboards?to graphically identify patterns. For investigating?Group-related events, see my?Group and Membership Changes?post.
Bonus
As an added bonus, I have included information on how to look up when an account was modified, disabled, enabled, unlocked, password reset — and by whom.
Active Directory Accounts
Let's look at what Active Directory is and how network logins are related.
Microsoft's Active Directory (AD) is a service that governs how resources can be utilized by a collection of users, groups, and computers. Enterprises use AD to authenticate, authorize, secure, and audit access within a security boundary -- a Domain -- to file servers, computers, emails, and more. You are given a user account (often referred to as your "network login") to access what has been made available to you. A Domain Controller (DC) is the server that contains a copy of the AD database and is responsible for the replication of said data between all other DCs within the Domain.
To secure the company network, Active Directory uses Group Policy Objects (GPOs) to define various user- and computer-related settings, including password policies and the Account Lockout Threshold. The latter controls when an account is locked after a set number of failed login attempts. If you mistype your password three times, for example, it would be locked for a specified time or until an administrator unlocks. This is an important security step to frustrate an unauthorized person from gaining access.
What Happens During a Lockout?
Behind the scenes, when an incorrect password was provided for an account, the Domain Controller that it authenticated to relays the request to the DC holding the “PDC Emulator” role. The PDC Emulator always holds the account’s most recent password, and so it will re-check the provided password against its own database. If it is still incorrect, the PDC Emulator increments the?badPwdCount?attribute of the account, and an invalid login is recorded to a Security Event Log. If the?badPwdCount?has met the?Account Lockout Threshold, the DC will lock the account, record Event ID 4740 (more on that later) to its Security log, and notify the other Domain Controllers of the locked state. The key here is that every lockout is known by the PDC Emulator.
The?PDC Emulator?can be found through multiple ways, and my preferred one is via the command line:
Command Prompt:?nltest /dclist:name (where?name?is the AD Domain name)
PowerShell
# Get the PDC Emulator for the current AD domain
(Get-ADDomain).PDCEmulator
# Get the PDC Emulator for "name" (either AD Domain or Domain Controller)
(Get-ADDomain -Server name).PDCEmulator
Account Lockout Threshold
Here are two ways to quickly find the configured,?Domain-wide threshold. A value of 0 means the account will never be locked. This setting can be from 0 to 999.
Warning:?If your company uses?Fine-Grained Password Policies?(FGPP) introduced with Windows Server 2008, the above commands may not reflect the password policy actually applied to individual accounts or Global Groups. FGPP allows an administrator to?set different password policies?for various groups, such as privileged administrator accounts that require more restrictive settings, than what is configured for the entire domain using GPO. FGPPs take precedence over the domain-wide GPO.?Learn more
You may view a user’s FGPP in PowerShell with:?Get-ADUserResultantPasswordPolicy?username. However, your administrator may not have granted rights to view it if the result ends with the error, “Cannot find an object with identity: ‘CN=UserPasswordPolicy,CN=Password Settings Container,CN=System,DC=yuenx,DC=com”.
Account Lockout Status
You can use?Active Directory Users and Computers?(ADUC) to check on an account’s lockout status. However, for automation purposes, I prefer the command line:
To check lockout state:
If “Account active” is “No”, it is locked or disabled.
To unlock:
Troubleshooting
When I used to be in Desktop Support with large companies, I came across lockout tickets all the time. As a Systems Engineer, I have more tools and access rights at my disposal to troubleshoot issues that were escalated to me. If after unlocking an account, the lockouts continue to occur, here are the general things I look at. Be sure to check both the?local?computer and any?remote?servers the account may have been used at.
General Areas
Has the password been mistyped? One way to find out is to open a command prompt as that account via?RunAs. If there is no error, the password is correct.
Look for disconnected or idle remote desktop/terminal server sessions. Check mobile devices, email clients in particular. If your company uses Outlook Web Access (OWA), look for any mobile devices associated with the email account (Go to OWA > Options > Mobile Devices). Reboot the device as needed. Have the user check their personal computers and devices.
TIP:?You can write a PowerShell script to gather all disconnected remote desktop/terminal server sessions from a list of computer names
Disconnect all mapped drives and log out (or reboot). Any drives mapped by GPO would automatically reconnect upon login.
Look for any tasks configured to run as the account.
Take a look at the Web Passwords and the Windows Credentials sections.
Check saved credentials. Delete cookies and temporary files. As a last resort, try deleting the browser history and all saved passwords.
With service accounts especially, be sure the applications are using the correct password. If lockouts are occurring for multiple users from the same server, there may be a culprit application. Check any applications that automatically log in.
Go to?services.msc?and check any services that may be running under the affected account.
Have the account logged off from every computer so the roaming profile is fully synchronized. Rename the roaming profile on the server. We will be creating a NEW one with the next step. As another user with admin rights, delete the roaming profile from ONE computer, then log on to it. A new roaming profile will be created on the computer. Log off so it synchronizes a fresh copy to the server. If the issue goes away, delete the roaming profiles on the other computers. Finally, manually copy any data from the old profile (on the server) back to the new one.
There may be a policy misconfiguration or the network is under attack.
Has there been a worm infection recently? Worms are self-replicating malware that can use your credentials to travel across the network.
True story:?In 2007, I was hunting a lockout for several days. I do not remember the details of how I found the MAC address of the culprit, but I asked the network team to check the switches to locate the port it came from. From the port, we traced to the connected computer, but oddly, there was no Windows profile for the affected account. As a result, that PC was initially dismissed, but lockouts kept coming from that address. Ultimately, I discovered that the account had a drive mapped under another user’s profile. That person likely mapped a network share to get something, but forgot to disconnect it when done.
Tip:?If you get a hold of a MAC address, you can try to look up the manufacturer?here,?here, or?here?to help narrow down the hardware. The first 6 characters (example: AC:E2:D3) identify the manufacturer. In the example, that would be “Hewlett Packard”, my HP laptop.
Advanced Areas
Check the Account Lockout Threshold policy and see if it may be too restrictive, such as one that locks out after just 1 failed attempt. A Denial of Service (DoS) attack may take advantage of this to disrupt a business. Check replication performance between affected sites. There may be a delay in replicating password changes. Check the Security log with the Windows Event Viewer on Domain Controllers that have recorded Bad Password Counts, paying special attention to various Event IDs. A free tool from Microsoft can help with gathering that information. More details on that and Event IDs later.
Should you have narrowed down the lockouts to come from a particular computer, and none of the general troubleshooting steps have helped, temporarily try logging some events locally. On the computer, with elevated administrator rights, run “gpedit.msc". Go to Computer Configurations >?Windows Settings > Security Settings > Local Policies > Audit Policy, and enable: "Audit logon events:?Success, Failure" and "Audit process tracking:?Success, Failure".
Once the account locks again, check the Event Viewer’s Security log, paying attention to lockout-related Event IDs that I will describe later in this post. Some of the events can give you insight into what Caller Process or Source Network Address may have triggered the lockout.
Hackers may be trying to guess someone’s password through various means, such as a brute force attack. A disgruntled employee may be locking his or her manager’s account on purpose.
领英推荐
An external company the security team has hired may be performing a penetration test with unexpected results.
True story:?A penetration test happened at one of my employers during the middle of the day that inadvertently locked out multiple accounts, prompting our team to hunt down a possible hack attempt. This brought to our attention that this type of Denial of Service attack could easily disrupt a business if someone got a hold of the account names or login format.
Start with the “Account Lockout Status” section above to develop your script.
True story:?Recently, a service account used for backing up virtual machines, files, and more kept locking. I received a Sunday call at 7:30pm with an urgent call for help as backups were failing. After 4.5 hours of troubleshooting, checking Splunk logs, and using other methods, we were unable to find the lockout source. It was now midnight and some were tired.
Thankfully, I was writing a PowerShell script during the call — just in case we needed to automate — that would check whether an account was locked out and at what time it occurred. It would then give the option to unlock once or to continuously monitor and automatically unlock. Ultimately, we used it so backups could complete while we got some rest. (Do you see why I prefer the command line and automating things?)
The next morning, we found that the password was typed incorrectly on one of the backup servers.
Don’t forget:?Wherever you had enabled additional debugging or auditing, remember to turn them off so that performance does not suffer or space runs out!
Gathering Account Activity
As illustrated earlier, troubleshooting lockouts can be a very time consuming process. Not only are lockouts frustrating for the user, application owner, or even the business, but the IT person tends to get the brunt of that even if it was not his or her fault. There are some tools you could use to help with troubleshooting, all of which essentially comb the?Security?section of the Windows Event Log. Here are some of my favorites.
Free Tools
This is Microsoft’s own utility. Lockoutstatus.exe:?Displays the?Bad Pwd Count,?Last Bad Pwd?date and time, when the password was last set, when the Lockout occurred, and which DC reported this data.
EventCombMT: Can search through a list of Domain Controllers for specific lockout-related Event IDs associated with the account. It will save the output to a text file, showing successful and failed login attempts. Depending on your environment, this can take several hours to complete.
Search for: 529, 644, 675, 676, 681,?4624,?4625,?4740, 4770, 4771,?4776. See the “Interpreting Account Activity” section below for Event ID details.
This is a popular, free tool that gives you quite a lot of details. It also performs a few, simple troubleshooting checks for you. However, I have tried the licensed version at two companies, and both times we ran into the same issue: it appears to have a memory leak that requires the server to be rebooted from time to time
Scripts
Windows provides a free, built-in way to perform certain tasks when a specific Event ID is recorded to the Event Log. If you recall, I mentioned earlier that the PDC Emulator records all lockout events. Use this fact to have the Domain Controller send you an email every time a lockout event (ID 4740) has occurred. This is accomplished through?an Event-based Triggered Task. When configured, you will see the trigger job listed in the DC’s Task Scheduler.
Having all the lockout emails stored in one folder allows you to search for a specific name and quickly scan through the details. This saves you from having to search through multiple Domain Controllers’ Event Logs.
Tip:?You can control what the email contains by writing a PowerShell script that formats and provides exactly the details that you may be interested in, including: Username, Domain, Caller Machine, Event ID, Lockout time, Failure reason, Logon type, Caller Process Name, Source Network Address, Source Port, and more.
You may realize by now that I am a supporter of PowerShell scripting. I have written a few of my own to aid with troubleshooting lockouts. However, they are beyond the scope of this post, although I may share some in the future. Meanwhile, there are many, readily-available scripts at the?PowerShell Gallery?that you may want to look at.
Tool: Splunk ($)
Splunk is a VERY powerful, expensive tool that aggregates logs from multiple sources (such as systems, applications, network devices, and more) to allow you to search, monitor, and analyze a wealth of Big Data. It is a very useful?SIEM?(Security Information and Event Management) tool that can also be used to deconstruct a timeline of events, such as a breach in the network.
I was first introduced to Splunk in late 2017 at one of my past employers, but did not have the opportunity to try it until this year. Knowing that the software aggregates Active Directory logs at my current employer, I wanted to see how Splunk Cloud could be used to help with lockout troubleshooting. Its administrator, however, was always too busy to help, and there were no good search queries I could find on the web at the time. Naturally, I decided to learn some of the Splunk?Search Processing Language?(SPL) on my own. Here is what I came up with.
Tip:?See the “Interpreting Account Activity” section below on how to read the data that Splunk and other tools produce
Search for Lockout-related Events
This query will locate any events within the last 14 days that contribute to an account’s lockout, including failed password attempts (and how the logon was used), which machine, IP address, and/or process spawned the event, and the actual lockout.
index="*" Account_Name=Michael.Yuen
earliest=-14d latest=now() source=WinEventLog:Security
(EventCode=4740 OR EventCode=4625 OR EventCode=644 OR EventCode=529 OR EventCode=675 OR EventCode=676 OR EventCode=681 OR EventCode=4771 OR EventCode=4776 OR EventCode=4777 OR EventCode=4725 OR EventCode=4724 OR EventCode=4767)
| eval Account0=mvindex(Account_Name,0) | eval Account1=mvindex(Account_Name,1)
| eval Account=case(EventCode==4624,Account1, EventCode==4625,Account1, EventCode==4648,Account1, EventCode==4722,Account1, EventCode==4724,Account1, EventCode==4725,Account1, EventCode==4738,Account1, EventCode==4740,Account1, EventCode==4767,Account1, EventCode==4768,Account0, EventCode==4769,Account0, EventCode==4771,Account0, EventCode==5140,Account0) | fillnull Value="-" Account
| eval ActionBy=case(EventCode==4725,Account0, EventCode==4722,src_user, EventCode==4767,src_user, EventCode==4724,src_user, EventCode==4738,src_user)
| eval Time=strftime(_time, "%m/%d/%y %H:%M:%S") | sort -_time
| eval Caller_Machine=if(Caller_Machine_Name!= NULL, Caller_Machine_Name, Caller_Computer_Name) | fillnull Value="-" Caller_Machine
| eval Caller_Process_Name=if(like(Caller_Process_Name, "%lsass.exe%"), "lsass.exe", Caller_Process_Name)
| eval EventCode=case(EventCode==4740, "4740 Locked", EventCode==4625, "4625 Logon Failed", EventCode==644, "644 Locked", EventCode==529, "529 Logon Failed", EventCode==4771, "4771 Kerberos Pre-Auth Failed", EventCode==4624, "4624 Logon OK", EventCode==4648, "4648 Logon Attempt Explicit Creds (ie. Task/RunAs)", EventCode==4767, "4767 Unlocked", EventCode==12294, "12294 Potential attack against Administrator", EventCode==4725, "4725 Disabled", EventCode==4722, "4722 Enabled", EventCode==4724, "4724 Password reset attempted", EventCode==4738, "4738 Object changed", EventCode==4720, "4720 Created", EventCode==4726, "4726 Deleted", 1=1, EventCode)
| eval Logon_Type=case(Logon_Type==2, "2 Interactive", Logon_Type==3, "3 Network", Logon_Type==4, "4 Batch", Logon_Type==5, "5 Service", Logon_Type==7, "7 Unlock", Logon_Type==8, "8 NetworkClearText", Logon_Type==9, "9 NewCredentials", Logon_Type==10, "10 RemoteInteractive", Logon_Type==11, "11 CachedInteractive", 1=1, Logon_Type)
| rename name as "EventCodeDescription"
| table Time, Account, EventCode, ActionBy, Caller_Machine, Failure_Reason, Client_Address, Logon_Type, Caller_Process_Name, ComputerName, Workstation_Name, Source_Network_Address, Source_Port, EventCodeDescription
Tips: Replace "Account_name=" with "ComputerName=XYZ" [where "XYZ" is either a computer's FQDN or "Name*" (wildcard)] to search for events logged by that machine. Replace 'Index="*"' with the appropriate index to search through
Search for Non-Lockout-related Events
This query will help figure out where the account may have been used successfully within the last 14 days, including logons, logoffs, and which machines, IP addresses, and/or processes contributed to the event. Optionally, it will also show who unlocked the account.
index="*" Account_Name=Michael.Yuen
earliest=-14d latest=now() source=WinEventLog:Security
NOT (EventCode=4740 OR EventCode=4625 OR EventCode=644 OR EventCode=529 OR EventCode=675 OR EventCode=676 OR EventCode=681 OR EventCode=4771 OR EventCode=4776 OR EventCode=4777) NOT EventCode=4767
| eval Account0=mvindex(Account_Name,0) | eval Account1=mvindex(Account_Name,1)
| eval Account=case(EventCode==4624,Account1, EventCode==4625,Account1, EventCode==4648,Account1, EventCode==4722,Account1, EventCode==4724,Account1, EventCode==4725,Account1, EventCode==4738,Account1, EventCode==4740,Account1, EventCode==4767,Account1, EventCode==4768,Account0, EventCode==4769,Account0, EventCode==4771,Account0, EventCode==5140,Account0) | fillnull Value="-" Account
| eval ActionBy=case(EventCode==4725,Account0, EventCode==4722,src_user, EventCode==4767,src_user, EventCode==4724,src_user, EventCode==4738,src_user)
| eval Time=strftime(_time, "%m/%d/%y %H:%M:%S") | sort -_time
| eval Process_Name=if(like(Process_Name, "%lsass.exe%"), "lsass.exe", Process_Name)
| eval EventCode=case(EventCode==4740, "4740 Locked", EventCode==4625, "4625 Logon Failed", EventCode==644, "644 Locked", EventCode==529, "529 Logon Failed", EventCode==4771, "4771 Kerberos Pre-Auth Failed", EventCode==4624, "4624 Logon OK", EventCode==4648, "4648 Logon Attempt Explicit Creds (ie. Task/RunAs)", EventCode==4767, "4767 Unlocked", EventCode==12294, "12294 Potential attack against Administrator", EventCode==4725, "4725 Disabled", EventCode==4722, "4722 Enabled", EventCode==4724, "4724 Password reset attempted", EventCode==4738, "4738 Object changed", EventCode==4720, "4720 Created", EventCode==4726, "4726 Deleted", 1=1, EventCode)
| eval Logon_Type=case(Logon_Type==2, "2 Interactive", Logon_Type==3, "3 Network", Logon_Type==4, "4 Batch", Logon_Type==5, "5 Service", Logon_Type==7, "7 Unlock", Logon_Type==8, "8 NetworkClearText", Logon_Type==9, "9 NewCredentials", Logon_Type==10, "10 RemoteInteractive", Logon_Type==11, "11 CachedInteractive", 1=1, Logon_Type)
| rename name as "EventCodeDescription"
| table Time, Account, TaskCategory, EventCode, ActionBy, Logon_Type, Process_Name, ComputerName, Source_Network_Address, Source_Port, Network_Address, Port, EventCodeDescription?
Note:?Remove “NOT EventCode=4767” in the query above, if you want to also see who unlocked the account.
Search for ALL Events related to the account
This query combines lockout-related and non-lockout-related events from the last 14 days for a better look at the timeline leading up to a lockout.
index="*" Account_Name=Michael.Yuen
earliest=-14d latest=now() source=WinEventLog:Security
| eval Account0=mvindex(Account_Name,0) | eval Account1=mvindex(Account_Name,1)
| eval Account=case(EventCode==4624,Account1, EventCode==4625,Account1, EventCode==4648,Account1, EventCode==4722,Account1, EventCode==4724,Account1, EventCode==4725,Account1, EventCode==4738,Account1, EventCode==4740,Account1, EventCode==4767,Account1, EventCode==4768,Account0, EventCode==4769,Account0, EventCode==4771,Account0, EventCode==5140,Account0) | fillnull Value="-" Account
| eval ActionBy=case(EventCode==4725,Account0, EventCode==4722,src_user, EventCode==4767,src_user, EventCode==4724,src_user, EventCode==4738,src_user)
| eval Time=strftime(_time, "%m/%d/%y %H:%M:%S") | sort -_time
| eval Caller_Machine=if(Caller_Machine_Name!= NULL, Caller_Machine_Name, Caller_Computer_Name) | fillnull Value="-" Caller_Machine
| eval Process_Name=if(like(Process_Name, "%lsass.exe%"), "lsass.exe", Process_Name) | eval Caller_Process_Name=if(like(Caller_Process_Name, "%lsass.exe%"), "lsass.exe", Caller_Process_Name)
| eval EventCode=case(EventCode==4740, "4740 Locked", EventCode==4625, "4625 Logon Failed", EventCode==644, "644 Locked", EventCode==529, "529 Logon Failed", EventCode==4771, "4771 Kerberos Pre-Auth Failed", EventCode==4624, "4624 Logon OK", EventCode==4648, "4648 Logon Attempt Explicit Creds (ie. Task/RunAs)", EventCode==4767, "4767 Unlocked", EventCode==12294, "12294 Potential attack against Administrator", EventCode==4725, "4725 Disabled", EventCode==4722, "4722 Enabled", EventCode==4724, "4724 Password reset attempted", EventCode==4738, "4738 Object changed", EventCode==4720, "4720 Created", EventCode==4726, "4726 Deleted", 1=1, EventCode)
| eval Logon_Type=case(Logon_Type==2, "2 Interactive", Logon_Type==3, "3 Network", Logon_Type==4, "4 Batch", Logon_Type==5, "5 Service", Logon_Type==7, "7 Unlock", Logon_Type==8, "8 NetworkClearText", Logon_Type==9, "9 NewCredentials", Logon_Type==10, "10 RemoteInteractive", Logon_Type==11, "11 CachedInteractive", 1=1, Logon_Type)
| rename name as "EventCodeDescription"
| table Time, Account, TaskCategory, EventCode, ActionBy, Caller_Machine, Failure_Reason, Client_Address, Logon_Type, Process_Name, Caller_Process_Name, ComputerName, Workstation_Name, Source_Network_Address, Source_Port, Network_Address, Port, EventCodeDescription
Bonus: Search for Account Disable, Enable, Unlock, Modify, Create, Delete, Password Reset — and by Whom
This query searches through the last 30 days for specific account modification events — and by whom.
index="*" Account_Name=Michael.Yuen
earliest=-30d latest=now() source=WinEventLog:Security
(EventCode=4725 OR EventCode=4722 OR EventCode=4724 OR EventCode=4738 OR EventCode=4767?OR EventCode=4720 OR EventCode=4726)
| eval ActionBy=src_user | eval Account=mvindex(Security_ID,1)
| eval Time=strftime(_time, "%m/%d/%y %H:%M:%S") | sort -_time
| eval EventCode=case(EventCode==4767, "4767 Unlocked", EventCode==4725, "4725 Disabled", EventCode==4722, "4722 Enabled", EventCode==4724, "4724 Password reset attempted", EventCode==4738, "4738 Object changed", EventCode==4720, "4720 Created", EventCode==4726, "4726 Deleted", 1=1, EventCode)
| rename name as "EventCodeDescription"
| table Time, Account, EventCode, ActionBy, EventCodeDescription, ComputerName
Now that Splunk has produced some reports, how do you interpret them? This will be covered in the next section.
Tip:?The Splunk results can be downloaded as CSV, XML, and JSON files for further reporting and analysis. They can also be printed as PDF, although at the time of writing, the orientation is locked in Portrait mode.
Interpreting Account Activity
The amount of data that can be collected about an account’s activity can be very overwhelming. “Event ID 4740” — what is that? What does “Logon Type 3” mean? What about “Network Address” and “Caller Machine“? What if a lockout shows the source to be a Domain Controller? Does that mean an unauthorized user attempted to log in to the DC, and if so, why?
Before we can interpret the Splunk results (or output provided by Microsoft’s EventCombMT and other tools), let’s look at the various Event IDs that are related to account activity.
In the above table, I have separated the events by two types: Lockout and Other. The former are general sources that could contribute to a lockout, and the latter are informational to help gain an understanding of what had occurred. The ones to pay particular attention to:
When I troubleshoot an account, I look for a group of?4625?events that?may?have led to the?4740?lock event. The message within?4740?would tell you what ultimately caused the lock. Keep in mind that although?4625?reports a failed logon, it may not necessarily have been the culprit. It may have simply failed because the account was ALREADY locked as illustrated in the below?4625?sample.
Event ID?4740 (above): The account, “DOMAIN\MichaelYuen” was locked out by “Caller Computer Name“, “MyComputer1”. “DC01” logged this event. The lock likely came from “MyComputer1”. Start troubleshooting there.
If “Caller Computer Name” is blank/null or a Domain Controller, look at the “Process Information” and “Network Information” fields next:
The next example provides more details on both.
Event ID?4625 (above): “DC02” (from the?Subject?field) reported the logon failure for “Account Name:?MichaelYuen” and cites “Failure Reason: Account locked out”. The account could not log in because it was ALREADY locked.
Logon Type?is the method an account tried to log in with. Let’s look at the various types.
In the example I had provided for Event ID?4625, the Logon Type was “3”. The logon was attempted over the network from a remote server — a VMware Host in that particular situation.
Looking for the suspect process, application, or computer can be a?test of patience and perseverance, and having customers understandably vent their frustration in an effort to nudge you to find the source can be discouraging. Hopefully, the information and tools presented here will aid you towards a quick(er) resolution, and helped you understand how Active Directory tracks account activities. Furthermore, I encourage you to learn PowerShell, if you haven’t already, as it can be a very powerful tool to have in your IT arsenal.
Happy lockout hunting!
Tip:?For investigating?Group-related events, see my?Group and Membership Changes?post.
- Michael Yuen
Nice work Michael