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

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.

I'm running VirtualBox on my personal computer, the same setup I used for the AD lab. For this one I'm using Windows Server 2022, which you can download as a free 180-day evaluation directly from Microsoft. No license needed. The VM gets 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.

On the cloud side, I set up 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. You get a free tenant with any Azure account, no credit card required.

Building the Identity Structure

Once the environment was up, it was time to actually build something in it.

I started with the organizational structure. In Active Directory, Organizational Units are how you separate users by department or function. Think of them like folders, but with real access implications. I created four: HR, IT, Finance, and Marketing. That maps to how most real companies are structured, and it gave me a realistic foundation to work with instead of just dumping everyone into the default Users container like a test lab with no intention behind it.

From there I created eight user accounts and distributed them across the OUs. Two per department. Each one has a name, a job title, and a department assigned. Not placeholder accounts. Actual identities that I'll be running lifecycle operations on throughout this series.

Then security groups. One per department, HR Team, IT Team, Finance Team, Marketing Team, each with their users added as members. Groups are how access gets managed at scale in real environments. You don't assign permissions to individuals, you assign them to groups and put people in the right groups. Getting that structure right from the start matters because everything built on top of it, automation, RBAC, governance, depends on it.

Same structure got mirrored in Entra ID. All eight users, all four groups, built out in the cloud tenant to match what's in Active Directory. That parallel setup is the foundation for everything that comes next, including eventually syncing the two environments together.

What's Next

The environment is up, the identity structure is built, and both Active Directory and Entra ID are ready to go. In Part 2 I'm getting into PowerShell, connecting to the Entra ID tenant via the Microsoft Graph SDK, and running my first real identity commands. See you there. :)