Active Directory : Introduction to (AD)

  1. What is Active Directory?
  2. Why AD is important in cybersecurity
  3. Core AD components (domains, forests, OUs, GPOs)
  4. Basic AD objects (users, computers, service accounts, groups)
  5. AD security groups explained
  6. Organizational Units (OUs) in depth
  7. Group Policy Objects (GPOs)
  8. AD authentication: Kerberos and NTLM
  9. Common AD ports
  10. How to identify AD environments
  11. Suggested labs and TryHackMe rooms

Active Directory (AD) is Microsoft’s centralized identity and access management (IAM) system. It allows organizations to manage users, devices, permissions, and policies from a central location — the Domain Controller.

Think of AD as the central nervous system of a Windows network. It decides:

  • Who can log in
  • What they can access
  • How policies are enforced

In pentesting, AD is a high-value target — because controlling AD means controlling the network.

AD is used in nearly all enterprise networks. It stores and manages:

  • User credentials and hashed passwords
  • Trust relationships between systems
  • Group memberships (like Domain Admins)
  • Policies that affect every user and machine
  • Access to shared drives, printers, and applications

Attackers abuse AD to escalate privileges, move laterally, and maintain persistence. It’s the crown jewel in a red teamer’s eyes.

ConceptExplanation
DomainA logical boundary grouping users, computers, and resources under one administrative unit. Think: corp.local.
ForestA collection of one or more domains that trust each other. All domains in a forest share a global catalog and schema.
TreeA group of related domains with a shared namespace (e.g., sales.corp.local, hr.corp.local).
Organizational Unit (OU)Logical containers for organizing AD objects like users, groups, and computers. Used for delegation and applying Group Policy.
Domain Controller (DC)A server that runs AD Domain Services (AD DS) and handles authentication and directory services.
TrustsRelationships between domains that allow users in one domain to access resources in another. Can be one-way or two-way.
Global CatalogA distributed data repository that helps locate objects in any domain of the forest.

These objects are the DNA of an AD environment:

  • Users: Human or service accounts. Target for attacks like password spraying, AS-REP roasting.
  • Groups: Collections of users. Often used to assign permissions or control access.
  • Computers: Domain-joined endpoints. Can be used for lateral movement or privilege escalation.
  • Service Accounts: Used by applications or services. These often have elevated privileges and weak passwords.
  • GPOs: Manage how systems behave (e.g., enforce password complexity, firewall settings).

Security groups are used to manage permissions and access control. You’ll encounter these often during enumeration:

GroupDescription
Domain AdminsFull control over all AD objects. Owning this = owning the domain.
Enterprise AdminsHighest privilege across all domains in a forest. Used for forest-wide changes.
Schema AdminsCan modify the AD schema (rarely used but very powerful).
AdministratorsLocal admin access on Domain Controllers.
UsersDefault group for regular domain users.
Account OperatorsCan create and manage user accounts (limited power, still dangerous).
Backup OperatorsCan bypass file permissions to perform backups — useful for credential theft.
Print OperatorsCan manage printers, but can also restart the Print Spooler (used in PrintSpoofer attacks).

As a pentester, group membership can be your stepping stone to privilege escalation.

OUs are logical containers used to structure AD objects. They help with:

  • Delegating administrative control (e.g., HR admins manage only HR users)
  • Applying Group Policy to specific departments
  • Organizing users by department, location, or function
corp.local
├── Users
│   ├── HR
│   │   ├── HR_Admins
│   │   └── HR_Staff
│   ├── IT
│   │   ├── IT_Admins
│   │   ├── IT_Security
│   │   └── IT_Support
│   ├── Finance
│   │   ├── Finance_Admins
│   │   └── Finance_Staff
│   ├── Sales
│   │   ├── Sales_Managers
│   │   └── Sales_Reps
│   └── Executives
│       ├── C-Level
│       └── Executive_Assistants
│
├── Computers
│   ├── Workstations
│   │   ├── HR_Workstations
│   │   ├── IT_Workstations
│   │   ├── Finance_Workstations
│   │   ├── Sales_Workstations
│   │   └── Executive_Workstations
│   └── Servers
│       ├── File_Servers
│       ├── Domain_Controllers
│       ├── SQL_Servers
│       ├── Web_Servers
│       └── Application_Servers
│
├── Service Accounts
│   ├── SQL_Service
│   ├── WebApp_Service
│   ├── Backup_Service
│   ├── Print_Service
│   └── Monitoring_Agents
│
├── Groups
│   ├── HR_Groups
│   ├── IT_Groups
│   ├── Finance_Groups
│   └── Sales_Groups
│
├── Policies
│   ├── Password_Policies
│   ├── Software_Restrictions
│   ├── Drive_Mapping
│   └── Firewall_Rules
│
└── External
    ├── Vendors
    ├── Contractors
    └── Temporary_Accounts

This kind of setup gives attackers a roadmap of the organization. Understanding how OUs are laid out helps you:

  • Target privileged users in groups like IT_Admins or C-Level
  • Look for weak GPOs applied to Workstations (e.g., drive mapping scripts or credential exposure)
  • Hunt for exposed service accounts like Backup_Service that may have high privileges and weak passwords
  • Use naming conventions to guess other assets or accounts (e.g., if SQL_Service exists, so might SQL_Admin)
  • Identify lateral movement paths, e.g., a Finance_Staff user with access to shared drives used by Finance_Admins

GPOs are settings applied to users or computers in an AD environment. They are linked to sites, domains, or OUs.

  • Enforce password policies
  • Disable/control USB drives
  • Deploy software
  • Set login scripts
  • Configure local admin groups
  • Set startup/shutdown tasks

Misconfigured GPOs can lead to privilege escalation. For example:

  • A GPO adds a user to the local Administrators group on all machines.
  • A GPO runs a startup script with credentials hardcoded in plaintext.

Use tools like gpresult /r, grouppolicy.html, or BloodHound to analyze GPOs during an engagement.

Active Directory primarily relies on two authentication protocols:

  • Kerberos — the modern standard
  • NTLM (NT LAN Manager) — the legacy fallback

Each protocol plays a huge role in the attack surface of an AD environment. Let’s break them down.

Kerberos is the default authentication protocol in Windows domains since Windows 2000. It’s designed to be more secure than NTLM by using tickets instead of password hashes for authentication.

  1. AS-REQ: The user sends an Authentication Service Request to the Key Distribution Center (KDC — part of the Domain Controller).
  2. AS-REP: The KDC replies with a Ticket Granting Ticket (TGT) encrypted with the user’s password hash.
  3. The user decrypts the TGT (proving their identity) and stores it in memory.
  4. To access a service (like SMB), the user presents the TGT and requests a Service Ticket (TGS).
  5. The KDC issues the TGS, which is then used to authenticate to the target service.
AttackDescription
KerberoastingExtract service tickets for accounts with SPNs and crack them offline to recover service account passwords.
AS-REP RoastingIf a user has “Do not require Kerberos preauthentication” enabled, you can request an AS-REP encrypted with their hash and crack it offline.
Golden TicketCreate a forged TGT using the KRBTGT hash (from the DC) and impersonate any user, even Domain Admin.
Silver TicketForge a TGS using a service account hash to access specific services (like CIFS or HTTP) without a TGT.
Pass-the-TicketReuse a stolen TGT or TGS from memory (via Mimikatz or Rubeus) to access resources without a password.
  • Rubeus — Extract, request, inject, or forge Kerberos tickets.
  • Mimikatz — Dump TGTs/TGSs and perform Golden/Silver ticket attacks.
  • Impacket — Toolkit with Kerberos attack support (e.g., GetUserSPNs.py, ticketer.py).

NTLM (NT LAN Manager) is a challenge-response protocol based on password hashes. It’s older and less secure than Kerberos, but still widely used — especially by:

  • Legacy systems
  • Misconfigured services
  • Applications that don’t support Kerberos
  • Local account logins

How NTLM Works (Simplified):

  1. Client sends a username to the server.
  2. Server replies with a challenge (nonce).
  3. Client encrypts the challenge with the hash of the user’s password and sends it back.
  4. Server verifies it using the stored hash in the domain.

No ticketing system. Just hash-based magic — which is bad for security.

Common NTLM Attacks:

AttackDescription
Pass-the-Hash (PtH)Reuse the NTLM hash of a user without cracking it to authenticate as them.
NTLM RelayIntercept NTLM authentication and relay it to another system, often gaining privileged access.
Credential ForwardingAbuse protocols like WinRM, RDP, or WMI where credentials can be auto-forwarded and reused.

Important: NTLM hashes can be dumped with tools like Mimikatz or found in LSASS memory or SAM hives.

As a pentester, understanding how these protocols work lets you:

  • Know where to look for tickets and hashes
  • Choose the right attacks based on the protocol in use
  • Identify weak or misconfigured accounts ripe for roasting or relaying
  • Move laterally and escalate privileges more effectively

When you get a foothold, these protocols are your bridge to full domain compromise.

ToolDescription
RubeusKerberos ticket interaction (roasting, forging, renewal)
MimikatzExtract credentials, hashes, and Kerberos tickets from memory
ImpacketSuite of tools for NTLM/Kerberos attacks (Python-based)
ResponderPoison LLMNR/NBTNS to capture NTLM hashes
NTLMRelayXRelay captured NTLM auth to other services
CrackMapExecCredential spraying, relay support, and service enumeration

Kerberos is the king of modern Windows authentication — but even kings bleed. NTLM is the rotting skeleton of legacy networks — and attackers still feast on it.

As a pentester:

  • Know how to detect which protocol is in use
  • Understand how tickets and hashes behave
  • Be ready to exploit both — because most real networks have both in play
PortProtocolPurpose
88TCP/UDPKerberos authentication
135TCPMicrosoft RPC
139TCPNetBIOS
389TCP/UDPLDAP (user directory lookups)
445TCPSMB (file sharing, authentication)
464TCP/UDPKerberos password changes
3268TCPGlobal Catalog
5985TCPWinRM (PowerShell Remoting)

Run this Nmap scan to detect an AD environment:

nmap -sS -sV -p 88,135,139,389,445,464,593,3268,5985 10.10.10.10

Look for signs like:

  • Hostnames starting with dc01, dc02, etc.
  • Open ports related to Kerberos, LDAP, SMB
  • Shares named SYSVOL, NETLOGON
  • Domains in login prompts (domain\user)
  • Responses to LDAP/Kerberos enumeration
  • DNS suffixes like .local, .corp, .internal

Use tools like:

  • nmap, rpcclient, ldapsearch, crackmapexec
  • BloodHound for mapping users/groups/privileges

You’ve just laid the groundwork for mastering Active Directory as a pentester. Now you know:

✅ What AD is and why it’s mission-critical
✅ The structure of domains, forests, and OUs
✅ The key groups and how permissions are controlled
✅ How authentication works with Kerberos and NTLM
✅ What to look for during recon and enumeration

In Part 2, we’ll dive into Active Directory enumeration — how to map users, groups, and trust relationships using real tools and techniques.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top