Practical IT Training and Technical KnowledgeWhere to Buy through Server Warehouse
NETCOMTECHIT Training & Technical Knowledge

ACTIVE DIRECTORY DEEP CORE

Active Directory Objects, OUs, Users, Groups and Computers Deep Core

Understand Active Directory as a structured object database instead of a collection of GUI folders.

Active Directory Deep Core | Chapter 3 of 7

Chapter purpose

The historical Cookbook split objects, OUs, users, groups and computers into separate chapters. This modern chapter ties them into one identity lifecycle.

Historical source context: The supplied reference books describe Windows 2000/2003 and Exchange 2000/2003. They are used for subject breadth and architectural history, not as current production instructions. The material below is rewritten in original wording and modernized with current Microsoft documentation.

Learning objectives

  • Explain object, class, attribute and distinguished name.
  • Use OUs for delegation and policy scope.
  • Use groups for authorization.
  • Manage joiner, mover and leaver events consistently.

Why this matters in a real company

A clean identity lifecycle shortens onboarding, reduces forgotten access and makes audits easier. A messy directory creates hidden permissions that survive staff changes.

Chapter contents

  1. 3.1 Objects and attributes are the basic unit
  2. 3.2 Use OUs for management and groups for access
  3. 3.3 Joiner, mover and leaver is the real control
  4. 3.4 Computer accounts establish machine identity
Identity lifecycle from business event to resource access
HR eventjoin move leaveAD objectuser/computerOU and grouppolicy + accessBusiness resourcefiles/appsTrace the dependency chain, then prove each handoff with evidence.

3.1 Objects and attributes are the basic unit

Users, computers, groups and OUs are directory objects. Their classes define which attributes they can contain. A distinguished name identifies an object location in the directory hierarchy.

Automation should not rely only on display names because they can change and may not be unique.

Get-ADUser -Identity alice
Get-ADUser -Filter 'Department -eq "Finance"' -Properties Department,Enabled

3.2 Use OUs for management and groups for access

OU design should support Group Policy scope and delegated administration. It should not be a perfect copy of an organization chart that changes every year.

Granting resource access through role-based groups makes intent easier to understand than adding individual users directly to ACLs.

3.3 Joiner, mover and leaver is the real control

  1. Create identity from approved source.
  2. Assign role groups.
  3. Place computer/user in intended OU.
  4. Verify sign-in and access.
  5. On role change remove old access and add new.
  6. On departure disable promptly and follow retention process.

3.4 Computer accounts establish machine identity

A domain-joined Windows device has a computer account and a secure relationship with the domain. Resetting or deleting computer accounts without understanding that relationship can break trust.

Stale accounts should be reviewed according to policy, not blindly deleted because a date threshold was exceeded.

Get-ADComputer -Filter * -Properties LastLogonDate | Sort-Object LastLogonDate | Select-Object Name,LastLogonDate
DEEPER READING

Identity attributes that survive name changes

An account has several identifiers. Display name is for people. sAMAccountName supports legacy-style logon naming. User Principal Name is commonly used for user sign-in. The security identifier, or SID, is what Windows authorization ultimately uses for security principals. ObjectGUID is another stable object identity inside AD.

This distinction explains why renaming Alice Smith to Alice Jones does not automatically destroy her permissions. The object remains the same security principal unless it is deleted and recreated. Recreating an account with the same visible name produces a different SID and can break access tied to the old identity.

Group design and nested access

Group nesting can simplify large environments, but it also hides effective access. A user may gain access through several nested groups even when the final resource ACL never mentions the user. During troubleshooting, inspect the full membership path and the user token rather than only the first-level group list.

Keep role groups understandable and assign owners. A group named TEMP-ACCESS-2 that nobody owns will eventually become permanent. Names should describe business purpose and, where appropriate, the resource or role they grant.

WORKED BUSINESS SCENARIO

An employee moves from Sales to Finance

The user keeps the same laptop and email identity but must lose Sales share access and gain Finance access.

Decision: Change role-group membership rather than rebuilding the account. Review nested or direct permissions that may preserve old access.

Evidence: Show before/after membership and test denied old resource plus allowed new resource.

PRACTICAL WORK

Hands-on lab

Create Sales and Finance OUs, role groups and two test users. Move one user between roles and prove access changes separately from OU policy changes.

Troubleshooting exercise

  1. User still has old access after group removal: check nested groups, token refresh and direct ACLs.
  2. New PC has domain trust failure: check DNS, time and computer account state.
  3. Policy follows user unexpectedly: identify user vs computer policy.

Field checklist

  • OU purpose documented.
  • Groups used for access.
  • Direct user ACLs minimized.
  • Joiner/mover/leaver process exists.
  • Stale accounts reviewed.
  • Computer-account recovery procedure known.

Current technical references

The supplied PDF books are used as a historical curriculum map. Current implementation guidance is checked against current Microsoft documentation.