Identity Security Posture Management for Active Directory and Entra ID: A Practical Guide

What ISPM Is, and What It Is Not

Identity security posture management (ISPM) is the continuous assessment of whether your identity configuration enforces the policies you intend. That definition matters because it separates ISPM from two adjacent disciplines that operators sometimes conflate with it.

Cloud Security Posture Management (CSPM) evaluates infrastructure configuration: storage bucket permissions, network security groups, IAM role trust policies. It is resource-centric. IAM tooling, by contrast, handles identity lifecycle: provisioning, deprovisioning, role assignment, and group membership. IAM is identity-CRUD. Neither discipline asks the question ISPM asks, which is: given the identities and policies that exist right now, what can an attacker do?

For Active Directory and Entra ID environments, that question surfaces a class of risks that IAM dashboards and CSPM scanners both miss. A user account can be correctly provisioned, correctly licensed, and still carry an RC4-only Kerberos configuration that makes it trivially roastable. A service account can be in scope for a Conditional Access policy on paper, but excluded from it by a legacy exception added during a migration two years ago. ISPM exists to find that gap.

Retrievy's ISPM module operates across both on-premises AD and Entra ID, correlating posture findings against your defined policy baseline rather than against a generic benchmark alone.

The Five Risk Classes ISPM Tools Surface

1. Privileged-Account Sprawl

Privileged access is the most targeted surface in any AD environment. The canonical attacker path runs through accounts with Domain Admins, Schema Admins, or Enterprise Admins membership, but sprawl extends further: accounts with DCSync rights via ACL delegation, accounts with GenericAll over high-value OUs, and Entra ID roles such as Global Administrator or Privileged Role Administrator assigned directly rather than through Privileged Identity Management (PIM).

ISPM tooling enumerates effective privilege, not just group membership. A user who is not in Domain Admins but holds WriteDACL on the AdminSDHolder object has a path to domain compromise that a membership report will not show. Effective-privilege enumeration is the core differentiator here.

A well-configured environment should keep permanent Global Administrator assignments to fewer than five accounts. In practice, many tenants accumulate dozens of standing assignments because PIM activation friction pushes engineers toward convenience.

2. Stale Credentials and Dormant Accounts

Accounts that have not authenticated in 90 days or more represent durable footholds. Attackers targeting an environment through a phishing or credential-stuffing campaign will preferentially use dormant accounts because detection logic based on behavioral baselines has no baseline to compare against.

The risk is compounded in hybrid environments where an on-premises account synced to Entra ID may be disabled in AD but the cloud object remains enabled, or vice versa. ISPM tooling that operates across both planes surfaces these sync-state inconsistencies as a distinct finding class, separate from simple last-logon staleness.

3. Weak Kerberos Cryptography

Kerberos roasting (MITRE ATT&CK T1558.003) targets service principal names (SPNs) registered to user accounts. When those accounts are configured to support RC4-HMAC encryption (etype 23), the resulting ticket can be cracked offline. AES-only enforcement, enforced via the msDS-SupportedEncryptionTypes attribute and Group Policy, eliminates the roastable ticket class entirely.

A related issue is the presence of accounts with the DONT_REQ_PREAUTH flag set, which enables AS-REP roasting (T1558.004) without requiring the attacker to have any prior credentials. ISPM tooling should enumerate both SPN-bearing accounts with RC4 support and accounts with pre-authentication disabled, and correlate them against privilege level to prioritise remediation.

Windows Server 2022 domain functional level supports AES-256 enforcement natively. Environments still operating at 2016 or 2019 functional levels can enforce AES through fine-grained password policy and attribute-level controls, but the path requires deliberate configuration rather than a default.

4. ADCS Template Misconfigurations

Active Directory Certificate Services (ADCS) misconfigurations have become one of the most operationally significant risk classes in on-premises AD. The ESC1 through ESC8 vulnerability classes, documented publicly by SpecterOps, describe conditions under which low-privileged users can obtain certificates that authenticate as Domain Admins or other privileged principals.

The highest-impact pattern is ESC1: a certificate template that permits the requester to supply an arbitrary Subject Alternative Name (SAN), combined with enrollment rights granted to a broad group such as Domain Users, combined with the CA flag EDITF_ATTRIBUTESUBJECTALTNAME2 enabled. An attacker with any domain account can request a certificate asserting the identity of any user in the directory, including Domain Admins, and use it to obtain a Kerberos TGT.

ISPM tooling with ADCS checks should enumerate every published template, evaluate the combination of enrollment ACLs, EKU configuration, SAN flags, and CA-level settings, and produce a prioritised list of exploitable templates. This is not a one-time audit task; templates change, and new CAs are added. Continuous assessment is the only posture that holds.

5. Conditional Access Gaps in Entra ID

Conditional Access (CA) policies are the primary enforcement mechanism for authentication policy in Entra ID. They are also the primary source of policy-intent drift. Common gap patterns include:

• Break-glass accounts and service principals explicitly excluded from MFA policies, where those exclusions are broader than intended.
• Policies scoped to "All cloud apps" that do not apply to legacy authentication protocols, allowing SMTP AUTH or IMAP to bypass MFA entirely.
• Named location definitions that have not been reviewed since the policy was written, covering IP ranges that no longer map to trusted corporate egress.
• Guest accounts that fall outside the policy scope because the target principal type was set to "Members only".

ISPM tools evaluate CA policies not as individual objects but as a coverage mesh. The question is not whether a policy exists, but whether every authentication path to every sensitive resource passes through at least one enforcing policy. GPO X-Ray and similar policy-analysis capabilities apply the same mesh-coverage logic to on-premises Group Policy, identifying authentication and Kerberos settings that conflict across GPO precedence layers.

ISPM vs. IAM: The Policy-Aware Distinction

The practical difference between ISPM and IAM tooling comes down to what each system models. IAM systems model identity state: who exists, what groups they belong to, what licenses they hold. They are authoritative for provisioning correctness.

ISPM models policy effectiveness: given the current identity state, which policies are enforced, which are bypassed, and which are absent. A user correctly provisioned with no standing privileged role is still an ISPM finding if their account has an SPN, supports RC4, and has not authenticated in 180 days. IAM sees a healthy account. ISPM sees a roastable, dormant credential.

That distinction is why ISPM belongs in the identity engineer's toolkit alongside, not instead of, IAM and CSPM. The three disciplines cover different layers of the same stack, and gaps appear at the boundaries between them.

Operating ISPM Continuously

Posture is not a point-in-time measurement. A CA policy exclusion added at 11 PM on a Friday to unblock a vendor integration represents a posture change that an annual audit will not catch. The operational model for ISPM is continuous assessment with alert thresholds on high-severity drift: new accounts added to tier-zero groups, ADCS template ACL changes, CA policy exclusion additions, and pre-authentication flag changes.

Retrievy's ISPM module surfaces these as policy-correlated findings rather than raw attribute changes, which means the alert carries context: not just "this account changed" but "this account now has a path to Domain Admin that did not exist 24 hours ago." That context is what makes posture data actionable rather than noisy.