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 AD-DNS Relationship

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.

Two Domain Controllers: Redundancy and Replication

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.

Organisational Unit Structure

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.

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.

Onboarding a New User

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.

Password Reset and Account Unlock

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.

Security Groups

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.

Offboarding

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..

Group Policy Management

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.

GPOs I Configured in This Lab

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. 

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.