Chapter purpose
Directory permissions are more granular than group membership alone. This chapter teaches the access-control model behind OU delegation, object rights and inherited permissions.
Learning objectives
- Explain DACL, ACE and inheritance in plain language.
- Distinguish resource groups from administrative delegation.
- Delegate routine tasks at OU scope.
- Recognize why explicit deny and excessive inheritance complexity create operational risk.
Why this matters in a real company
A company should not need Domain Admin membership just to reset passwords or join workstations. Correct delegation lowers the impact of stolen or misused admin credentials.
13.1 Security descriptors define control
Active Directory objects have security descriptors. The discretionary access control list contains access-control entries that identify a security principal, the right being granted or denied, inheritance behavior and sometimes the object class or property affected.
You rarely need to edit raw security descriptors by hand, but you do need to understand that the Delegation of Control Wizard is writing ACL entries behind the scenes.
13.2 Inheritance makes delegation scalable
Permissions placed on an OU can inherit to child objects according to the ACE design. That lets one helpdesk group receive password-reset rights for users in an OU without adding rights separately to every account.
Inheritance can also hide mistakes. A right granted high in the tree may affect thousands of objects below.
13.3 Delegate tasks, not broad roles
- Define the exact task.
- Choose the narrowest OU scope.
- Create a role group.
- Delegate only the required object types and permissions.
- Test an allowed action.
- Test a denied action outside scope.
- Document owner and review date.
13.4 Avoid casual deny entries
Explicit deny can be useful, but it complicates effective permission analysis because it interacts with inherited allows and object-specific ACEs. Prefer clean scope and least-privilege allows where possible.
Before adding a deny, understand exactly which identities and child objects will inherit it.
13.5 Evidence and review
PowerShell can expose directory ACLs, but output is dense. Export before/after evidence when changing delegated rights and test with a non-privileged account.
Get-Acl 'AD:OU=Users,DC=corp,DC=example,DC=com' | Format-List
Get-ADGroupMember 'Helpdesk-PasswordReset'Helpdesk needs to reset passwords for staff but not executives
The company has normal users in one OU and executive accounts in another. Helpdesk currently shares a Domain Admin account.
Decision: Create a dedicated helpdesk group and delegate reset/unlock rights only to the ordinary-user OU. Remove routine dependence on Domain Admin.
What to prove: A helpdesk test account can reset an ordinary user's password but cannot change an executive or privileged account.
Hands-on lab
In a test domain, create Users and Executives OUs, delegate password reset to a Helpdesk group only on Users, and prove both allowed and denied operations.
Troubleshooting exercise
- Helpdesk can reset too many accounts. Trace inherited ACL scope.
- Delegated user gets access denied on one object. Check protected/inheritance state and object ACL.
- A deny entry blocks an expected admin action. Calculate effective permissions before adding more entries.
Field checklist
- Task requirement documented.
- OU scope intentional.
- Dedicated delegation group used.
- Allowed and denied tests performed.
- Privileged accounts outside routine helpdesk scope.
- ACL changes reviewed periodically.
Chapter summary
Delegation is successful when people can perform the work they own and nothing broader. OU structure, groups and ACL inheritance should make that intent easy to explain.
Current technical references
The supplied historical books are used as curriculum and operational context. Current implementation details are checked against current Microsoft documentation.