Active Directory Security Lab

Overview

This project documents the deployment, configuration, and security hardening of a Microsoft Active Directory environment within my cybersecurity homelab.

The goal of the project was to build a realistic Windows domain environment and gain hands-on experience with Active Directory Domain Services, DNS, Organizational Units, security groups, Group Policy, access control, shared resources, and policy validation.

I deployed a Windows Server 2022 Domain Controller for the homelab.local domain and joined a Windows 10 workstation to the environment. From there, I created a structured Active Directory hierarchy representing multiple business departments, implemented role-based security groups, configured Group Policy Objects (GPOs), deployed department-specific network drives, and validated that users received the appropriate policies and permissions.

A major focus of the project was not simply configuring Active Directory, but testing and validating the controls from the domain-joined endpoint.

Objectives

The primary objectives of this project were to:

• Deploy Active Directory Domain Services.
• Configure the homelab.local domain.
• Join a Windows workstation to the domain.
• Configure DNS correctly for domain authentication.
• Design a structured Organizational Unit hierarchy.
• Create departmental user accounts.
• Implement role-based security groups.
• Configure administrative privileges.
• Create and deploy Group Policy Objects.
• Implement password and account lockout policies.
• Configure Windows workstation policies.
• Enable Remote Desktop through Group Policy.
• Deploy department-specific mapped drives.
• Implement access controls on shared folders.
• Validate GPO application using gpresult.
• Test authorized and unauthorized resource access.

Lab Environment

System	Role
Windows Server 2022	Domain Controller / DNS Server
Windows 10	Domain-Joined Workstation
Proxmox VE	Virtualization Platform
homelab.local	Active Directory Domain
coolserver.homelab.local	Domain Controller

The Windows Server 2022 and Windows 10 systems are virtual machines hosted within my Proxmox cybersecurity homelab.

Active Directory Deployment

I installed Active Directory Domain Services on Windows Server 2022 and promoted the server to a Domain Controller for:

homelab.local

The Windows 10 workstation initially failed to join the domain.

Troubleshooting revealed that the workstation was not using the Domain Controller as its primary DNS server. After configuring the Windows 10 system to use the Domain Controller for DNS resolution, the system successfully joined homelab.local.

This reinforced the importance of DNS within an Active Directory environment, since domain members rely on DNS to locate domain services and Domain Controllers.

Organizational Unit Design

I created a custom homelab OU to organize the primary Active Directory objects used throughout the lab.

For this project, the main OUs used were:

• Computers — Contains the domain-joined Windows workstation.
• Groups — Organizes security groups by administrative, departmental, computer management, and remote access roles.
• Users — Contains the domain user accounts created for the simulated organization.

OU Structure

homelab.local
│
└── homelab
    │
    ├── Computers
    │
    ├── Groups
    │   │
    │   ├── Administrative
    │   ├── Computer Management
    │   ├── Departments
    │   ├── Remote Access
    │   └── Service Accounts
    │
    └── Users

The security-group structure further separates permissions according to their purpose.

Examples include:

• IT_Admins
• HelpDesk
• Server_Admins
• Workstation_Admins
• Domain_Servers
• Domain_Workstation
• Remote_Users
• VPN_Users
• Finance
• HR
• Marketing
• Sales

This structure provided a manageable way to organize users, computers, security groups, permissions, and Group Policy targeting within the lab.

User and Department Configuration

I created eleven domain users representing multiple departments and administrative roles.

User	Username	Department / Role
Vision	vvision	Marketing
Plox	mplox	Finance
Victory	vvictory	HR
Lonely	llonely	Sales
Murda	fmurda	Helpdesk
Barney	bbarney	Helpdesk
Dent	jdent	Marketing
Stories	jstories	Sales
Wisconsin	mwisconsin	Finance
FrenchToast	FrenchToast	HR
Yung	fyung	IT Administrator

Users were assigned to security groups corresponding to their roles and departments.

Security Groups and Role-Based Access

Security groups were created to separate administrative privileges, departmental access, computer management, and remote access.

Rather than assigning permissions individually to every user, permissions were assigned through security groups and users were placed into the appropriate groups.

For example:

Yung
  ↓
IT_Admins
  ↓
Administrative privileges

Department users were similarly assigned to their respective Finance, HR, Marketing, and Sales security groups.

The IT_Admins security group was also granted administrative privileges, allowing administrative access to be controlled through group membership instead of individually assigning permissions to accounts.

This provided hands-on experience with role-based access control and the principle of least privilege.

Group Policy Configuration

Several Group Policy Objects were created to centrally manage and secure the domain environment.

Configured GPOs included:

• Allow Remote Desktop
• Workstation Policy
• Default Password Policy
• Department Drive Maps

The workstation-related policies were linked to the appropriate computer OU, while user-specific policies such as department drive mapping were applied to the Users OU.

This demonstrates centralized management of Windows systems through Active Directory rather than configuring each workstation individually.

Password and Account Lockout Policy

I configured a domain password and account lockout policy to establish baseline authentication security requirements.

The policy included:

Policy	Configuration
Password history	10 passwords remembered
Maximum password age	0 days
Minimum password age	1 day
Minimum password length	8 characters
Password complexity	Enabled
Reversible encryption	Disabled
Account lockout threshold	5 invalid logon attempts
Account lockout duration	30 minutes
Reset lockout counter	30 minutes

These controls provide centralized authentication requirements and introduce protections against weak passwords, password reuse, and repeated password-guessing attempts within the lab environment.

Department Drive Mapping

I created shared folders for individual departments, including:

• Finance
• HR
• Marketing
• IT

A Department Drive Maps GPO was then created to automatically map the appropriate network drive based on the user's department.

I used Item-Level Targeting so that drive mappings would only apply to users belonging to the corresponding Active Directory security group.

For example, a Finance user receives access to the Finance network drive after signing into the domain.

Successful Finance Drive Mapping

Testing confirmed that the Finance drive was automatically mapped and that the authenticated user could create and access files within the authorized share.

Shared Folder Access Control

Drive mapping alone does not provide resource security, so permissions were also configured on the underlying departmental shares.

Users belonging to the appropriate department security group were permitted to access their department's resources.

I then tested access to a share belonging to another department.

Unauthorized Access Test

The Finance user was denied access to the Marketing share.

This validated that the environment was not merely hiding unauthorized resources. The underlying access controls were actively preventing access.

Group Policy Validation

After configuring the Group Policy environment, I verified policy application from the domain-joined Windows 10 workstation rather than assuming the policies had applied successfully.

I generated Resultant Set of Policy information using:

gpresult

The results confirmed that the workstation received the expected computer policies, including:

• Allow Remote Desktop
• Workstation Policy
• Default Domain Policy
• Default Password Policy

The user configuration also confirmed that:

• Department Drive Maps was successfully applied.
• Group Policy was processed from coolserver.homelab.local.
• The workstation was recognized as a domain computer.
• The authenticated IT administrator was recognized as a member of the IT_Admins security group.

This provided endpoint-side verification that the policies configured on the Domain Controller were actually reaching their intended computer and user targets.

Security Validation

The project included several validation steps rather than relying solely on successful configuration.

Testing confirmed that:

• The Windows 10 workstation successfully joined homelab.local.
• Domain users could authenticate from the workstation.
• Computer GPOs were successfully applied.
• User GPOs were successfully applied.
• Department drives mapped according to group membership.
• Authorized users could access their department shares.
• Unauthorized users were denied access to other department shares.
• Password and account lockout requirements were centrally configured.
• Administrative privileges could be controlled through security-group membership.

This validation process was one of the most important parts of the project because it demonstrated that the configured security controls produced the intended behavior.

Troubleshooting

One of the first issues encountered occurred while joining the Windows 10 workstation to the Active Directory domain.

The workstation initially failed to locate and join homelab.local.

I identified DNS configuration as the issue and changed the workstation's primary DNS server to the Windows Server 2022 Domain Controller.

After correcting DNS, the workstation successfully discovered the domain and joined it.

This provided practical troubleshooting experience with the relationship between:

Client
   ↓
DNS
   ↓
Domain Controller
   ↓
Active Directory

I also used gpresult during Group Policy testing to verify whether policies were actually being delivered to the intended computer and user objects.

Skills Demonstrated

This project provided hands-on experience with:

• Active Directory Domain Services
• Windows Server 2022
• DNS configuration and troubleshooting
• Domain administration
• Organizational Units
• User and computer management
• Active Directory security groups
• Role-Based Access Control
• Group Policy Management
• Group Policy Preferences
• Item-Level Targeting
• Password security policies
• Account lockout policies
• Windows Firewall configuration through GPO
• Remote Desktop configuration
• SMB/network shares
• NTFS and share permissions
• Network drive deployment
• Access-control testing
• gpresult
• Policy validation
• Windows domain troubleshooting

Security Concepts Demonstrated

Beyond Windows administration, this project demonstrates several broader cybersecurity concepts.

Least Privilege: Users were assigned access according to their job function rather than receiving unnecessary permissions.

Role-Based Access Control: Security groups were used to manage privileges and resource access based on roles and departments.

Centralized Security Management: Group Policy provided centralized configuration and enforcement of security settings.

Authentication Security: Password complexity and account lockout controls were implemented at the domain level.

Access Control: Department shares were protected so users could access authorized resources while unauthorized access attempts were denied.

Security Validation: Controls were tested from the client endpoint to verify that the intended policies and permissions were actually enforced.

Future Improvements

Future improvements to the Active Directory lab could include:

• Implementing Windows LAPS.
• Creating additional administrative tiers.
• Separating standard and privileged administrator accounts.
• Deploying additional domain-joined workstations.
• Implementing more advanced GPO hardening.
• Applying Microsoft security baselines.
• Expanding PowerShell-based Active Directory administration.
• Forwarding additional Active Directory security events into Wazuh.
• Simulating authentication attacks and analyzing the resulting logs.
• Testing account lockout and password attack detections.
• Integrating the Active Directory environment with segmented VLANs in the pfSense lab.

These improvements would allow the environment to evolve from an Active Directory administration lab into a more complete enterprise security monitoring and detection environment.

Key Takeaways

This project gave me practical experience designing and administering a Windows domain rather than working only with isolated Windows systems.

The biggest takeaway was understanding how Active Directory, DNS, security groups, Group Policy, and file permissions work together to provide centralized identity and access management.

It also reinforced the importance of validation. Creating a GPO or assigning a security group does not automatically prove that a security control works. Testing the resulting behavior from the endpoint provided evidence that policies and access restrictions were being enforced as intended.

The lab now provides a foundation for future identity security, endpoint security, attack simulation, and detection engineering projects.