5 Active Directory Misconfigurations We See in Every Engagement

Active Directory remains the single most targeted infrastructure component in enterprise breaches. The Verizon 2025 Data Breach Investigation Report found that 88% of breaches now involve compromised credentials, with attackers increasingly leveraging AD authentication flows rather than deploying malware. The IDSA 2024 Trends in Securing Digital Identities Report reported that 91% of organizations experienced an identity-related breach in the past year.

We've conducted hundreds of AD security assessments across Fortune 500 environments, financial services, healthcare, and government agencies. The same five misconfigurations appear in nearly every single one. These aren't exotic zero-days or nation-state techniques — they're configuration defaults and inherited settings that have persisted for years, sometimes decades, in production environments.

The NSA and CISA issued a joint advisory in September 2024 specifically addressing the detection and mitigation of Active Directory compromises. The misconfigurations below align directly with their findings.

1. MachineAccountQuota Left at Default (10)

The ms-DS-MachineAccountQuota attribute ships with a default value of 10. This means any authenticated domain user — no admin privileges required — can create up to ten computer accounts in Active Directory. Most organizations have never changed this setting because they don't know it exists.

Why it matters: those computer accounts become the foundation for attacks like KrbRelayUp, where an attacker creates a machine account, exploits Kerberos relay without LDAP signing, and escalates to SYSTEM on a domain-joined machine. From there, lateral movement is straightforward.

How to fix it

1. Set ms-DS-MachineAccountQuota to 0 across all domains
2. Delegate computer account creation exclusively to authorized service accounts or specific IT staff using Active Directory delegation
3. Audit existing computer accounts created by non-admin users — these may already be attack artifacts

# PowerShell — Check current MachineAccountQuota
Get-ADObject -Identity ((Get-ADDomain).distinguishedname) `
  -Properties ms-DS-MachineAccountQuota | 
  Select-Object ms-DS-MachineAccountQuota

# Set to 0
Set-ADDomain -Identity (Get-ADDomain) `
  -Replace @{"ms-DS-MachineAccountQuota"="0"}

2. Kerberoastable Service Accounts with Weak Passwords

Kerberoasting (MITRE ATT&CK T1558.003) remains one of the most reliable privilege escalation techniques we execute in engagements. Any authenticated domain user can request a Kerberos service ticket for any account with a Service Principal Name (SPN). That ticket is encrypted with the service account's password hash — and can be cracked offline with no failed authentication events, no account lockouts, and no alerts in standard monitoring.

The attack is trivial to execute. Tools like Rubeus, Impacket's GetUserSPNs.py, and Mimikatz make it a single command. The real issue isn't the technique — it's that service accounts in most environments still use passwords that crack in minutes.

In our assessments, we routinely crack service account passwords in under four hours. The record was 47 seconds.

How to fix it

• Migrate to Group Managed Service Accounts (gMSAs) — gMSAs use automatically rotated 240-character passwords that are computationally impossible to crack. This is the definitive fix.
• For accounts that cannot use gMSAs, enforce minimum 25-character passwords and rotate them quarterly
• Audit all SPN assignments quarterly using Get-ADUser -Filter {ServicePrincipalName -ne "$null"}
• Monitor for Event ID 4769 (Kerberos Service Ticket Operations) with RC4 encryption type — a strong indicator of Kerberoasting attempts

3. AS-REP Roastable Accounts

When a user account has "Do not require Kerberos pre-authentication" enabled, the Key Distribution Center returns an AS-REP containing data encrypted with the user's password hash — without verifying who made the request. An unauthenticated attacker can request this material and crack it offline.

This is MITRE ATT&CK T1558.004, and it's worse than Kerberoasting in one critical way: it produces no failed authentication events, no account lockouts, and no visible signs of intrusion in standard monitoring. As Trellix research documented, this attack is exceptionally stealthy.

The setting exists because certain legacy applications from the Windows 2000 era required it. The applications are long gone. The setting persists.

How to fix it

• Enforce Kerberos pre-authentication on all accounts: Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}
• If any legacy system genuinely requires pre-authentication disabled, assign a minimum 30-character unique password and exclude the account from all privileged groups
• Monitor Event ID 4768 with RC4 encryption type (0x17) for multiple accounts in a short timeframe — this pattern indicates AS-REP Roasting

4. Excessive DCSync Permissions

DCSync (MITRE ATT&CK T1003.006) allows an attacker to impersonate a Domain Controller using the MS-DRSR replication protocol. With tools like Mimikatz (lsadump::dcsync) or Impacket's secretsdump.py, the attacker extracts NTLM hashes for every account in the domain — including the KRBTGT account, which enables Golden Ticket attacks — without ever touching the DC itself.

The permissions required are Replicating Directory Changes All and Replicating Directory Changes in Filtered Set. In a properly configured domain, only Domain Controllers and a small number of authorized replication accounts should have these rights.

In practice, we find these permissions granted to Entra Connect synchronization accounts (the MSOL_ accounts), backup service accounts, legacy migration tools, and sometimes individual admin accounts from projects completed years ago. Each one is a DCSync vector.

How to fix it

• Audit replication permissions immediately: enumerate all principals with Replicating Directory Changes All at the domain root
• Remove replication rights from any account that does not require them for current, documented operations
• For Entra Connect accounts, isolate the sync server and treat the MSOL_ account as a Tier 0 asset
• Monitor Event ID 4662 with the specific GUIDs for replication operations: 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 (DS-Replication-Get-Changes-All)
• Alert on any account performing replication that is not a known Domain Controller

# PowerShell — Find accounts with DCSync rights
Import-Module ActiveDirectory
$domainDN = (Get-ADDomain).DistinguishedName
$acl = Get-Acl "AD:\$domainDN"
$acl.Access | Where-Object {
  $_.ObjectType -eq "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2" -or
  $_.ObjectType -eq "89e95b76-444d-4c62-991a-0facbeda640c"
} | Select-Object IdentityReference, ActiveDirectoryRights

5. NTLM Relay Exposure and Missing SMB Signing

NTLM relay attacks remain highly exploitable in environments where SMB signing is not enforced. An attacker positioned on the network — or leveraging tools like Responder to intercept authentication traffic — can capture NTLM challenges and relay them to other services, effectively authenticating as the victim.

The Marks & Spencer breach in 2025 demonstrated the catastrophic potential: attackers exfiltrated the NTDS.dit file (the core AD credential database), cracked administrator passwords, and deployed ransomware after achieving full lateral movement through exactly these types of identity-layer weaknesses.

Microsoft's 2025 guidance is unambiguous: disable NTLM wherever possible. SMB signing and LDAP channel binding became defaults in Windows Server 2025, but every earlier version requires manual configuration — and the majority of production environments still run Server 2016 or 2019.

How to fix it

1. Enforce SMB signing via Group Policy on all domain controllers and member servers: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Microsoft network server: Digitally sign communications (always) → Enabled
2. Enforce LDAP signing and channel binding — set LDAPServerIntegrity to 2 (Require signing) on all DCs
3. Enable Extended Protection for Authentication (EPA) on IIS, Exchange, and ADFS
4. Audit NTLM usage with auditing policies before disabling — identify applications that still depend on NTLM and plan migration to Kerberos
5. Implement Just-In-Time (JIT) access with MFA for all sensitive resources

The Attack Chains These Misconfigurations Enable

These five issues don't exist in isolation. In our engagements, they chain together into complete domain compromise paths:

1. Phishing → Kerberoasting → DCSync → Domain Dominance: Initial access through a phished credential, enumerate SPNs, crack a service account hash, discover the account has replication rights, extract KRBTGT, forge Golden Tickets
2. MachineAccountQuota → KrbRelayUp → Lateral Movement: Standard user creates a computer account, exploits Kerberos relay, escalates to SYSTEM, pivots across the domain
3. Entra Connect Compromise → DCSync → NTDS.dit Extraction: Compromise the MSOL_ sync account (which holds legitimate DCSync permissions), dump the entire domain credential database

Each misconfiguration by itself is a medium-severity finding. Chained together, they consistently produce complete domain compromise in under four hours of testing.

Where to Start

If your organization hasn't conducted an AD security assessment in the past 12 months, assume these misconfigurations exist. They're present in environments with mature security programs, dedicated identity teams, and significant tooling investments — because they're defaults and inherited configurations, not the result of negligence.

Priority order for remediation:

1. This week: Set MachineAccountQuota to 0 and audit DCSync permissions
2. This month: Identify and remediate all Kerberoastable and AS-REP Roastable accounts; begin gMSA migration
3. This quarter: Enforce SMB signing, LDAP channel binding, and develop an NTLM deprecation plan