When teams ask what are the most common Active Directory security misconfigurations, the useful answer is not a frequency table. It is the set of control failures that keep appearing in Microsoft hardening guidance, ANSSI recommendations, and recurring enterprise AD reviews because they still create real privilege escalation paths, credential exposure, or visibility gaps.
This article is the misconfiguration view of Active Directory security. It is not a full audit checklist like How to Audit Active Directory Security, and it is not a rollout order guide like Hardening Active Directory: What to Lock Down First and How to Validate It. The goal here is narrower: identify the AD security misconfigurations that still matter most, explain why they matter, and show what to validate before and after you change them.
What Counts as an Active Directory Security Misconfiguration?
An Active Directory security misconfiguration is not just any setting that differs from a benchmark. In practice, it is a control weakness that leaves authentication, privilege, directory replication, administrative access, or policy management broader than it needs to be for the environment.
That is why the same families of problems keep resurfacing: too many privileged accounts, weak administrative separation, replication rights assigned too broadly, unsigned directory traffic, reusable local admin secrets, service accounts with static passwords, unsafe delegation settings, and overly permissive Group Policy control. They are configuration problems, but they become attack-path problems when they stay in production.
What Are the Most Common Active Directory Security Misconfigurations?
ℹ️ Note: This list is not a market-wide statistical ranking. It is a practical Top 10 of the misconfiguration families that repeatedly matter in Microsoft and ANSSI guidance and that still create material AD exposure in real environments.
| Misconfiguration | Primary exposure | Deep dive |
|---|---|---|
| Too many privileged accounts | Admin sprawl and larger blast radius | Hardening Active Directory |
| No separated admin paths | Credential theft and admin session reuse | How to Audit Active Directory Security |
| Broad replication rights | DCSync-capable identities outside the intended scope | How to Audit Active Directory Security |
| LDAP signing not enforced | Unsigned binds and weaker directory traffic controls | LDAP Signing Disabled |
| SMB signing not required | NTLM relay and tampering exposure | SMB Signing Disabled |
| Windows LAPS not deployed | Reused local admin passwords across endpoints | Windows LAPS Not Deployed |
| Weak password controls | Predictable or long-lived credentials | Active Directory Password Security |
| Static-password service accounts | Hard-to-rotate secrets and service account credential risk | Active Directory Password Security |
| Unsecure Kerberos delegation | Broader impersonation paths than intended | Active Directory Attack Paths |
| Dangerous GPO permissions | Policy takeover and indirect control of privileged systems | GPO Misconfigurations |
1. Too Many Privileged Accounts and Sensitive Group Memberships
This is the most basic AD misconfiguration family: too many users, service accounts, or break-glass style identities have standing membership in highly sensitive groups or equivalent delegated rights. Microsoft and ANSSI both push the same principle here: minimize privileged standing access and keep administrative scope explicit.
The risk is straightforward. Every extra privileged account increases credential exposure, interactive sign-in surface, delegation risk, and recovery scope when one identity is compromised. In practice, the problem is usually not a single Domain Admin account. It is the slow accumulation of old admin users, support accounts, emergency accounts that became permanent, and nested group paths that nobody prunes.
Validate before changing it: enumerate privileged groups, nested membership, delegated rights on Tier 0 assets, and actual administrative use cases. Removing access without checking ownership and operational dependency creates outages.
Keep as proof after rollout: an exported privileged group inventory, change records for removals, and a reviewed list of the identities that still require standing privilege.
2. No Separated Administrative Paths or Secure Admin Hosts
Many AD environments still let the same identity administer servers, browse email, open documents, and sign in to lower-trust workstations. Microsoft's secure administrative host guidance exists because privileged access is not only about group membership. It is also about where administrative credentials are exposed.
If privileged users administer from general-purpose endpoints, admin credentials and tokens are more likely to be captured, replayed, or reused along lateral movement paths. This is why dedicated admin workstations, separate admin accounts, and a clean administrative path matter even when group membership already looks reasonable.
Validate before changing it: identify which admins use separate accounts, which systems are used for administration, and which workflows still depend on mixed-use endpoints. Some teams discover they have role separation on paper but not in daily operations.
Keep as proof after rollout: host inventory for secure admin workstations or equivalent privileged endpoints, sign-in restrictions or admin host assignments, and evidence that sensitive administration no longer takes place from unmanaged or general-use systems.
3. Replication Rights Granted Too Broadly
DCSync is not only an offensive technique label. Operationally, it is a permissions problem: identities that do not need directory replication rights have them anyway. Microsoft Defender for Identity exposes this through the assessment on non-admin accounts with DCSync permissions because the underlying issue is so high impact.
When Replicating Directory Changes, Replicating Directory Changes All, or related replication rights are granted too broadly, an identity can request highly sensitive directory data that should remain tightly controlled. The right remediation mindset is not “block DCSync.” It is “reduce replication-capable principals to the minimal intended set.”
Validate before changing it: review ACLs on the domain root and other relevant directory objects, identify who currently holds replication rights, and confirm whether each holder is truly required for backup, sync, or security tooling.
Keep as proof after rollout: an ACL review snapshot, the final approved list of replication-capable identities, and a record showing removed principals no longer retain those rights.
4. LDAP Signing and Channel Binding Not Properly Enforced
Unsigned LDAP is still one of the clearest examples of an AD control that looks old but remains operationally relevant. Microsoft guidance on LDAP signing for AD DS exists because unsigned SASL binds and simple binds can weaken the integrity of directory traffic, and compatibility concerns often leave environments stuck in partial deployment.
The misconfiguration is rarely a single registry value. More often, it is inconsistent enforcement across domain controllers, applications that still depend on weaker bind behavior, or incomplete validation of whether clients will break when signing requirements rise.
Validate before changing it: inventory LDAP clients, identify unsigned bind use, confirm whether LDAPS, signing, or channel-binding related requirements will affect legacy apps, and stage the change before enforcement.
Keep as proof after rollout: domain controller policy settings, test results for critical apps, and telemetry showing that expected clients are using compliant bind behavior.
For the full mechanism and validation caveats, use LDAP Signing Disabled: How Unsigned Binds Expose Active Directory.
5. SMB Signing Not Required Where It Still Matters
SMB signing is another control where teams know the recommendation but delay enforcement because of performance assumptions, compatibility fears, or inherited workstation and server baselines. Microsoft guidance has become stronger here because unsigned SMB still leaves room for tampering and supports NTLM relay conditions in environments that have not reduced legacy trust paths.
The misconfiguration is not “SMB exists.” It is that integrity is not required where it should be, especially on systems that still accept sensitive authentication flows or that sit on administrative paths.
Validate before changing it: identify legacy devices, embedded systems, older servers, or application paths that still rely on weaker SMB behavior. Check current signing policy on clients and servers instead of assuming one side enforces it consistently.
Keep as proof after rollout: effective SMB signing policy state, exception register for systems that cannot yet comply, and validation results showing sensitive systems now require signing.
For the protocol-specific attack surface, see SMB Signing Disabled: Why It Still Enables NTLM Relay.
6. Windows LAPS Not Deployed
A large number of AD environments still rotate domain credentials more carefully than local administrator passwords. That leaves one of the oldest Windows exposure patterns in place: reused or static local admin secrets across endpoints and, in some environments, weak handling of DSRM passwords on domain controllers.
Microsoft's Windows LAPS guidance matters because this is not only a workstation hygiene issue. Reusable local admin passwords support lateral movement, make password disclosure events harder to contain, and weaken the value of other hardening measures.
Validate before changing it: identify which endpoints already use Windows LAPS, whether legacy LAPS and Windows LAPS overlap, how password retrieval is delegated, and whether DSRM management is in scope for domain controllers.
Keep as proof after rollout: policy deployment state, managed endpoint coverage, authorized password readers, and sample verification that passwords rotate and are retrievable only by approved roles.
The deployment and validation details are covered in Windows LAPS Not Deployed: Why Shared Local Admin Passwords Still Matter.
7. Weak Password Policies and Privileged Password Exceptions
Weak password policy is still common, but the real operational problem is broader than one domain-wide setting. It usually includes weak minimums, lack of targeted fine-grained password policies, long-lived privileged passwords, and exceptions that quietly leave critical accounts outside the intended baseline.
Microsoft's guidance on fine-grained password policies exists because high-value accounts do not always fit a one-policy model. At the same time, ANSSI emphasizes that privileged accounts and administrative uses need stricter handling than general users.
Validate before changing it: review the effective default domain password policy, any fine-grained password policies, privileged accounts with exception flags, Password never expires usage, and service accounts that are still treated like human users.
Keep as proof after rollout: effective policy export, mapping of which users or groups receive stricter policies, and review artifacts for any remaining exceptions.
For adjacent credential issues, see Active Directory Password Security: Misconfigurations That Matter.
8. Legacy Service Accounts with Static Passwords Instead of gMSA Where Possible
Static-password service accounts are common because they survive migrations, support older apps, and are rarely owned end to end. Microsoft promotes gMSA because it reduces the operational burden of password management for supported workloads, but many environments still keep privileged or SPN-bearing service accounts on manually managed, long-lived passwords.
The risk is not only password age. Static-password service accounts are often overprivileged, hard to inventory, exempt from normal lifecycle review, and difficult to rotate safely. Where SPNs are present, long-lived service account credentials also increase the value of offline ticket-cracking opportunities, which is why this issue overlaps with Kerberoasting exposure.
Validate before changing it: identify service accounts, ownership, SPN usage, privilege level, password rotation process, and application compatibility with gMSA. Not every service can move immediately, so scope the highest-risk accounts first.
Keep as proof after rollout: service account inventory, documented owners, migration decisions for gMSA candidates, and evidence of password rotation or conversion for the accounts left on static credentials.
9. Unsecure Kerberos Delegation
Kerberos delegation becomes a misconfiguration when it is broader than the service design actually requires. Microsoft Defender for Identity highlights unsecure delegation because unconstrained or otherwise unsafe delegation settings expand impersonation paths and can materially change how far a compromise can spread.
This is a good example of why “common misconfiguration” does not mean “simple fix.” Delegation is often application-driven. Removing or converting it without validating service behavior can break production authentication flows.
Validate before changing it: inventory unconstrained delegation, constrained delegation, and resource-based delegation where relevant; identify application owners; and confirm which systems still require delegation at all.
Keep as proof after rollout: reviewed delegation inventory, removed or converted delegation settings, and application test evidence showing the required flows still work after tightening.
For the broader chain effect, link this issue back to Active Directory Attack Paths to Domain Admin.
10. Dangerous GPO Permissions and Weak GPO Change Control
Group Policy becomes a security misconfiguration when low-trust or broadly scoped identities can modify high-impact GPOs, link dangerous settings, or change policy paths that affect privileged systems. Microsoft and ANSSI both treat GPO administration as a control-plane issue, not just a desktop management issue.
The impact is larger than a bad policy value. Dangerous GPO permissions can let an attacker or overprivileged operator push code execution, weaken host security, change local group membership, or alter the posture of systems that sit on administrative paths.
Validate before changing it: review who can edit, link, or create GPOs; which GPOs apply to privileged systems; and whether change control distinguishes high-impact GPOs from routine desktop policy changes.
Keep as proof after rollout: GPO permission review outputs, restricted editor lists, approval records for high-impact policies, and monitoring coverage for GPO change events.
For the direct path analysis, see GPO Misconfigurations: How Group Policy Becomes an Attack Vector.
⚠️ If AD CS is deployed: certificate template, enrollment, and CA configuration weaknesses belong in the same first-tier review even though they are not part of this Top 10 list. Use ADCS Attack Paths Explained as the dedicated deep dive.
Why These Misconfigurations Persist
These issues persist because they sit at the intersection of compatibility, ownership, and accumulated exceptions. LDAP and SMB hardening can affect older applications. Service accounts often outlive the teams that created them. Delegation settings are kept because nobody wants to break authentication. GPO permissions drift because policy administration is spread across teams. Privileged accounts remain because removing them requires operational evidence, not just a security opinion.
That is also why annual reviews are not enough. If you only check these controls once a year, privileged sprawl, service account drift, and policy exceptions can return faster than the review cycle catches them. A recurring process matters as much as the first cleanup. See Recurring AD Audit Workflow: Why Annual Audits Drift and How Continuous Posture Monitoring Works.
How to Validate Them Without Guesswork
A good fix is not only a changed setting. It is a changed setting plus proof that the control is now enforced and that required workflows still function.
| Control family | Validate before enforcement | Keep as proof after rollout |
|---|---|---|
| Privileged access | Group membership, delegated rights, admin workflows | Reviewed privileged inventory and approved standing access |
| LDAP and SMB hardening | Client compatibility, legacy systems, staged tests | Effective policy state and successful application validation |
| LAPS and password controls | Coverage, readers, exceptions, account classes | Policy export, managed coverage, exception register |
| Service accounts and delegation | Owners, SPNs, privilege scope, app dependencies | Updated inventory, migration decisions, tested service paths |
| GPO and control-plane changes | Editor lists, linked scope, high-impact policy owners | Permission review, approval trail, change monitoring |
This is where logging and change visibility matter. If you are changing core AD security controls, you should also know whether your current audit policy and collection model let you see group changes, directory ACL changes, GPO changes, and other high-value control-plane events. Use Active Directory Monitoring: Security Event IDs That Matter if your logging baseline is still weak.
How EtcSec Helps Prioritize AD Misconfigurations
EtcSec is most useful here when the goal is not a one-time checklist, but a repeatable view of which AD misconfigurations still create the most meaningful exposure. Findings such as EXCESSIVE_PRIVILEGED_ACCOUNTS, DCSYNC_CAPABLE, LDAP_SIGNING_DISABLED, SMB_SIGNING_DISABLED, LAPS_NOT_DEPLOYED, PASSWORD_POLICY_WEAK, KERBEROASTING_RISK, UNCONSTRAINED_DELEGATION, and GPO_DANGEROUS_PERMISSIONS help turn this list into an auditable remediation queue.
The important part is repeatability. After you tighten a control, you need to remeasure whether the exposure is actually gone and whether drift reintroduced it later. That is the difference between reading a hardening guide once and maintaining an AD security posture over time.
Primary References
- Best practices for securing Active Directory
- Implementing Secure Administrative Hosts
- Privileged access strategy
- Security assessment: Remove non-admin accounts with DCSync permissions
- LDAP signing for Active Directory Domain Services
- Control SMB signing behavior
- Windows LAPS overview
- Group Managed Service Accounts overview
- Configure fine-grained password policies for AD DS
- Protected Users security group
- Authentication Policies and Authentication Policy Silos
- Security assessment: Unsecure Kerberos delegation
- Group Policy overview
- Configure Windows Event Forwarding
- Active Directory Certificate Services overview
- ANSSI Active Directory guide
