To check the password change history in Active Directory (AD), it’s crucial to understand that AD doesn’t natively store a comprehensive historical log of all password changes indefinitely. However, there are ways to track recent password changes using Event Logs, PowerShell, and by enabling auditing.
Method 1: Using Event Logs
When users change their passwords, Event Logs in Windows Server capture these events, assuming password change auditing is enabled.
- Enable Auditing (if not already enabled):
- Open Group Policy Management (
gpmc.msc). - Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Logon/Logoff.
- Enable Audit Logon Events and Audit Account Logon Events.
- Ensure that Audit Directory Service Access is enabled in Security Settings > Advanced Audit Policy.
- Open Group Policy Management (
- View the Event Logs:
- Open Event Viewer (
eventvwr.msc). - Go to Windows Logs > Security.
- Look for Event ID 4723 (Password change attempt), Event ID 4724 (Password reset), and Event ID 628 (Password change).
- Filter the logs for these events to track password change history.
- Open Event Viewer (
- Event Details:
- In the Event Details, you’ll find information about the user account and the timestamp of the password change.
Method 2: Using PowerShell (with Auditing Enabled)
PowerShell can help you query password-related events if auditing is enabled.
-
Search Event Logs for Password Changes: Run the following command to search for password change events:
Get-WinEvent -LogName Security | Where-Object { $_.Id -eq 4723 -or $_.Id -eq 4724 -or $_.Id -eq 628 } | Format-Table TimeCreated, Id, Message -AutoSize -
Interpret the Results: This command will display the time of the password change and associated user details for each relevant event.
The output will show something like this:
| TimeCreated | Id | Message |
|---|---|---|
| 2/3/2025 10:15:45 AM | 4723 | An attempt was made to change the password of user ‘john.doe’ |
| 2/3/2025 10:20:30 AM | 4724 | The password of user ‘admin’ was reset by user ‘jane.doe’ |
- TimeCreated shows the time when the event occurred.
- Id represents the Event ID (4723, 4724, 628).
- Message provides additional details like the user who performed the action or the target user account.
Method 3: Using a Third-Party Tool (Optional)
If you need more detailed history and reporting capabilities, you can consider third-party tools like Netwrix Auditor, Lepide Auditor, or Specops that can provide more granular tracking of password changes, including change history over time and additional reporting features.
Limitations and Considerations:
- Default retention: Event logs are not retained indefinitely by default; old events may be overwritten after a period depending on your server’s log settings (log size, retention period). If you need to keep a long history, consider increasing log retention or exporting logs to a central logging solution.
- PowerShell speed: On large networks, querying logs using PowerShell might take time depending on the number of events. In such cases, filtering logs to a specific time range could improve performance.
Tracking password changes in Active Directory requires enabling auditing, then reviewing Event Logs or using PowerShell to query those logs. The main events to look for are Event IDs 4723, 4724, and 628. By ensuring auditing is set up correctly, you can capture and track password change attempts and resets efficiently.
Service accounts are dedicated Active Directory (AD) accounts that are used to manage Windows services and other network applications. These accounts have privileged access to applications, resources, and network access. Just like any other privileged account, it’s important to closely monitor all logons and accesses these accounts make. However, the native monitoring capabilities in AD are far from what today’s enterprises need to thoroughly monitor this behavior. For instance, reporting on and analyzing service account password changes in AD using just the native tools is a challenge, which, when performed incorrectly, can easily lead to serious security concerns or failed services.
Auditing service accounts using native tools in AD
To detect password changes using native auditing, you can access the Group Policy Management Console for configuring Group Policy settings.
-
Navigate to the GPO that you want to modify (the GPO needs to be linked to a domain or a domain controller OU).
-
In the Group Policy Editor, go to Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies.
-
Select Audit Policy to list all the sub-policies.
-
Double-click Audit account management to view its properties.
-
Enable Define these policy settings, and check the Success option to audit successful events. Refer to Figure 1.
-
Click Apply and OK.
Figure 1. Configure Audit account management properties.In addition to configuring GPO settings, security access control lists (SACLs) must also be configured for the respective AD objects. To learn about setting up the SACLs, click here.
Once auditing is enabled, do the following to view events:
-
Go to Administrative Tools, and open Event Viewer.
-
Under Windows Logs, select Security. Search for the event ID 4724 and/or 4723. Event ID 4724 corresponds to a password reset attempt by an administrator, whereas event ID 4723 corresponds to a password change attempt by a user. Refer to Figure 2.
Figure 2. Event 4724 monitors when a user’s password is changed.In AD, security logs are continuously recording events on the domain controllers. Every action is identified by a specific event ID, as you may have noticed from Figure 2, and requires a certain level of expertise to adequately respond to such an action. With continuous logging of data on domain controllers, huge volumes of data can quickly pile up. There’s a good chance that critical information requiring immediate action will end up lost among the normal event logs. That’s why a real-time AD solution that can inform administrators of key events is important for any enterprise.
A good auditing mechanism will effectively track and alert on all service account activities, including changes made in real time. This will help IT admins react faster in case of an emerging threat.
Responding to password changes with ADAudit Plus
ADAudit Pus enhances native auditing capabilities by providing real-time alerts on password changes. You can configure alerts to notify you if a service account password changes, as shown in Figures 3 and 5. You’ll also be able to receive reports on services running on a specific computer, with information about the service, service account, and service status, as shown in Figure 6.
Figure 3. Real-time alerts in ADAudit Plus.
Figure 4. User-Based Password Changes report in ADAudit Plus.
Figure 5. All AD Changes report in ADAudit Plus.
Figure 6. Real-time User Services report in ADAudit Plus.
Summary
Monitoring changes to service account passwords is paramount for security and service availability. With the comprehensive monitoring and real-time alerting provided by ADAudit Plus, you can spot and tackle threats before they cripple your organization.
To try ADAudit Plus out for your service accounts, download a free, 30-day trial.
16.11.2022
Разберемся, как в доменной среде Active Directory по журналам контроллеров домена определить, кто из администраторов сбросил пароль учетной записи определенного пользователя.
В первую очередь, в политиках домена нужно включить аудит событий управления учётными записями. Для этого:
- Откройте консоль управления групповыми политиками Group Policy Management (gpmc.msc) и отредактирует политику домена Default Domain Policy.
- Затем в консоли редактора групповых политик, перейдите в раздел Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy
- Найдите и включите политику Audit User Account Management (если нужно фиксировать в журнале как успешные, та и неудачные попытки смены пароля, выберите опции Success и Failure).
Примечание. Эту же политику можно включить и в разделе расширенных политик аудита (Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Configuration)
- После прохождения цикла обновления групповых политик на клиентах можно попробовать изменить пароль любого пользователя в AD.
- После этого, откройте консоль просмотра событий на контроллере домена и перейдите в раздел Event Viewer -> Windows Logs -> Security. Щелкните ПКМ по журналу и выберите пункт Filter Current Log.
- В параметрах фильтра укажите, что нужно вывести только события с кодом EventID 4724.
- В списке событий останутся только события успешной смены пароля (An attempt was made to reset an account’s password.). При этом в расширенном представлении события можно увидеть имя учётной записи администратора, которая выполнила смену пароля (Subject:) и, собственно, учетную запись пользователя, чей пароль был сброшен (Target Account:).
Совет. В контексте получения полной информации о событиях смены пароля пользователя, в фильтр можно добавить следующие идентификаторы событий:
- 4724 (628 — в старых версиях Windows Server) – An attempt was made to reset an account’s password (сброс пароля пользователя администратором)
- 4723 (627 — в старых версиях Windows Server) – An attempt was made to change an account’s password (смена пароля самим пользователем)
Информацию о данном событии из журналов всех контроллеров домена Active Directory с помощью PowerShell командлетов Get-ADComputer и Get-WinEvent, можно получить таким образом:
(Get-ADComputer -SearchBase ‘OU=Domain Controllers,DC=winitpro,DC=loc’ -Filter *).Name | foreach {
Get-WinEvent -ComputerName $_ -FilterHashtable @{LogName="Security";ID=4724 }| Foreach {
$event = [xml]$_.ToXml()
if($event)
{
$Time = Get-Date $_.TimeCreated -UFormat "%Y-%m-%d %H:%M:%S"
$AdmUser = $event.Event.EventData.Data[4]."#text"
$User = $event.Event.EventData.Data[0]."#text"
$dc = $event.Event.System.computer
write-host “Admin ” $AdmUser “ reset password to ” $User “ on ” $dc “ “ $Time
}
}
}
При необходимости эти данные можно записывать прямо из PowerShell во внешнюю mysql базу данных, через специальный коннектор MySQL .NET Connector по аналогии со сценарием, описанным в статье Узнаем кто удалил файл на файловом сервере.
Describe the bug
After booting in to the live environment I tried to install elementary from the Applications Menu. An Authentication Menu
pops up and asks for the password of the user elementary, which the user does not have and cannot reset. The user cannot select another user.
Daily build: elementaryos-6.0-daily.20200812.iso
To Reproduce
Steps to reproduce the behavior:
- Boot into live environment
- Click on Applications
- Click on Install elementary OS
- Authentication window pops up
Expected behavior
Installer should launch, as we are in a live environment with no option for the user to set a password
Desktop (please complete the following information):
- OS: Windows 10 — Hyper-V VM with daily build of elementary OS 6.0 20200812
Additional context
This issue may elevate into a bigger context, as the user cannot test anything in the live environment which requires sudo / root.
Please drop a note if I should open an issue for that too.
Password errors occur when users attempt to log into Active Directory (AD) with incorrect passwords. Mistyping a password is an easy mistake to make and happens on a regular basis with no cause for concern. However, if there are a large number of employees with bad password attempts occurring within a short period of time then this is cause for concern as it could indicate a brute force attack where a hacker is trying to guess user passwords. It is critical, therefore, that an effective password policy is in place and that the account lockout policy is configured to mitigate brute force attacks.
Here are some reasons for monitoring bad password attempts in Active Directory:
- To identify password spraying attempts or brute force attacks on user accounts.
- To troubleshoot and resolve user account lockout issues.
- To generate Active Directory Reports for auditing and compliance.
How Bad Password Attempts are Logged in AD
In order to authenticate Active Directory, a user needs to provide a valid username and password. If the user has entered an incorrect password, an error message will be displayed on the Windows sign-in screen and details of the error are written to the badPasswordTime attribute in the user’s AD user properties. It also increases the badPwdCount attribute value by one. This can be seen in the Attribute Editor.
If the badPwdCount value exceeds the threshold specified in the Account lockout threshold parameter of your Account Lockout Policy, the user account will be locked for a period of time.
However, if you haven’t configured a lockout policy, or if you’ve set a high lockout threshold value that has not been reached, you won’t be able to find the source of bad password login attempts.
In this article, we will have a look at how to identify the computer name and IP address of the device from which the login attempts with a bad password are being made. This can help you quickly detect brute force attacks or resolve user account lockout issues. We will look at two native ways to do this; by using the Event Log and by using PowerShell, and then we will look at a more straightforward approach using Lepide Auditor.
Find Bad Password Attempts in AD using Event Logs
Please follow below steps:
- Open the Group Policy Management Console (gpmc.msc);
- Expand the Domain Controllers Organizational Unit and edit the Default Domain Controllers Policy
- Go to the following Group Policy section: Computer Configuration, Policies, Windows Settings, Security Settings, Advanced Audit Policy, Audit Policies, Logon/Logoff
- Enable the Audit Logon policy. To only track bad password attempts in domain controller security logs, select Failure only; check bad password attempts in active directory
- Force the update of the GPO settings by using the command gpupdate /force (or wait for 5 minutes which is the default policy refresh interval for Domain Controllers).
- Now if a user tries to log in with an incorrect password, an event with the Event ID 4625 will appear on the domain controller which they are trying to authenticate against (logonserver).
- Open the Event Viewer (eventvwr.msc)
- Expand Windows Logs
- Right-click on Security and select Filter current log; PowerShell bad password attempts
- Enter the Event ID 4625 in the Event ID field; trace bad password attempts
- Only failed login events are listed
- Open the latest event an account failed to log on.
- The event description contains lots of useful information including the name of the user who attempted to authenticate, the account for which Logon Failed and the Failure Reason
- Scroll down the event description, and the name and IP of the computer from which the failed login attempt was made will be listed here
Find the Source of Bad Passwords in AD using PowerShell
You can use the following PowerShell command to get the information on accounts locked out because of wrong password attempts:
Get-ADUser -Filter * -Properties AccountLockoutTime,LastBadPasswordAttempt,BadPwdCount,LockedOut |
Where-Object {$_.BadPwdCount -gt 0 } |
Where-Object {$_.LockedOut -cnotin $False}
How Lepide Auditor Helps in Tracking Bad Password Attempts
Lepide Auditor for Active Directory provides a much more straightforward way to report and alert on bad password attempts in Active Directory. The Failed Logons Report provides information about Who, Where, When and the Reason for failed logons. Along with this, because failed logon attempts could indicate the start of a data breach, the Potential Brute Force attack Threat model could be enabled to send an alert if the threshold for failed password attempts is met. An example of the Report and the Threat model are shown below:
The Failed Logon Report in Lepide Auditor for Active Directory
To run the Failed Logon Report in Lepide Auditor:
- From the States & Behavior screen, expand the Active Directory component and click on Failed Logon Report
- Select a date range and filter by ‘User name is correct but the password is wrong’ to see only failed logons for bad passwords
- Click Generate Report
- The report is generated and can be grouped, filtered, saved and exported
The Potential brute force attack threat model:
The Potential brute force threat model can be configured to generate a real-time alert and respond to a threat once the threshold values, set by the user, have been met.
Using custom script execution, the response could be to shut down users, servers and take other actions to mitigate the effects of a security breach.