After deploying Active Directory Domain Services (AD DS) on a Windows Server 2019 virtual machine using Hyper-V, the next logical step is to configure core Active Directory objects that reflect a real enterprise environment.
This lab focuses on Organizational Units (OUs), Groups, and Users, which form the foundation of identity, access control, and administration in Active Directory.
Prerequisite: AD DS is already installed and the server is promoted to a domain controller. Previous lab: How to Install AD DS on Windows Server using Hyper-V
Lab Objective
To simulate a real-world Active Directory environment by:
- Designing a basic OU structure
- Creating security groups
- Creating user accounts and assigning them to groups
Step-by-Step Lab Tasks
Step 1: Create Organizational Units (OUs)
Organizational Units are used to logically separate users, groups, and computers.
- OUs are created to represent departments or roles
- This structure prepares the domain for Group Policy application and delegated administration
An OU is a management and policy boundary, not a security boundary by itself. Moving an object into an OU doesn't automatically restrict access to it. Design OUs around Group Policy and delegated administration requirements rather than copying the company organization chart without a technical reason.
Open Active Directory Users and Computers (ADUC)
Right-click the domain (humbletech.cloud) → New → Organizational Unit
Name the OU (e.g., HR Dept) → Click OK
I keep Protect container from accidental deletion enabled. I use predictable names without unnecessary punctuation, and consider separate OUs for users, workstations, servers, service accounts, and administrative tiers when policy or delegation differs.
I verify that the OU appears under your domain
Step 2: Create Active Directory Groups
Security groups are created to manage authorization efficiently.
- Security groups are created within the appropriate OUs
- Groups are designed to reflect either job roles or resource access requirements
- This approach avoids assigning permissions directly to users
I use group scope deliberately:
- Global groups normally collect accounts with the same organizational role.
- Domain local groups normally represent access to a resource in the domain.
- Universal groups can span domains but add global-catalog and replication considerations.
- Distribution groups are for email distribution and can't be used in access control lists.
For one domain, AGDLP provides a maintainable pattern: Accounts → Global role group → Domain Local resource group → Permissions.
Navigate to the newly created OU
Right-click the OU → New → Group
Enter a role-based group name, for example GG-HR-Staff. Don't use an “Admins” suffix unless the members truly receive administrative privileges.
Choose Global scope and Security type for the role group. I create separate domain local groups later for specific resources, such as DL-HR-Documents-Modify.
Click OK
Step 3: Create Users and Assign Group Membership
User accounts are created and added to the relevant groups.
- Each user is placed in the correct OU
- Users receive authorization through group membership when those groups are granted permissions
- This mirrors standard enterprise identity management practices
Right-click the OU → New → User
Fill in the First Name, Last Name, and User Logon Name
Set a password and configure account settings
I use a unique temporary password delivered through an approved channel, require change at first sign-in where appropriate, and never reuse a password shown in training material. Set account expiry for temporary workers and document ownership for service accounts.
After creation, right-click the user → Properties
Go to the Member of tab → Click Add
Search for and select the role group, for example GG-HR-Staff, then select OK.
Verification:
I check the user’s group membership in Active Directory Users and Computers (ADUC)
I test user login and permission if applicable.
PowerShell provides a second, auditable way to verify the result:
Get-ADOrganizationalUnit -Filter * |
Select-Object Name, DistinguishedName
Get-ADUser -Identity '<sam-account-name>' `
-Properties Enabled, PasswordLastSet, MemberOf
Get-ADGroupMember -Identity 'GG-HR-Staff'After changing group membership, the user normally needs a new sign-in token before newly granted access is visible.
Congratulations! You have successfully created Organizational Unit, Groups, and Users.
Why OU and Group Structure Matters
A well-designed Active Directory structure enables:
- Centralized access control through groups
- Easier Group Policy management
- Secure delegation of administrative tasks
- Scalability for on-premises and hybrid environments
It should also minimize privileged group membership, separate administrative accounts from standard user accounts, and support delegated tasks without making routine operators Domain Admins. I review group ownership and membership regularly; a clean initial structure can still accumulate excessive access over time.
Microsoft recommends managing access through groups rather than individual users, especially in environments that integrate with cloud identity platforms.
Lab Outcome
At the end of this lab, the environment includes:
- A structured OU hierarchy
- Role-based security groups
- Users correctly assigned to groups
This setup provides a solid foundation for:
- Group Policy Objects (GPOs)
- Delegation of control
- Hybrid identity scenarios (on-prem AD + cloud)
Next Steps
- I use the AD PowerShell automation guide to create and verify objects repeatably.
- Apply AGDLP in the NTFS permissions and mapped drives lab.
- Link narrowly scoped policies through the Group Policy workstation lab.
- I add and validate an additional domain controller before treating the lab as resilient.