Create Active Directory Password Reports with PowerShell
Create Active Directory Password Reports with PowerShell. Well, in order to maintain a safe environment and thwarting malicious activity early depends on tracking and auditing password changes in an Active Directory (AD) domain.
Thankfully, although challenging to analyse and comprehend, AD provides the data required to track these changes. Learn how to set up Active Directory password auditing, filter events in the Event Viewer and utilize PowerShell to more quickly audit the report with a script in this article.
Shall we start with Create Active Directory Password Reports with PowerShell?
Create AD Password Reports with PowerShell
Prerequisites
If we would like to follow this article, please be sure we have the following:
- An AD environment with at least one domain-joined workstation.
- Domain functional level of at least Windows Server 2016.
- Remote Server Administration Tools (RSAT) for Active Directory installed on your domain-joined workstation.
- Latest PowerShell version or at least PowerShell 7. x and above.
Well how to Create Active Directory Password Reports with PowerShell? Let’s find out.
Enable Password Auditing in AD
Generally the Domain controllers (DC) include the auditing data we need to record AD password changes. However, the request will eventually reach the domain controller playing the Primary Domain Controller (PDC) emulator role. But on DCs, the essential auditing is disabled by default.
Use the PowerShell command below to find the DC holding the PDC emulator role.
(Get-ADDomain).PDCEmulator
Firstly make a new group policy object (GPO) to enable password auditing. We will make this GPO and connect it to the entire domain. For example, we could change the Default Domain Policy, but Microsoft recommends against this. Secondly always construct a separate GPO if we need to alter something across DCs in your environment.
The pertinent audit events are only accessible on DCs, even though we can create and bind a GPO to the entire domain. By the same token, access to the same logs is advantageous for domain joined clients since they can be helpful if a local non AD user password is changed. What is more you can link the GPO to the DC organizational unit (OU) if you inspect Active Directory accounts.
Creating Password Auditing GPO
How to create a GPO on your domain joined workstation to compel DCs to start auditing password changes? Here is how:
- For this purpose go to the Start button, type Run, press Enter, and type in gpmc.msc to launch the Group Policy Management snap in.
- Give the group policy a name and click Create a GPO in this domain. We will use the Active Directory Password Auditing name in this article.
3. Right click the created policy and choose Edit to open the Group Policy Management Editor.
4. Next step is to go to Audit account management under Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies.
5. We can track successful and unsuccessful password attempts by double clicking on the “Audit Account Management Policy” option. Likewise checking the box to define these policy settings and ensuring the Success and Failure checkboxes are in their default values (with a check).
6. Well, to close and leave the editor, click OK.
7. The PDC emulator (PDCe) role holding domain controller (DC) is the only DC that processes password changes, so technically, we only need to pay attention to this DC’s activity. But, first of all connect to the domain controller executing the PDC emulator (PDCe) AD role by launching a Remote Desktop (RDP) client.
8. In order to force a group policy update, launch a command prompt or PowerShell console on the PDCe DC and type gpupdate. We can also run a GPO update if your DCs have PowerShell Remoting enabled.
Once we executed the configuration changes and the group policy updated, we now have auditing events turned on and logging for account management.
Interpreting Account Management Events
Basically Account Management events are a subset of audit events that include password changes. In addition, the system store recorded information like password changes and user account lockouts during circumstances. Nevertheless, the system also stores Logged Account Management audit events in Windows in the Security event log on a computer with auditing enabled.
On your domain joined machine:
- Run eventvwr.msc or access Windows Event Viewer from the Start menu.
- Connect to Another Computer by selecting it from the context menu of Event Viewer (Local).
3. Link Event Viewer to the DC’s event source, enter the name of the DC running the PDCe role in the Another computer text box and press OK.
4. On the Security tab, expand the Windows Logs item. Then the console will take us to the Security log by clicking the tab below.
Also, the security log will include various events with a source of Microsoft Windows security auditing and User Account Management task categories, as seen in the filtered view above.
Above all, the system assigns a distinct ID that identifies the type of event to each Windows event. Nevertheless Microsoft Windows security auditing source contains several event IDs. Those are the ones we should be most concerned about for password changes (and user lockouts) are:
- Event ID 4723 – where a user attempted to change an account’s password.
- Event ID 4724 – here a user tried to reset an account password.
- Event ID 4740 – well, the particular user account was locked out.
- Event ID 4767 – and in this instance, a user unlocked a user account.
All in all, the Security log contains a lot of events, so we will need to design and use specific filters to focus on password changes exclusively.
Filtering Password Change Events
Besides we can build a filter inside the Event Viewer. For example, we need a filter when searching through the Windows Security event log because it helps reduce the number of events displayed.
By all means, we can create this filter in the Event Viewer by doing the following steps:
1. Select Filter Current Log from the menu by right clicking the Security log, as shown below.
2. Using the following criteria, establish a filter in the Filter Current Log dialog box that only finds password change events, then click the OK button.
- Event IDs: 4723,4724,4740,4767
- Event Sources: Microsoft Windows security auditing.
- Task Category: User Account Management.
When finished, your Filter Current Log screen should appear as shown below:
After those steps are taken, we display a tailored list of events related to password and password updates on the domain controller by filtering the Event Viewer to only the necessary event IDs.
Filtering Audit Events with PowerShell
Even though, we use Windows Event Viewer connected to the DC’s Security event log, a quicker method is required. In essence, we might already have some automation or want to monitor this event log automatically. So, in this instance, we should utilize PowerShell.
Certainly, PowerShell allows you to do the same function within a single script. We won’t need to connect to DCs, manually set up filters, or parse through events if we have a script.
For this purpose, we use the Get-WinEvent cmdlet in PowerShell to locate significant auditing events. In return this cmdlet returns all events after it searches a local or remote event log. Similar to the Event Viewer, it also supports filters. Even if you’ve already built a filter with Event Viewer, you can in fact, share that same filter with PowerShell.
Extracting the Filtered Report Using PowerShell
Let’s save some time by extracting the filter and using it with PowerShell’s Get-WinEvent cmdlet since the Event Viewer and PowerShell can utilize it.
At first, on a connected domain controller:
1. First of all visit the Filter Current Log screen once more. If the filter criteria were still fully set, that would be helpful.
2. Second step is, at the top please select the XML tab. This tab holds the unprocessed XML that the Event Viewer sends to the event log to display specific events exclusively. PowerShell can also use this XML.
3. After that, select and copy the entire content block between and . The Get-WinEvent cmdlet can use this text as an XPath value.
4. Lastly paste the following line of code into a PowerShell console. The text collected from the Event Viewer filter matches the value of the FilterXPath argument.
$filterPath = "*[System[Provider[@Name='Microsoft-Windows-Security-Auditing'] and Task = 13824 and (EventID=4723 or EventID=4724 or EventID=4740 or EventID=4767)]]"
Get-WinEvent -ComputerName -LogName 'Security' -FilterXPath $filterPath
In conclusion, the events we viewed in the Event Viewer should appear when you execute Get-WinEvent, as shown in the screenshot below.
Thank you for reading Create Active Directory Password Reports with PowerShell. We shall conclude.
Perform Auditing and Get 200+ Reports with InfraSOS Tool
With InfraSOS monitoring and reporting tool you will get detailed reports on Active Directory, Office 365, Azure AD on all your Active Directory Objects and attributes. That is the only SaaS reporting platform for Active Directory Auditing.
Already, the leading active directory reporting and monitoring tool available on the market. It aids the Admin that can access information about the current status of user accounts, their security permissions, password expiry dates (or when they had changed their passwords), failed login attempts, and much more.
Create Active Directory Password Reports with PowerShell Conclusion
This article taught us how to enable auditing and navigate through the Windows Event Viewer. From there, we have filtered through the Security logs to check all events relating to password changes. Moreover we have also learned how to translate these manual efforts to PowerShell to automate the report generation process seamlessly.
Take a look at our Active directory section and PowerShell section.
