How to Check Password Change History in Active Directory

Tracking password change history in Active Directory (AD) is a critical task for maintaining security, ensuring compliance, and performing forensic audits. While AD doesn't store a long-term, searchable history by default, you can effectively monitor these events by enabling the right audit policies and using built-in Windows tools.

This guide will provide a clear, step-by-step process for tracking password changes using Windows Event Viewer and PowerShell, while also outlining the limitations and best practices for a scalable solution.

Prerequisite: Enable Active Directory Auditing

Before you can check password change events, you must ensure that audit policies are enabled on your domain controllers. These policies instruct Windows to record specific actions in the Security Event Log.

Configuring via Group Policy Management

1. Open the Group Policy Management Console by typing gpmc.msc in the Run dialog.

2. Navigate to your domain, right-click on the Default Domain Controllers Policy, and select Edit.

3. In the Group Policy Management Editor, navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Management.

4. Double-click on the Audit User Account Management policy and enable both Success and Failure events. This ensures that any user-related account changes, including password changes, are logged.

After configuring the policy, force a Group Policy update on your domain controllers by running gpupdate /force in an elevated Command Prompt.

Method 1: Using Windows Event Viewer

Once auditing is enabled, Windows will begin logging password change and reset events in the Security Event Log. The Event Viewer provides a graphical interface to view these logs.

1. Open the Event Viewer by typing eventvwr.msc in the Run dialog.

2. In the left pane, navigate to Windows Logs > Security.

3. The Security Log contains a high volume of events. To find password changes, you need to filter the logs for specific Event IDs.

Key Event IDs for Password Changes

The following Event IDs are essential for tracking password-related activity:

• Event ID 4723: A user attempted to change their own password. The message will include the user's name.

• Event ID 4724: An administrator or a privileged user reset another user's password. This is critical for auditing administrative actions.

• Event ID 4728: A member was added to a security-enabled global group. While not a direct password change event, it's often an indicator of a change in user privileges that can be related to a new account or a reset.

To filter the logs, click "Filter Current Log..." in the right-hand pane and enter these Event IDs in the Includes/Excludes Event IDs field.

Method 2: Using PowerShell for Auditing

For a more powerful, automated, and report-friendly approach, you can use PowerShell to query the security event logs. This is especially useful in large environments where manually sifting through logs is impractical.

To search for password change and reset events, use the Get-WinEvent cmdlet. The following command filters for the key Event IDs and formats the output for easy reading.

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4723,4724} -ErrorAction SilentlyContinue | Select-Object TimeCreated, Id, @{Name='User'; Expression={$_.Properties[0].Value}}, Message | Sort-Object TimeCreated -Descending | Format-Table -AutoSize

Interpreting the Results:

The command will produce a table with the TimeCreated, Event ID, User, and Message for each password-related event. For example, a result with Id 4724 will tell you which account was reset and by whom, providing a clear audit trail.

Understanding Event Log Limitations & Best Practices

While Event Viewer and PowerShell are effective, it's crucial to be aware of their limitations for large-scale enterprise use.

• Limited Retention: By default, event logs have a fixed size and are configured to overwrite older events. This means your password change history may only go back a few days or weeks.

• Decentralized Logs: Event logs are stored locally on each domain controller. To audit an entire domain, you must query logs on every domain controller, which is time-consuming and inefficient.

For long-term, scalable solutions, consider these best practices:

• Increase Log Retention: Adjust the log size and retention settings via Group Policy to store more events.

• Centralize Logs: Implement a Security Information and Event Management (SIEM) solution or a log forwarding system like Windows Event Forwarding (WEF) to consolidate all security events to a central server. This allows for unified searching and long-term storage.

Method 3: Leveraging Third-Party Tools (Optional)

For a more comprehensive, turn-key solution, many IT administrators turn to third-party tools. These solutions offer:

• Pre-configured Reporting: Automated reports and dashboards for password changes, user activity, and compliance audits.

• Long-Term Auditing: Centralized logging that bypasses the limitations of local event logs.

• Real-Time Alerts: Immediate notifications for critical events, such as a password reset on a sensitive account.

Examples of such tools include  Netwrix Auditor, ManageEngine, Lepide Auditor, or Specops. These platforms simplify the auditing process, providing a user-friendly interface for complex security tasks.

Summary

Tracking password change history in Active Directory requires a three-pronged approach: first, ensure auditing is properly enabled via Group Policy; second, use Event IDs 4723 and 4724 to query the logs with either Event Viewer or PowerShell; and finally, adopt a scalable solution for long-term data retention, such as a SIEM or a third-party tool, especially in larger environments.