Password change history in Active Directory refers to the logged record of all password modifications and resets performed on user accounts within your AD environment. These events are captured through Windows Security Event Logs when auditing is properly configured, allowing administrators to track who changed or reset passwords, when these changes occurred, and which accounts were affected.
Why Audit Password Changes in Active Directory?
Auditing password changes and resets in Active Directory is crucial for several reasons:
- Security: Identify unauthorized or suspicious password modifications and take swift action to prevent potential security breaches or unauthorized access to sensitive information.
- Compliance: Meet strict regulatory requirements that mandate maintaining a secure and auditable system. A record of password-related activities demonstrates compliance during audits, ensuring data integrity and confidentiality.
- Troubleshooting: Resolve login issues and password-related problems quickly by reviewing a log of recent password changes to identify the cause and implement appropriate solutions.
In this article, we will discuss the steps required to detect password changes and resets in Active Directory. We’ll go through two methods: first, the native way using event logs, and then we’ll show you how much easier the process is using Lepide Active Directory Auditor.
Audit Password Changes and Resets with Native Auditing
Auditing password changes and resets in Active Directory natively requires two main steps: configuring group policy settings to enable auditing, and then finding the corresponding Event ID in Windows Event Viewer.
Prerequisites
Before you begin, ensure you have the following:
- Permissions: Domain Admin or delegated Group Policy management rights
- Supported Versions: Windows Server 2008 R2 or later
- Required Tools: Group Policy Management Console (GPMC), Event Viewer
Step 1: Configuring Group Policy Settings to Enable Auditing
- Go to “Start Menu” ➔ “All Programs” ➔ “Administrative Tools” and double-click “Group Policy Management” to access its window.
NOTE: You can also open “Run” dialog box from the start menu, type “GPMC.MSC” and click “OK” to access Group Policy Management console.
- In the left panel of Group Policy Management Console, go to “Forest” ➔ “Domains” ➔ “www.domain.com.”
- Double-click “www.domain.com” and navigate to “Default Domain Policy.”
- Right-click any customized policy under “Domain Controllers” node. (We recommend you edit a customized group policy instead of editing Default Domain Controller Policy.) You may create a new GPO, link it to the domain, and edit it.
- “Group Policy Management Editor” window appears on the screen. In the left panel, navigate to “Computer Configuration” ➔ “Policies” ➔ “Windows Settings” ➔ “Security Settings” ➔ “Local Policy”.
- Select “Audit Policy” to list all of its sub-policies in the right panel.
Figure 1: Audit Policy Settings - Double-click “Audit Account Management” to access its “Properties.”
Figure 2: Audit Account Management Properties - Click to select “Define these policy settings.”
- Select both” Success and Failure” checkboxes to audit successful and failed events.
- Click “Apply and OK.”
Step 2: Search for Password Reset Event IDs
Once Auditing is enabled, perform the following steps in Event Viewer to view the events:
- Open “Event Viewer”, and go to “Windows Logs” ➔ “Security”.
- Search for Event ID 4724 check password reset attempts made for an account.
The following screenshot shows event ID 4724 for user who has reset the password (Subject:).
Figure 3: Event Details for Password Reset by Administrator You can scroll down to view the details of the user account whose password was reset (Target Account:).
Figure : Event Details for Account Whose Password was Reset - Search for Event ID 4723 to check attempts made by a user who (Subject) change the password and whose (Target) password was changed. Following screenshot is showing user who has changed the password,
Figure 4: Event Details for Change in an Account’s Password by a User
Alternative Method: Query Password Events with PowerShell
You can also retrieve password change events using PowerShell commands:
`# Query password reset events (Event ID 4724) Get-WinEvent -FilterHashtable @{LogName='Security';ID=4724} | Format-ListQuery user-initiated password change events (Event ID 4723)
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4723,4724;StartTime=(Get-Date).AddDays(-7)} | Export-Csv -Path "PasswordChanges.csv" -NoTypeInformation `Export password change events to CSV for the last 7 days
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4723,4724;StartTime=(Get-Date).AddDays(-7)} | Export-Csv -Path "PasswordChanges.csv" -NoTypeInformationHow Lepide Active Directory Auditor Tracks Password Changes and Resets
As you can see from the above, tracking password changes and resets using the Event Viewer is a bit of a pain. In general, event logs are noisy – and administrators can spend hours trawling through false positives or irrelevant information to find what they are looking for. Event logs also lack critical context.
Want a quicker, more comfortable, and straightforward means of determining when passwords are changed for user accounts? Lepide Active Directory Auditor can provide you with this level of in-depth visibility through real-time alerts and reports that help you overcome the limitations of native auditing. The screenshot given below shows the “Password Change Report.”
You can select an event and extract detailed information in a matter of clicks; including answers to critical information – object name, object path, email address, password last set, days since password set, etc.
Lepide also provides a simple report for tracking password resets in Active Directory. The screenshot given below shows the “User password reset” report. Simply select an event to extract in-depth information, including answers to the critical who, what, where and when questions, which enables you to spot suspicious activities.
Native Auditing vs. Lepide Active Directory Auditor
Conclusion
After configuring auditing, you can carefully monitor password changes and password resets in real-time, including users with soon-to-expire passwords, users with already expired passwords, users whose passwords never expire, accounts with passwords due to be changed at next logon and recent logon failures.
Key Takeaways
- Event ID 4724 tracks administrator password resets; Event ID 4723 tracks user-initiated password changes.
- Enable “Audit Account Management” in Group Policy before password change events will be logged.
- Native auditing requires manual log searching; third-party tools provide faster reporting and real-time alerts.
- PowerShell commands offer a scriptable alternative for querying password change events.
- Regular monitoring of password changes is essential for security, compliance, and troubleshooting.
Frequently Asked Questions
Event ID 4723 is logged when a user changes their own password, while Event ID 4724 is logged when an administrator or another user resets someone else’s password.
By default, the Security event log retains events until it reaches its maximum size (typically 20 MB), then overwrites the oldest events. You can configure retention settings in Event Viewer properties or through Group Policy.
Yes. When you locate Event ID 4724 in the Security log, the “Subject” section shows the administrator who performed the reset, and the “Target Account” section shows whose password was reset.