Centralized Control: An Introduction and Hands-On Guide to Active Directory

Why is Active Directory a "Must-Know" Skill?

In simple terms, Active Directory is a database and a set of services that connect users with the network resources they need to get their work done. Think of it as the "brain" or the "digital phonebook" of an organization. It contains information about every user, computer, and group in the company, and it dictates exactly what each entity is allowed to do.

For those of us transitioning into IT, AD is often the first thing you'll be asked to touch. Here is why it’s so important:

• Centralized Management: Instead of managing 500 computers individually, an admin can manage them all from one place.

• Security & Compliance: AD allows us to enforce "Group Policies"—rules like "passwords must be 15 characters long" or "USB drives are blocked on all workstations."

• Identity is the New Perimeter: In modern cybersecurity, knowing exactly who is on your network is the first line of defense.

• Cloud Integration: Most companies use a hybrid model, syncing their on-premise AD with Entra ID.

I recently completed a lab where I built an AD environment from scratch in the cloud. Here is exactly how I did it and what I learned along the way.

The Lab: Building a Domain in Azure

The goal of this project was to move beyond theory and actually deploy a functional Windows Domain Controller, manage users, and successfully join a client workstation to the domain.

Phase 1: Setting the Foundation in Azure

I started by deploying a Windows Server 2022 VM in Azure. Since this was a lab, I focused on minimal cost while ensuring the infrastructure was stable.

Crucial Step: I assigned a Static IP to this VM. In a network, the Domain Controller (DC) acts as the DNS server. If the DC’s IP address changes, the entire network "breaks" because the computers won't know where to look for authentication.

Phase 2: Installing AD DS & Promotion

Once the server was live, I used Remote Desktop Protocol (RDP) to log in. Using the Server Manager, I added the Active Directory Domain Services (AD DS) role.

Installing the role is just the first step; you then have to "Promote" the server to a Domain Controller. Since I was starting fresh, I created a New Forest and set up my root domain name.

Phase 3: Designing the Structure (OUs and Groups)

With the domain live, I opened Active Directory Users and Computers (ADUC). I didn't want a messy "flat" network, so I designed a logical Organizational Unit (OU) structure. OUs are like folders that help you organize your users and computers by department or location.

I followed the security best practice of assigning permissions to Groups, not individuals. If a new person joins the Accounting department, I just add them to the "Accounting Group" instead of manually setting 20 different permissions for them.

Phase 4: Joining the Client to the Domain

This is where the "real world" simulation happens. I created a second VM (a Windows Client) on the same Virtual Network.

Before the client could join the domain, I had to tell it exactly where the Domain Controller was. I went into the network settings and pointed the Preferred DNS Server to the static IP of my DC. Once that was done, I joined the domain, entered my admin credentials, and received the "Welcome to the Domain" message!

Phase 5: Testing & Troubleshooting

To verify everything was working, I tried to log in as one of the users I created earlier (Wemby).

The Stumble: I actually hit my first real-world error here! My domain user didn't have permission to log on via RDP.

The Fix: I had to log back in as an admin and explicitly grant "Domain Users" the right to log on remotely in the system settings.

Once fixed, I logged in successfully. I ran a quick command prompt check to verify my security token and group memberships.

Final Thoughts

This lab was a fun first step and a massive confidence booster in understanding the real-world impact of IT. It touched on identity, authentication, DNS, and even a bit of cloud networking. Seeing a user account I created on one server successfully log into a completely different computer—and carry its permissions with it—really makes IT feel tangible.

Building a lab like this is the best way to learn. It forces you to troubleshoot and understand the why behind the configurations.

What’s next? I've used PowerShell to automate an "enterprise" environment to practice Active Directory in a professional environment. Feel free to check out that post here!