In many offices the Domain Admin password is shared with every branch helper because "they need to reset passwords". This page replaces that habit with the Delegation of Control wizard - one right, one OU, nothing more.
The call is always urgent: a user in the Jaipur branch is locked out and work has stopped. So the admin password travels - by phone, by chat, by sticky note - until half the company effectively runs the domain. Delegation exists precisely for this: give a named group one small job on one OU, and the job gets done at branch speed while the domain stays yours. This page walks the wizard and the boundaries that make it safe.
One task, one OU, one group. Everything not on this list stays with the domain admin.
Three choices make delegation safe, and all three are in your hands before the wizard opens:
GRP-Jaipur-Helpdesk) - people join and leave the group; the delegation itself never changesRight-click the OU in dsa.msc → Delegate Control → add the group → tick that single task → Finish. The whole job takes two minutes.
The helper can now reset passwords for users inside that OU - and nothing else. They cannot delete accounts, change group memberships, touch other branches, or log on to the domain controller itself. Test it the same day: sign in as a helper, reset a test user's password, then try one forbidden action and confirm it fails. A delegation you have not tested from the helper's side is a hope, not a control.
A shared password has no owner. When something breaks, the log shows "Administrator" and every helper is a suspect; when the password leaks, it must change everywhere at once, including on the people you still trust. Delegated rights are the opposite: each helper signs in as themselves, every reset carries their name in the event log, and removing one helper from the group ends their power in seconds. That difference is the entire argument.
Once password reset works, the same pattern extends carefully: unlocking accounts is usually bundled with the same helpdesk role; a store manager might get read-only visibility of their OU; an HR assistant might update phone numbers and titles (the wizard's custom task can scope attribute-level rights). Add one job at a time, test it, and write it down. Delegation creep - five new rights granted in one sitting because it was convenient - recreates the original problem in a nicer costume.
Delegations are invisible in daily use, so review them deliberately. In ADUC, enable Advanced Features, open the OU's Properties → Security tab, and read who holds what - that list should match your one-page delegation record exactly. A helper leaving the company is handled by the normal leaver routine: disable their account and remove them from the helpdesk group, and every delegated right disappears with the membership.
The full OU, user and group creation process - live on a real domain controller, step by step.
▶️ Watch Full VideoNo. Password reset rights apply to ordinary user accounts in the delegated OU. Admin accounts are protected by AdminSDHolder, and a helpdesk delegation does not override that protection - which is exactly how it should be.
No server access is needed. They use Active Directory Users and Computers from the free RSAT tools on their own Windows PC, signed in with their own account, and the delegated right follows their sign-in.
Open the OU Properties with Advanced Features on, go to the Security tab, select the group, and remove the special permissions listed there. There is no single undo button, which is one more reason to delegate slowly and keep a written record.