Active Directory Phase 3: Directory Structure and Identities¶

Purpose¶

Build a small, understandable directory structure before creating users, groups, and delegated accounts. The structure separates objects by how they will be administered and which Group Policies they may receive.

Concepts used in this phase¶

Active Directory object¶

An object is a directory entry representing something such as a user, computer, group, or organizational unit, together with its stored attributes.

Organizational unit¶

An organizational unit, or OU, is a container used to organize AD objects, link Group Policies, and delegate limited administrative control.

Container versus OU¶

The default Users and Computers folders are compatibility containers, not OUs, so they cannot be used for Group Policy links in the same flexible way as purpose-built OUs.

Distinguished name¶

A distinguished name, or DN, is an object's complete LDAP path; for example, OU=Users,OU=Lab,DC=ad,DC=arphaxad,DC=dev uniquely identifies the lab's user OU.

Group Policy scope¶

Group Policy scope describes which users or computers receive a policy; OU placement is one of the main ways to control that scope.

Delegation of control¶

Delegation grants a user or group only the directory permissions needed for a task, such as joining workstations, instead of granting broad Domain Admin membership.

Standard and privileged accounts¶

A standard account is used for everyday work, while a separate privileged account is used only for administration; separating them reduces exposure of high-value credentials.

Security group¶

A security group collects users or computers so permissions can be assigned to the group rather than repeatedly to individual accounts.

Service account¶

A service account is an identity used by an application, scheduled task, or service rather than for ordinary interactive user sign-in.

Approved OU design¶

ad.arphaxad.dev
└── Lab
    ├── Admin Accounts
    ├── Users
    ├── Groups
    ├── Workstations
    ├── Servers
    └── Service Accounts

OU	Intended contents
`Lab`	Parent for objects managed as part of this learning environment
`Admin Accounts`	Named privileged accounts used only for administration
`Users`	Standard human user accounts
`Groups`	Security groups used for roles, permissions, and delegation
`Workstations`	Domain-joined Windows client computer accounts
`Servers`	Future member servers, excluding domain controllers
`Service Accounts`	Identities used by services or automation

The existing Domain Controllers OU remains separate and continues to contain DC-05. Do not move the DC into Lab\Servers; domain controllers receive special policy and permissions through their built-in OU.

The built-in Users and Computers containers must also remain in place for compatibility. New lab objects will be created or moved into the new OUs deliberately.

Phase sequence¶

Create and verify the OU hierarchy with accidental-deletion protection.
Create a standard personal user and a separate named administrative user.
Create role-based security groups.
Use group membership rather than assigning permissions directly to users.
Create a narrowly delegated workstation-join account and delegate permissions through its role group.
Exercise the account lifecycle: create, reset, disable, re-enable, and remove a test identity.
Validate the visible structure, identities, groups, and memberships in Active Directory Users and Computers.

Step 1: Create the OU hierarchy¶

On DC-05, sign in with the domain Administrator account for this initial directory build.

Open Server Manager.
Select Tools > Active Directory Users and Computers.
Expand ad.arphaxad.dev.
Right-click the domain, select New > Organizational Unit.
Enter Lab.
Keep Protect container from accidental deletion selected.
Select OK.
Right-click the new Lab OU and create each of these child OUs, keeping accidental-deletion protection selected for every one:
- Admin Accounts
- Users
- Groups
- Workstations
- Servers
- Service Accounts

Do not create users, groups, or computer accounts yet. Do not move DC-05 or any built-in object.

Verify the OU hierarchy¶

Open PowerShell as Administrator:

Get-ADOrganizationalUnit `
    -Filter * `
    -SearchBase "OU=Lab,DC=ad,DC=arphaxad,DC=dev" `
    -SearchScope Subtree `
    -Properties ProtectedFromAccidentalDeletion |
    Sort-Object Name |
    Select-Object Name,ProtectedFromAccidentalDeletion,DistinguishedName

The output should show Lab and all six child OUs. Every row should report:

ProtectedFromAccidentalDeletion : True

The OU hierarchy and protection settings were confirmed on August 13, 2026.

Step 2: Create separate standard and administrative users¶

Use public-safe placeholders in this repository and record the exact account names only in the private identity inventory. The intended naming pattern is:

Purpose	Public-safe example	Location
Everyday account	`lab.user`	`Lab\Users`
Privileged account	`lab.admin`	`Lab\Admin Accounts`

The everyday account remains a normal member of Domain Users. The privileged account is added to Domain Admins for this single-domain learning lab and is used only when administrative rights are required.

Create the standard user¶

In Active Directory Users and Computers, open Lab > Users.
Right-click the OU and select New > User.
Enter the person's name and the agreed everyday logon name.
Confirm the UPN suffix is @ad.arphaxad.dev.
Set a unique temporary password.
Keep User must change password at next logon selected.
Leave User cannot change password, Password never expires, and Account is disabled unselected.
Complete the wizard.

Create the named administrative user¶

Open Lab > Admin Accounts.
Right-click the OU and select New > User.
Use a clearly privileged logon suffix such as .admin.
Confirm the UPN suffix is @ad.arphaxad.dev.
Set a strong, unique password stored in the password manager.
Leave Password never expires unselected so normal domain password policy still applies.
Complete the wizard.
Right-click the new account and select Add to a group.
Enter Domain Admins, select Check Names, and then select OK.

Do not add the everyday account to Domain Admins, Administrators, or another privileged group. Do not reuse either password or the DSRM password.

Verify the two users¶

Get-ADUser -SearchBase "OU=Lab,DC=ad,DC=arphaxad,DC=dev" `
    -Filter * -Properties Enabled,PasswordNeverExpires,MemberOf |
    Sort-Object SamAccountName |
    Select-Object Name,SamAccountName,Enabled,PasswordNeverExpires,MemberOf

The standard account should have no privileged group in MemberOf. The named administrative account should list CN=Domain Admins.

Test the named administrative account before retiring the built-in Administrator from routine use:

Sign out of ARPHAXAD\Administrator.
Sign in once with the named ARPHAXAD\<name>.admin account.
Run whoami and confirm the expected identity.
Open an administrative tool such as Active Directory Users and Computers to confirm the privileged account works.

Keep the built-in Administrator available for recovery, but use the named administrative account for subsequent lab administration.

The following results were confirmed on August 14, 2026:

the everyday account exists in Lab\Users and has no privileged membership
the named administrative account exists in Lab\Admin Accounts
the administrative account is a member of Domain Admins
both accounts are enabled and follow the domain password-expiration policy
sign-in and administrative tools work with the named administrative account

Exact account names and all credentials remain outside this public repository.

Step 3: Create role-based global security groups¶

Create these groups in Lab\Groups:

Group	Scope and type	Initial membership	Intended purpose
`GG-Lab-Users`	Global, Security	Everyday user	General role group for normal lab users
`GG-Workstation-Joiners`	Global, Security	Empty	Receives delegated rights to join workstation accounts
`GG-Workstation-Local-Admins`	Global, Security	Empty	Can later receive local admin rights on lab workstations through policy

GG means global group. Global groups are appropriate for collecting accounts from this domain by role. Security groups can receive permissions; distribution groups are intended for email lists and cannot be used in access control lists.

Create each group¶

In Active Directory Users and Computers, open Lab > Groups.
Right-click the OU and select New > Group.
Enter the exact group name.
Set Group scope to Global.
Set Group type to Security.
Select OK.
Repeat for all three groups.

Add only the intended initial member¶

Open the properties of GG-Lab-Users.
Open Members, select Add, and enter the everyday user's private account name.
Select Check Names, then OK twice.
Leave GG-Workstation-Joiners empty until the delegated join identity is created.
Leave GG-Workstation-Local-Admins empty until workstation policy is designed.

Do not add the named Domain Admin account to these groups merely for convenience. Its existing privileges would make delegation tests meaningless.

Verify the groups and memberships¶

Get-ADGroup -SearchBase "OU=Groups,OU=Lab,DC=ad,DC=arphaxad,DC=dev" `
    -Filter * -Properties GroupScope,GroupCategory |
    Sort-Object Name |
    Select-Object Name,GroupScope,GroupCategory

Get-ADGroupMember "GG-Lab-Users" |
    Select-Object Name,SamAccountName,ObjectClass

Get-ADGroupMember "GG-Workstation-Joiners"
Get-ADGroupMember "GG-Workstation-Local-Admins"

All three groups should show Global and Security. The first membership query should return only the everyday user; the last two commands should return no objects.

The three global security groups and their intended initial memberships were confirmed on August 14, 2026.

Step 4: Create and delegate the workstation-join identity¶

This task uses two objects with separate purposes:

a dedicated user account supplies credentials during a workstation join
GG-Workstation-Joiners receives the delegated permissions

Permissions are assigned to the group, not directly to the user. This makes access easier to audit and revoke by changing group membership.

Create the dedicated join account¶

Create the account in Lab\Admin Accounts using a private name that clearly describes its task. Use join.account as the public-safe example.

In Active Directory Users and Computers, open Lab > Admin Accounts.
Select New > User.
Use a descriptive full name such as Workstation Join Account.
Set the private logon name and confirm the @ad.arphaxad.dev UPN suffix.
Set a strong, unique password stored in the password manager.
Clear User must change password at next logon. A domain-join credential prompt cannot complete an interactive password change.
Leave Password never expires unselected so the domain password policy remains effective; track and rotate the credential when required.
Complete the wizard.
Add the account to GG-Workstation-Joiners.

Do not add it to Domain Admins, Administrators, Account Operators, or GG-Workstation-Local-Admins.

Delegate the workstation-join task¶

Perform this step while signed in with the named Domain Admin account:

In Active Directory Users and Computers, right-click Lab > Workstations.
Select Delegate Control.
Select Next, then Add.
Enter GG-Workstation-Joiners, select Check Names, and select OK.
Select Next.
On Tasks to Delegate, select Create a custom task to delegate, then select Next. The expected Join a computer to the domain common task was not available in this server's wizard.
Select Only the following objects in the folder.
Select Computer objects.
Select both Create selected objects in this folder and Delete selected objects in this folder, then select Next.
Under the general and property-specific permissions, select only:
- Reset Password
- Read and write Account Restrictions
- Validated write to DNS host name
- Validated write to service principal name
Select Next, review the summary, and select Finish.

These permissions allow the delegated role to create and remove workstation computer objects and set the attributes needed during a domain join or rejoin. They do not give the role full control of the OU.

The delegation is scoped to the Workstations OU and its descendant objects. It does not grant authority over users, servers, domain controllers, Group Policy, or the rest of the domain.

When the Windows client is joined later, its computer account must be created in the Workstations OU. The client join procedure will use an OU-aware method rather than silently creating the object in the built-in Computers container.

Verify identity and membership¶

Substitute the private join-account name only on the DC; do not publish it:

Get-ADGroupMember "GG-Workstation-Joiners" |
    Select-Object Name,SamAccountName,ObjectClass

Get-ADPrincipalGroupMembership "join.account" |
    Sort-Object Name |
    Select-Object Name,GroupScope,GroupCategory

Expected results:

GG-Workstation-Joiners contains only the dedicated join account
the account is a normal Domain Users member plus GG-Workstation-Joiners
no privileged built-in group appears

The domain's default machine-account quota is intentionally unchanged for this small learning lab. By default, that quota can allow an ordinary authenticated user to create a limited number of computer accounts. The custom OU delegation still demonstrates role-based administration, but this build does not claim that the delegated group is the only identity capable of joining a computer. Setting the quota to zero is a reasonable later hardening exercise if exclusive delegated enrollment needs to be tested.

Validation confirmed the dedicated join account, its membership in GG-Workstation-Joiners, and the custom delegation on Lab\Workstations on August 16, 2026.

Step 5: Exercise the user-account lifecycle¶

A temporary lifecycle.test user was created in Lab\Users to practise the basic identity operations performed when a person joins, needs credential support, is temporarily suspended, returns, or leaves an organization.

The exercise followed this sequence:

Create the enabled user with a temporary password and require a password change at the next sign-in.
Reset the password to practise credential recovery.
Disable the account and verify that its Enabled property became False.
Re-enable the account and verify that Enabled returned to True.
Delete the temporary identity and confirm that it no longer existed.

Get-ADUser lifecycle.test -Properties Enabled,PasswordLastSet |
    Select-Object Name,Enabled,PasswordLastSet

The final query correctly returned an object-not-found error after deletion. The August 16, 2026 lifecycle exercise left no additional permanent account in the directory.

Step 6: Final GUI validation¶

The phase was validated through Active Directory Users and Computers because the Proxmox console makes transferring longer PowerShell commands inconvenient. The visible checks confirmed:

the Lab OU and its six child OUs exist
the everyday, named administrative, and workstation-join identities remain in their intended OUs
the three role groups exist in Lab\Groups
the temporary lifecycle identity was deleted
workstation-join permissions were delegated to GG-Workstation-Joiners on Lab\Workstations

PowerShell remains useful for automation and reporting, but it is not required when the same learning objective can be verified clearly through the GUI.

How the pieces work together¶

The objects created in this phase serve different operational purposes:

The dedicated join account supplies credentials only when enrolling a workstation. It receives no permissions directly.
GG-Workstation-Joiners represents the workstation-join role. The OU permissions are assigned once to this group, and adding or removing a user changes who can perform that role.
The Workstations OU limits where that authority applies and provides the future scope for computer-side Group Policy.
The everyday user will sign in to the joined client with domain credentials. It does not need workstation-join or Domain Admin rights.
The named administrative account remains separate for changes that genuinely require domain administration.

Joining the client creates a computer account in the domain, not a second domain or forest. The computer account establishes the workstation's trusted relationship with ad.arphaxad.dev; users can then authenticate through the domain controller and receive policies applicable to their user and computer objects.

Group Policy will be introduced after the client joins. A Group Policy Object (GPO) stores centrally managed settings, while linking it to an OU determines which users or computers are in scope. This lab will use a small number of visible, testable policies so the relationship between AD placement, policy processing, and client behavior remains clear.

Lab scope principle¶

This lab intentionally uses one domain controller and one Windows client. It keeps only the identities and groups that demonstrate important operational patterns: ordinary user access, separate privileged administration, delegated workstation enrollment, role-based permissions, and basic lifecycle management. Temporary test identities may be created and removed to practise real administrative tasks, but unnecessary permanent accounts and enterprise-scale components are out of scope.

Why this structure is intentionally small¶

OUs should exist for a management, policy, or delegation reason rather than to imitate an organization chart. This layout is enough to demonstrate separate user and computer policy, privileged-account handling, server policy, group management, and delegated workstation joins without creating unnecessary depth.