Learning Active Directory Through a Hands-On Security Lab

I created this Active Directory lab to help students understand how a Windows domain works from both an administrator and defender point of view. Active Directory can look confusing when you are only reading about users, groups, domain controllers, Kerberos, Group Policy, DNS, and logs. So I wanted to build a practical lab where students can see all these concepts in one place and understand how they connect.

The lab is based on a fictional company called TerraVault Financial Group. The domain is terravault.local, and the main domain controller is TV-DC01. My goal was to create an environment that feels close to what students may see in a real Windows enterprise network, but still simple enough for beginners to follow.

The first screenshot shows the Active Directory Users and Computers window. This is one of the most important parts of the lab because it shows how identity is managed inside a Windows domain.

On the left side, you can see the domain structure for terravault.local. There are containers for Domain Controllers, Servers, Workstations, Users, Service Accounts, and Groups. This teaches students that Active Directory is not just a list of usernames. It is a structured directory where users, computers, servers, and groups are organized.

The Service Accounts section is important because it shows accounts like svc-backup, svc-sql, and svc-web. These accounts have SPN labels, which means they are linked to services. In Active Directory security, service accounts are very important because they can become targets for attacks like Kerberoasting if they have weak or old passwords.

The Groups section also shows privileged groups like Domain Admins, IT-Admins, and Server-Admins. This helps students understand why group membership matters. If a user is added to Domain Admins, that user can control the whole domain. That is why defenders must monitor privileged groups carefully.

On the right side, the lab shows users such as Marcus Webb, Jordan Hayes, Rachel Kim, Omar Vasquez, Sandra Bloom, James Tanner, Patricia Cole, Robert Diaz, Brandon Lee, and Sarah Quinn. Each user has a SAM account, title, department, status, and password age. This teaches students how to read account details and spot possible security issues.

For example, Sarah Quinn’s account is locked. That could mean she typed her password wrong too many times, but it could also mean someone attempted password guessing against her account. The password age column also matters because older passwords can become a risk, especially if password policy is weak.

The second screenshot shows Event Viewer. This is where Windows records important security activity. I included this section because defenders need to know how to read logs, not just manage users.

In this screenshot, we can see events like successful logons, failed logons, Kerberos service ticket requests, special privileges, network share access, and account lockouts. These events are important because they help tell the story of what happened inside the domain.

For example, Event ID 4624 means a successful logon happened. Event ID 4625 means a failed logon happened. Event ID 4769 points to Kerberos service ticket activity. Event ID 4672 means special privileges were assigned to a logon. Event ID 5140 shows network share access. Event ID 4740 shows an account lockout.

The main lesson here is that defenders should not only look at one event by itself. A single failed login may be normal. A single successful login may also be normal. But when events appear in a suspicious pattern, they can reveal an attack or insider activity.

The third screenshot shows more important security events inside Event Viewer. This section is where students can start learning how to connect logs together.

One important event shown here is a Kerberos TGS request involving svc-backup. That can be important because service accounts with SPNs can be targeted during Kerberoasting. Another important event shows svc-backup being added to Domain Admins. That is a very serious event because Domain Admins is one of the most powerful groups in the domain.

There is also a logon event for svc-backup using RemoteInteractive/RDP. That is suspicious because service accounts are normally used by services, not by humans logging in through RDP. If a service account logs in interactively, defenders should investigate immediately.

This screenshot teaches one of the most important blue team lessons: security logs become powerful when you correlate them. A Kerberos ticket request, followed by a privileged group change, followed by a suspicious RDP logon, can tell a much bigger story than each log alone.

The fourth screenshot shows Group Policy Management. I included this because Active Directory security is not only about users and logs. It is also about enforcing rules across the domain.

The lab includes policies such as Default Domain Policy, Workstation Security Baseline, Server Security Baseline, Admin Workstation Policy, and Executive Workstation Policy. Each one teaches a different security concept.

The Default Domain Policy includes password rules like minimum password length, maximum password age, account lockout attempts, and password complexity. This teaches students that password security is usually enforced centrally in Active Directory.

The Workstation Security Baseline includes BitLocker, Windows Firewall, AppLocker, and USB device blocking. These controls help protect employee machines from malware, unauthorized programs, data theft, and lateral movement.

The Server Security Baseline includes advanced audit policy, WinRM restrictions, SMB signing, and RDP with 2FA. These settings are important because servers usually hold sensitive data and should be more protected than normal workstations.

The Admin Workstation Policy includes enhanced audit logging, Credential Guard, PowerShell Script Block Logging, and LAPS. This teaches students that administrator machines need stronger protection because attackers often target admin workstations to steal credentials.

The Executive Workstation Policy includes MFA, VPN requirements, BitLocker with PIN, and a short screen lock time. This shows that high-value users like executives may need additional protections.

The lesson from this screenshot is simple: Group Policy is how administrators enforce security across many systems without configuring every machine one by one.

The fifth screenshot shows DNS Manager for TV-DC01. DNS is very important in Active Directory, and I wanted students to understand that DNS is not just a basic networking topic.

In Active Directory, computers use DNS to find domain controllers and services. If DNS is broken, domain login, Kerberos authentication, file access, and many other domain functions can fail.

The screenshot shows records inside the terravault.local forward lookup zone. There is an SOA record, NS records, and A records for systems like TV-DC01 and TV-DC02. The A record maps a hostname to an IP address. The NS record identifies nameservers for the zone. The SOA record identifies the primary DNS server for the zone.

This section teaches students that DNS records can also reveal useful information about the environment. From a defender’s point of view, DNS should be monitored and protected. From an administrator’s point of view, DNS must be configured properly or Active Directory will not work correctly.

The sixth screenshot shows the simulated Command Prompt on TV-DC01.terravault.local. I added this command-line section because students should not only rely on graphical tools. In real environments, defenders and administrators often use commands to quickly collect information.

The help menu shows commands such as whoami, whoami /groups, whoami /priv, hostname, ipconfig /all, net user, net group "Domain Admins" /domain, net share, nltest /dclist:terravault.local, klist, tasklist, and dir.

These commands teach basic Windows and Active Directory enumeration from a defender’s perspective. For example, whoami shows the current user. whoami /groups shows group memberships. ipconfig /all shows network configuration. net user lists domain users. net group "Domain Admins" /domain helps check privileged group membership. klist shows Kerberos tickets.

The goal is not just to type commands. The goal is to understand what each command helps you verify during an investigation.

The seventh screenshot continues the command prompt section and shows both PowerShell AD commands and attack simulation options from a defender’s view.

The lab includes commands like Get-ADUser j.hayes and Get-ADGroupMember "Domain Admins". These teach students how PowerShell can be used to investigate Active Directory users and group memberships.

It also includes defender-view simulations for Kerberoasting, BloodHound, Mimikatz, DCSync, and PsExec/Pass-the-Hash. I designed this part carefully because the purpose is not to teach students how to attack real systems. The purpose is to show what defenders may see in logs, SIEM tools, and Microsoft Defender for Identity when these techniques happen.

For example, Kerberoasting helps students understand suspicious Kerberos service ticket activity. BloodHound teaches why excessive ACL and relationship enumeration may matter. Mimikatz teaches why credential dumping detections are critical. DCSync teaches why replication-style behavior from a non-domain controller is dangerous. PsExec and Pass-the-Hash teach how lateral movement can appear in Windows logs.

This part of the lab helps students connect offensive technique names with defensive evidence. That is important because a good analyst must understand both the behavior and the log trail.

Building this lab helped me understand Active Directory much better. I had to think through how a domain is structured, how users are organized, what service accounts look like, which groups are privileged, what logs defenders should monitor, what security policies matter, and which commands help investigate the environment.

The biggest lesson from building this project is that Active Directory security is not one single topic. It is a combination of identity management, authentication, authorization, DNS, logging, Group Policy, command-line investigation, and security monitoring.

This project is important for my portfolio because it shows that I am not only learning Active Directory theory. I am also building a practical learning environment that can teach other students. The lab allows beginners to click through real-looking Windows admin tools, understand what each section means, and learn how defenders investigate suspicious activity.

Overall, the Hackademy Active Directory Lab gave me a way to make AD easier to understand. Students can see users, groups, service accounts, logs, policies, DNS records, and commands in one place. That is what makes the lab useful. It does not just tell students what Active Directory is. It shows them how the pieces work together.