skip to content

In Active Directory, a user in no privileged group still reaches Domain Admins — which rights explain it?

level: middleimportance: should knowfreq 52%

answer

  1. membership is one edge type
  2. who can rewrite the permissions
  3. the owner can grant themselves anything
  4. inherited at the organisational unit
  5. force reset, self-membership, WriteDacl

basics

~20 s

Membership is only one kind of edge. Ownership, WriteDacl, WriteOwner, GenericAll, write access to a group's member attribute and the force-password-reset extended right each let one principal take control of another, and inherited delegation spreads them across whole organisational units.

solid answer

~50 s

Group membership is one edge type in a graph that has several. An owner of an object implicitly holds the right to rewrite its ACL, so ownership alone is control. `WriteDacl` and `WriteOwner` are the same story one step removed. `GenericAll` and `GenericWrite` cover it outright. Write access to a group's `member` attribute — including the self-membership right — means an account can add itself. The force-password-reset extended right over a user means you become that user. Crucially these are usually granted at an organisational unit and inherited by every child object, including objects created years later, and groups nest into other groups, so the edges compose. So a user in no privileged group can own a group that is nested into a group whose members hold server administration, or can reset the password of somebody who is. Nothing was escalated; every step used a right somebody granted deliberately.

code

text · 10 lines
text
OU=Finance,DC=corp,DC=example
  ACE ALLOW  CORP\Helpdesk-Tier1  ExtendedRight: User-Force-Change-Password
              (inherited by child user objects)
  ACE ALLOW  CORP\App-Owners      WriteDacl
              (inherited by child group objects)
...
CN=Finance-Reporting,OU=Finance,DC=corp,DC=example
  owner:     CORP\jdoe
  member:    CN=svc-reporting,OU=Finance,...  (servicePrincipalName present)
  memberOf:  CN=Server-Admins,...  ->  memberOf: CN=Backup Operators,CN=Builtin,...

go deeper

for a junior

Know that permissions in a directory are held on objects, not only through groups, and that resetting somebody's password or editing a group's membership are rights that can be delegated to ordinary staff.

for a middle

Be able to name the control rights and say what each one buys — ownership implying ACL rewrite, WriteDacl, self-membership, force reset — and explain how inheritance and nesting compose them into chains.

for a senior

Demonstrate that you review the graph rather than the membership list: stale delegations on long-lived organisational units, forgotten owners, and nesting that quietly promotes a group into an administrative one.

for a principal

Own the design consequence: delegation granted for operational convenience accumulates for decades with nobody accountable for its removal, so the estate needs a tiering model where such grants cannot cross a privilege boundary at all.

## Membership is one edge among many The common mental model is that privilege in a directory equals group membership, so the review question is *who is in Domain Admins*. That model misses most of the graph. An edge exists from principal A to object B whenever A holds a right that lets A take control of B, and membership is only the most visible of those rights. ## The edges that actually matter **Ownership.** The owner of a directory object implicitly holds `READ_CONTROL` and `WRITE_DAC` on it regardless of what the ACL currently says. An owner can therefore grant themselves anything. Ownership is invisible on a membership report and is frequently stale — the account that created a group ten years ago may still own it. **WriteDacl and WriteOwner.** `WriteDacl` lets a principal rewrite the object's ACL and grant itself full control. `WriteOwner` lets it take ownership first and then do the same. Both are one hop from total control of the object. **GenericAll and GenericWrite.** Full control, or write over the object's attributes. On a group, write over attributes includes the `member` attribute. **Write on the member attribute, and self-membership.** A principal that can write `member` can add anyone, including itself, to the group. The self-membership extended right is the narrower version: the holder may add only itself, which is entirely sufficient. **Force password reset.** The `User-Force-Change-Password` extended right lets the holder set a user's password without knowing the current one. That converts an edge into full use of the target identity. **Service principal names as a weighted edge.** An account carrying a `servicePrincipalName` can have a service ticket requested for it by any authenticated principal, and that ticket is encrypted with the account's own key. The path to that account therefore exists at the cost of an offline password crack rather than a granted right. It is a real edge with a price tag, and the price is low whenever the service account has a human-chosen password. ## Why the edges compose Two mechanisms turn a handful of grants into a dense graph. **Inheritance.** Delegations are almost always applied to an organisational unit with inheritance to child objects. A help-desk delegation created in 2006 to reset passwords in `OU=Finance` still applies to every user object created in that OU since, including accounts that have since been made members of privileged groups. **Nesting.** A group can be a member of another group, and membership is transitive. Control of an unremarkable group can therefore be control of a group that is nested, two levels up, into something that administers servers. The result is a directed graph, and direction matters: A being able to reset B's password says nothing about B being able to reset A's. Shortest-path computation over that graph is what produces a ranked list of two-hop routes. ## Reading the fragment In the example above there is not a single privileged group membership belonging to the user. There is an inherited force-reset delegation over every user in the OU, an inherited `WriteDacl` over every group in the OU, an ownership entry, a nested membership chain ending in a builtin administrative group, and a service account with a service principal name sitting inside the group. Any one of those is a step; together they are a two-hop route. ## The exception worth knowing Inherited delegations do not reach members of protected groups. The SDProp process copies the AdminSDHolder object's ACL onto principals in protected groups roughly every hour and disables inheritance on them, so an OU-level delegation does not silently grant control of a Domain Admin. Two consequences follow: privileged accounts are protected from OU delegation, and the `adminCount` marker can linger after somebody is removed from the group, leaving an account whose ACL no longer matches its OU. ## The wrong answers - *He is not in the group, so there is no path.* Membership is one edge type. - *Ownership is only metadata.* Ownership implies the right to rewrite the ACL. - *Old delegations only apply to accounts that existed at the time.* Inheritance applies to child objects created afterwards too. - *These are all the same right.* They differ in what they let you do and in how noisy using them is; the graph distinguishes them.

  • Why is ownership an edge even when the owner holds no granted rights?
    Because the owner of a directory object implicitly holds READ_CONTROL and WRITE_DAC on it. That means the owner can rewrite the object's ACL and grant themselves full control at any moment, regardless of what the current entries say. Ownership is therefore equivalent to control, and it is easy to miss because it never appears on a membership or permissions summary.
  • Does an inherited organisational-unit delegation reach members of Domain Admins?
    No. The SDProp process stamps the AdminSDHolder ACL onto principals in protected groups about every 60 minutes and turns inheritance off on them, so OU-level delegations do not apply. The side effect worth knowing is that the adminCount marker can persist after somebody leaves the group, leaving an account with a protected ACL that no longer matches its container.
  • Are these control relationships directed, and why does that matter?
    Yes, strictly. A being able to force B's password reset implies nothing about B being able to do the same to A, and ownership runs one way. Shortest paths must be computed on the directed graph; treating the edges as undirected invents routes that do not exist and hides the real ones by making everything look reachable.
  • Why does a service principal name on an account count as an edge at all?
    Because any authenticated principal can request a service ticket for an account that advertises one, and that ticket is encrypted with the account's own key. The route to that identity therefore exists at the cost of cracking the key offline rather than at the cost of a granted right. It is an edge whose weight is password strength, which is why service accounts need long random passwords.

saying these in an interview costs you the question

  • Says no privileged group membership means no path
  • Treats object ownership as metadata rather than control
  • Assumes old OU delegations do not apply to newer accounts
  • Thinks only administrators can change group membership
  • Treats the control relationships as undirected

context

resolving links…