Skip to content
Safestorm
Menu
structuredData=[object Object]

Insight · Active Directory

Common Active Directory weaknesses found during internal assessments

· Safestorm · 5 min read

Active Directory security is rarely defined by a single bad setting. In practice, the risk usually comes from the way identities, group memberships, delegated rights, legacy protocols, and management decisions interact. Microsoft’s own guidance describes misconfiguration as a common root cause of AD weakness, and joint government guidance notes that AD is especially susceptible because of permissive defaults, opaque relationships between objects, and continued reliance on legacy technologies.

Privilege paths build quietly

One of the most common problems in internal assessments is not a single “Domain Admin mistake”, but an accumulation of smaller permissions that form a path to something more sensitive. Privileged service accounts, nested group membership, legacy operator groups, and hidden privilege through attributes such as SIDHistory can all create escalation routes that are easy to miss in a basic permissions review. Microsoft now explicitly flags service accounts in privileged groups, built-in operator groups such as Server Operators and Backup Operators, and insecure SIDHistory as conditions that can lead to privilege abuse, persistence, or even effective domain-wide administrative access. AD hardening is therefore not just about reviewing who is in Domain Admins today; it is about understanding which identities can become highly privileged through relationships and delegated control.

Service accounts often expand the blast radius

Accounts with Service Principal Names are especially important because any authenticated domain user can request the service ticket for that account, and that ticket can then be cracked offline in a Kerberoasting attack. Joint government guidance notes that if the affected service account is privileged, compromise can quickly lead to wider domain compromise. The same guidance also explains that AS-REP roasting becomes possible when an account is configured not to require Kerberos pre-authentication, which is usually only justified for legacy compatibility scenarios. Microsoft’s guidance is straightforward here: use group managed service accounts wherever possible, keep privileges minimal, and avoid leaving service accounts in privileged groups unless there is a documented and reviewed reason.

Credential hygiene matters beyond password length

Weaknesses frequently appear in the operational handling of credentials rather than in the password policy alone. Microsoft warns that stale user and service accounts remain a security risk because they can retain high or legacy permissions without attracting attention. It also now surfaces “discoverable passwords” in free-text AD attributes such as description, info, and adminComment because those fields are often readable by authenticated users and can reveal passwords, reset hints, or other credential clues. Older password distribution patterns also still matter: the joint AD compromise guidance notes that Group Policy Preferences cpasswords remain a recurring problem because they can still be found in SYSVOL if they were never removed. For local administrator accounts, Microsoft recommends LAPS because it rotates unique passwords and reduces the lateral movement risk created by shared local administrator credentials.

Legacy authentication and delegation still create real exposure

Kerberos is the preferred authentication method in Active Directory environments, but NTLM is still supported in many organisations for legacy or fallback scenarios. Microsoft now classifies all versions of NTLM as deprecated and recommends replacing direct NTLM usage with Negotiate so Kerberos is used whenever possible. That matters because legacy authentication and poor delegation choices still show up in internal reviews. Joint government guidance describes unconstrained delegation as a particularly high-risk setting because it stores copies of users’ TGTs on the delegated host; if that host is compromised, an attacker may be able to reuse those tickets and escalate to privileged identities. The safest direction is to remove unconstrained delegation wherever possible, use constrained or resource-based constrained delegation when there is a genuine business need, and reduce reliance on NTLM-based workflows over time.

Certificate Services changes the risk picture

Many organisations still think of AD CS as a specialist PKI topic rather than as part of the identity attack surface, but that view is outdated. Microsoft now treats AD CS as an identity security concern and highlights misconfigured certificate templates, weak CA settings, risky enrolment agent templates, and overly permissive ACLs as issues that can lead to unauthorised access or full domain compromise. In Microsoft’s current guidance, certificate templates become especially dangerous when unprivileged groups such as Authenticated Users or Domain Users are allowed to modify them, or when template settings allow abuse of privileged EKUs or enrolment agent workflows. Microsoft also warns that unmonitored AD CS servers are high-value targets because attackers can exploit them to issue unauthorised certificates, enable stealthy lateral movement, or maintain persistence. In short, if Certificate Services is present in the environment, it belongs in scope during an internal assessment.

The practical lesson is that good internal testing should not stop at listing misconfigurations. It should map how those weaknesses combine, identify which paths actually matter, validate what can be exploited safely, and give the client a remediation plan that reduces both standing privilege and future attack surface. Microsoft’s Enterprise Access Model and current AD hardening guidance both point in the same direction: treat Tier 0 systems and identities as a separate control plane, reduce unnecessary privileged access, prefer managed identities such as gMSAs, rotate privileged local passwords with LAPS, require Kerberos pre-authentication unless there is a documented exception, remove stale accounts, and review AD CS and delegation settings as first-class security concerns rather than side issues.

At Safestorm, the goal of an internal Active Directory assessment is not to generate noise. It is to show you which identity and privilege paths are genuinely usable, which systems belong in your highest-trust tier, and which remediation steps will materially reduce the chance of a routine internal foothold becoming a domain-wide incident. That is a far more useful outcome than a flat list of settings with no context. This closing point is an inference from the Microsoft and joint-government guidance above, which consistently emphasises privilege-path visibility, Tier 0 protection, and remediation based on real impact rather than isolated configuration review.

References and further reading

Microsoft guidance

Joint government guidance