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

Source: https://srvscripts.com/guides/delegate-password-reset-active-directory/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

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.

**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.

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”.

## 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

**Official documentation:** [Dsacls command reference](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc771151(v=ws.11)), [Appendix C: Protected Accounts and Groups in Active Directory](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-c--protected-accounts-and-groups-in-active-directory), [User-Force-Change-Password extended right](https://learn.microsoft.com/en-us/windows/win32/adschema/r-user-force-change-password).

**Related guides:** [AD Account Lockout Source: Easy Event 4740 Tracing](/guides/ad-account-lockout-source-event-4740/) · [AD audit policy: logons, account changes, lockouts](/guides/active-directory-audit-policy/) · [Fine-Grained Password Policy (PSO) in Active Directory: Easy 2026 Setup](/guides/fine-grained-password-policy-pso/).

## 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.