Active Directory from Zero: What I Had to Learn Before I Could Break Anything

I'd used Windows my whole life with a single account, logging straight into whatever I wanted. So when I started setting up Organizational Units and Group Policy for Chakravyuha: An Active Directory Purple Team Lab, the idea that a policy could reach into a specific OU and quietly restrict what a specific user could do on a specific machine was new territory - not in theory, but in the "I'm the one configuring this and have no intuition for it yet" sense.

I found out the hard way. I'd set a GPO restricting logon to specific workstations, and when I tried to RDP into one of my own machines afterward, I was locked out - by a policy I'd written myself, for a scenario I hadn't fully thought through. That was the moment the theory and the practice stopped being the same thing. Understanding that Kerberos handles authentication doesn't tell you anything about how a GPO decides where that authenticated user is allowed to actually log on.

Before I could get anywhere near Kerberoasting or any other attack, I needed a working domain - a domain controller, DNS, machines actually joined to the domain, an organizational structure that meant something, and Group Policy that did what I intended instead of what I assumed. None of that is the attack itself. But without it, there's no realistic environment to attack, no logs worth detecting against, and no way to tell whether a detection rule actually works or just happens to fire in an empty lab.

This post covers the Active Directory concepts I had to learn - and in a couple of places, learn by locking myself out - before moving into the offensive side of the lab.

TL;DR for recruiters / hiring managers

• In plain English: Active Directory centralises identity, authentication, and administration across Windows environments.
• What I built: A domain with a domain controller, DNS, a member server, two workstations, a tiered organisational structure, and Group Policy baselines - including a GPO that briefly locked me out of my own machine.
• Why it matters for a SOC: understanding how a domain is supposed to behave is what makes it possible to recognise when something about an authentication event, a privilege change, or a policy looks wrong.

1. What Is Active Directory, Really?

Active Directory Domain Services (AD DS) is Microsoft's directory service for managing identities and resources across a Windows domain.

Picture an organisation with hundreds of employees, dozens of computers, and several administrators. Without a central directory, every account and permission would need managing machine by machine - slow, inconsistent, and hard to secure. AD solves that by keeping users, computers, groups, and organisational units in one directory, with authentication and policy mechanisms built around it.

In my lab, that directory lives on DC-01, a Windows Server 2022 box running AD DS, DNS, and the Key Distribution Center role. A few pieces make the whole thing work together:

• Domain controller - DC-01, which authenticates users and holds the directory
• The directory database - the persistent store of every object and its attributes
• DNS - how domain members actually find DC-01 and the services it offers (more on this below - it bit me)
• Kerberos - the authentication protocol underneath nearly everything
• Group Policy - how configuration and restrictions get applied centrally (also bit me, in a more literal sense)

These pieces are connected, not separate. A suspicious login isn't just "a username" - it's an account, its group memberships, the service it authenticated to, and the event that logged it. Understanding how those pieces relate is what turns a log line into something an analyst can actually investigate.

2. Domain vs Tree vs Forest: Understanding the Structure

A domain, a tree, and a forest describe different levels of AD's logical structure. They're related, but not interchangeable, and I'd mixed them up more than once before building this out.

A domain is the administrative and identity-management unit. My domain is CORP.CHAKRAVYUH.LOCAL, with DC-01 as its domain controller and SRV-01, WS-01, and WS-02 joined to it as domain members rather than running on independent local accounts.

A tree is a hierarchy of domains sharing a contiguous DNS namespace - for example, corp.example.com and a child domain sales.corp.example.com. A tree is not an OU: a child domain is an entirely separate domain, where an OU is just a container inside one domain.

A forest is the broader structure: one or more domains sharing a schema, configuration data, and trust relationships. It's also a meaningful security boundary - compromising the right identity or directory control inside a forest can have consequences well beyond one workstation.

Chakravyuha is a single-domain forest. I didn't need multiple domains or trees to demonstrate authentication, tiered permissions, attack paths, or detection - one domain was enough to make all of that real.

Active Directory Forest
│
└── Domain: CORP.CHAKRAVYUH.LOCAL
    ├── OU: Tier 0 (DC-01)
    ├── OU: Tier 1 (SRV-01)
    ├── OU: Tier 2 (WS-01, WS-02)
    ├── Users
    ├── Groups
    └── Computers

![[Screenshot 2026-10-17 100452.png]](https://cdn.hashnode.com/uploads/covers/62ed3a7de3a3793580dfdd20/a5a5a8d5-53dd-481a-b958-b7b890435e94.png align="center")

The practical takeaway: a domain, a tree, and a forest describe different parts of the structure and trust relationships. Getting that straight makes it a lot easier to reason about where an object belongs and how far a compromise could actually spread.

3. Organisational Units vs Groups: The Confusion Worth Resolving Early

OUs and groups are easy to mix up, and setting up Chakravyuha's tiered model was where I actually felt that confusion rather than just reading about it.

Setting up the tiered admin model - separate accounts and groups for Tier 0, Tier 1, and Tier 2, each with their own scope and their own policies - was confusing before it clicked. It wasn't a single thing that broke; it was not yet having the mental model for why three different admin identities, each restricted to its own tier, mattered more than one admin account used everywhere. Once I understood that a Tier 0 credential typed into a Tier 2 workstation is only as safe as that workstation's security, the separation stopped being bureaucratic overhead and started being the actual point - it's the same reasoning real environments use to limit how far a single compromised account can reach.

Mechanically, the distinction is this: an OU organises objects and is what a GPO links to. A group manages membership and is what permissions get granted to. In Chakravyuha:

• Tier 0 - DC-01, the domain controller itself
• Tier 1 - SRV-01, the server tier
• Tier 2 - WS-01 and WS-02, the workstations

Separate admin accounts exist for each tier - adm.t0.yash for DC-01 only, adm.t1.yash for SRV-01 only, adm.t2.yash for the workstations only - and none of them is meant to ever log on outside its own tier. That's the OU side: organisation and where policy applies.

The group side solves a different problem. The IT-Support group is granted local admin on both workstations through Group Policy, while the daily-use accounts on those machines (pnair, rdesai) are not members of it. That's a deliberate, specific permission relationship - not something you'd see just by looking at where an account sits in the OU structure.

That's the real lesson: seeing where a user sits in an OU doesn't tell you what they can actually do. Group membership, delegated permissions, and local group membership all matter too - and an analyst who only checks one of those is missing half the picture.

4. Group Policy: How Organisations Manage Windows at Scale - and How I Managed to Lock Myself Out

A Group Policy Object (GPO) is a set of configuration settings an administrator links to a domain, a site, or an OU, applied to the users or computers inside it. The alternative - configuring every machine by hand - doesn't scale and drifts out of sync fast.

In Chakravyuha, the Default Domain Policy sets password and account-lockout requirements, and a separate Workstation-Baseline-Restrictions GPO applies additional restrictions to the Tier 2 OU - including, as I found out directly, a logon restriction limiting which users could log on to which workstations.

![[Screenshot 2026-10-17 101053.png]](https://cdn.hashnode.com/uploads/covers/62ed3a7de3a3793580dfdd20/3108a40b-9f13-430e-bb92-2135564640dc.png align="center")

I'd set that restriction myself, as part of building out the Tier 2 environment properly, and then tried to RDP into one of my own workstations shortly after. I was locked out - by my own policy, on my own lab, because I hadn't fully thought through who the restriction actually applied to when I set it. It was a useful reminder that linking a GPO to an OU doesn't mean "this setting applies to everything underneath it, loosely" - it means exactly what you configured, applied precisely, whether or not you remembered every detail of what you configured.

Two things are worth being explicit about. First, a GPO can configure both user and computer settings - it's not limited to one type of object. Second, whether a given setting actually reaches a given object depends on scope, inheritance, enforcement, and security filtering - not just "is this OU under that GPO." I learned that distinction by tripping over it.

For a SOC analyst, this matters beyond the embarrassment of locking yourself out once. An unexpected change to a security-relevant GPO can weaken protections across an entire OU, not just one machine. Knowing what the intended baseline is supposed to be is what gives an analyst something real to compare an unexpected change against.

5. DNS: The Dependency That Makes Active Directory Discoverable

DNS is easy to think of as "names become IP addresses," and that's true - but in AD, its job runs deeper than that. Domain members use DNS, including SRV records, to actually locate domain controllers and the services on them. That matters most during domain join and authentication, and it's exactly where I ran into trouble - though not in the way I expected.

My first real DNS problem wasn't really DNS - it was networking underneath it. I'd set up two virtual networks in VMware, NAT and Host-Only, and DC-01 ended up reachable over whichever one actually answered. I'd assigned it a static Host-Only IP, 192.168.10.10, and that's the address every other machine and Wazuh were configured to expect. But querying 192.168.10.10 from another device returned nothing, while the NAT adapter's IP - which changed on every reboot - was the one actually answering.

The fix was at the VMware network console level, not inside Windows: I set the static IP as the default for each machine directly in VMware's network settings, removing the ambiguity before Windows ever saw it, rather than trying to force adapter priority from inside the guest OS. It's a small distinction, but it matters - a DNS record pointing at the right address doesn't help if the machine itself answers on a different one depending on boot order.

It's also a good example of why domain-join and authentication problems aren't always what they look like. Nothing about Kerberos or AD DS was actually broken here. The domain simply wasn't reachable at the address everything expected, which is exactly the kind of failure that looks like "authentication is broken" to someone who doesn't check connectivity first.

For a SOC analyst, that sequencing matters: check connectivity and name resolution before jumping to conclusions about credentials or Kerberos. It's the difference between a discovery problem and an authentication problem, and they look identical from the symptom alone.

6. NTDS.DIT: Where Active Directory Stores Its Directory Data

NTDS.DIT is the database file AD DS uses to store directory information on a domain controller - every user, group, computer, and attribute, along with sensitive authentication-related material in protected, non-plaintext form.

I'll admit Kerberos didn't click for me from documentation alone - two posts in particular made the authentication flow click in a way the official docs hadn't: a walkthrough of Kerberos authentication and an introduction to Active Directory concepts. Worth a read if AD and Kerberos still feel abstract at this point - they were the thing that made the rest of this build make sense.

Why should an aspiring SOC analyst care about a database file specifically? Because it explains why control over a domain controller is so consequential. An attacker with sufficiently powerful access - particularly replication rights - can obtain credential material affecting many identities across the domain, without ever touching the file directly. That's the premise behind DCSync: abusing directory replication rights to request sensitive directory data from a domain controller, rather than copying NTDS.DIT by hand. It depends on having those replication rights in the first place - not something an ordinary domain user can just do. I'll cover the technique and its detection later in this series.

7. Why These Foundations Matter for a SOC Analyst

The offensive case for learning AD is obvious - it explains where attack opportunities come from. But the same knowledge is just as load-bearing on the defensive side.

An unusual authentication event means little without understanding the domain controller, Kerberos, and the services involved. An unexpected privilege change is only meaningful if you understand the difference between where an account sits and what it actually has access to - which is the OU-vs-group distinction again. A policy change on a GPO linked to an OU can affect every machine under it, not just one endpoint - which I now understand a little more personally than I did before building this.

That's why Chakravyuha follows Attack → Detect → Respond → Harden for every module. I want each one to show not just that a technique works, but how it can be investigated, how a response would actually play out, and what changes would reduce the risk - built on an environment (DC-01, SRV-01, WS-01, WS-02, and a separate Ubuntu-based SIEM running Wazuh with Sysmon) real enough that those answers mean something.

A Tier 1 SOC analyst needs more than the ability to recognise an event ID. They need to understand the system that generated it, what normal looks like, the account's actual role, and what the activity could mean. That context is what AD fundamentals provide - and it's a lot more durable when a few of them were learned by locking yourself out of your own lab first.

Closing: The Foundation Before the Attack

Domains, forests, OUs, groups, Group Policy, DNS, and the directory database aren't disconnected topics to memorise. Together, they explain how identities are organised, how machines find domain services, how configuration actually gets enforced, and where the boundaries can fail - sometimes on the person configuring them.

The next post goes deeper into the piece holding much of this together: Kerberos authentication. I'll break down the authentication flow and explain why ticket encryption choices matter, before moving into Kerberoasting itself.

Understanding the foundation comes first. Now it's time to understand the protocol underneath it.

Full series index: Series Link