Active Directory / Basic / Lesson 6

Accounts, groups, and resource access

Separate principal lifecycle from role membership and resource permission, using group scope and a simple offline relationship model deliberately.

About 5 min readContent reviewed 2026-10-26

On this page

Lesson goals

Distinguish user, computer, service, and local account identities.
Explain security-group type and scope in access design.
Review membership changes without assuming immediate session revocation.

An account represents an authority and a lifecycle

A domain user, a computer account, a service identity, and a local machine account have different purposes and management owners. Similar names do not make them the same security principal. Document creation approval, intended use, accountable owner, expiration or review, and offboarding. Routine interactive work should not use a broadly privileged service or administrative identity. Computer membership also involves a machine relationship, not just a visible hostname. This course never creates accounts, joins devices, resets secrets, or tests credentials. Its examples use labels that cannot stand in for real SIDs, credentials, or actual access tokens.

Put roles in groups and permissions at resources

Security groups can contribute authorization data; distribution groups are not security-enabled entries for a DACL. Global, universal, and domain-local scopes have different membership and permission-placement rules. A common same-domain design places accounts in a global role group, nests that group in a domain-local resource group, and grants the resource permission to that resource group. This is a design pattern with scope constraints, not an instruction to add every user to a powerful default group. Record why membership exists and who approves it. A group name such as Readers does not itself grant anything until a resource policy refers to the appropriate principal.

Resolve the modeled group chain without evaluating Windows ACLs

The complete Python example follows two declared membership edges and checks one allow-only resource-group condition. A visited set prevents an infinite walk if the synthetic graph contains a cycle. This does not implement Windows access checking, AD group-scope validation, deny ACE behavior, inherited ACL ordering, SID history, or session token construction. Its value is making a role-to-resource relationship reviewable. In a real investigation, distinguish current directory membership from the authorization data in an existing session and from the target’s policy. Do not report the model’s True as effective permission on a real share.

python Offline allow-only membership graph

membership = {
    "learner-17": {"GG_CourseReaders"},
    "GG_CourseReaders": {"DL_CourseFiles_Read"},
}
seen = set()
pending = list(membership.get("learner-17", set()))
while pending:
    group = pending.pop()
    if group in seen:
        continue
    seen.add(group)
    pending.extend(membership.get(group, set()))
print(sorted(seen))
print("DL_CourseFiles_Read" in seen)

Expected output

['DL_CourseFiles_Read', 'GG_CourseReaders']
True

The sorted group chain contains the role and resource group, then prints True. No directory lookup or resource access check occurs.

Document the entitlement rather than a vague group change

The contextual record names the actor label, role group, resource group, allowed action, and approval owner. It is not a group-management command or an import file. A real grant must satisfy group-scope rules and the resource’s full access policy, including additional share/application layers when present. Review privileged default groups especially carefully because their effects extend beyond one named resource. Avoid direct per-user grants when a maintained role/resource group design fits the requirement, but do not convert a design preference into a claim that group nesting automatically solves least privilege or revocation.

json Non-runnable synthetic entitlement record

{"principal":"learner-17","role_group":"GG_CourseReaders","resource_group":"DL_CourseFiles_Read","resource":"course-files","action":"read","approval_owner":"course-resource-owner"}

The plan makes the intended grant and owner explicit. It does not add a member, alter an ACL, or authenticate an account.

Membership state is not every active session

Removing a group membership or disabling an account changes directory state, but existing tickets, tokens, application sessions, caches, and resource policies can affect when access actually ends. Define the required revocation behavior and an approved verification process instead of promising immediate universal denial. Review service identities separately because an offboarding action can interrupt a workload. Keep entitlement reviews tied to resource owners and recorded business need. Test both intended allowance and intended denial in an authorized isolated fixture. An access issue should not be repaired by adding broad administrator membership when the target action is only reading course material.

Common errors and fixes

A distribution group is used as an assumed security grant.

Why it happens: Group purpose and security-enabled type were not distinguished.
How to fix it: Choose a valid security principal and scope for the resource policy.
Prevent it next time: Record type, scope, membership, and permission placement.

Removing a group is claimed to revoke every session instantly.

Why it happens: Directory state was confused with existing authorization state.
How to fix it: Define and verify revocation across the actual session boundaries.
Prevent it next time: Include ticket and application-session assumptions in offboarding plans.

A read-only resource issue is repaired with administrator membership.

Why it happens: A narrow entitlement problem became a broad privilege grant.
How to fix it: Review the intended resource-group and policy path.
Prevent it next time: Require resource-owner approval and negative access tests.

Check your understanding

1. Remove the edge from GG_CourseReaders to DL_CourseFiles_Read in the model. Give the result and its limitation.

Show worked solution

The reachable set contains only GG_CourseReaders and the allow-only condition prints False. This shows that the declared model no longer contains the modeled permission path. It does not prove a real user is denied: explicit grants, other groups, existing tokens, and target policies are not represented. Keep actual effective-access verification within an authorized procedure.

2. A user changes departments but still needs temporary read access to one course archive. Separate the OU and entitlement decisions.