Building an IAM Home Lab from Scratch

If you've been following along, you already know I built an Active Directory home lab a while back. Four virtual machines, a Kali Linux attacker box, Splunk ingesting logs, the whole setup. That project taught me how systems talk to each other and what it looks like when they're under attack.

This project is different. Where the AD lab was about understanding how things break, this one is about understanding how access is managed. Who gets in, who gets moved, and who gets the door closed behind them when they leave. That's the world of Identity and Access Management, or IAM.

I've been leaning toward IAM as a career direction because it sits at the intersection of security, automation, and real business impact. Every company, regardless of size or industry, has to answer the same questions: who has access to what, should they still have it, and what happens when they leave? IAM engineers are the ones building the systems that answer those questions at scale. That appeals to me.

This blog series documents how I built a home lab to simulate exactly that, and automated it with PowerShell.

What I'm Building

By the end of this series, I'll have a working lab environment that does the following:

• A Windows Server Domain Controller running in VirtualBox, with Active Directory managing on-premises users and groups
• A free Microsoft Entra ID tenant (Microsoft's cloud identity platform) connected via the Microsoft Graph API
• A set of PowerShell automation scripts that handle the full employee identity lifecycle: onboarding a new hire, updating access when someone changes roles, and cleanly offboarding someone who leaves
• A GitHub repository documenting everything, written so anyone can follow along and build it themselves

If you're not in tech, think of it this way: every time a new employee starts at a company, someone has to create their accounts, add them to the right systems, and set their permissions. When they leave, someone has to undo all of that. At small companies that's done manually. At larger ones it's automated. I'm building the automation.

The Environment: What You Need

Before writing a single line of PowerShell, you need two things set up: a local server to run Active Directory, and a cloud identity tenant to connect it to.

1. VirtualBox + Windows Server

I'm running VirtualBox on my personal computer, which is the same setup I used for the AD lab. If you followed that project, you're already familiar with the basics.

For this lab, I'm using Windows Server 2022, which you can download as a free 180-day evaluation directly from Microsoft. No license needed. It's the same full version, just time-limited, which is more than enough for a home lab project.

The Windows Server VM will be promoted to a Domain Controller, meaning it's the central authority for the entire local network. It handles authentication, stores user accounts, and enforces group policies. In a real enterprise, this is the system that decides whether your login attempt is valid when you open your laptop on Monday morning.

Minimum specs for the VM:

• 2 CPU cores
• 4 GB RAM
• 50 GB storage

If your machine is tight on resources (I've been there), you can drop to 2 GB RAM and it'll still work. It'll just be slower.

2. A Free Microsoft Entra ID Tenant

Entra ID is Microsoft's cloud-based identity platform, formerly called Azure Active Directory. It's what sits behind every Microsoft 365 login, and it's one of the most widely deployed identity platforms in enterprise environments today.

The good news: you get a free Entra ID tenant with any Azure account, and Azure has a free tier. You don't need to pay anything. Head to portal.azure.com, sign up with a personal Microsoft account, and you'll have a real Entra ID tenant to work with.

This is where the cloud side of the project lives. While Active Directory manages on-premises users, Entra ID manages cloud identities, and Microsoft Graph PowerShell lets us interact with it programmatically. That's exactly what we'll be doing in Phase 4.