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.

One decision that's easy to get wrong is how the Domain Controllers themselves point to DNS. DC1 is configured with a static IP of 192.168.10.225 and its preferred DNS server points to DC2 at 192.168.10.119, with DC1's own IP as the alternate. This is deliberate and follows Microsoft's best practice where a Domain Controller should not point to itself as the primary DNS server. If DC1 pointed to itself first and the DNS service had a problem starting up, it could fail to locate other domain controllers or replicate correctly before DNS was fully available. Pointing to DC2 first means DC1 always has a healthy external DNS reference for domain operations, with its own DNS as a fallback. 

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.

Shared Storage and NTFS Permissions

Before I built this I thought drive mapping and file permissions were the same thing. They are not, and understanding the difference is what lets you actually diagnose an access issue rather than just restarting things and hoping. 

The GPO maps the drive, telling DELL-LAPTOP to connect H: to \\DC1\emeka.cloud\HR when the user logs in. It has no idea whether the user can do anything once they get there. I found this out when the drive appeared, I clicked it, and got Access Denied. The mapping was working fine. The permissions were the problem. 

NTFS permissions are what actually control access. I created a folder per department under C:\Shares on DC1, shared each one over the network, then set permissions on the Security tab. Permissions go on groups, not individual users. HR-Staff gets Modify on the HR folder, Finance-Team gets Modify on the Finance folder. Nobody gets Full Control because that would let users change the folder permissions themselves. 

The H: drive only appears for users in the correct security group thanks to item-level targeting in the GPO. Add someone to HR-Staff and they get access. Remove them and it is gone. No manual changes on any machine.

Remote administration via RSAT

One thing I was deliberate about throughout this project was never logging into DC1 or DC2 for routine AD tasks. In a real environment the Domain Controller is critical infrastructure and direct logons to it should be the exception, not the habit. RSAT (Remote Server Administration Tools), lets delegated users manage Active Directory, Group Policy and DNS from any domain joined workstation as if you were sitting at the server.

The screenshot above shows Active Directory Users and Computers running on DELL-LAPTOP, a standard Windows 11 workstation, with the full domain structure visible and manageable from there. DC1 and DC2 were not touched. 

But remote access alone is not enough. In a real helpdesk environment nobody hands out Domain Admin credentials to every IT support analyst. Instead, specific permissions are delegated to the right people for the right tasks in the right places. That is what least privilege actually looks like in practice.

I used the Delegation of Control Wizard in ADUC to delegate administrative permissions to the IT-Staff security group rather than to an individual user. This means any member of IT-Staff automatically gets those permissions the moment they are added to the group. No manual permission assignments per person, no permissions that survive someone leaving the team.

The delegation is scoped to the wider domain ensuring IT-Staff can create and manage user accounts, reset passwords, read user information and modify group membership within the scope. However, this scoping approach can more granular into a specific OU level.

What I Took Away From This 

DNS is everything I did not fully appreciate this until authentication broke completely because of a DNS misconfiguration. Fix DNS first. Always.

Containers and OUs are not the same thing No course told me this. I found out when I tried to link a GPO to the Computers container and nothing happened. You only learn this by actually building it.

Computer Configuration and User Configuration go to different places Computer Configuration follows the computer. User Configuration follows the user. I wasted time troubleshooting a wallpaper policy before I understood this.

Two settings that look the same are not always the same Machine inactivity lock and screensaver timeout look like one thing. They are two completely separate settings. Active Directory is full of these and certifications do not warn you.

Local settings win silently My screensaver was ignoring the GPO because a local setting was overriding it. No error. No warning. Just not working. Centralise everything through GPO from the start.

The GPO is just a signpost I spent time debugging a drive mapping GPO before realising the shared folder did not exist yet. The GPO cannot map a drive to nothing.

Delegate to groups not people When someone leaves a group their access goes with them. No cleanup needed. This is how access management should always work.

Resilience has to be designed in from the start I put DC1 and DC2 on separate Hyper-V hosts on purpose. One host going down should never take the whole domain with it. That decision costs nothing extra but matters enormously when something goes wrong.

What Comes Next  

This project focused purely on building and managing an on premises Active Directory environment. Two things I plan to take on next will extend what I have built here significantly.

The first is installing a MID Server and integrating this ADDS environment with ServiceNow. Every domain joined machine and user account will become a Configuration Item in the ServiceNow CMDB automatically. That project will be documented separately on this site.

The second is connecting this Active Directory environment to Azure AD, now known as Entra ID, using Azure AD Connect. This extends the on premises identity infrastructure into the cloud, giving users a single identity that works both on premises and in Microsoft 365. Hybrid identity management is how the majority of real organisations operate today and building it in my home lab is the next logical step.

Both projects will be documented here on emeka.cloud when complete.