Six Playbooks for Active Directory and Entra ID

July 15, 2026 · InfraScout Team

Identity questions rarely come alone. "Is our Active Directory healthy?" turns into "who actually holds Domain Admin?", and then "which apps could do the same without a human at all?" This post walks through six playbooks that answer those questions, three from the InfraScout playbook library and three custom ones you can build the same way, covering what each asks, how it is built, what it teaches, and how you run it. If you want the anatomy of a playbook first (phases, guardrails, insight rules), read What's in a Playbook and come back.

All six are read-only and recommendation-only, and every finding lands as an insight you can track and close.

Three Layers of Identity Questions

The six playbooks are easier to reason about as layers than as a list. Inventories answer "what exists, and what depends on it?" Assessments answer "what is risky?" The JIT Role Assessment answers the question that comes after both: "how do we remove standing access without breaking anything?"

The layers feed each other on purpose. An identity inventory can reuse the insights an app inventory already saved, an oversized admin group is only actionable once you know what it is used for, and a JIT design is only safe when it starts from an accurate map of who holds what on both sides of the sync.

AD Assessment

The AD Assessment answers the broadest question in the family: is your Active Directory documented, healthy, and hard to attack? It is also the heaviest playbook of the six, because it works against real domain controllers through connected Windows agents rather than through an API.

How the AD Assessment Is Built

Reconnaissance finds the domain controllers among your connected agents and reads the forest topology. A documentation baseline follows (domains, sites and replication, trusts, the OU tree, GPOs, DNS and DHCP), then an operational audit of DC health, replication, FSMO roles, SYSVOL, time, password policy, and backup readiness. The security assessment comes last.

What the AD Assessment Checks

The security phase is where most of the reusable knowledge lives. It groups its checks into a handful of attack surfaces:

• Kerberos: KRBTGT password age (the Golden Ticket window), Kerberoastable and AS-REP-roastable accounts, weak encryption types, and unconstrained or constrained delegation
• Privileged groups: an oversized Domain Admins group, service accounts in Tier-0 groups, a non-empty Schema Admins, AdminSDHolder orphans, Protected Users coverage, and Tier-0 accounts logging on to lower tiers
• Protocols: LDAP signing and channel binding, SMB1 and SMB signing, NTLM level and auditing
• Directory rights and DNS: DCSync rights, dangerous ACLs on the domain head, DnsAdmins membership, insecure dynamic updates, and open zone transfers
• Recovery and trusts: AD Recycle Bin, system-state backups, tombstone lifetime, LAPS coverage, and SID filtering on external trusts

A check that would need a write is skipped and documented, no credential appears in the output, and when a PowerShell module is missing it falls back to LDAP or built-in command-line tools. You run it interactively, per DC in parallel, and get an interactive report (DOCX available) with a management summary, documentation, operations and security chapters, and an action plan tiered from immediate to recommended.

JIT Role Assessment

The JIT Role Assessment is for the people who own privileged access and want to move to just-in-time access with a PAM system such as GrantFlow. Its question: who holds privileged access across AD and Entra ID today, and how do you get to zero standing privileges?

It looks for existing PAM structures first, such as tiering OUs and PAW groups, because existing tiering groups become JIT roles rather than something to work around. It then inventories AD privilege (privileged groups, service accounts, break-glass accounts, Protected Users) and Entra privilege (directory roles by tier, PIM state, role-assignable groups, Conditional Access impact). A correlation phase matches both sides: synced admins with rights in both are the first JIT candidates, and a common gap is a checked-in AD account that still holds a permanent Entra role. The last phases design task-based roles, map eligibility, and plan removal in priority waves.

The design defaults are worth reusing on their own. Tier 0 (takeover) gets one to four hours with dual approval, Tier 1 (significant) four to eight hours with single approval, and Tier 2 (limited) eight to 24 hours with auto-approval, always with a justification. Roles are bundled by task, not by source system, and only created where real assignments exist. Migration runs Tier 2, then Entra Tier 1, then AD Tier 1, then Tier 0, each as a phased parallel run. Exclusions stay short: at most two break-glass accounts, gMSAs, directory sync accounts, and Conditional Access exclusion accounts.

WARNING

The JIT Role Assessment designs, it does not migrate. Before any standing assignment is removed, its pre-migration checklist requires a tested role, granted eligibility, a successful test activation, a documented rollback, and an agreed change window.

You run it as a consultative chat and get role definitions, an eligibility matrix, the exclusion list, and a P1 to P4 removal matrix with rollback.

Azure Tier Audit

The Azure Tier Audit asks a narrower question: which app registrations and service principals could take over your tenant or exfiltrate data through Microsoft Graph application permissions? It is the smallest playbook in the family and uses the public AzTier classification of Graph permissions.

It enumerates every app registration with full pagination, extracts Graph application permissions (not delegated ones), and matches them to tiers: Tier 0 is tenant takeover, Tier 1 is data exfiltration, and unknown permissions are flagged "untiered, review." It then verifies actual consent through app role assignments. For each Tier-0 app it asks where a secret could be reached (scripts, key vaults, CI/CD, device-management scripts), describes the chain to Global Admin, and rates how realistic it is. First-party Microsoft apps are flagged only when modified, and secrets are never printed. The report separates the takeover and exfiltration scopes and ends with a three-horizon plan.

Custom: Identity-Indicator Assessment

The first custom example is an Entra ID assessment modeled on well-known public identity-security indicator sets. It asks two questions at once: how exposed is the tenant (indicators of exposure), and are there signs of compromise (indicators of compromise)? It is agentless and runs entirely through Microsoft Graph, which keeps it to minutes.

Its checks span privileged access, authentication, Conditional Access, applications, Identity Protection, and the tenant authorization policy. Examples: more than five permanent Global Admins, dormant or synced privileged accounts, anything other than exactly two break-glass accounts, password-only admins (critical) or SMS-only admins (high), a missing legacy-auth or device-code-flow block, policies stuck in report-only, and Security Defaults running alongside custom Conditional Access. Application permissions are graded by name, so role-management write, directory write, or full mailbox access land as critical, and test apps holding write consent or internal apps with a multi-tenant audience surface too.

The indicator type drives what happens next: an exposure goes to the backlog, a confirmed compromise indicator goes to incident response. The report adds a category scorecard and groups remediation into 24 hours, one week, one month, and one quarter. It works in chat, or as a workflow where task agents fan out over the independent areas.

Custom: Enterprise App Inventory

The second custom example is an inventory: what third-party and homegrown apps live in your tenant, and which of them are risky? It enumerates every service principal and buckets them into first-party (counted, then excluded), homegrown, third-party, undetermined (kept for review), and managed identities. Only that working set is enriched with granted permissions, delegated consents, assignments, and credential metadata, and dormancy comes from one aggregated 90-day sign-in query that includes non-interactive sign-ins.

First-party detection is a heuristic based on the owning organization, so apps with no owner are never silently dropped. Delegated consent is split into tenant-wide admin and single-user consent, and credentials are described by type, count, and expiry, never by value. Write-all permissions plus a valid secret is critical; expired or very long-lived credentials and dormant high-privilege apps are high; open assignment, missing owners, and unverified publishers are medium. It runs as a scheduled workflow in minutes and can publish a timestamped wiki page per run.

Custom: Identity Inventory with a Usage Index

The third custom example serves admins, the service desk, and incident responders who need a break-fix reference. Its question: how much of your identity landscape sits outside the AD lifecycle, and what depends on each object?

It classifies users and groups as synced, cloud-only, or sync orphans. The sync flag is effectively tri-state: true means synced, empty means cloud-only, and false means synced once and now orphaned, cross-checked against leftover on-premises attributes. Privilege follows five paths: active roles, eligible roles, scoped assignments including administrative units, roles via role-assignable groups with nesting expanded, and PIM eligible versus active.

The usage index makes it more than a user list. For each object it records app assignments (built from the app side and inverted), Conditional Access includes and excludes, group-based licensing, device-management assignments, and entitlement packages. An exclude on an MFA policy is recorded as what it is: a bypass group. An empty index with no owner is a cleanup candidate; a full one is a production dependency that needs an owner. The report opens with a quick reference mapping symptoms (a lost license, denied app access, unexpected MFA prompts, an undeprovisioned account) to lookup paths.

Distinctions Worth Teaching

The same five distinctions do most of the work across all six playbooks, and they are worth teaching to anyone who reviews identity findings:

• Configured versus granted. An app can request a permission it was never consented to. Only granted permissions are risk.
• Exposure versus compromise. A weak policy is backlog work; evidence of misuse is an incident. Mixing them buries the incident.
• Eligible versus active. A PIM-eligible Global Admin is a very different risk from a permanent one, and both belong in the inventory.
• Disabled versus stale under check-out PAM. When a PAM system enables accounts only while they are checked out, a disabled account with recent logons is an active JIT user, not a leftover.
• No assignment versus open access. An enterprise app with no assignments may mean nobody can use it, or, if assignment is not required, that everyone can.

A Shared Trust Model

All six playbooks follow the same rules. Every finding carries its evidence. When a scope is missing, pagination is incomplete, or a dependency cannot be resolved, the result is "not assessable" rather than a guess, and object IDs are resolved to names before they reach a report. Insights use stable keys, so a re-run next month updates the same findings instead of creating new ones, and you can see what actually changed.

Running Them from Chat or a Workflow

In chat, you name the playbook and the scope, and steer as it goes:

Follow the JIT Role Assessment for our AD forest and the connected Entra tenant.
Start with existing PAM structures and stop after the cross-environment
correlation so we can review the JIT candidates before you design roles.

For a recurring inventory, the same playbook becomes the core of a workflow instruction:

Run the enterprise app inventory playbook against the pinned tenant. Save
findings as insights with the playbook's stable keys, mark anything with
incomplete data as not assessable, and publish the report as a new wiki page.

The Entra-only playbooks finish in minutes and suit schedules. The AD and PAM playbooks are longer interactive sessions where your judgment on each phase is part of the value.

Next Steps

See where playbooks come from to get the library versions into your tenant, then read What's in a Playbook before you write your own. To schedule the Entra-only playbooks, see Agentic Workflows. If the AD Assessment flags your privileged groups, Privileged Group Housekeeping in AD shows what the follow-up conversation looks like.