Most IT support roles assume you already know Active Directory. I decided to build it from scratch in my home lab and not just to say I've used it, but to actually understand what's happening under the hood when a user can't log in, a Group Policy isn't applying, or a new starter needs to be onboarded at 8am on a Monday.
This project documents the build, decisions, things that stopped working and why, and what I learned from it. It also forms the on-premises half of my broader ITOM project, where I'm integrating both AWS cloud infrastructure and on-premises Active Directory into a single ServiceNow CMDB.
The OU structure for my home lab domain (Advanced View)
Active Directory Domain Services is the identity backbone of the majority of enterprise IT environments. When someone joins a company and gets a laptop on day one, when a user gets locked out at 9am, when IT needs to push a security policy to every machine in the building, ADDS is doing the work behind the scenes.
I built this environment in my home lab to get handson with the technology that IT support and service desk professionals work with every day. Rather than just passing a certification, I wanted to build it, break it, and understand why things work the way they do.
Hyper-V Virtualisation: This lab mostly runs on Hyper-V. Both domain controllers and MID servers configured and managed from scratch, with the exception of workstation computers running on bare metal. Virtualisation is the foundation of modern enterprise infrastructure and a core skill for any IT support role working with on-premises or hybrid environments
Domain Controller setup and DNS: DNS is the Foundation of all Windows enterprise environments. if DNS breaks, everything breaks. Understanding the AD-DNS relationship is one of the most important things an IT support professional can know.
Two-DC environment with AD replication: No single point of failure mirrors how real organisations protect their identity infrastructure. One DC going down for maintenance doesn't take authentication with it.
Organisational Unit design: Logical structure that mirrors how real organisations manage users and devices. Designed before a single user account was created, because changing it later creates more work than getting it right upfront.
User lifecycle management: Onboarding, password resets, account unlocks, offboarding, which I consider the bread and butter of service desk work. Every step documented with the security reasoning behind it.
Group Policy Objects: Enforcing security and configuration consistently across all machines without touching them individually. Password policies, drive mappings, screen locks, USB restrictions, all managed from one console.
Cross-version GPO testing (Windows 10 + Windows 11): Policies verified across both OS versions using DELL-LAPTOP and HP-PAVILION. Real environments are never uniform, testing across versions is how you catch problems before users do.
Shared storage and NTFS permissions: GPO maps the drive, NTFS controls what users can actually do once they're in. Understanding both layers is what lets you diagnose access issues quickly rather than guessing.
Remote administration via RSAT: How IT teams manage AD in the real world, from their own workstation, not the server. DC1 and DC2 are never logged into directly for routine tasks.
ServiceNow CMDB integration: Connecting on-premises infrastructure to the ITSM platform for centralised configuration management. Every domain-joined device becomes a CMDB record automatically.
Home lab architecture showing two Windows Server 2022 Domain Controllers (DC1 + DC2) with AD replication, two domain-joined clients (DELL-LAPTOP running Windows 11, HP-PAVILION running Windows 10), and a dedicated MID Server connecting the environment to ServiceNow.
Before anything else, I needed a spec. In an ITIL-aligned environment, you don't build first and ask questions later by defining what you're building, why, and what success looks like. For this lab, that meant two Windows Server 2022 Domain Controllers for redundancy, two domain-joined client machines running different versions of Windows, and DNS configured correctly from the start.
Virtualisation Platform: All VMs created and managed using Microsoft Hyper-V.
Primary Domain Controller — DC1: Windows Server 2022. First DC promoted, holds all five FSMO roles, AD DS and DNS Server roles installed.
Secondary Domain Controller — DC2: Windows Server 2022. Additional DC for redundancy, replication partner to DC1. DNS also hosted here.
Domain Name: emeka.cloud — my registered public domain used as the internal AD domain.
Client Machine 1 — DELL-LAPTOP: Windows 11, domain joined, RSAT installed. Primary admin workstation for remote AD management.
Client Machine 2 — HP-PAVILION: Windows 10, domain joined. Used to verify GPO application across different OS versions.
Cross-version GPO testing (Windows 10 + Windows 11): Policies verified across both OS versions using DELL-LAPTOP and HP-PAVILION. Real environments are never uniform — testing across versions is how you catch problems before users do.
MID Server — MID-01: Separate domain-joined VM. Runs the ServiceNow discovery agent as the svc.midserver service account.
DNS: AD-integrated DNS hosted on both DC1 and DC2 for redundancy.
Remote Administration: neither DC is logged into directly for routine tasks. Rather from DELL-LAPTOP using RSAT.
Building the Lab in Hyper-V
The servers in this lab run on Hyper-V but not all on the same machine. DC1 and MID-01 share one physical host, and DC2 sits on a separate host entirely. That was a deliberate call. If one host goes down, DC2 is still up and the domain keeps working. Both DCs are allocated 4GB RAM each which gives them enough to handle authentication, DNS, Group Policy and replication without struggling.
MID-01 runs as a Windows 11 VM on the same host as DC1. It doesn't need much, its only job is running the ServiceNow discovery agent, so keeping it lean made sense.
DELL-LAPTOP and HP-PAVILION are not VMs as both run on bare metal. Real hardware, real Windows installs, joined to the domain the same way any physical workstation would be in an office. That matters because it tests the domain setup against actual machines, not just virtualised ones. If GPOs apply correctly on bare metal across two different hardware configurations and two different versions of Windows, you know the environment is solid.
The reason I split the DCs across two hosts comes down to something I picked up studying for ITIL whic is you don't design resilience into a system after the fact, you build it in from the start. Putting both Domain Controllers on the same physical machine would mean a hardware fault or a reboot takes authentication down for everyone. Separating them means maintenance on one host is invisible to users. That thinking is what service continuity management is actually about in practice, not just in an exam.
Hyper-V Manager across two separate physical hosts: DC1 and MID-01 on Host 1, DC2 on Host 2. DCs deliberately separated so a single host going down doesn't take domain authentication with it
Hyper-V Virtual Switch connecting all VMs on an internal network. The virtual equivalent of a physical network switch. Configured before the first Domain Controller was promoted to ensure all machines could communicate and DNS could resolve correctly from the start.
One thing that became clear very quickly was tghebrelationship between Active Directory and DNS. They are one thing. Every time a client joins the domain, it registers a DNS record. Every time a domain controller replicates, it uses DNS to find its replication partner. When DNS broke in my lab, authentication broke. That experience taught me more about the AD-DNS relationship than any course ever could.
I used my registered public domain emeka.cloud, rather tham emeka.local to mitigate the future risk of DNS namespace collision when I decide to extend the lab to the internet or connect it to Azure AD. It also mirrors what larger organisations increasingly do which is using a subdomain of their real domain internally rather than a .local suffix that can cause certificate and split-DNS headaches down the line.
The trade-off is a management overhead, internal DNS must resolve emeka.cloud to the Domain Controller, while external DNS continues to serve the public-facing website at emeka.cloud. This is split-DNS, and configuring it correctly was one of the more interesting challenges in this build.
Windows Server 2022 promoted to Domain Controller for the emeka.cloud domain. The AD DS role and DNS Server role were installed together. AD requires DNS to function and I configured it as AD-integrated from the start.
Running a single Domain Controller is fine for a basic lab. But in a real environment, a single DC is a single point of failure, if it goes down, nobody can log in. I promoted a second Windows Server 2022 instance as an additional DC, which means the domain now has two copies of Active Directory replicating with each other.
AD replication means any change made on DC1 i.e. a new user, a password reset, a group membership change; gets replicated to DC2 automatically. From a service continuity perspective this is the difference between a resilient directory service and one that takes the whole business offline if a server needs a reboot. ITIL's service continuity management principle underpins exactly this kind of design decision.
DC1 holds the FSMO roles which are the five Flexible Single Master Operations roles that govern specific AD operations like password changes, domain naming and schema updates. DC2 is the replication partner. If DC1 ever needs to come down for maintenance, DC2 continues serving authentication requests without any interruption to users.
AD replication summary showing DC1 and DC2 successfully replicating. Any change to the directory i.e new user, password reset, group membership update; propagates to the second Domain Controller automatically. Also, it shows FSMO roles held by DC1, these five roles govern critical AD operations.
AD-integrated DNS showing the emeka.cloud Forward Lookup Zone with both Domain Controllers registered. Every machine that joins the domain registers its A record here automatically, and clients can reach either DC for authentication if one becomes unavailable.
Organisational Units are the logical containers of Active Directory. They determine how Group Policy gets applied, how administrative responsibilities can be delegated, and how easy, or painful day-to-day management is. A poorly designed OU structure means IT teams end up applying policies to things they shouldn't, or manually managing exceptions they wouldn't have needed if the structure was right from the start.
I designed my OU structure before creating a single user account because changing it later means re-linking Group Policy objects and moving objects around, which creates more work than getting it right upfront.
The OU design for emeka.cloud. Departments separated for targeted Group Policy application, a dedicated Computers OU for device management, and a Disabled Accounts OU for clean offboarding
The Disabled Accounts OU is worth calling out specifically. In a well-run IT environment, you never delete a user account immediately when someone leaves, you disable it and move it to a holding OU. This preserves audit trails, gives you a recovery path if access needs to be reinstated, and supports the organisation's data retention obligations.
What the Job Ads Keep Asking For
If there is one thing I know from everything I've read and learned about IT support, it's that the majority of service desk tickets are about user accounts. New starters. Password resets. Account lockouts. Someone leaving the business. These are tasks are not particularly glamourous, but they are the tasks that keep an organisation running, and they are the tasks that go wrong if the process isn't followed correctly.
When a new employee joins, their account needs to be created in the right OU, assigned to the correct security groups, and set with a temporary password that forces a change on first logon. In larger organisations this is automated through HR system integrations or scripted with PowerShell, but understanding the manual process is what makes the automation make sense.
User account properties showing the General tab
Account lockouts happen. A user types their password wrong three times (depending on Group Policies) before their morning coffee and suddenly IT gets a ticket. The process is straightforward, but it needs to be done correctly. Resetting a password without ticking 'User must change password at next logon' means IT now knows the user's password, which is a security risk and in regulated environments, a compliance issue.
Resetting the password.
Unlocking a locked account. The 'User must change password at next logon' flag is non-negotiable, it keeps the reset auditable and ensures IT never holds a user's live credentials.
Permissions should never be assigned directly to individual users. Assign permissions to groups, assign users to groups. It sounds simple but it's the difference between an environment that's manageable and one that turns into a permissions nightmare the moment someone changes role or leaves. This is a principle ITIL reinforces through access management which are Role based access contorl, Proper documentation and an Auditable trail.
HR-Staff security group showing permissions assigned to the group, users assigned to the group. When someone joins HR they get added here and immediately inherit all required access. When they leave, removing them from the group revokes everything in one action.
Offboarding done badly is a security risk. An account left active after someone leaves is an open door. The correct process is to disable the account, remove group memberships, and move it to the Disabled Accounts OU. Not delete, but disable. Deletion coukd be irreversible and problematic if data recovery is needed or if the person returns..
Offboarded user account disabled and moved to the Disabled Accounts OU. Account will be retained for 90 days in line with the lab's data retention policy before permanent deletion, preserving the audit trail and allowing recovery if needed.
Group Policy is one of those things that felt complicated until it clicked for me. Once it clicked, I realised how much of what IT does at scale is just Group Policy. Password complexity. Screen lock timeouts. Mapped drives. Blocking USB storage in the finance department. All of it configured once, linked to the right OU, and applied automatically to every machine in scope, without anyone physically touching a single device.
One thing I had to get my head around was GPO inheritance and precedence. Policies are applied in a specific order: Local, Site, Domain, OU — and a policy linked at the OU level can override one set at the domain level. Understanding that order is essential when troubleshooting why a policy isn't applying the way you expected.
Each policy is linked to a specific OU rather than the domain root, so it only applies to the machines and users it's intended for. One thing I discovered during this process is that the default Computers container in Active Directory is not an OU , but a container, and you cannot link Group Policy Objects to it directly. This caught me off guard at first. The fix was straightforward once I understood the difference so I created a dedicated Workstations OU directly under emeka.cloud and moved DELL-LAPTOP and HP-PAVILION into it. From there I could link GPOs to it exactly as intended. It's a small but important distinction that I wouldn't have appreciated without actually trying to do it.
Password Policy: Domain level: Configured directly in the Default Domain Policy is the built-in GPO that applies to every account in the domain without exception. Found under Computer Configuration → Policies → Windows Settings → Security Settings → Account Policies → Password Policy. Minimum 12 characters, complexity required, 90-day expiry. I learned during this process that password policy can only be enforced at the domain level in Active Directory, linking it to an OU won't work for domain accounts. The Default Domain Policy is the right and only place for it.
Output of net accounts run on DC1 confirming the domain password policy is live
Screen Lock, Screensaver and Desktop Wallpaper: Workstations OU and Departments OU: Both policies are configured in a single GPO called Workstation-Policy, but I learned during this process that Computer Configuration and User Configuration settings target different objects in AD, so the GPO ended up getting linked in two places.
The screen lock and screensaver settings live under Computer Configuration and follow the computer account, so the GPO is linked to the Workstations OU where DELL-LAPTOP and HP-PAVILION sit. Two settings work together here to get consistent behaviour:
Machine inactivity lock: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Interactive logon: Machine inactivity limit → 600 seconds
Screensaver timeout: User Configuration → Policies → Administrative Templates → Control Panel → Personalisation → Screen saver timeout → 600 seconds, Password protect the screen saver → Enabled, Screen saver executable → scrnsave.scr
I discovered that machine inactivity lock and screensaver timeout are two completely separate settings. Having only one configured meant the screensaver was locking the screen after 2 minutes from local settings, overriding the GPO. Configuring both centrally via GPO resolved it.
The wallpaper setting lives under User Configuration and follows the user account, so the same GPO is also linked to the Departments OU where the user accounts sit. The wallpaper image is stored in SYSVOL so every domain-joined machine can reach it:
Desktop Wallpaper path: User Configuration → Policies → Administrative Templates → Desktop → Desktop → Desktop Wallpaper → \emeka.cloud\SYSVOL\emeka.cloud\Wallpaper\pic.jpg
Keeping everything in one GPO linked to two OUs keeps the environment tidy, one place to manage, two targets.
Group Policy Management Console showing Workstations
Running gpupdate /force on DELL-LAPTOP to immediately apply pending Group Policy changes without waiting for the standard 90-minute background refresh. Computer Policy and User Policy both updated successfully.
Output of gpresult /r on DELL-LAPTOP confirming which GPOs have been applied and from which level