Active Directory Fundamentals

Active Directory Fundamentals: Core Concepts

In a Windows network without Active Directory, each computer maintains its own local user database. Users need separate accounts on every machine, passwords are managed independently, and there is no centralized way to enforce security policy. Active Directory (AD) solves this by providing a centralized directory service that stores accounts, groups, computers, and policies for the entire domain.

Core Components

Domain — The logical boundary of an AD environment. All objects (users, groups, computers) within a domain share the same directory database and security policies. A domain is identified by a DNS name (e.g., corp.example.com).

Domain Controller (DC) — A server that hosts a copy of the AD database and provides authentication and authorization services. Every DC in a domain has a writable copy of the database (unlike read-only domain controllers in some configurations). Changes made on any DC replicate to all others.

Organizational Unit (OU) — A container within a domain used to organize objects hierarchically. OUs are the primary unit for delegating administrative permissions and applying Group Policy Objects. A well-designed OU structure mirrors the organization's administrative needs, not necessarily its org chart.

Forest — One or more domains that share a common schema and configuration. A forest is the security boundary of AD — by default, administrators in one domain cannot administer another domain within the same forest unless explicitly granted permission.

Schema — The blueprint that defines every object type and attribute that can exist in AD. The schema is forest-wide and rarely modified, but understanding it is essential for advanced administration.

Authentication: Kerberos

AD uses Kerberos as its primary authentication protocol. Kerberos uses tickets instead of passwords for subsequent authentications, which means the user's password is never sent across the network after the initial logon.

The Kerberos flow:

1. AS-REQ/AS-REP — The user authenticates to the Authentication Service (AS) on the DC by encrypting a timestamp with their password hash. The AS responds with a Ticket Granting Ticket (TGT).
2. TGS-REQ/TGS-REP — When the user wants to access a service (e.g., a file share), they present the TGT to the Ticket Granting Service (TGS), which issues a service ticket for that specific service.
3. AP-REQ/AP-REP — The user presents the service ticket to the target service, which validates it and grants access.

Each ticket is encrypted with the service's secret key, so only the target service can decrypt it. This prevents ticket forgery and ensures that tickets cannot be redirected to unintended services.

Groups and Delegation

Security groups are used to assign permissions to resources. A user who is a member of a security group inherits all permissions assigned to that group. Best practice is to assign permissions to groups, not individual users (AGDLP: Accounts → Global groups → Domain Local groups → Permissions).

Delegation allows granting specific administrative permissions without making someone a Domain Admin. For example, you can delegate the ability to reset passwords in a specific OU to a helpdesk group, without giving them any other permissions.

Where It Fits

Active Directory is the foundation of Windows enterprise security. It provides the identity infrastructure that Group Policy depends on, the authentication that Kerberos enables, and the organizational structure that makes large-scale administration possible. Study Group Policy Hardening first to understand how AD's organizational structure is used for policy enforcement.

Active Directory Fundamentals: Practice

Active Directory is best learned by doing. The exercises below cover the core administrative tasks you will perform regularly: creating users and groups, organizing OUs, and verifying replication.

Exercise 1: Create an OU Structure

Design an OU structure for a company with three departments (Engineering, Sales, Operations) that need different Group Policy settings:

# Import the AD module
Import-Module ActiveDirectory

# Create the top-level OU
New-ADOrganizationalUnit -Name "Corp" -Path "DC=corp,DC=example,DC=com"

# Create department OUs
New-ADOrganizationalUnit -Name "Engineering" -Path "OU=Corp,DC=corp,DC=example,DC=com"
New-ADOrganizationalUnit -Name "Sales" -Path "OU=Corp,DC=corp,DC=example,DC=com"
New-ADOrganizationalUnit -Name "Operations" -Path "OU=Corp,DC=corp,DC=example,DC=com"

# Create nested OUs for users and computers
New-ADOrganizationalUnit -Name "Users" -Path "OU=Engineering,OU=Corp,DC=corp,DC=example,DC=com"
New-ADOrganizationalUnit -Name "Computers" -Path "OU=Engineering,OU=Corp,DC=corp,DC=example,DC=com"

Separating users and computers into different OUs allows you to apply different Group Policy settings to each. For example, you might want stricter password policies for user accounts but different audit policies for computer accounts.

Exercise 2: Create Users and Groups

# Create a user
New-ADUser -Name "Jane Smith" -GivenName Jane -Surname Smith `
  -SamAccountName "jsmith" -UserPrincipalName "jsmith@corp.example.com" `
  -Path "OU=Users,OU=Engineering,OU=Corp,DC=corp,DC=example,DC=com" `
  -AccountPassword (ConvertTo-SecureString "P@ssw0rd!2024" -AsPlainText -Force) `
  -Enabled $true -ChangePasswordAtLogon $true

# Create a security group
New-ADGroup -Name "Engineering-Admins" -GroupScope Global `
  -GroupCategory Security `
  -Path "OU=Engineering,OU=Corp,DC=corp,DC=example,DC=com"

# Add the user to the group
Add-ADGroupMember -Identity "Engineering-Admins" -Members "jsmith"

# Verify membership
Get-ADGroupMember -Identity "Engineering-Admins"

Exercise 3: Verify Replication

After making changes on one DC, verify they replicate to all others:

# Check replication status
Get-ADReplicationPartnerMetadata -Target "DC01.corp.example.com" -Scope Domain

# Force replication from a specific partner
Sync-ADObject -Object "CN=Jane Smith,OU=Users,OU=Engineering,OU=Corp,DC=corp,DC=example,DC=com" `
  -Source "DC01.corp.example.com" -Destination "DC02.corp.example.com"

# Check for replication failures
Get-ADReplicationFailure -Target "DC01.corp.example.com"

Exercise 4: Delegate Permissions

Delegate the ability to reset passwords in the Sales OU to a helpdesk group:

# Create the helpdesk group
New-ADGroup -Name "Helpdesk-Sales" -GroupScope Global -GroupCategory Security `
  -Path "OU=Sales,OU=Corp,DC=corp,DC=example,DC=com"

# Delegate password reset permissions
$ou = "OU=Sales,OU=Corp,DC=corp,DC=example,DC=com"
$group = "Helpdesk-Sales"

dsacls $ou /I:S /G "${group}:CA;Reset Password;user"
dsacls $ou /I:S /G "${group}:RPWP;Lockout Time;user"
dsacls $ou /I:S /G "${group}:RPWP;pwdLastSet;user"

Check Your Understanding

• Why is it important to separate users and computers into different OUs?
• What is the difference between a security group and a distribution group?
• How does Kerberos prevent password exposure after the initial logon?

Active Directory Fundamentals: Trade-offs and Interviews

Active Directory is the backbone of Windows enterprise infrastructure, but it comes with significant complexity and security considerations. Understanding the trade-offs is essential for both design and incident response.

The Single Point of Failure Problem

If all domain controllers are unavailable, no one can authenticate. This makes AD a critical availability target. Mitigation strategies:

• Deploy multiple DCs across different physical locations
• Maintain at least one DC per site to avoid WAN dependency for authentication
• Regularly back up AD with Windows Server Backup or a dedicated AD backup solution
• Monitor DC health with replication status checks and event log monitoring

Security Risks

• Domain Admin compromise: A single Domain Admin account compromise gives the attacker complete control over the entire domain. Implement tiered administration (Tier 0, 1, 2) to limit the blast radius of credential theft.
• Kerberoasting: Attackers can request service tickets for service accounts and crack them offline. Use Group Managed Service Accounts (gMSAs) with automatic password rotation to mitigate this.
• Pass-the-Hash: Attackers can authenticate using NTLM password hashes without knowing the actual password. Disable NTLM where possible and implement Credential Guard on Windows 10/11.
• AD CS misconfiguration: Active Directory Certificate Services can be abused for privilege escalation if certificate templates are misconfigured. Regularly audit certificate template permissions.

When Active Directory Is the Wrong Tool

• Cloud-native environments: In Azure AD / Entra ID environments, traditional AD concepts (OUs, GPOs, Kerberos) are replaced by different mechanisms (Intune, Conditional Access, OAuth). While hybrid environments exist, cloud-native applications should use cloud-native identity.
• Small environments: For fewer than 20 users, a workgroup with local accounts may be simpler and sufficient. AD introduces overhead that is not justified at small scale.
• Non-Windows environments: AD is optimized for Windows. While LDAP and Kerberos can be used from Linux, a pure Linux environment may be better served by FreeIPA or Samba AD.

How This Comes Up in Interviews

• "How does Kerberos authentication work in AD?" Explain the three-step flow: AS-REQ/AS-REP (get TGT), TGS-REQ/TGS-REP (get service ticket), AP-REQ/AP-REP (present ticket to service). Emphasize that passwords are never sent after the initial authentication.
• "What happens if a domain controller fails?" Other DCs continue to authenticate users. If all DCs are down, cached credentials allow previously authenticated users to log on, but new authentications fail. This is why multiple DCs per site are critical.
• "How do you secure Active Directory?" Implement tiered administration, deploy gMSAs, disable NTLM, audit certificate templates, monitor for DCSync attacks, and regularly review group membership for privileged groups.