Active Directory Security: Harden Your AD Environment

This guide covers Active Directory security best practices that every IT professional should know.

In March 2023, Cl0p operators compromised a regional financial services company and reached their domain controllers in 87 minutes. The initial vector was a spearphishing email. From there, the attack chain was almost embarrassingly simple: a local admin credential reuse hop, then a service account with domain admin rights running on every server in the environment. Game over before the SOC received the first alert. This is essential for Active Directory security best practices.

That’s not an edge case. That’s Tuesday for most enterprise AD environments.

Why Active Directory Is the Actual Target — Active Directory Security Best Practices

Active Directory isn’t just an authentication service – it’s the keys to your kingdom. Control AD, and you control DNS, GPOs, group memberships, trust relationships, and ultimately every Windows workstation and server in scope. Threat actors know this. APT29, Lazarus Group, and every ransomware affiliate worth their salt targets AD specifically because it offers the highest return on compromise.

MITRE ATT&CK documents this extensively under TA0004 (Privilege Escalation) and TA0006 (Credential Access). Techniques like T1003.006 (DCSync) and T1558 (Steal or Forge Kerberos Tickets) are AD-specific – and they appear in almost every major breach post-mortem from the last three years. This is essential for Active Directory security best practices.

AD stores credentials in NTDS.dit on domain controllers. It controls authorization through group membership. It distributes policy through GPOs. Attackers don’t need a zero-day if they can just become a domain admin through misconfiguration and overprivilege. CVE-2020-1472 (Zerologon) was a perfect example – a critical flaw in the Netlogon protocol that allowed unauthenticated attackers to seize domain controller credentials in seconds. Patch Tuesday matters more than most teams act like it does.

The Tiered Administration Model vs. Flat AD

Most organizations I’ve audited – and I’ve done more than a few – have what I call “flat AD.” One tier. Domain admins for everything. Service accounts with excessive rights. Help desk staff sitting in groups they were added to years ago and never removed from. This is essential for Active Directory security best practices.

Microsoft’s tiered administration model (formalized in their Enterprise Access Model) splits administrative access into three logical tiers:

• Tier 0: Domain controllers, AD DS itself, PKI, and privileged identity management systems
• Tier 1: Member servers, applications, and cloud management planes
• Tier 2: Workstations and end-user devices

The rule is strict: credentials used at a higher tier must never touch a lower tier. A Tier 0 admin account should never log into a Tier 2 workstation. If it does, that credential can be harvested via T1003 (OS Credential Dumping) and used to escalate back up the chain. This is essential for Active Directory security best practices.

Implementing tiering properly is genuinely hard. It requires redesigning how your team operates, creating separate admin workstations (PAWs – Privileged Access Workstations), and changing deeply ingrained habits. But it’s the single most impactful structural change you can make to AD security. For organizations that need guidance getting this right, teams that specialize in this kind of migration can accelerate the process significantly and help avoid the outages that come from doing it wrong.

Privileged Groups: Audit First, Then Lock Down

Before you change anything, audit your privileged groups. All of them – Domain Admins, Enterprise Admins, Schema Admins, Administrators, Account Operators, Backup Operators. You will find things that concern you. This is essential for Active Directory security best practices.

Pull current membership with PowerShell:

# Enumerate all members of high-privilege groups
# Run before any hardening work - establishes your security baseline
$privilegedGroups = @(
    "Domain Admins",
    "Enterprise Admins",
    "Schema Admins",
    "Backup Operators"
) This is essential for Active Directory security best practices.

foreach ($group in $privilegedGroups) {
    Write-Host "`n=== $group ===" -ForegroundColor Yellow
    # Recursive flag exposes nested group members - a common path attackers exploit for hidden privilege
    Get-ADGroupMember -Identity $group -Recursive |
        Select-Object Name, SamAccountName, objectClass |
        Format-Table -AutoSize
}

Run this. Save the output. Then ask why each account is there. In my experience, roughly 40% of those accounts don’t need to be. Ex-employees. Service accounts. Test accounts someone forgot to clean up when a project ended in 2019. This is essential for Active Directory security best practices.

CIS Benchmark for Windows Server 2022 (v1.0.0) recommends keeping Domain Admins membership as small as possible and using it only for specific AD management tasks – never for day-to-day administration. For practical OU and group hygiene workflows that complement this cleanup, the guide on managing Active Directory objects covers the operational side in detail.

Service Accounts: The Overlooked Attack Vector

Service accounts are where most AD compromises actually happen. They’re old. They have static passwords set years ago by someone who no longer works there. They’re often in Domain Admins because someone took a shortcut when deploying an application. And they’re running on every server in the environment. This is essential for Active Directory security best practices.

The modern answer is Group Managed Service Accounts (gMSAs). Introduced in Windows Server 2012, gMSAs have passwords managed automatically by AD – rotating on a configurable schedule, typically every 30 days. No human ever knows the password. No credential to harvest via Kerberoasting.

# Create a gMSA for a web application service account
# Requires a KDS root key - run New-KdsRootKey -EffectiveImmediately first in lab environments
# In production, wait 10 hours after KDS key creation before deploying gMSAs
New-ADServiceAccount `
    -Name "svc-webapp01" `
    -DNSHostName "webapp01.corp.contoso.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "WebApp-Servers" `
    -ManagedPasswordIntervalInDays 30 `
    -Enabled $true

gMSAs work well for services running on Windows Server 2012 R2 and above. But they don’t solve everything – they can’t be used for interactive logons, scheduled tasks on older systems, or services requiring delegation to non-Kerberos resources. Legacy services often need traditional accounts, and those need extra scrutiny: 25-plus character passwords, no SPNs where avoidable, and dedicated monitoring for anomalous authentication behavior.

Kerberos Hardening and Protocol Controls

Kerberoasting (T1558.003) is one of the most common post-exploitation techniques used against AD environments today. An attacker requests service tickets for accounts with SPNs registered – which includes most service accounts – and takes those tickets offline to crack. No special privileges required. Any domain user can launch this attack. This is essential for Active Directory security best practices.

The mitigations layer on top of each other:

• Service account passwords must be 25-plus characters – offline cracking becomes computationally impractical
• Migrate to gMSAs wherever possible – automatic rotation eliminates the attack entirely
• Enable AES encryption for Kerberos and disable RC4 via GPO – RC4 cracks significantly faster and has no place in a modern environment
• Monitor for bulk TGS requests from a single account within a short window – the classic T1558.003 IOC pattern

On Windows Server 2019 and 2022, you can enforce AES-only Kerberos by setting msDS-SupportedEncryptionTypes to 24 (AES128 and AES256) on service accounts. This intentionally breaks RC4 fallback. And yes, some legacy applications will break. Test in a non-production environment first and document every service that fails. This is essential for Active Directory security best practices.

Raising your domain and forest functional level is a prerequisite for several of these controls. If you haven’t addressed this recently, the full process is documented at How to Raise the Active Directory Forest Functional Level.

Auditing and Detection Baselines

You can’t detect what you don’t log. Most environments still don’t have adequate AD audit policies configured. This is essential for Active Directory security best practices.

The minimum audit policy (per NIST SP 800-53 and CIS Controls v8) that every AD environment should have enabled:

• Audit Account Management: Success and failure – catches unauthorized group membership changes
• Audit Directory Service Changes: Success – logs attribute modifications including password resets and SPN additions
• Audit Logon Events: Success and failure – the baseline for lateral movement detection
• Audit Privilege Use: Success and failure – flags elevated operations across the environment

But logging without a SIEM is just noise retention. Event ID 4769 (Kerberos service ticket request) is completely normal – hundreds per hour in any active environment. That same event ID hitting every SPN in your directory from a single workstation in five minutes is a Kerberoasting attack in progress. Context is everything.

For the endpoint detection side of this picture, the Endpoint Security guide for IT teams covers EDR integration and behavioral detection rules that complement your AD audit logging – particularly relevant for detecting T1550 (Pass the Hash) and lateral movement from compromised workstations.

AD Backup Is a Security Control

Ransomware groups increasingly target AD backups specifically. BlackCat/ALPHV operators documented in 2023 targeted Windows Server Backup repositories to eliminate recovery options before triggering encryption. If your AD goes down and you have no clean backup, you’re rebuilding from scratch – that means weeks of downtime, not hours.

AD system state backups should run daily on all domain controllers. Those backups need to reach a network-isolated location – immutable and separated from your production environment. Using a reliable backup target with immutability features directly addresses the ransomware threat to your recovery capability.

Test your restores quarterly. Non-authoritative restores are straightforward. Authoritative restores – recovering specific deleted objects and having them replicate out to all DCs – are not. Practice before you need it under pressure at 2am.

A Prioritized Hardening Roadmap

I have a strong opinion here: don’t try to fix everything at once. AD hardening done wrong creates outages and destroys trust with the business. Done right, it’s incremental and sustainable.

A realistic sequence:

1. Weeks 1-2: Audit privileged groups and remove unnecessary members. Zero outage risk. Immediate attack surface reduction.
2. Month 1: Enable comprehensive audit logging and route events into a SIEM. You need visibility before you change anything structural.
3. Months 2-3: Implement tiered administration and PAWs for Tier 0 accounts. This is the hardest step culturally – expect pushback.
4. Months 3-6: Migrate service accounts to gMSAs. Audit and document every SPN in the environment.
5. Ongoing: Quarterly privilege audits, backup restoration tests, and AD health checks.

This approach works well for organizations with dedicated security staff. Smaller environments where one person manages everything will find the full tiering model harder to sustain – it assumes dedicated admin accounts that aren’t realistic with two IT staff. Adjust the scope to match your context, but never skip the audit phase. Knowing what you have is the non-negotiable first step.

Active Directory is not going away. Despite Entra ID and hybrid cloud migrations, on-premises AD remains the authentication backbone for most enterprises. APT29’s 2023 campaigns specifically targeted hybrid AD configurations to pivot from cloud back to on-premises environments. Your AD security posture matters regardless of where you are in your cloud journey.

If you need hands-on help hardening your AD environment or want an external assessment of your current configuration, reach out through SSE Technical Insights. Sometimes the clearest view of your AD attack surface comes from someone who hasn’t been staring at it for three years.