Active Directory / Intermediate / Lesson 8

Delegation and administrative boundaries

Delegate a narrow task over an explicit object scope, distinguish data administration from service control, and verify denied actions as carefully as allowed ones.

About 5 min readContent reviewed 2026-10-26

On this page

Lesson goals

Define a delegated actor, task, target scope, and approval owner.
Explain inherited directory permissions and privileged-object exceptions.
Review effective privilege paths without changing ACLs.

Delegate an operation, not an undefined administrator label

A support team may need to maintain selected learner objects without controlling domain controllers, schema, or privileged accounts. Define the permitted task and object scope before choosing permissions. Data administration and directory service administration have different blast radii. A broad group such as Domain Admins is not the normal answer to a narrow support workflow. Use an approved role group, identifiable owners, and a review condition. This lesson models task eligibility only and never changes a security descriptor, resets an account, or requests administrative credentials. The model’s labels are not actual directory rights or ACE identifiers.

Test the role and target conditions independently

The complete Python fixture permits one synthetic support action only within the Learners scope. It checks one allowed request and rejects the same task outside that scope as well as an unrelated task. This is not a Windows effective-access engine and omits inheritance, object-specific ACEs, protected objects, deny rules, and token membership. Its purpose is to make the intended least-privilege contract explicit before any implementation review. A real delegation can grant more than its friendly task name suggests, so compare the actual directory permissions and ownership paths against this narrow intent under an authorized process.

python Offline task-and-scope decision model

allowed_actions = {"support_learner_record"}
allowed_scope = "Learners"
def permitted(action, scope):
    return action in allowed_actions and scope == allowed_scope
print(permitted("support_learner_record", "Learners"))
print(permitted("support_learner_record", "Privileged"))
print(permitted("change_schema", "Learners"))

Expected output

True
False
False

The outputs are True, False, False. No AD permission or account state is queried or modified.

Directory containment does not guarantee identical effective rights

Delegated permissions can be inherited through an OU hierarchy, but the actual security descriptor, inheritance flags, object class, and protected administrative-object handling matter. Moving an object into a support OU does not prove the support role can or should control it. Conversely, a role that can edit group membership or permissions may indirectly reach more valuable resources. Treat ownership and the ability to modify another privileged principal as part of the privilege graph. Keep service identities and privileged users outside ordinary learner workflows unless a reviewed requirement says otherwise. Special administrative protections must not be disabled simply to make a delegation appear convenient.

Write the grant and its explicit exclusions

The contextual record lists an intended support task, the learner scope, and exclusions for schema, controller management, and privileged identities. It is not a Delegation of Control Wizard script or an ACL import. A real review needs exact rights, inheritance targets, approval, change identity, audit coverage, rollback, and negative tests. Resource permissions are separate from the right to administer the directory record. Owning an OU or supporting a user does not automatically entitle the administrator to read that user’s private application data. Document both administrative authority and resource access rather than collapsing them into one role.

json Non-runnable delegated-task specification

{"role":"learner-support","scope":"OU=Learners,DC=ad,DC=example,DC=test","intent":["support_learner_record"],"excluded":["schema_control","controller_management","privileged_identity_management"],"state":"design_review"}

The record is a review contract only. It grants no rights and cannot establish effective permission in a real directory.

Prove both reach and limits

An isolated delegation test should cover the allowed object type and task, a sibling OU, a protected account, and a prohibited operation. Test nested role membership and inherited permissions when the design uses them. Preserve a sanitized before/after permission record and approved audit evidence rather than collecting credentials. A local Boolean test cannot prove an ACL was implemented correctly. Review delegated groups periodically and after OU or application changes. When a task fails, identify the exact missing or denied right before adding broader access. A successful workaround with a highly privileged identity is evidence of a difference, not justification to grant that privilege permanently.

Common errors and fixes

Support receives full domain administration for one task.

Why it happens: Task scope was replaced by a broad privileged role.
How to fix it: Define and implement only the reviewed task and target rights.
Prevent it next time: Require negative delegation tests and periodic review.

An OU move is assumed to make a privileged account ordinary.

Why it happens: Containment was confused with privileged-object handling and control paths.
How to fix it: Review the account’s actual privileged relationships and protections.
Prevent it next time: Keep privileged identities out of routine support scope.

A role can modify another role that controls a critical resource.

Why it happens: Only direct permissions were reviewed.
How to fix it: Include indirect membership, ownership, and permission-editing paths.
Prevent it next time: Maintain a reviewable privilege relationship model.

Check your understanding

1. The support role must also work in Alumni. Describe the model change and the real-world validation still required.

Show worked solution

Change the permitted scope model to an explicit set containing Learners and Alumni, then add allowed and denied cases for both boundaries. That does not implement delegation. Review actual object types, inherited rights, privileged exclusions, approvals, and audit/rollback before any authorized change. Do not replace the scope test with a universal True just because another OU is needed.

2. A delegated administrator can edit a group that has access to confidential files. Explain why reading only the direct OU task list misses a risk.