Active Directory - the most common misconfigurations we find in security audits
Top 10 Active Directory misconfigurations found during penetration tests - from unconstrained Kerberos delegation to missing tiering. Practical guidance on how to check and fix each one.
When we start an internal infrastructure penetration test, Active Directory is always one of the first targets. Not because it is the easiest to compromise, but because even minor configuration mistakes can open a path to full domain takeover. In our experience, more than 9 out of 10 environments contain at least three of the issues described below.
The Microsoft Digital Defense Report 2025 indicates that over 40% of ransomware attacks begin with compromised Active Directory credentials. The good news is that most of these problems can be resolved without replacing infrastructure - configuration changes and proper policies are enough.
1. No administrative tiering model
The tiering model (Tier 0 / Tier 1 / Tier 2) is the foundation of AD security that Microsoft has promoted for years as part of the Enterprise Access Model. In practice, we rarely see it implemented.
The problem: Domain administrator accounts (Tier 0) log on to regular workstations (Tier 2) or application servers (Tier 1). If an attacker compromises such a workstation, they gain tokens or hashes of accounts with the highest privileges.
How to check: In BloodHound, run the query “Find Shortest Paths to Domain Admins.” If you see paths through workstations, tiering is not working.
How to fix:
- Set up dedicated Privileged Access Workstations (PAW) for Tier 0
- Configure GPO blocking Tier 0 account logon to Tier 1 and Tier 2 resources
- Implement Authentication Policies (Windows Server 2012 R2+) or Authentication Policy Silos
TIP
Full tiering deployment is a project that takes months. Start with one step: block Domain Admins from logging on to workstations using GPO “Deny log on locally” and “Deny log on through Remote Desktop Services.”
2. Unconstrained Kerberos Delegation
Unconstrained Delegation is a legacy feature from early Windows versions that allows a server to store and reuse Kerberos TGT tickets of any user who authenticates to it.
Why it matters: An attacker who compromises a server with unconstrained delegation can force domain controller authentication (e.g., through the Printer Bug or PetitPotam) and obtain the DC machine account TGT, leading to full domain compromise.
How to check:
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegationHow to fix:
- Migrate to Constrained Delegation or Resource-Based Constrained Delegation
- Add critical accounts (especially domain controllers) to the “Protected Users” group
- Mark service accounts with the “Account is sensitive and cannot be delegated” flag
3. Stale (unrotated) service account passwords
In many organizations, Active Directory service accounts have passwords set years ago and never changed. These are often simple passwords that can be easily cracked offline after obtaining a Kerberos hash (Kerberoasting attack).
The scale: In our tests, we regularly recover service account passwords within minutes to hours of obtaining a TGS ticket. Passwords like “Service2018!” or “Password1” are not uncommon.
How to check:
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties PasswordLastSet, ServicePrincipalName | Select Name, PasswordLastSetHow to fix:
- Deploy Group Managed Service Accounts (gMSA), which automatically rotate passwords every 30 days
- For accounts that cannot use gMSA, set passwords of at least 25 characters
- Regularly audit accounts with SPNs and monitor TGS ticket requests
4. NTLM protocol still enabled
NTLM is a 30-year-old authentication protocol that Microsoft is officially retiring through a three-phase plan launched in 2025. Phase two (second half of 2026) will introduce IAKerb and Local KDC, eliminating the main reasons for NTLM fallback. Yet in most environments we test, NTLM remains fully active.
Why it matters: NTLM is vulnerable to relay attacks, pass-the-hash, and offline brute force. We cover relay attacks in detail in the article NTLM Relay - why it still works and how to defend.
How to check: Enable NTLM auditing in GPO: “Network security: Restrict NTLM: Audit NTLM authentication in this domain” and analyze EventID 8004 logs.
How to fix:
- Identify applications requiring NTLM and plan migration
- Enforce SMB and LDAP signing
- Gradually restrict NTLM through GPO, starting with audit mode
5. Weak password policy and no Fine-Grained Password Policies (FGPP)
The default AD password policy (minimum 7 characters, complexity enabled) does not provide adequate security in 2026. It is even worse when organizations do not use Fine-Grained Password Policies for privileged accounts.
How to check:
Get-ADDefaultDomainPasswordPolicy
Get-ADFineGrainedPasswordPolicy -Filter *How to fix:
- Set minimum 14 characters for regular accounts, 20+ for privileged accounts
- Deploy FGPP with stricter requirements for administrative groups
- Consider integration with banned password lists (Azure AD Password Protection)
For more on password security, see our article Password security - why 22% of breaches start with stolen credentials.
6. Misconfigured AD Certificate Services (AD CS)
Active Directory Certificate Services is an increasingly exploited attack vector. In 2025, Certipy v5 expanded the catalog of known vulnerabilities to ESC16. The most common issues are ESC1 (certificate templates allowing arbitrary SAN specification) and ESC8 (web enrollment without HTTPS/EPA enforcement).
How to check: Run Certipy or PSPKIAudit in audit mode - the tools automatically identify vulnerable templates.
How to fix:
- Review all certificate templates - disable “Enrollee Supplies Subject” where not essential
- Enforce HTTPS and EPA on web enrollment interfaces
- Restrict certificate enrollment permissions to the minimum necessary
7. Inactive accounts and groups with excessive privileges
User accounts of people who left the organization long ago, test accounts with administrative privileges, multi-level nested groups - these are a permanent fixture in our audit reports.
How to check:
# Inactive accounts for more than 90 days
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly
# Privileged group members
Get-ADGroupMember "Domain Admins" -Recursive | Select NameHow to fix:
- Implement periodic account reviews (at least quarterly)
- Disable accounts after 90 days of inactivity, delete after 180
- Audit privileged group membership - apply the principle of least privilege
8. LDAP and SMB signing not enforced
Default settings on many domain controllers do not enforce LDAP or SMB signing, enabling relay attacks. Windows Server 2025 changes this default behavior, but older versions require manual configuration.
How to fix:
- LDAP Signing: Set “Domain controller: LDAP server signing requirements” to “Require signing”
- SMB Signing: Set “Microsoft network server: Digitally sign communications (always)” to Enabled
- LDAP Channel Binding: Set “Domain controller: LDAP server channel binding token requirements” to “Always”
9. GPO with excessive permissions
Group Policy Objects with misconfigured permissions are an often-overlooked attack vector. If a regular user or service account has permissions to modify a GPO linked to the OU containing domain controllers, they can inject a malicious script that runs with SYSTEM privileges.
How to check: In BloodHound, search for “WriteDACL” and “WriteProperty” paths leading to GPO objects.
How to fix:
- Regularly audit GPO permissions
- Restrict GPO management delegation to dedicated administrative accounts
- Monitor GPO changes through advanced auditing (EventID 5136)
10. No monitoring and alerting
Even the best configuration will not help if the organization does not monitor AD security events. Too often, we encounter environments where audit logs are disabled or nobody analyzes them.
Key events to monitor:
| EventID | Description | Significance |
|---|---|---|
| 4768 | TGT ticket request | Detecting AS-REP Roasting |
| 4769 | TGS ticket request | Detecting Kerberoasting |
| 4771 | Failed Kerberos authentication | Brute force attacks |
| 4724/4726 | Password reset / account deletion | Administrative actions |
| 5136 | AD object change | GPO, schema modifications |
| 4672 | Special privilege assignment | Privilege escalation |
WARNING
Collecting logs alone is not enough. Without event correlation and automated alerts, audit logs are merely an archive - useful after the fact, but useless in real time. Consider deploying Microsoft Defender for Identity or a SIEM solution with dedicated AD rules.
Checklist: Minimum Active Directory hygiene
- Tiering model implemented - Tier 0 accounts do not log on to workstations
- Unconstrained Delegation disabled on all servers except DC
- Service accounts use gMSA or have 25+ character passwords with rotation
- NTLM in audit mode, migration plan to Kerberos in progress
- Fine-Grained Password Policy for privileged accounts (20+ characters)
- AD CS templates audited, ESC1-ESC8 eliminated
- Inactive account review once per quarter
- LDAP Signing and Channel Binding enforced
- GPO permissions audited
- Advanced event auditing enabled, alerts configured
Regulatory context: NIS2
The NIS2 Directive requires essential and important entities to implement risk management measures covering the security of network and information systems. Active Directory, as the central authentication and authorization system, is a critical element of this infrastructure. Failure to properly secure AD may be treated as a breach of the obligation to apply appropriate and proportionate risk management measures.
Summary
The misconfigurations described here do not require advanced tools to fix. They require a systematic approach, knowledge of current attack vectors, and consistency in implementing changes. At SEQRED, we help organizations through the entire process - from identifying issues during penetration tests, through prioritization, to remediation support.
If you want to assess the security posture of your Active Directory, we invite you to get in touch. We start with a free scoping call where we evaluate the environment size and tailor the test scope to actual needs.
Sources:
Need help in this area?
Our experts will help you assess the risk and plan next steps.