Active Directory (AD) attacks rarely start with “zero-days.” In most incidents, attackers win by chaining ordinary configuration mistakes: over-permissive delegation, weak credential hygiene, stale legacy protocols, and brittle Group Policy controls. This article focuses on what defenders need: the misconfigurations that show up repeatedly in real environments, why they’re exploited, how to spot them early, and how to fix them without breaking production.
How attackers think about AD misconfigurations
Most AD compromises follow a predictable sequence: gain a foothold, expand local privileges, pivot laterally, then escalate to domain-level control (or to a “near-equivalent” control plane like AD CS or GPO). What makes this possible is not one “fatal” setting, but a path composed of small weaknesses.
Two defender-friendly mental models:
- Paths, not points: fix the links that connect low privilege → high privilege.
- Rights, not roles: group names matter less than the effective permissions they hold.
If you want a deeper “permissions-first” view, review how safe delegation should look in practice: How to delegate OU permissions with minimal risk.
1) Over-permissive OU delegation and “helpdesk admin by accident”
A classic AD failure mode: delegation that was intended to be narrow (reset passwords, manage a subset of computers) becomes broad (write properties on users/groups, modify ACLs, create objects). Over time, it becomes impossible to explain who can do what—and attackers love that.
Why it gets exploited
- Attackers look for delegated rights that allow them to change group membership or reset credentials.
- Mis-scoped permissions can enable privilege escalation without triggering obvious “Domain Admin added” alerts.
How to spot it
- Review OU ACLs for broad rights like
GenericAll,GenericWrite,WriteDacl,WriteOwner. - Look for delegation done to individual users instead of tightly controlled groups.
- Audit changes to group membership and delegated permissions as a routine, not a one-off.
How to fix it
- Replace user-based delegation with role groups (e.g., “Helpdesk-Password-Reset-Only”).
- Use least-privilege delegation patterns and document intent for each delegated ACE.
- Re-check inheritance and deny/allow interactions—especially on sensitive OUs (Admins, Servers, DCs).
Practical guidance and a safer pattern library: Delegating OU permissions with minimal risk.
2) Excessive GPO permissions and GPO delegation drift
Group Policy is a powerful control plane. If someone can edit a GPO linked to servers or privileged systems, they can often achieve code execution at scale—without needing direct admin credentials on every machine.
Why it gets exploited
- Over time, “temporary” GPO access becomes permanent.
- GPO rights are frequently granted broadly (or inherited) and rarely reviewed.
High-risk signs
- Non-admin teams have
Edit settingsorEdit, delete, modify securityon high-impact GPOs. - GPOs linked to Domain Controllers OU or Tier-0 assets have non-Tier-0 editors.
- GPO ownership is unclear (or owned by a personal account).
How to fix it
- Restrict GPO creation and editing to dedicated admin groups with change control.
- Separate “linking rights” from “editing rights” where possible.
- Review GPO delegation quarterly; diff changes weekly.
For a refresher on how GPO permissions and delegation actually work in AD, see: GPO Delegation in AD.
3) Kerberos delegation misconfigurations (unconstrained, constrained, RBCD)
Delegation is legitimate functionality—but it is also a frequent escalation path when misconfigured. The short version: if a host/service can impersonate users to other services too broadly, a compromise of that host/service can become a compromise of many identities.
Common risky patterns
- Unconstrained delegation on servers that are reachable from user workstations.
- Constrained delegation configured too broadly (too many allowed services/targets).
- Resource-based constrained delegation (RBCD) granted to accounts that are easy to compromise.
How to spot it
- Inventory all accounts/computers trusted for delegation and classify by tier (Tier-0, Tier-1, Tier-2).
- Alert on new delegation enablement (treat it as a security change, not an “IT normal”).
- Review the “blast radius”: which users can authenticate to those delegated systems?
How to fix it
- Eliminate unconstrained delegation wherever feasible; prefer constrained or RBCD with strict scoping.
- Harden and isolate any remaining delegated systems (admin-only access, PAWs, tiering).
- Use dedicated service accounts; avoid shared credentials and interactive logon.
If you need a quick orientation on where these delegation settings live, start here: Active Directory Computer Delegation tab.
4) Weak service account posture (SPNs, stale passwords, over-privileged services)
Service accounts are often “quietly dangerous”: they run critical workloads, persist for years, and accumulate permissions. Common mistakes include weak password policies, lack of rotation, interactive logon enabled, and membership in powerful groups “because it fixed the app.”
Why it gets exploited
- Service identities can become high-value stepping stones to servers and databases.
- When service accounts have too many rights, compromise is immediately useful.
How to fix it
- Use gMSA where possible to reduce password management risk.
- Strip group memberships and rights back to the minimum the service requires.
- Block interactive logon for service accounts; enforce strong rotation for legacy accounts.
5) Legacy authentication still enabled (NTLM sprawl, weak Kerberos settings)
Legacy protocol dependency is one of the most stubborn AD risks. NTLM isn’t automatically “evil,” but broad NTLM usage increases attack surface (especially when paired with lax workstation/server hygiene). Likewise, weak Kerberos crypto choices and outdated domain functional levels can keep doors open longer than you think.
How to spot it
- Measure NTLM usage (where and why), then reduce it systematically.
- Identify systems that require legacy protocols and plan remediation or isolation.
- Enforce stronger crypto where compatible and ensure time synchronization is reliable.
If your team needs a clear refresher on the moving parts, see: NTLM and Kerberos Authentication Protocols Explained.
6) Nested group sprawl and “invisible privilege”
Groups inside groups inside groups—eventually nobody knows who is effectively privileged. Attackers do. They enumerate group relationships and target the weakest link that inherits high privilege transitively.
What makes it risky
- Privilege becomes non-obvious (especially across OUs and delegated admin models).
- Over time, “temporary access” becomes permanent via nesting.
- Reviews focus on direct members, missing transitive membership entirely.
How to fix it
- Define and protect Tier-0 groups (Domain Admins, Enterprise Admins, key operator groups, etc.).
- Reduce nested groups for privileged roles; prefer explicit, documented membership.
- Run recurring transitive membership reviews and require approvals for changes.
A practical runbook (native auditing + queries) is here: Auditing Nested Group Memberships: An Expert Guide.
7) Trust misconfigurations (overly broad trusts, weak trust hardening, SID-related issues)
Trusts are necessary in many enterprises, but they extend identity boundaries. Misconfigured trust settings, weak monitoring, and legacy compatibility requirements can make cross-domain escalation significantly easier.
Common problems
- Trusts created “for convenience” without tight scope or clear ownership.
- Insufficient auditing of trust attribute changes.
- SID-related configurations that increase risk during migrations and complex forest topologies.
How to fix it
- Inventory all trusts and document business justification, owners, and security requirements.
- Harden trusts (and monitor changes) as you would any Tier-0 control plane.
- Review SID-related migration decisions and implement safe constraints for complex layouts.
For deeper guidance on SID-related risks and hardening: SID filtering in complex AD layouts: expert guide & runbook.
8) AD CS (Certificate Services) misconfigurations that quietly become “domain takeover paths”
AD CS is widely deployed and often under-reviewed. Certain combinations of template permissions, enrollment rules, and subject name settings can allow unintended certificate issuance that effectively grants elevated authentication capability. In many environments, this becomes a stealthy alternative to “classic” domain admin escalation.
Defender approach
- Inventory certificate authorities, templates, and who can enroll.
- Review template settings for risky combinations (subject/alt-name controls, client auth EKUs, overly broad enrollment).
- Restrict who can manage CA and templates; treat these as Tier-0 assets.
9) LAPS/gLAPS gaps and local admin reuse
If local administrator passwords are reused across endpoints or servers, attackers who compromise one machine can often pivot broadly. The fix is straightforward in concept: ensure unique, managed local admin passwords and restrict local admin membership.
How to fix it
- Deploy Microsoft LAPS / Windows LAPS (depending on your environment) with strong policies.
- Reduce local admin membership; enforce tiering (admins don’t log on to lower-trust machines).
- Monitor local admin group membership changes and local account usage.
10) “Password never expires”, weak lockout strategy, and stale privileged accounts
Credential hygiene is still a top contributor to compromise. A few recurring offenders:
- Users or service accounts set to Password never expires without compensating controls.
- Overly permissive password policies for privileged identities.
- Weak lockout strategy and missing monitoring for password spraying indicators.
- Stale privileged accounts left enabled long after job role changes.
How to fix it
- Create separate policies for privileged identities and enforce higher standards.
- Rotate/modernize service identities (gMSA where possible).
- Implement strong monitoring and rapid response for anomalous authentication patterns.
11) Insufficient auditing and “no one is watching the right events”
Many organizations have logs—but not the ones that matter, not centralized, or not retained long enough to investigate. The goal isn’t “log everything.” It’s “log the control-plane changes and the escalation signals.”
Minimum viable auditing goals
- Capture identity changes (group membership changes, privilege assignments, delegation changes).
- Capture policy control-plane changes (GPO edits, links, security filtering changes).
- Centralize logs, ensure time sync, and retain long enough to cover detection + investigation windows.
A practical audit checklist (start here)
If you want a focused starting point, this sequence finds “high leverage” fixes quickly:
- Tier-0 inventory: identify DCs, PKI/AD CS, identity management servers, and privileged admin workstations.
- Privileged group review: flatten and review transitive memberships; remove unknown/legacy nests.
- Delegation sweep: find unconstrained delegation; validate constrained/RBCD scope and tier alignment.
- GPO rights review: who can edit high-impact GPOs? who can link them? who owns them?
- OU and object ACL review: find broad rights (WriteDACL/WriteOwner/GenericAll) outside admin groups.
- Protocol reduction: measure NTLM usage, reduce it, and tighten authentication policies.
- Local admin controls: ensure unique local admin passwords + reduce local admin membership.
- Logging + alerts: forward critical events and alert on control-plane changes.
Quick-win remediation patterns that don’t break everything
- Move from people → groups: delegate permissions only to role groups with owners and reviews.
- Tiering: enforce admin tier boundaries (who can log on where, and from what devices).
- Change control for control planes: GPO, CA/templates, trusts, DC configs require approvals and alerts.
- Make drift visible: export/diff high-risk settings weekly and alert on changes.