How-to Windows Active Directory Security

Delegate Password Reset in Active Directory: Secure 5-Step Helpdesk Setup

Give the helpdesk the right to reset passwords and unlock accounts on standard users only: Delegation of Control Wizard, the exact permissions it writes, dsacls and PowerShell equivalents, AdminSDHolder behaviour, auditing, testing and removal.

Published 30 Sep 2026Updated 3 Oct 2026 12 min read By srvScripts team

When you delegate password reset rights in Active Directory, the service desk can reset passwords and unlock accounts for normal users without being Domain Admins or Account Operators. This guide shows the three permissions involved, how to grant them with the Delegation of Control Wizard, dsacls or PowerShell, why admin accounts stay out of reach, and how to audit, test and remove the delegation on Windows Server 2016 to 2025.

Applies to Windows Server 2016 to 2025

Short answer: Create a group such as HD-PasswordReset, right-click the OU that holds standard user accounts in Active Directory Users and Computers, choose Delegate Control, add the group and select “Reset user passwords and force password change at next logon”. For unlocking, add a custom task that grants Read lockoutTime and Write lockoutTime on user objects.

Which method to use

Method	Best for	Pros	Cons
Delegation of Control Wizard	One-off setup on a few OUs	Guided; no typing of GUIDs	No undo; hard to repeat identically
`dsacls`	Scripts, many OUs, documentation	One line per permission; built in on DCs and with RSAT	Cryptic syntax
PowerShell (`Get-Acl`/`Set-Acl` on the `AD:` drive)	Automation and audits	Repeatable; easy to report and remove	Needs schema GUIDs
Account Operators group	Nothing	None	Far too broad; can manage most accounts and log on to DCs

The exact permissions

To delegate password reset and unlock correctly, grant three things on descendant User objects of the OU, and nothing else:

Permission	Type	Schema GUID	What it allows
Reset Password	Extended right (User-Force-Change-Password)	`00299570-246d-11d0-a768-00aa006e0529`	Set a new password without knowing the old one
Read/Write `pwdLastSet`	Property	`bf967a0a-0de6-11d0-a285-00aa003049e2`	Tick or clear “User must change password at next logon”
Read/Write `lockoutTime`	Property	`28630ebf-41d5-11d1-a9c1-0000f80367c1`	Unlock the account (set `lockoutTime` to 0)

The User class GUID, used to limit inheritance to user objects, is bf967aba-0de6-11d0-a285-00aa003049e2. Do not grant Full Control, Write all properties or the “Create, delete, and manage user accounts” task to the service desk: those allow changes to group membership, logon scripts and many other attributes.

Do not confuse Reset Password with Change Password. Change Password requires the old password and is granted to every user on their own account through the SELF principal; it is what happens when a user presses Ctrl+Alt+Del and changes their password. Reset Password is the right you delegate to the service desk.

Prerequisites

A global security group for the service desk, for example HD-PasswordReset, with only service desk accounts as members (ideally their separate admin accounts, not their daily mailbox accounts).
An OU design that separates standard users from admin, service and privileged accounts. Delegation on OU=Staff is safe only if nothing sensitive lives inside it.
Rights to change permissions on the OUs (Domain Admins, or a delegated role with Modify permissions).
RSAT Active Directory tools on the service desk workstations.

Step 1: Create the helpdesk group

New-ADGroup -Name 'HD-PasswordReset' -GroupScope Global -GroupCategory Security -Path 'OU=Groups,OU=Admin,DC=contoso,DC=com' -Description 'Reset passwords and unlock users in OU=Staff'
Add-ADGroupMember -Identity 'HD-PasswordReset' -Members 'adm-jsmith', 'adm-lcarter'

Put the group itself in an OU the service desk cannot manage, so members cannot add themselves to other groups. Use a separate admin account for each service desk member: if a daily-use account that reads e-mail is phished, the attacker should not inherit the right to reset other people’s passwords.

Step 2: Delegate with the Delegation of Control Wizard

Reset password and force change at next logon

Open Active Directory Users and Computers (dsa.msc), right-click the staff OU, for example Staff, and choose Delegate Control…. Click Next.
On Users or Groups, click Add, enter HD-PasswordReset and click Next.
On Tasks to Delegate, select “Delegate the following common tasks” and tick “Reset user passwords and force password change at next logon”. Click Next, then Finish.

This common task grants the Reset Password extended right and Read/Write pwdLastSet on descendant user objects. It does not include unlocking.

Unlock accounts (custom task)

Run Delegate Control… on the same OU again and add HD-PasswordReset.
Select “Create a custom task to delegate”.
Choose “Only the following objects in the folder”, tick User objects and click Next.
Under Show these permissions, clear General and tick Property-specific.
Tick Read lockoutTime and Write lockoutTime, click Next and Finish.

Repeat both wizard runs for every OU where the service desk should work. If your staff OUs share a parent, it is simpler to delegate password reset once on the parent: the entries inherit to user objects in every child OU, including ones created later.

Step 3: Or delegate with dsacls

The same delegation from an elevated command prompt. /I:S applies the entries to child objects only, and the last field (user) limits them to user objects:

dsacls "OU=Staff,DC=contoso,DC=com" /I:S /G "CONTOSO\HD-PasswordReset:CA;Reset Password;user"
dsacls "OU=Staff,DC=contoso,DC=com" /I:S /G "CONTOSO\HD-PasswordReset:RPWP;pwdLastSet;user"
dsacls "OU=Staff,DC=contoso,DC=com" /I:S /G "CONTOSO\HD-PasswordReset:RPWP;lockoutTime;user"

CA is Control Access (an extended right), RP is Read Property and WP is Write Property. To delegate password reset on several OUs, repeat the three lines per OU in a batch file and keep the file as documentation.

Step 4: Or delegate with PowerShell

Import-Module ActiveDirectory
$ou    = 'OU=Staff,DC=contoso,DC=com'
$sid   = (Get-ADGroup -Identity 'HD-PasswordReset').SID
$user        = [guid]'bf967aba-0de6-11d0-a285-00aa003049e2'
$resetPwd    = [guid]'00299570-246d-11d0-a768-00aa006e0529'
$pwdLastSet  = [guid]'bf967a0a-0de6-11d0-a285-00aa003049e2'
$lockoutTime = [guid]'28630ebf-41d5-11d1-a9c1-0000f80367c1'
$inherit     = [System.DirectoryServices.ActiveDirectorySecurityInheritance]::Descendents
$acl = Get-Acl -Path "AD:\$ou"
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $sid, 'ExtendedRight', 'Allow', $resetPwd, $inherit, $user))
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $sid, 'ReadProperty, WriteProperty', 'Allow', $pwdLastSet, $inherit, $user))
$acl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $sid, 'ReadProperty, WriteProperty', 'Allow', $lockoutTime, $inherit, $user))
Set-Acl -Path "AD:\$ou" -AclObject $acl

The AD: drive is created when the ActiveDirectory module loads. Wrap the block in a loop over Get-ADOrganizationalUnit results to apply the same delegation to every regional staff OU.

Protected accounts and AdminSDHolder

Members of protected groups such as Domain Admins, Enterprise Admins, Administrators, Account Operators, Backup Operators, Server Operators and Print Operators are handled by a background process called SDProp. It runs on the PDC emulator every 60 minutes by default, disables permission inheritance on those accounts and replaces their ACL with the one on CN=AdminSDHolder,CN=System,DC=contoso,DC=com. It also sets adminCount to 1.

The result is that when you delegate password reset on an OU, an admin account inside that OU still returns “Access is denied” for the service desk. That is the intended behaviour. Never add service desk permissions to AdminSDHolder: it would let the service desk reset Domain Admin passwords.

A side effect catches many teams: an account that used to be in a protected group keeps adminCount = 1 and its inheritance stays disabled after removal, so the service desk cannot reset it. Find and fix those accounts:

# Accounts marked as protected
Get-ADUser -LDAPFilter '(adminCount=1)' -Properties adminCount, MemberOf | Select-Object Name, SamAccountName
# After confirming jdoe is no longer in any protected group:
$dn  = (Get-ADUser -Identity jdoe).DistinguishedName
Set-ADUser -Identity jdoe -Clear adminCount
$acl = Get-Acl -Path "AD:\$dn"
$acl.SetAccessRuleProtection($false, $true)
Set-Acl -Path "AD:\$dn" -AclObject $acl

SetAccessRuleProtection($false, $true) turns inheritance back on and keeps the existing explicit entries.

How the service desk uses it

In ADUC, the service desk right-clicks the user, chooses Reset Password, enters a temporary password, ticks “User must change password at next logon” and, if needed, “Unlock the user’s account”. The same with PowerShell:

Set-ADAccountPassword -Identity jdoe -Reset -NewPassword (Read-Host 'Temporary password' -AsSecureString)
Set-ADUser -Identity jdoe -ChangePasswordAtLogon $true
Unlock-ADAccount -Identity jdoe
Get-ADUser -Identity jdoe -Properties LockedOut, PasswordLastSet | Select-Object LockedOut, PasswordLastSet

Agree an identity check before any reset, such as a call-back to a known number or a manager confirmation, because a delegated reset is exactly what a social engineering attacker asks for.

Add other helpdesk tasks safely

Once you delegate password reset, requests for “just one more right” follow. Grant each one narrowly, on user objects in the same OU, and document it next to the reset permissions:

Task	Permission to grant	Watch out for
Update phone, office and address	Read/Write the Personal Information or Public Information property set, or the individual attributes	Property sets include more attributes than their names suggest; review them first
Enable and disable accounts	Read/Write `userAccountControl`	The same attribute controls “password not required” and delegation flags; audit changes with event 4738
Add users to specific groups	Write Members on those groups only	Never on privileged groups or on the OU that holds them
Move users between OUs	Delete on the source and Create User objects on the target	Moving into another OU changes which GPOs and delegations apply

Keep each task in its own group (for example HD-PasswordReset, HD-UserContactInfo) so you can grant them independently.

Reduce the load with self-service

A delegated reset still costs a phone call. In hybrid environments, Microsoft Entra self-service password reset with password writeback lets users reset their own AD password after multifactor verification; it needs Microsoft Entra ID P1 or higher and writeback enabled in Entra Connect or Cloud Sync. Keep the delegated reset for users who cannot use self-service, and apply the same identity checks.

Step 5: Test the delegation

Test before you announce the change. A mistake when you delegate password reset rights is usually either too little (unlocking fails) or too much (other attributes are writable), and both show up in five minutes of testing with a dedicated test account.

Sign in as a test member of HD-PasswordReset, or run runas /user:CONTOSO\hd.test "mmc dsa.msc".
Reset the password of a test user in Staff and tick the change-at-logon box. Both must succeed.
Lock the test user out with wrong passwords, then unlock it. It must succeed.
Try to reset a user in another OU and an account with adminCount = 1. Both must fail with “Access is denied”.
Try to edit another attribute, such as the telephone number or group membership. It must fail.

If step 4 or 5 succeeds, the group has more rights than intended; check group nesting and existing ACEs before going live.

Audit delegations and resets

Review the ACLs quarterly and after every OU restructure. Delegations are invisible in normal ADUC views, and old entries for renamed or deleted groups (shown as unresolved SIDs) tend to accumulate over the years.

Where the group has permissions

$name = 'CONTOSO\HD-PasswordReset'
Get-ADOrganizationalUnit -Filter * | ForEach-Object {
    $ou = $_.DistinguishedName
    (Get-Acl -Path "AD:\$ou").Access |
        Where-Object { $_.IdentityReference -eq $name -and -not $_.IsInherited } |
        Select-Object @{ n = 'OU'; e = { $ou } }, ActiveDirectoryRights, ObjectType, InheritedObjectType
}
dsacls "OU=Staff,DC=contoso,DC=com" | findstr /i "HD-PasswordReset"

Each OU should show exactly three entries: ExtendedRight with the Reset Password GUID and ReadProperty, WriteProperty for pwdLastSet and lockoutTime.

Who reset or unlocked what

Enable Audit User Account Management (Success and Failure) under Computer Configuration » Policies » Windows Settings » Security Settings » Advanced Audit Policy Configuration » Audit Policies » Account Management in a GPO linked to the Domain Controllers OU. The Security log on DCs then records:

4724: an attempt was made to reset an account’s password (subject = service desk user, target = user).
4767: a user account was unlocked.
4738: a user account was changed (for example the change-at-logon flag).

Get-WinEvent -ComputerName dc01 -FilterHashtable @{ LogName = 'Security'; Id = 4724, 4767; StartTime = (Get-Date).AddDays(-7) } |
    Select-Object TimeCreated, Id, @{ n = 'By'; e = { $_.Properties[4].Value } }, @{ n = 'Target'; e = { $_.Properties[0].Value } }

Collect these events centrally (event forwarding or your SIEM) because each DC logs only the resets it processed.

Troubleshooting

Symptom	Cause	Fix
“Access is denied” on one user only	`adminCount = 1` with inheritance disabled	Clear `adminCount` and enable inheritance if the account is no longer privileged
Reset works, but the change-at-logon box fails	Only Reset Password granted	Add Read/Write `pwdLastSet`
Unlock checkbox greyed out or fails	No rights on `lockoutTime`	Add the custom task or the `lockoutTime` dsacls line
Works for new users, not for old ones	Inheritance disabled on older objects	Check the Security » Advanced tab; enable inheritance
Changes not visible yet	Replication or cached token	Wait for replication; sign the service desk user out and in after group changes

Remove the delegation

To remove every entry for the group on one OU:

dsacls "OU=Staff,DC=contoso,DC=com" /R "CONTOSO\HD-PasswordReset"
# PowerShell equivalent
$acl = Get-Acl -Path "AD:\OU=Staff,DC=contoso,DC=com"
$acl.PurgeAccessRules((Get-ADGroup -Identity 'HD-PasswordReset').SID)
Set-Acl -Path "AD:\OU=Staff,DC=contoso,DC=com" -AclObject $acl

Run the audit script afterwards to confirm no explicit entries remain on other OUs. When you delegate password reset through a dedicated group, removing a person is as simple as removing them from the group, and the ACLs never need to change.

Delegate password reset at a glance

Delegate Password Reset in Active Directory summary card: Create a group such as HD-PasswordReset, right-click the OU that holds standard user accounts in Active Directory Users… — In short: Create a group such as HD-PasswordReset, right-click the OU that holds standard user accounts in Active Directory Users and Computers, choose Delegate Control, add the group and select “Reset user passwords and force password change at next logon”.

Official documentation: Dsacls command reference, Appendix C: Protected Accounts and Groups in Active Directory, User-Force-Change-Password extended right.

Frequently asked questions

Does the Delegation of Control Wizard include unlocking accounts?

No. The common task “Reset user passwords and force password change at next logon” grants Reset Password and pwdLastSet only. Add Read and Write lockoutTime on user objects with a custom task to allow unlocking.

Why can the helpdesk not reset an admin account in the delegated OU?

Members of protected groups get their permissions from AdminSDHolder every 60 minutes and have inheritance disabled, so OU delegations do not apply. This is intentional and should not be changed.

How do I see who reset a user’s password?

Enable Audit User Account Management on domain controllers and look for event 4724 in the Security log. Event 4767 records unlocks.

How do I undo a delegation?

Run dsacls on the OU with /R and the group name, or remove the entries with PowerShell PurgeAccessRules. Then check other OUs with an ACL audit script.

Maintenance record

This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.

Maintained by: srvScripts editorial team
Supported versions: Windows Server 2016 to 2025
Last full review: 3 Oct 2026
Next review: 1 Apr 2027
Sources: learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc771151(v=ws.11)
learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory
learn.microsoft.com/en-us/windows/win32/adschema/r-user-force-change-password