Module 1 · AD Architecture Fundamentals 🔒

Active Directory is the authentication backbone of ~95% of enterprise environments in India and globally. Every enterprise breach of note — from Colonial Pipeline to Maersk to countless Indian banks — involved AD compromise somewhere on the kill chain. Understand AD and you understand enterprise attack paths; stay ignorant and you audit blind.

This module covers the architectural fundamentals. By the end you will understand:

• What AD is, why it exists, and what it authenticates
• The core objects (users, groups, computers, OUs) and their relationships
• How Kerberos authentication actually works — the step-by-step flow
• Why every privileged account is a potential domain-compromise vector
• The common misconfigurations that turn AD from security tool into attack surface

What Active Directory is

Active Directory (AD) is Microsoft’s directory service — a centralised database that stores information about users, computers, groups, and policies, and a set of services that let those entities authenticate and authorise access across a Windows network.

The key things AD does:

• Authentication — verify “are you really Manish?”
• Authorisation — determine “can Manish access this share?”
• Directory — look up “what’s Manish’s email, phone, group memberships?”
• Policy enforcement — push config (password policy, drive mappings, software) to every joined machine

Without AD, every Windows server would maintain its own local users and passwords. Scaling to 1000 employees would require maintaining 1000 accounts on every server. AD centralises this: one account, one password, access to everything you’re authorised for.

Core concepts

Domain

A domain is the unit of administrative boundary in AD. Users, computers, policies in one domain are managed together. Every domain has a DNS-style name (corp.example.com) and a NetBIOS short name (CORP).

Domain Controller (DC)

A domain controller is a server running Active Directory Domain Services. It holds the directory database, handles authentication, and replicates with peer DCs. Every domain has at least one DC; production domains have multiple for redundancy.

Forest

A forest is a collection of one or more trees (domains linked by trust). The forest root is the first domain created. All domains in a forest share schema, global catalog, and trust relationships.

Organisational Unit (OU)

OUs are containers within a domain used to organise users, groups, and computers. They’re primarily for delegating admin rights and applying Group Policy. Structure typically mirrors org chart: OU=Engineering, OU=Finance, OU=Sales.

Group Policy Object (GPO)

A GPO is a collection of settings (password length, screensaver lock, firewall rules, drive mappings, installed software) applied to users or computers in a scope (domain, OU). GPOs are how enterprises enforce consistent configuration across thousands of machines without touching each one.

Trust

A trust is a relationship between two domains (or forests) letting users in one authenticate to resources in another. Trusts can be one-way or two-way, transitive or non-transitive. Over-permissive trusts are a common path for lateral movement across organisational boundaries.

Core objects and attributes

User account

Represents a person. Stored in the directory with attributes including:

• sAMAccountName — pre-Windows 2000 login name (manish.garg)
• userPrincipalName — modern login (manish.garg@corp.example.com)
• memberOf — groups the user belongs to
• servicePrincipalName (SPN) — the service(s) this account hosts, if a service account
• userAccountControl — flags (disabled, password never expires, smart card required, etc.)
• lastLogon, pwdLastSet — audit data

Computer account

Represents a machine joined to the domain. Has its own password (random, 240-char by default, rotated every 30 days). Every joined machine authenticates as itself using this account. Attributes similar to users plus OS version, DNS name, etc.

Group

Holds members (users, computers, other groups). Used for access control: “Everyone in ‘Finance-Read’ can read the finance share.” Group types:

• Security groups — used for permissions
• Distribution groups — used for email distribution lists
• Scope — Universal, Global, Domain Local (affect where members can come from and where the group can be used)

Key privileged groups that attackers target:

• Domain Admins — full control over the domain
• Enterprise Admins — full control over the forest (exists in forest root only)
• Schema Admins — can modify AD schema
• Administrators — local admins on DCs + forest-level admin
• Account Operators — can create/modify user accounts (often over-delegated)
• Backup Operators — can read any file via backup APIs (including SYSTEM files)

Kerberos — how authentication works

Kerberos is the primary authentication protocol in modern AD (NTLM still exists for fallback and is widely abused — we’ll cover it in Module 2). Kerberos is ticket-based. Understanding the flow is essential.

Three parties:

• Client — the user/machine wanting access
• Key Distribution Center (KDC) — runs on the DC. Consists of the Authentication Service (AS) and the Ticket Granting Service (TGS)
• Service — the resource being accessed (file share, SQL server, web app, etc.)

The flow (simplified):

1. AS-REQ: Client sends authentication request to KDC, including a pre-authentication blob encrypted with the user’s password hash
2. AS-REP: If the hash decrypts correctly, KDC returns a Ticket Granting Ticket (TGT) encrypted with the krbtgt account’s hash, plus a session key encrypted with the user’s hash
3. TGS-REQ: Client wants to access service X. Sends the TGT to KDC along with the requested Service Principal Name (SPN)
4. TGS-REP: KDC returns a service ticket encrypted with the target service’s hash (derived from that service’s account’s password)
5. AP-REQ: Client sends the service ticket to the service. Service decrypts it with its own hash, verifies, and grants access

Why this matters for attackers:

• Every step involves hashes derived from passwords. Weak service-account passwords = crackable tickets (Kerberoasting, Module 2)
• The TGT is encrypted with the krbtgt account’s hash. Compromise krbtgt and you can forge any TGT for any user (Golden Ticket)
• Service tickets are encrypted with the service account’s hash. Compromise a service’s hash and you can forge tickets for that service (Silver Ticket)
• Pass-the-Hash — if you steal an NTLM hash, you can authenticate as that user without knowing the password. Applies to local accounts; Kerberos has some mitigations

Group Policy — the double-edged sword

GPOs push configuration to domain-joined machines. A single GPO can enforce password policy, install software, map drives, configure firewall, disable USB ports — across thousands of machines.

From a security standpoint:

• Good: consistent hardening (require screensaver lock, restrict PowerShell, enable Credential Guard)
• Good: GPOs can push audit settings (log authentications, log privileged actions) uniformly
• Bad: write permissions on a GPO linked to privileged containers = remote code execution on every affected machine. GPO abuse is a common privilege escalation path
• Bad: GPO Preferences historically stored credentials in cpassword attribute (AES-encrypted with a leaked key); any authenticated user could decrypt. Patched but still found in legacy environments

LDAP — the query protocol

LDAP (Lightweight Directory Access Protocol) is how applications query AD. “Give me all users in this OU.” “Who’s in this group?” “What groups is Priya in?”

By default, any authenticated user can query a great deal of AD information — user lists, group memberships, SPNs, computer accounts. Attackers use this for reconnaissance: find admins, find over-privileged accounts, find service accounts to Kerberoast.

Tools attackers use:

• ldapsearch, Get-ADUser PowerShell cmdlets
• SharpHound / BloodHound — collector that dumps relationships, visualiser that finds attack paths (covered in Module 3)
• Impacket’s GetADUsers.py, adidnsdump, etc.

Common AD misconfigurations

The misconfigurations that reliably show up on audits:

1. Kerberoastable accounts with weak passwords — service accounts with SPNs set and human-memorable passwords (see Module 2)
2. ASREPRoastable accounts — users with “Do not require Kerberos preauthentication” set, allowing offline hash crack
3. Excessive Domain Admin membership — every “IT” employee is a DA
4. Service accounts with DA — a SQL service runs as a DA; compromise the SQL server and you own the domain
5. Unconstrained Delegation on non-DC machines — any server users authenticate to can impersonate them to anything, including DA
6. Resource-Based Constrained Delegation misconfig — can allow computer-account takeover to privileged impersonation
7. LAPS not deployed — every desktop has the same local admin password; one compromise = LAN-wide admin
8. SMBv1 enabled — EternalBlue vulnerable
9. Password Policy bypass via fine-grained policies — specific groups with weaker password rules
10. Old/abandoned accounts — ex-employees with active accounts; service accounts for dead services
11. GPO write permissions on IT operators — GPO modification = code execution on every machine in scope
12. AdminSDHolder misconfig — AdminSDHolder resets ACLs on protected objects; attackers add themselves, then ACL changes are re-applied as “normal”

An external penetration test against AD is really a checklist run against these items. BloodHound, Hashcat, Mimikatz, Impacket — the toolchain is mature.

The principle of tiered admin

Microsoft’s “Red Forest” / tiered admin model:

• Tier 0 — domain controllers, AD itself, PKI. Tier-0 admins log in ONLY to Tier-0 assets from hardened admin workstations (PAWs)
• Tier 1 — servers (file, app, SQL, DB). Tier-1 admins manage servers, never log in to user workstations
• Tier 2 — end-user workstations. Help-desk admins work here, never touch servers

The principle: credentials used at each tier must never appear at a lower tier. A DA login on a user workstation means the DA’s credential is exposed to whatever malware is on that workstation.

Implementing this properly requires:

• Separate admin accounts per tier (Priya uses priya daily, priya-t1 for server ops, priya-t0 for AD)
• Privileged Access Workstations (PAWs) for Tier-0 — dedicated, hardened, no email/browsing
• Logon restrictions (deny logon via GPO for higher-tier accounts on lower-tier assets)

What every defender should run monthly

• PingCastle — free AD security assessment. Generates a score and lists findings
• BloodHound — run SharpHound collector, analyse in BloodHound. Look for “shortest path to Domain Admin” from any user
• PurpleKnight / Semperis Directory Services Protector — commercial but widely used for continuous AD posture monitoring
• Native checks — enumerate DA group membership, old user/computer accounts, weak service account passwords, delegation configurations

Quick reference summary

• AD = centralised auth, authz, directory, policy enforcement for Windows networks
• Forest > Domain > OU — administrative boundaries
• Domain Controller (DC) runs AD services and holds the directory
• Kerberos flow: AS-REQ → TGT → TGS-REQ → Service Ticket → AP-REQ
• krbtgt account encrypts every TGT — compromising it = Golden Ticket (forge any TGT)
• Privileged groups: DA, EA, Schema Admins, Account Operators, Backup Operators
• Common misconfigs: Kerberoastable accts, unconstrained delegation, DA service accts, no LAPS, SMBv1, GPO write ACL abuse
• Tiered admin: T0 (DCs, AD) / T1 (servers) / T2 (workstations) — credentials never cross downward
• Tools to run monthly: PingCastle, BloodHound, continuous posture monitors

Take the quiz. Next (Pro tier): Kerberoasting in Practice — a hands-on walkthrough of one of the most common AD attacks, with defences.