Active Directory

What is Active Directory? Active Directory is a service developed by Microsoft that helps manage and organize computers, users, and other resources on a network. Think of it like a digital phonebook + control center that stores info about everything in a Windows domain (like usernames, passwords, computers, printers, etc.).

How does it work? AD uses something called a domain, which is basically a group of users and devices under one roof. The main controller of the domain is the Domain Controller (DC) it’s the brain that verifies users when they log in and gives out permissions like “yeah, you can access this file” or “nah, you’re blocked.”

Why is it important? In big organizations, you can’t manually manage thousands of users or computers. Active Directory automates this. Admins can set rules (called Group Policies) that apply to entire groups of users. So you could, for example, block access to USB drives for all interns with just a few clicks.

What’s stored in it? Everything in AD is an object users, computers, printers, groups all are objects. Each object has attributes like names, emails, passwords, etc. These are organized in a hierarchy like folders inside folders, called the Directory Information Tree.

Security side of it AD also handles authentication (proving you are who you say you are) and authorization (deciding what you’re allowed to do). It uses protocols like Kerberos and LDAP to do that. Hackers love targeting AD because if you pop the Domain Controller, you basically own the whole network.

🧑‍💻 Users

In Active Directory, users are basically individual accounts that represent people or services. If you’re an employee at a company, you’d have a user account to log into the network, access your email, shared drives, printers, etc.

Now here’s the catch users aren’t just for humans. Some services like a web server (IIS) or a database (MSSQL) also need user accounts to run. These are special “service users” that only have permissions to do one specific job, like serving web pages or handling database queries. They aren’t logging in like us, they’re just quietly doing their thing in the background.

Also, users are called security principals that means they can be authenticated (checked if they’re legit) and authorized (given permissions) by the domain.

💻 Machines

Yup, even computers get their own accounts in AD. When a PC or server joins the domain, AD creates a machine account for it. These machine accounts are also security principals, just like user accounts, and they have their own passwords (that are like 100+ characters and auto-change over time).

Machine accounts usually aren’t touched by humans. They’re used internally by the OS so the domain can trust and communicate with that computer securely. But if someone gets that machine’s password (rare, but doable), they can technically use it to log in and do recon or escalate privileges.

Also, machine accounts usually have names like COMPUTERNAME$. That dollar sign at the end makes it clear it’s a machine, not a human.

👥 Security Groups

Security groups are just a way to organize users (and machines) so you don’t have to assign permissions one by one. Instead of saying “give Bob, Alice, and John access to this folder,” you just toss them in a group and give the group access. Easy peasy.

Groups can also be nested meaning you can have groups inside other groups, like a Russian doll of permissions.

Some groups are made automatically when a domain is created, and each has a specific role. Here are some popular ones:

Security groups make admin life way easier and help keep access control clean and organized.

Let’s log into the Domain Controller that’s basically the main server running Active Directory. Once you’re in, you’ll see a window that shows the whole structure of the domain: users, computers, and groups all organized in a tree view. It’s kinda like looking at folders on your computer, but for network objects.

These objects are grouped into Organizational Units, or OUs. Think of OUs like labeled folders they help you organize stuff, like putting all IT users in one OU, all HR people in another, etc. But it’s not just for looks you can also apply different rules or policies (like password rules or access restrictions) to each OU.

Now let’s create a new OU called Hospital this could be for organizing all the machines and users working in a hospital department. That way, we can manage them separately and apply hospital-specific rules when needed.

So once you’re in the Active Directory Users and Computers window, look for your domain name in my case, it’s homelab.local.

Now do this:

• Right-click on homelab.local

• Hover over ”New”

• Click on ”Organizational Unit”

• For the name, type Hospital

• Then hit OK

Boom, now you’ve got an OU named Hospital set up. You can start dropping users, computers, or even other OUs into it. That’s how you keep your domain nice and organized, especially when you’re managing different departments or teams.

I decided to create sub-OUs (mini folders inside the Hospital OU).

Now let’s create some users for the IT OU.

We’ll start with:

• First Name: Sarah

• Last Name: Patel

• Username: s.patel

To create the user:

1.  Right-click on the IT OU

2.  Select New > User

3.  Fill in the user details (first name, last name, and username)

4.  Set a temporary password

5.  Check the box “User must change password at next logon”

6.  Click Next, then Finish

Done.

🏷️ What is Delegation in AD?

Delegation in Active Directory is basically letting someone else do admin stuff without giving them full-blown god-mode access.

Think of it like this: You’re the sysadmin, and you don’t want to be bothered every time someone needs a password reset or a new user added. So you delegate those tasks to another user or group like your IT helpdesk team but only those specific permissions, not full admin rights.

🧑‍⚕️ Let’s give Sarah permission to reset passwords for doctors Alright, so Sarah’s in IT, and we want her to help out when doctors forget their passwords (which happens a lot, let’s be real).

Instead of giving her full admin rights, we’ll delegate control to her so she can only reset passwords for users in the Doctors OU.

1) Right-click on the Doctors OU → choose “Delegate Control…“

2) The Delegation of Control Wizard will pop up. Click Next.

3) To avoid mistyping the user’s name, write “phillip” and click the Check Names button. Windows will autocomplete the user for you.

4) Select “Reset user passwords and force password change at next logon” This gives her the ability to help if any doctor forgets their login.

5) Click Next, then Finish

Now let’s log in as user s.patel and test their privileges.

Now we’re gonna use PowerShell to handle this:

🩺 Scenario:

Let’s say we have a user in the Doctors OU named Doctor John, with the username d.joe. He forgot his password and reached out to IT for help.

Since we already delegated password reset permissions on the Doctors OU to Sarah (who’s part of the IT team in the IT OU), she can now reset John’s password without needing full domain admin rights.

From Sarah’s account, we can run this PowerShell command to reset d.joe’s password:

powershell

PS C:\Users\tobiasare> Set-ADAccountPassword d.joe -Reset -NewPassword (Read-Host -AsSecureString -Prompt 'New Password') -Verbose

Now that we’ve reset his password, we don’t want John to keep using the one we just set (since Sarah knows it). So we’ll force him to change it at next login with this command:

PS C:\Users\tobiasare> Set-ADUser -ChangePasswordAtLogon $true -Identity d.joe -Verbose

🔐 Final Step:

John can now log in with the new temporary password. As soon as he logs in, Windows will prompt him to set a new one something only he knows.

🖥️ 1. Workstations

These are the desktops or laptops your users log into every day. They’re your frontline devices the ones people use to write papers, check emails, Slack off (we know), or get actual work done.

🔐 Pro tip: Never (like, ever) log in to these with privileged or admin accounts. If one gets compromised (phishing, malware, you name it), and it’s tied to a high-privilege account? Boom. That’s how entire networks get pwned.

👉 Think of it like this: Workstations are the student laptops in a university lab. They’re everywhere, and everyone touches them. Keep them locked down.

🗄️ 2. Servers

These bad boys are the backbone of your network. They’re not for browsing Reddit or playing Valorant they exist to serve (literally). Whether it’s hosting websites, databases, or internal apps, they handle the heavy lifting.

🔁 They usually interact with other servers or respond to users, but they shouldn’t be used like workstations. Treat ‘em like dedicated, no-nonsense machines that stay clean and focused.

👉 Example: A web server hosting your school’s blog site or a file server storing your class materials.

🧠 3. Domain Controllers (DCs)

Okay, now we’re at the top-tier, god-mode devices in AD: Domain Controllers. These are the ones running the show managing users, devices, logins, policies, and more.

⚠️ These are super sensitive. Why? Because they store hashed passwords for everyone in the domain. If an attacker gains access to a DC, it’s basically game over.

💡 Best practice: Lock these down harder than your finals study notes. Limited access, serious logging, no unnecessary software. Only admins should touch these and only for legit reasons.

🛡️ Group Policies 101: Why OUs Actually Matter

So, you’ve split your users and computers into Organizational Units (OUs) cool. But if you’re thinking “this is just for show,” nah. There’s real power behind that setup.

The real reason we organize things into OUs is to unlock custom control with something called Group Policy Objects (GPOs).

🎛️ What’s a GPO?

GPO = Group Policy Object It’s basically a bundle of rules and settings you can apply to users or computers inside an OU. Think of it like this:

"Hey, Marketing team? You get this wallpaper, these password settings, and you can't install random apps. But IT? You get admin tools, different lock screen timeouts, and no drive restrictions."

Boom. That’s the vibe of GPOs.

🧩 Users vs. Computers

GPOs can target either:

• 👤 Users Think logon restrictions, desktop settings, password rules, etc.

• 💻 Computers Think firewall rules, software installations, update settings, etc.

The cool part? One GPO can contain policies for both, or you can split them up depending on how granular you wanna get.

🧠 Example: Real GPOs on Your Machine

If you crack open gpmc.msc, you’ll probably already see some preloaded GPOs like:

• Default Domain Policy baseline stuff applied to everyone.

• Default Domain Controllers Policy applied specifically to DCs.

These are global policies, but the real fun starts when you build your own.

✨ Why It’s Dope

This setup lets you:

• Push security configs to different departments

• Lock down public machines without restricting devs

• Control USB access, RDP, or software installs per team

• Make your AD environment scalable and secure

🧬 Inheritance: GPOs Flow Downstream

Here’s something a lot of beginners miss, but it’s super important:

📢 Any GPO linked to an OU will also apply to its sub-OUs.

Let’s break that down real quick.

Imagine you’ve got this structure:

Domain.com

└── Staff

    └── Doctors

If you apply a GPO to Staff, guess what? It automatically affects Doctors too. That’s called inheritance, and it can be a blessing… or a headache, if you’re not paying attention.

So yeah, even though you might only link the Default Domain Policy at the top level, it’ll still reach everyone below it, unless you tell it not to.

🔒 Want to Stop That?

You’ve got two main options if inheritance is messing with your plans:

1. Block Inheritance (on the sub-OU) This tells the OU: “Yo, I’m independent. No upstream GPOs for me.” Use it sparingly though it can make things messy to troubleshoot.

2. Enforce (on the GPO itself) This overrides any Block Inheritance. Basically says: “No matter what, I run this.” Use this for high-priority GPOs like security baselines.

Let’s take a closer look at the Default Domain Policy to understand what a GPO actually contains.

When you click on a GPO, the first tab you’ll land on is called Scope. This tab shows you where in Active Directory the GPO is linked. In the case of the Default Domain Policy, you’ll see it’s linked to the entire homelab.local domain.

Now, check out the Security Filtering section. This controls who the GPO actually applies to within that linked location. By default, it’s set to Authenticated Users, which means every user and computer that’s logged into the domain.

But here’s the trick: you can customize this filtering. If you only want the GPO to affect certain users or machines even if they’re in the same OU you can change the Security Filtering to target a specific group or object.

So even though a GPO is linked to a whole domain or OU, Security Filtering gives you finer control over who really gets hit by the policy.

When you open the Settings tab on a GPO, you’ll see the specific configurations it applies. Remember, GPOs can have settings that target either computers or users. In the case of the Default Domain Policy, it only contains Computer Configuration settings.

These are super basic, foundational settings that most domains should have. Things like password policies and account lockout rules. Since this GPO is linked to the entire domain, any changes made here will apply to all computers in the domain.

Let’s say we want to change the minimum password age to 31 days. Here’s how you’d do it:

1. Right-click the Default Domain Policy and hit Edit.

1. A new window pops up with all the settings.

2. Navigate to: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Password Policy

1. Find Minimum password age and set it to 31 days.

Some of the settings are pretty self-explanatory. But if you’re unsure what something does, just double-click it and go to the Explain tab. It breaks down what the setting does and how it affects the system.