How to delegate and audit password changes on a Domain

Recently I was asked to give some administrative personnel the ability to reset, unlock and change passwords. To which I said: HELL NO!, but since this was not my decision to make and it was my task to complete I had to come up with a solution.  So I had to give these muggles access but have the ability to audit what they were doing.

… so that is how this post came to be.

Preparing the servers to collect auditing information

We will need to prepare the environment first.  To do this Create a GPO called “Domain Controllers Security Policy” (or whatever name you want) and link it to the Domain Controllers OU. This is done following best practices not to modify the default GPOs.

Launch the Group Policy Manager and under Computer Configuration/Windows Settings/Security Settings/Local Policies/Audit Policy enable Succces, Failure on the Audit account management and Audit privilege use

All of this information will go to the event logs so you will have to increase the default size of the Security Log.  The maximum size needed will depend on a lot of factors in you Domain, but be aware that the security log should never be over written. I will go with a nice number like 256MB for this demo.

** To apply to GPO and be on the safe side open a CMD prompt and execute gpupdate /force, also it’s a good idea to restart the server if possible.

It’s a good idea to configure AutoBackupLogFiles registry entry to do log rotation


Value: AutoBackupLogFiles
Data value: Value not present or 0 (zero) equals “disabled.” (This is the default.) Any non-zero value equals “enabled.”

By default, event logs are stored in the %SystemRoot%\System32\Config folder. If you turn on this registry value, a full log file is automatically backed up in the %SystemRoot%\System32\Config folder, the log file is cleared, and event logging resumes.

When a log file is successfully backed up, event 524 is logged with a source of “eventlog” in the Security event log file. The event is similar to:

The Security log file was saved as Security-YYYY-MM-DD-HH-MM-SSS-mmm.evt because the current log file is full.

If this does not work for you you can schedule a .cmd script with wevutil:

Or use PowerShell with the Get-EventLog and Clear-EventLog commands as a .ps1 script.


Delegating password control to X users

We have to launch the Active Directory Users and Computers administration tool and create a Global/Security group called gsPasswordManagers to delegate these privileges to and add the user(s) to as member of this group:

Now let’s do some delegation by right clicking the OU and chose Delegate Control from the menu. The Delegation of Control Wizard should be displayed. On the Welcome dialog box, click Next.

On the Users and Groups dialog box, click Add. Select the group gsPasswordManagers, and then click OK. On the Users and Groups dialog box, click Next.


On the Tasks to Delegate dialog box, click Create a custom task to delegate, and then click Next.

On the Active Directory Object Type dialog box, click Only the following objects in the folder:.  In the list, click User objects (the last entry in the list), and then click Next.

On the Permissions dialog box, click to clear the General check box, and then click to select the Property-specific check box. In the Permissions list, click to select: Read all properties, Change password, Reset password, Write lockoutTime and then click Next.

On the Completing the Delegation of Control Wizard dialog box, click Finish.

–Update —

In some systems I had problems applying the lockout settings  with the GUI.  So I had to apply it via command line.  This would be a the format to achieve it.

dsacls “ou=ouname,dc=domain,dc=com” /I:s /G “domain\group Name”:rpwp;lockoutTime;user

dsacls “ou=Domain Users,dc=homelab,dc=local” /I:s /G “homelab\gsPasswordManagers”:rpwp;lockoutTime;user

–/Update —

Then go to the OU you are delegating, right click and select Properties, Security Tab and click on Advance to verify permissions.


Auditing using PoweShell v3

Once you setup Auditing and Event Log configurations you are ready to pull the data there are different ways to do this but I go the PowerShell route.

To use Powershell v3 on Windows 2008 R8/Windows 7 you must have .net 4 and the Windows Management Framework 3 installed on your station and servers.

Let’s start PowerShell as an Administrator

Then let’s review your execution policy.


On Windows 2008 R2 and back it’s set by default as Restricted and we want it as RemoteSigned so our scripts run.

Set-ExecutionPolicy RemoteSigned

Confirm the changes by answering “yes” at the prompt.

Also you may (should) want to do this from your management station so for this we must enable Remoting.

For that just execute:

Enable-PSRemoting –Force

This will setup everything on your server for you to execute PowerShell commands remotely.

This should go something like this:

Finally let’s audit this sucker:

The event IDs we are looking for are:

  • 4767: A user account was unlocked.
  • 4738: A user account was changed.
  • 4724: An attempt was made to reset an account’s password.

To do this in PowerShell use the following command:

Get-EventLog –LogName Security –InstanceID 4767,4738,4724

To get this in a from that is consumable it should be as CSV, XML or for a quick report HTML (it’s kind of ugly).

Get-EventLog –LogName Security –InstanceID 4767,4738,4724 |Export-Csv c:\temp\report.csv

Get-EventLog –LogName Security –InstanceID 4767,4738,4724 |Export-Clixml c:\temp\report.xml

Get-EventLog –LogName Security –InstanceID 4767,4738,4724 |ConvertTo-Html |Out-File c:\temp\report.thm

To do this remotely from your management station:

Invoke-Command –ComputerName %computername%  {command}

Let assume my domain controllers are named LAB-DC01 and LAB-DC02 so the command would look like this:

Invoke-Command –ComputerName LAB-DC01,LAB-DC02 { Get-EventLog –LogName Secuirity –InstanceID 4667,4668,4867 |Export-Clixml c:\temp\report.xml }

And as you can see below this will have a performance cost, so you use some options to filter like: –Newest <int>, -UserName <string>, -After <yyyy/mm/dd>

After the wait is over the output would look like this:


XML is a “good” format to be feed to other systems (SQL or SIEM) or to be parsed.  Besides, you can always use good old CSV and do almost the same.



Auditing using the Event Viewer

Also for quick look using the GUI you can create a custom view on the Event Viewer:

Finally you can export the results of your Custom View to XML, CSV or TXT and feed it to any other tool you have.








Hope this helps some of you guys and gals out there …

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload CAPTCHA.