Before attacking Active Directory, you need to understand how it works. This module covers the key protocols and concepts: Kerberos authentication, LDAP queries, DNS's role in AD, trust relationships between domains, the AD object model, and how Access Control Lists govern authorization. No attacks yet — just the theory that makes every subsequent module make sense.
Kerberos Authentication Flow
How Kerberos Works
Kerberos is the default authentication protocol in Active Directory since Windows 2000. It is a ticket-based system — users authenticate once and receive tokens (tickets) that prove their identity without transmitting their password over the network.
The three key components are: the client (user workstation), the Key Distribution Center (KDC) running on the Domain Controller, and the service the user wants to access. The KDC has two logical sub-services: the Authentication Server (AS) and the Ticket Granting Server (TGS).
AS-REQ — The client sends an Authentication Service Request to the KDC, including its username and a timestamp encrypted with the user's password hash (NTLM hash of the password). This proves the client knows the password without sending it.
AS-REP — The KDC verifies the timestamp, then responds with two things: a Ticket Granting Ticket (TGT) encrypted with the krbtgt account's hash, and a session key encrypted with the user's hash. The client cannot read the TGT — only the KDC can.
TGS-REQ — When the user wants to access a service (e.g. SMB share), the client sends the TGT + a request for a service ticket to the TGS. The client also specifies the target service by its Service Principal Name (SPN).
TGS-REP — The KDC returns a Service Ticket encrypted with the service account's password hash. Again, the client cannot read this ticket — only the target service can.
AP-REQ — The client presents the Service Ticket to the target service. The service decrypts it with its own key, extracts the user's identity, and grants or denies access.
The TGT is valid for 10 hours by default (configurable via GPO). Service tickets are valid for 10 minutes. Attackers who steal a TGT can use it to request service tickets until it expires — this is the basis of Pass the Ticket attacks.
Kerberos is vulnerable when pre-authentication is disabled (AS-REP Roasting), when service accounts have weak passwords (Kerberoasting), or when the krbtgt hash is compromised (Golden Ticket). Modules 04 and 08 cover these attacks.
LDAP Basics
What LDAP Is and How AD Uses It
The Lightweight Directory Access Protocol (LDAP) is the protocol used to query and modify the Active Directory database. Every piece of AD data — users, groups, computers, GPOs, OUs — is stored as an LDAP object and is accessible via LDAP queries.
AD listens on port 389 (LDAP, plaintext) and port 636 (LDAPS, TLS). For enumeration, attackers typically use port 389 since it requires only a valid domain credential (or sometimes no credential at all for anonymous bind on older configurations).
Every object in AD has a Distinguished Name (DN) that describes its full path in the directory tree:
OU — Organizational Unit: a container for organizing objects.
DC — Domain Component: the domain name split by dots.
LDAP queries use a filter syntax. To search for all users in the domain:
# LDAP filter for all user objects
(&(objectClass=user)(objectCategory=person))
# With ldapsearch (from Kali)kali@kali:~$ ldapsearch -x -H ldap://192.168.1.10 -b "DC=meridianfg,DC=local" \
-D "CN=jsmith,OU=Employees,DC=meridianfg,DC=local" -w "Password123" \
"(&(objectClass=user)(objectCategory=person))" sAMAccountName
LDAP is the backbone of all AD enumeration tools. BloodHound, ldapdomaindump, and PowerView all make LDAP queries under the hood. Understanding the raw protocol helps you interpret what these tools collect and craft custom queries when needed.
DNS in Active Directory
Why DNS Is Critical in AD
Active Directory is entirely DNS-dependent. Every domain-joined machine locates services — Domain Controllers, Kerberos, LDAP, global catalog — by querying DNS. Without working DNS, domain functionality breaks entirely.
The Domain Controller also acts as the authoritative DNS server for the domain zone (e.g. meridianfg.local). Key DNS records in a healthy AD environment:
_ldap._tcp.dc._msdcs.meridianfg.local — SRV record pointing to DCs. Used by clients to find a DC for LDAP.
_kerberos._tcp.dc._msdcs.meridianfg.local — SRV record for Kerberos. Clients use this to find the KDC.
_gc._tcp.meridianfg.local — SRV record for the Global Catalog (used in multi-domain forests).
A records — Every domain-joined machine registers its hostname → IP mapping in the domain DNS zone when it joins.
From an attacker's perspective, DNS is a valuable enumeration target. Zone transfers (AXFR), if allowed, expose the full list of hostnames and IPs. Even without zone transfers, standard A/SRV lookups reveal the domain structure.
# Attempt DNS zone transfer (often blocked)kali@kali:~$ dig axfr meridianfg.local @192.168.1.10
# Query for Domain Controllers via SRV recordskali@kali:~$ nslookup -type=SRV _ldap._tcp.dc._msdcs.meridianfg.local 192.168.1.10
LLMNR and NBT-NS exist partly as fallback mechanisms when DNS fails. Disabling LLMNR and NBT-NS is a key hardening recommendation — but since many orgs don't do this, it's a reliable attack vector (Module 03).
Trust Relationships
Domain and Forest Trusts
A trust is a relationship between two domains (or forests) that allows authentication to flow across the boundary. Trusts are the attack path between otherwise separate domains — compromising one domain may allow pivoting to a trusted domain.
Parent-child trust — Automatic, bidirectional, transitive. Created when a child domain is added to a forest. contoso.local and us.contoso.local have an implicit parent-child trust.
Tree-root trust — Automatic, bidirectional, transitive. Between the forest root and a new tree root added to the same forest.
Forest trust — Manual, can be one- or two-way. Between the root domains of two separate forests. Allows users in one forest to authenticate to resources in the other.
External trust — Manual, non-transitive. Between a domain in one forest and a domain in another, without trusting the whole forest.
Shortcut trust — Manual, to speed up authentication in large forests with long trust chains.
Transitivity determines whether a trust can be extended through a chain: if A trusts B and B trusts C, a transitive trust means A also trusts C. Most internal AD trusts are transitive.
In penetration tests, always enumerate trusts. A Golden Ticket combined with a forest trust can allow cross-forest compromise if the SID filtering is not correctly configured. Inter-forest attacks are covered in the advanced module extensions.
AD Object Model
Objects, Attributes, and the Schema
Everything in Active Directory is an object — users, groups, computers, OUs, GPOs, contacts, printers. Each object is an instance of a class defined in the AD Schema (a master blueprint for what object types exist and what attributes they can have).
Key object types relevant to pentesting:
User objects — Represent human or service accounts. Key attributes: sAMAccountName (logon name), userPrincipalName, memberOf (group memberships), servicePrincipalName (SPNs — relevant for Kerberoasting), userAccountControl (flags controlling account behavior like DONT_REQ_PREAUTH).
Computer objects — Created automatically when a machine joins the domain. Computers authenticate as machine accounts (HOSTNAME$). They can also have SPNs.
Group objects — Security groups are used to assign permissions; distribution groups are for email. Groups can nest — a member of Group A which is a member of Group B inherits Group B's permissions.
GPO objects — Group Policy Objects linked to OUs, sites, or the domain. Define security settings, script deployments, and more. Misconfigured GPO permissions are an escalation path.
OU objects — Organizational Units are containers. They do not grant permissions by themselves, but GPO links and delegated permissions are typically applied at the OU level.
The userAccountControl attribute is a bitmask. The flag DONT_REQ_PREAUTH (0x400000) disables Kerberos pre-authentication for that account — making it vulnerable to AS-REP Roasting. Tools like PowerView enumerate this flag automatically.
ACL Overview
Discretionary ACLs and Access Control Entries
Every AD object has a Discretionary ACL (DACL) — a list of Access Control Entries (ACEs) that define which principals (users, groups) have which permissions on that object.
Common ACE rights that are dangerous when misconfigured:
GenericAll — Full control over the object. Can change passwords, add group members, modify any attribute, take ownership.
GenericWrite — Can modify most writable attributes, including servicePrincipalName (used for targeted Kerberoasting) and scriptPath (logon script execution).
WriteDACL — Can modify the DACL itself. An attacker with WriteDACL can grant themselves GenericAll — self-escalation.
WriteOwner — Can change the object's owner. Owners implicitly have WriteDACL.
ForceChangePassword — Extended right to change a user's password without knowing the current one.
AddMember (Self-Membership) — Can add accounts to the group — useful for escalating group membership.
DCSync rights (DS-Replication-Get-Changes-All) — Allows replication of all domain data including password hashes. Domain Admins and Domain Controllers hold this by default.
BloodHound maps these ACL relationships as edges in a graph, making it easy to find paths from a low-privilege account to Domain Admin. Understanding the underlying ACE model explains why those paths exist.
ACL abuse is covered in depth in Module 05. For now, the key takeaway is: misconfigured DACL entries on AD objects are as dangerous as misconfigured group memberships. Attackers who can write to another object's DACL can grant themselves any right on that object.