When you have a large Active Directory, auditing for password changes can be difficult to do. Tracking down the change of passwords is essential in order to prevent phishing attacks and keep your network safe.
The “password change history active directory powershell” is a script that will log all changes to the password. This can be very helpful in finding out when someone changed their password.
Tracking and auditing password changes in an Active Directory (AD) domain is critical for keeping the environment safe and catching rogue actors early. Thankfully, although being difficult to read and comprehend at times, AD provides the information needed to monitor these changes. LAPS is an excellent example.
In this article, you’ll learn how to activate password auditing in Active Directory, how to filter events in the Event Viewer, and how to utilize PowerShell to audit the results more simply using a script.
Specops and their valuable product Password Auditor are sponsoring this lesson.
Prerequisites
If you want to follow along with this lesson, you’ll need the following items:
- At least one domain-joined workstation in an Active Directory environment. Advanced Audit Policies were introduced in Windows Server 2008 through a logon script and in Windows Server 2008 R2 via a GPO. The tutorial is at a domain functional level of Windows Server 2016.
- On your domain-joined workstation, install Remote Server Administration Tools (RSAT) for Active Directory.
- 7.x PowerShell
For Active Directory Auditing, enable Group Policy.
The essential auditing information for auditing AD password changes is maintained on domain controllers (DC), however the request will be processed by the domain controller in the Primary Domain Controller (PDC) emulator role. On DCs, however, the essential auditing is disabled by default. Let’s make a difference.
Use the PowerShell command to locate the DC with the PDCe role (Get-ADDomain). PDCEmulator.
Create a new group policy object to allow password change auditing (GPO). This GPO will be formed and connected to the domain as a whole.
It is possible to alter the Default Domain Policy, however Microsoft advises against it. Always construct a separate GPO if you need to make a change across DCs in your environment.
The necessary audit events are only accessible on DCs, even if you create and attach a GPO to the whole domain. However, having those same logs on domain-joined clients is advantageous since it may be helpful if a local non-AD user password is changed. You may alternatively attach the GPO to the Domain Controllers organizational unit if you’re simply inspecting Active Directory accounts (OU).
Create a GPO on your domain-joined workstation that causes DCs to start auditing password changes:
- Go to Start Run and type gpmc.msc to launch the Group Policy Management snap-in.
2. Select Create a GPO in this domain and Link it Here… from the drop-down menu. Assign a name to the policy. The moniker Active Directory Password Auditing will be used in this tutorial’s example.
Making a GPO to store user password auditing preferences.
3. Right-click the newly generated policy and choose Edit to launch the Group Policy Management Editor.
Edit the GPO by opening it.
4. Go to Computer Configuration Policies Windows Settings Security Settings Local Policies Audit Policy Audit Account Management in Computer Configuration Policies.
5. Double-click the Audit Account Management policy option and tick the box. Make sure both the Success and Failure buttons are selected when defining these policy settings. This will track both successful and failed password attempts.
In the Group Policy Management Editor, enable Success and Failure for the Audit account management policy.
6. To close and quit the editor, click OK.
7. Connect to the domain controller running the PDC emulator (PDCe) AD role using a Remote Desktop (RDP) client.
All DCs process password changes, but only the DC with the PDC emulator (PDCe) role replicates them, thus you only need to look at the events of this DC.
8. Open a command prompt or PowerShell console on the PDCe DC and type gpupdate to force a group policy update.
If your DCs have PowerShell Remoting enabled, you may also use it to perform a GPO update.
Using the command line, force a group policy change.
You now have auditing events switched on and logging for account management after making the configuration modifications and updating the group policy. Continue reading to learn how to interpret these occurrences.
Understanding Account Management Logging
Account Management events are the type of audit events that include password changes. These events keep track of things like password changes and user account lockouts. Account Management audit events are reported in the Security event log of a computer with auditing enabled as Windows events.
On the domain-joined computer:
- Run eventvwr.msc or use the Start menu to launch Windows Event Viewer.
2. Select Connect to an Additional Computer from the right-click menu on Event Viewer (Local).
Connect to an Additional Computer
3. In the Another computer: box, enter the name of the DC that is executing the PDCe role and click OK to link Event Viewer to the DC’s event source.
Provide the name of the DC on another computer that is executing the PDCe role.
4. Select Security from the Windows Logs box. As demonstrated below, this will take you to the Log of Security.
Log of Security
Inside of the Log of Security, you’ll find various events with a source of Microsoft Windows security auditing and User Account Management task categories as shown in the filtered view below.
Demonstrate the Event Viewer’s filtered view of events.
Each Windows event has a unique ID that identifies the event type. Though the Microsoft Windows security auditing source provides a number of event IDs, the following are the ones you should be looking for when it comes to password changes (and user lockouts):
- 4723 – An attempt was attempted to change the password on an account.
- 4724 – An attempt to reset an account password was performed.
- 4740 – A user account has been disabled.
- A user account was unlocked at 4767.
You’ll see a lot of events in the Log of Security so you’ll need to create an apply some filters to narrow down only password changes.
Password Change Event Filtering
You may build a filter in the Event Viewer. When looking through the Windows Security event log, you must use a filter to reduce the amount of events that appear.
To make this filter in the Event Viewer, follow these steps:
- Right-click on the Log of Security and click on Current Log Filter… as shown below.
Current Log Filter
2. In the Current Log Filter dialog box, create a filter to only find password change events using the following criteria and click on OK.
- Microsoft Windows security auditing is an event source.
- 4723,4724,4740,4767 are event IDs.
- User Account Management is a task category.
When you’re complete, your Current Log Filter screen should look like below.
Create a filter for the Log of Security.
A focused list of events that have happened pertaining to password and password updates is given below by filtering the Event Viewer on the domain controller to only the necessary event IDs.
Demonstrate the Event Viewer’s filtered view of events.
Voila! Since you connected the GPO previously, you now have all of the password change (and user lockout) events that have happened in your domain!
With PowerShell, you can find audit events.
Even though you may link the Windows Event Viewer to the DC’s Security event log, there are instances when you need a quicker solution. Perhaps you have some background automation or would wish to watch this event log automatically. In this scenario, PowerShell should be used.
Using PowerShell, you may execute the same function several times in a single script. You won’t have to manually connect to DCs, build filters, or sift through events if you use a script.
Use the Get-WinEvent cmdlet in PowerShell to identify crucial auditing events. This cmdlet searches a local or remote event log for all occurrences and returns them. Filters are also supported, exactly as they are in the Event Viewer. If you’ve previously created a filter in Event Viewer, you can really share that filter with PowerShell!
Let’s save some time by extracting the Event Viewer’s filter and using it with PowerShell’s Get-WinEvent cmdlet.
While using Event Viewer to ensure you’re still connected to the DC:
- Go back to the Current Log Filter screen. You should still have all of the filter criteria set.
- At the top, choose the XML tab. This page includes the raw XML that Event Viewer sends to the event log to limit which events are shown. This XML may also be used by PowerShell.
- Select and copy all of the text been <Select Path=”Security”> and </Select> as shown below. This text is an XPath value that the Get-WinEvent cmdlet can use.
Show how to quickly get the XPath for the Get-WinEvent cmdlet.
4. Paste the following code snippet into a PowerShell console. The FilterXPath parameter value is the exact same text taken from the Event Viewer filter above, as you can see.
Get-WinEvent -ComputereName <YOUR DC> -LogName ‘Security’ -FilterXPath “*[System[Provider[@Name=’Microsoft-Windows-Security-Auditing’] and Task = 13824 and (EventID=4723 or EventID=4724 or EventID=4740 or EventID=4767)]]”
When you run Get-WinEvent, you should see the same events that you observed before in the Event Viewer, as seen in the picture below.
Demonstrate using Get-WinEvent to show the results of the Event Viewer Log of Security.
PowerShell has now discovered all password change and user lockout events!
You’ve seen how to audit AD events using PowerShell’s Get-WinEvent cmdlet. If you intend to do this often, create a reusable tool that you can reuse in other scripts or automation procedures.
Let’s create a Get-ADPasswordEvent PowerShell method in this area. This function will look at a number of approaches that may assist you access exactly the information you need without the other attributes that Get-WinEvent provides.
To avoid boring you with the specifics, you can see a fully functional function constructed for you below. This function has a few different functions:
- The XPath filter is created.
- Get-WinEvent is used to get the specified AD account management password events using the filter.
- Returns customized output that is relevant to the current job.
More detailed information may be found in the code comments.
Function Get-ADPasswordEvent { [CmdletBinding()] Param( [Parameter(Position=0)] [System.Collections.Generic.List[Int]]$EventID = @(4723,4724,4740,4767), [Parameter(Position=1)] [Int]$Hours, [Parameter(Position=2)] [ValidateSet(“Success”,”Failure”)] [System.Collections.Generic.List[String]]$EventType = @(“Success”,”Failure”), [Parameter(Position=3)] [string]$ComputerName ) Process { # The event type filter values are from the Audit Success and Audit Failure in the Keywords section of the Event Viewer filter. If ($EventType -Contains “Success” -And $EventType -Contains “Failure”) { $EventTypeFilter = ” and (band(Keywords,13510798882111488))” } ElseIF ($EventType -Contains “Success”) { $EventTypeFilter = ” and (band(Keywords,9007199254740992))” } Else { $EventTypeFilter = ” and (band(Keywords,4503599627370496))” } # We construct a filter to pass to -FilterXPath. Hours should be returned in milliseconds and we use Join-String to properly format the EventID combinations. $Filter = “*[System[Provider[@Name=’Microsoft-Windows-Security-Auditing’] and Task = 13824{0}{1}{2}]]” -F (($Hours) ? ” and TimeCreated[timediff(@SystemTime) <= $((New-TimeSpan -Hours $Hours).TotalMilliseconds)]” : $Null), (($EventId) ? ($EventId | Join-String -OutputPrefix ” and (” -FormatString ‘EventID={0}’ -Separator ‘ or ‘ -OutputSuffix “)”) : $Null), $EventTypeFilter Write-Verbose $Filter $Events = Get-WinEvent -ComputerName $ComputerName -LogName ‘Security’ -FilterXPath $Filter # For the Password Change and Reset ID’s we format the Details to be more readable and show what is going on regarding the target (account being changed) and the subject (who did the changing). $Events | ForEach-Object { $Event = $_ Switch ($Event.ID) { 4723 { $Description = “Account Password Change Attempt” $Details = [PSCustomObject]@{ “TargetAccount” = (“{0}{1}” -F ($Event.Properties)[1].Value, ($Event.Properties)[0].Value) “TargetSID” = ($Event.Properties)[2].Value “SubjectAccount” = (“{0}{1}” -F ($Event.Properties)[5].Value, ($Event.Properties)[4].Value) “SubjectSID” = ($Event.Properties)[3].Value } Break } 4724 { $Description = “Account Password Reset Attempt” $Details = [PSCustomObject]@{ “TargetAccount” = (“{0}{1}” -F ($Event.Properties)[1].Value, ($Event.Properties)[0].Value) “TargetSID” = ($Event.Properties)[2].Value “SubjectAccount” = (“{0}{1}” -F ($Event.Properties)[5].Value, ($Event.Properties)[4].Value) “SubjectSID” = ($Event.Properties)[3].Value } Break } 4740 { $Description = “Account Locked Out” $Details = $Event.Message Break } 4767 { $Description = “Account Unlocked” $Details = $Event.Message Break } Default { $Description = $Null $Details = $Event.Message Break } } # Finally let’s output our custom object that shows the event information in a more readable format. [PSCustomObject]@{ “TimeCreated” = (Get-Date $_.TimeCreated) “ID” = $_.ID “Description” = $Description “EventType” = (($_.KeywordsDisplayNames -EQ ‘Audit Success’) ? “Success” : “Failure”) “Details” = $Details } } } }
Drop this function into a PowerShell prompt and execute it without any arguments after it’s been built.
Get-ADPasswordEvent is shown below. The function produces a lot of success and failure events for password reset attempts, as you can see.
To make the output of the Get-ADPasswordReset function a bit simpler to understand, give it to Format-Table.
Using the Get-ADPasswordEvents method to get AD account management password events.
Putting Better Password Auditing Solutions in Place
You have to go through a few hoops to locate AD auditing events, whether you’re using the Event Viewer or PowerShell. Third-party solutions like Specops Password Auditor may assist extend Active Directory’s inherent features and capabilities.
The Password Auditor tool from Specops can not only detect these occurrences, but it can also provide detailed reports that contain updates, expired passwords, and blank passwords, among other things. Specops Password Auditor may help with Active Directory password auditing by filling in the gaps.
Active Directory is a directory service that allows users to maintain computer accounts. Active Directory also has an audit trail that keeps track of user passwords and changes. This article will show you how to check the password changes in Active Directory. Reference: how to check user password in active directory.
Related Tags
- active directory password history
- how to check when password was changed in active directory
- active directory password reset event id
- how to check password change history in windows 10
- active directory last password change all users
