What Active Directory Is
Active Directory is a directory service that centralises identity and access management across a Windows network. Every user account, computer, group, policy, and permission in an enterprise environment gets managed through AD. It's been the backbone of corporate Windows infrastructure since 2000, and it runs in somewhere around 95% of enterprise networks worldwide. That number is why understanding AD is non-negotiable for any pentester doing internal assessments.
The fundamental design decision that creates so many attack opportunities is that AD is intentionally designed to be readable. A standard domain user with no elevated privileges can enumerate users, computers, groups, GPOs, trust relationships, and service accounts across the entire domain. This isn't a bug. It was a design choice made for usability. But from an attacker's perspective, a single compromised account anywhere in the domain is enough to start mapping the entire environment.
The Core Implication
AD is essentially a read-accessible database of your entire organisation's identity infrastructure. A phished user account doesn't just give you that user's access — it gives you a starting point to enumerate everything and find the path to Domain Admin.
Domain Structure
The core unit is the domain — a logical boundary containing users, computers, and resources that share a single directory database. Domains are grouped into trees (contiguous namespace) and multiple trees form a forest. The forest is the outermost security boundary. A Domain Controller (DC) is the server that hosts a copy of the AD database and handles authentication requests.
Organisational Units (OUs) sit inside domains and provide a way to organise objects and apply Group Policy Objects (GPOs) granularly. GPOs are containers for settings pushed to users and computers — everything from password policy to which software gets installed and what the desktop wallpaper looks like.
Get-Module # list loaded PS modules Import-Module ActiveDirectory Get-ADDomain # domain info Get-ADUser -Filter * -Properties * # all users Get-ADGroup -Filter * | select name # all groups Get-ADComputer -Filter * # all computers Get-GPO -All # all Group Policy Objects
Kerberos and NTLM Authentication
AD uses two authentication protocols. Kerberos is the modern default — a ticket-based system where the KDC issues Ticket Granting Tickets (TGTs) after verifying credentials. These TGTs are used to request service tickets for specific resources without sending credentials again. NTLM is the legacy fallback, challenge-response based, and used when Kerberos isn't available or when connecting by IP address rather than hostname.
Understanding how Kerberos works is essential before you can understand the attacks against it. The flow: user authenticates to the KDC, receives a TGT encrypted with the krbtgt account's hash, uses that TGT to request a service ticket for a specific service, the service decrypts the ticket with its own service account's hash. The service account hash is the cryptographic material that makes Kerberoasting possible.
NTLM vs Kerberos
NTLM hashes can be captured via network relay attacks and either cracked or used in Pass-the-Hash attacks without cracking. Kerberos tickets can be extracted from memory and reused (Pass-the-Ticket). Both protocols have well-documented attack paths that work in real environments — that's why AD is such a rich target.
Why This Foundation Matters
I've been on internal assessments where the web application was hardened and the perimeter was clean, but once we got inside the network, the AD environment handed us Domain Admin in under two hours. The attack surface in AD is enormous — misconfigurations in delegation settings, weak service account passwords, overly broad group memberships, GPO permissions, and legacy protocols all create paths that aren't visible from the outside.
The defender's challenge is that most of these misconfigurations don't cause visible problems. A service account with a weak password and an SPN set runs fine for years, doing its job. The vulnerability is invisible until someone Kerberoasts it. That's the thing about AD — the attacks work against correct implementations of features that are working exactly as designed.