Common Active Directory Security Issues

What is Active Directory security?

Active Directory security is the practice of hardening the Windows directory service that authenticates users, computers and services across a network. It covers account hygiene, password policy, privileged group membership, authentication protocols, delegation settings and domain controller hardening, because a single weak setting in any of them can expose the entire domain.

Almost every technique used against Active Directory is publicly catalogued. The MITRE ATT&CK knowledge base assigns each one an identifier, which lets a finding be named precisely instead of vaguely: Kerberoasting is T1558.003, AS-REP roasting is T1558.004, credential dumping from LSASS memory is T1003.001, and directory replication abuse, commonly called DCSync, is T1003.006. This guide uses those identifiers where they apply.

Defensive baselines cover the same ground from the other direction. NIST SP 800-53 sets out access control and identification requirements at the programme level, and the Australian Signals Directorate's Essential Eight makes restricting administrative privileges one of its eight mitigation strategies.

Why Active Directory matters to an attacker

Active Directory centralises authentication and authorisation for users, computers, groups and services across a Windows-based environment. Because so much trust flows through it, a single weakly configured account, group membership or protocol setting can be the difference between a contained incident and a full domain compromise.

Attackers who gain any authenticated foothold, for example by phishing a single low-privilege user, typically spend very little time before mapping the trust relationships inside Active Directory. That map tells them exactly which weak links to pull to reach the accounts that matter. Proving whether that chain actually exists, rather than assuming it does, is the point of attack path validation.

It is worth being precise about what makes this different from host-level security work. Patching a server removes one vulnerability from one machine. A misconfigured delegation setting or an over-broad group membership is not a vulnerability in any single host at all: it is a property of the directory, and it keeps working exactly as designed while an attacker uses it.

The most common Active Directory security issues

The ten issues below turn up in one form or another in most Active Directory environments that have not been deliberately hardened and reviewed on a schedule. None of them are exotic. That is exactly why they are common, and why they remain reliable starting points for attackers.

1. Stale and orphaned accounts

Accounts belonging to former staff, decommissioned services or old contractors often outlive the need for them. A stale account is dangerous precisely because nobody is watching it: it still authenticates, it may still hold group memberships from a previous role, and activity on it is unlikely to be noticed quickly.

Inactive accounts can be listed directly from the directory. As an indicative example, the Active Directory PowerShell module reports user accounts unused for ninety days with: Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly. Swapping -UsersOnly for -ComputersOnly covers the machine accounts that reviews usually forget.

• Review and disable accounts unused past a defined threshold.
• Tie account creation and disablement to onboarding and offboarding.
• Audit stale computer accounts, not only user accounts.

2. Weak or inconsistent password policy

Many domains still run a default password policy with a short minimum length and no meaningful complexity or lockout enforcement, or apply a strong policy to standard users while leaving service and privileged accounts on a weaker, older fine-grained policy that predates the current standard.

Current guidance has moved away from forced rotation and character-composition rules. NIST SP 800-63B instead recommends longer minimum lengths, screening candidate passwords against lists of known-compromised values, and not requiring arbitrary periodic changes, which tend to produce predictable variations rather than stronger secrets.

• Enforce a strong minimum length and favour passphrases over complexity.
• Screen new passwords against known-compromised password lists.
• Apply account lockout thresholds consistently across the domain.
• Apply the strictest fine-grained policy to privileged and service accounts.

3. Over-privileged group membership

Privileged groups such as Domain Admins and Enterprise Admins tend to grow over time through convenience, not design: a service account added for a one-off task, a helpdesk account nested into an admin group to avoid a second request, and neither is ever removed.

Nesting is what makes this hard to audit by eye. A group three levels below Domain Admins confers the same rights as direct membership, so any review has to expand nested membership rather than read the top-level list. Get-ADGroupMember -Identity 'Domain Admins' -Recursive returns the effective set.

• Review privileged group membership on a fixed schedule, expanding nested groups.
• Avoid nesting standard user or service accounts into admin groups.
• Apply a tiered administration model instead of one flat admin tier.

4. Legacy authentication protocols left enabled

Legacy name resolution and authentication protocols are frequently left enabled by default even after Kerberos is available for everything that actually needs it. These protocols create opportunities for credential relay and interception that Kerberos alone does not expose.

This is catalogued as Name Resolution Poisoning and SMB Relay, T1557.001. An attacker on the same broadcast domain answers LLMNR, NBT-NS or mDNS lookups that DNS failed to resolve, collects the authentication attempt that follows, and either cracks it offline or relays it to another host. SMB signing, enforced across the fleet, breaks the relay half of that chain.

• Disable LLMNR and NBT-NS where they are not genuinely required.
• Enforce SMB signing so intercepted authentication cannot be relayed.
• Restrict or disable NTLM in favour of Kerberos wherever possible.
• Monitor for legacy protocol use as a signal, not just a config setting.

5. Kerberoastable service accounts

Any account with a Service Principal Name registered against it can have a Kerberos service ticket requested by any authenticated user, and that ticket can later be attacked offline without further contact with the domain. If the account's password is weak, this is a quiet, low-noise path from a normal domain user straight to a privileged service account.

This is Kerberoasting, T1558.003. Its close relative, AS-REP roasting, T1558.004, needs even less: any account with Kerberos pre-authentication disabled will hand out crackable material to an unauthenticated request. Both are worth auditing together.

Accounts carrying an SPN can be listed with Get-ADUser -Filter {ServicePrincipalName -like '*'} -Properties ServicePrincipalName, and accounts with pre-authentication disabled with Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}. Group managed service accounts remove the problem outright, since their passwords are long, random and rotated by the directory itself.

• Use group managed service accounts instead of ordinary user accounts for services.
• Where that is not possible, set a long random password on every SPN account.
• Avoid granting privileged accounts a Service Principal Name at all.
• Keep Kerberos pre-authentication enabled on every account.
• Monitor for unusual volumes of service ticket requests.

6. Unconstrained or unnecessary delegation

Delegation allows a computer or service account to act on behalf of another account. Unconstrained delegation configured on a compromised host can let an attacker capture credentials for anyone who authenticates to it, including highly privileged accounts, turning one compromised server into a much larger problem.

Because the ticket is cached on the delegating host, the attacker does not need to break anything: they wait. Get-ADComputer -Filter {TrustedForDelegation -eq $true} lists the machines configured this way, and on most estates the result should be domain controllers and very little else.

• Replace unconstrained delegation with constrained or resource-based delegation.
• Audit which accounts and computers hold delegation rights.
• Mark highly privileged accounts as sensitive and not delegatable.
• Avoid delegation on internet-facing or user-facing hosts entirely.

7. Unpatched or exposed domain controllers

Domain controllers hold the keys to the entire environment. An unpatched domain controller, or one with management interfaces reachable from outside its intended network segment, is one of the highest-impact targets available and does not need a complex attack chain to matter if it is compromised directly.

The endgame here is usually DCSync, T1003.006, in which an account holding directory replication rights asks a domain controller to replicate password data to it. No malware runs on the controller and no exploit is needed, so the defence is to treat replication rights as a privileged assignment and audit who holds them.

• Patch domain controllers promptly on a defined, tested cadence.
• Audit which principals hold directory replication rights.
• Never expose domain controller management interfaces to the internet.
• Isolate domain controllers on a restricted management network segment.

8. Local administrator password reuse

An identical local administrator password shared across many workstations means compromising a single machine reveals a credential that unlocks every other machine using the same password, turning one low-value endpoint into a springboard for lateral movement across the whole fleet.

The credential does not even need to be cracked. Pass the Hash, T1550.002, authenticates with the stored hash directly, so a long password is no defence against reuse; only uniqueness is. Windows LAPS, the Local Administrator Password Solution, is the standard mitigation: it sets a distinct random password on every machine, stores it in the directory under access control, and rotates it automatically after each use.

• Deploy Windows LAPS so every machine has a unique, rotated local administrator password.
• Restrict who can read LAPS passwords out of the directory.
• Block local accounts from authenticating across the network.
• Avoid reusing service account passwords across multiple systems.

9. Excessive Group Policy rights and leftover credential material

Group Policy Objects apply settings to every user and computer in their scope, which makes overly broad edit or link rights on a GPO a way to affect many machines at once. Older scripts or preference items left behind in the policy store, written before organisations knew better, can also still contain credential material.

The specific legacy case is Group Policy Preferences, T1552.006. Passwords set through preference items were stored in the policy store encrypted with a key that was published, which makes them readable by any domain user who can reach SYSVOL. Removing the setting from the console does not always remove the file, so the policy store needs checking directly.

• Restrict who can edit or link Group Policy Objects.
• Search SYSVOL for leftover preference files containing a cpassword value.
• Audit the policy store for old logon scripts holding secrets.
• Review Group Policy preference items specifically for stored credentials.

10. No tiered administration model

Without separating administrative tiers, workstation support, server administration and domain administration, IT staff routinely log into lower-trust systems using high-privilege credentials. Anything already running on that lower-trust host then has a chance to harvest a credential far more powerful than the host itself warranted.

Harvesting it is a solved problem for an attacker with local administrator rights: LSASS memory dumping, T1003.001, reads credential material straight out of the process that caches it. Tiering is the structural fix, because it means a domain administrator credential is never present on a machine an attacker is likely to reach first.

• Adopt a tiered administration model that separates privilege by tier.
• Use dedicated privileged access workstations for domain admin activity.
• Enable protections that restrict access to credential material in memory.
• Never authenticate with domain admin credentials on a standard end-user host.

At a glance

A short summary of each issue, the technique that exploits it where one is catalogued, and what good looks like.

From one weak credential to full domain compromise

None of the ten issues above is catastrophic entirely on its own. What makes Active Directory attacks so effective is that these weaknesses chain together. A realistic path looks something like this: a service account with a Service Principal Name has a weak password and is attacked offline after its ticket is requested by any ordinary authenticated user, which is T1558.003. That service account turns out to have local administrator rights on a server because of over-privileged group membership set up years earlier for a task that no longer exists.

From that server, a reused local administrator password reaches several other machines without ever being cracked, because the stored hash is enough (T1550.002). One of them has unconstrained delegation configured, and a domain administrator happens to authenticate to it during routine support work. That single moment hands over a credential that unlocks the entire domain, and replication rights then make copying the directory's password data (T1003.006) a matter of asking for it. Every individual step used a known, common issue. None of them, alone, looked severe on a checklist.

This is the reason proving exploitability matters more than listing findings in isolation. A single weak credential does not stay a single weak credential once it sits inside a network with these conditions present; it becomes the first link in a chain that ends somewhere far more damaging.

Finding these issues before an attacker does

Detecting most of these issues does not require guesswork. Structured Active Directory enumeration maps accounts, group memberships, trust relationships and delegation settings directly from the directory itself, which is enough to surface most of the structural issues above, over-privileged groups, stale accounts, delegation misconfiguration and missing tiering, without touching a single credential.

Password-policy weaknesses need a different, more careful approach: authorised password-policy auditing, including analysis of password hashes obtained through legitimate, in-scope enumeration such as SAM and NTDS extraction, checks whether accounts are actually using weak, default or reused passwords rather than assuming the written policy is being followed in practice. Kerberoastable accounts are identified the same way an attacker would find them: by requesting service tickets for accounts with a Service Principal Name and testing whether the resulting ticket resists an offline attack.

Where a formal method helps, NIST SP 800-115 sets out the planning, execution and post-execution structure that this kind of assessment follows, and mapping each finding to its ATT&CK technique gives defenders a shared reference for the detection and mitigation guidance already published against it.

All of this needs to happen under an authorised scope. Any testing that touches credentials, extracts hashes or attempts to chain findings into further access should run under a signed rules of engagement with clear boundaries, exactly as described in what penetration testing is.

How PentestOps helps

PentestOps runs Active Directory testing through the on-premise agent, which performs Windows and AD enumeration, credential testing, and password-policy auditing including SAM and NTDS hash analysis to identify weak, default or reused passwords across the domain. Kerberoastable service accounts, over-privileged group membership and legacy protocol exposure are surfaced as part of the same enumeration pass.

Where an exploit chain exists, PentestOps demonstrates it safely rather than only listing the individual issues: phased exploit chains can turn one weak credential into a full pivot, all gated by a per-tenant rules of engagement with scope enforcement that automatically stops activity outside authorised assets, with a full evidence trail attached to each finding.

Findings map to 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes. See Active Directory security testing for the full picture, or internal network penetration testing for the wider internal scope that surrounds it.

To try it against your own domain, run a free demo scan or start a trial: all paid plans start with a 7-day free trial, and a card is required to start your trial and is only charged after the trial ends, unless you cancel first.