Active Directory / Basic / Lesson 3
OUs, objects, and directory names
Design containment for management and policy, then distinguish an object’s current directory path from the stable identity integrations need.
On this page
Lesson goals
- Explain OU containment, delegation, and policy linkage.
- Read a distinguished name without treating it as a permanent identity.
- Separate organizational placement from security group membership.
Choose an OU for an administrative purpose
An organizational unit is a container inside one domain used to organize management and Group Policy scope. Its hierarchy should support who manages which objects and which policies apply, rather than simply copying every department name. OUs do not create new authentication realms or independent forest security boundaries. A user or computer has one current containment location, while group membership can express several roles at once. Keep those relationships separate. A large rename or move can affect delegated rights and policy inheritance even when the person’s job title did not change. Review the intended effects before an approved change.
Walk the declared hierarchy without querying a directory
The complete Python fixture represents three simple container identifiers and follows their parent links. It verifies the planned containment path and rejects a cycle if one appears in this model. It is not an LDAP distinguished-name parser and does not model every AD object class or inheritance rule. Real distinguished names have escaping and syntax requirements that naive string splitting can mishandle. Keep a model’s purpose narrow: a relationship diagram can reveal an ownership mistake without proving live ACLs, GPO processing, or the safety of moving an existing object. No directory is opened by this program.
parents = {"learners": "people", "people": "domain", "domain": None}
path = []
current = "learners"
while current is not None:
if current in path:
raise ValueError("cycle in model")
path.append(current)
current = parents[current]
print(" > ".join(path))
learners > people > domain
The path is learners > people > domain. These are model labels, not discovered OUs or an executable directory move.
A name can change while the object remains the same entity
A distinguished name describes a directory location through relative names and domain components. A common name, sign-in name, display name, and object identifier serve different purposes. Renaming or relocating an object can change its DN, so a long-lived integration should choose a documented identity attribute and a migration policy rather than assuming the path is immutable. User principal names also need a deliberate suffix and sign-in contract; they are not simply every DNS hostname associated with the organization. Never infer permissions from a friendly display name or treat a renamed account as a newly authorized person.
Document the object and the management owner
The contextual record describes a synthetic user under a learner OU and names an administrative owner. Its synthetic_object_id is a local fixture label, not a real AD GUID or SID. The record creates no user and is not a supported import format. A real OU review should include permitted object types, delegated actions, inheritance expectations, policy links, and exception handling. Default containers such as Users are not automatically OUs with the same linking behavior. A group can grant resource access without containing the user in the directory tree. Document both placement and membership when they influence an application’s assumptions.
{"synthetic_object_id":"user-17","dn":"CN=Mira,OU=Learners,OU=People,DC=ad,DC=example,DC=test","management_owner":"learner-support","resource_roles":["course-readers"]}
The review should distinguish the DN, model identity, owner, and role list. No object, group membership, or delegation is changed.
Test the consequences of placement before changing it
For a proposed OU move, identify which inherited policies and delegated rights can change and which explicit memberships should remain. Review applications that locate objects by path and workflows that assume a particular container. Test representative users and computers in an authorized isolated directory before production approval. An offline parent-path model cannot establish the resulting security descriptor or policy result. Keep the before/after plan and rollback constraints precise. If a user reports a problem after a move, compare placement, effective policy evidence, and resource permissions separately instead of assuming the account’s password or the whole domain is broken.
Common errors and fixes
A group is expected to change OU placement.
- Why it happens
- Role membership was confused with directory containment.
- How to fix it
- Model group membership and parent container separately.
- Prevent it next time
- Document both relationships for each managed object.
An integration breaks after a harmless-looking rename.
- Why it happens
- A mutable distinguished name was used as a permanent identity.
- How to fix it
- Review the supported identifier and update path-dependent contracts.
- Prevent it next time
- Test rename and relocation scenarios in design reviews.
An OU move unexpectedly changes user policy.
- Why it happens
- Inheritance effects were excluded from the change plan.
- How to fix it
- Compare the old and new policy/delegation scope before approval.
- Prevent it next time
- Require a before/after impact record for placement changes.
Check your understanding
1. Move the model label learners under a new parent training. What must the model data include, and what real-world effects remain outside the test?
Show worked solution
Add training with its own parent domain and point learners to training. The path becomes learners > training > domain. The model verifies those explicit edges only. It does not compute changed GPO links, inherited ACEs, application search paths, or the supported procedure for an actual OU move. Those need an authorized impact review and isolated directory evidence.
2. A record’s display name changes from Mira to Mira Training. Explain why neither authentication identity nor file permissions should be inferred from that text alone.
Show worked solution
Display names are presentation attributes and can be nonunique or mutable. Authentication and authorization depend on actual principal identity, session information, group/token data, and target policies. Review the documented attributes used by each integration rather than matching a friendly name. A rename test should confirm expected presentation while preserving the intended identity and access contract.
Key takeaways
- OUs organize policy and delegated management.
- Names and identifiers have different lifetimes.
- Placement changes need policy and access impact review.