Microsoft Entra ID

The Entra ID integration is ISE’s governance flagship: it brings identity into the estate and gives sensitive identity changes one governed place to happen. Every identity action sits in the highest risk tier — a human approver is always required — and structural guardrails prevent ISE from ever modifying the groups its own access derives from.

Capabilities

Discovery. Users (including guests), security groups, service principals, and Conditional Access policies are enumerated into the estate as tenant-scoped entities — four identity-shaped entity types alongside your infrastructure.

Alerts. Identity Protection risky users are ingested as stateful signals: a user at risk raises a signal that persists until Entra clears or dismisses the risk. Individual risk detections are deliberately evidence, not alerts — the user-level risk state is the thing worth paging on.

Evidence. On demand during an investigation: user_sign_ins, directory_audit_log, risk_detections, user_detail (including MFA state), group_members, ca_policy_detail, and app_credential_expiry.

Actions. Six identity actions — all T3, the tier that always demands a human approver:

Action	Tier	Notes
revoke_user_sessions	T3	Invalidates refresh tokens; the user signs in again.
disable_user	T3	Blocks sign-in.
enable_user	T3	Restores sign-in.
add_group_member	T3	Adds a user to a security group.
remove_group_member	T3	Removes a user from a security group.
set_ca_policy_state	T3	Enable / disable / report-only on an existing CA policy.

Guardrails. ISE structurally refuses to touch the groups its own role mapping derives from, plus an admin-configurable protected-group deny set — checked including transitive (nested) membership, failing closed. There are no password, credential, or directory-role actions at all, and no freeform CA policy editing — only the state switch on policies that already exist.

Setup

1. Create a read app registration with admin-consented, read-only Graph application permissions: User.Read.All, Group.Read.All, Application.Read.All, Policy.Read.ConditionalAccess, IdentityRiskyUser.Read.All, IdentityRiskEvent.Read.All, AuditLog.Read.All, Reports.Read.All. No directory roles, and never any *.ReadWrite.* permission — ISE verifies this invariant.
2. In ISE, add an Entra ID integration (Settings → Integrations) with tenant ID, client ID, and client secret. The secret is encrypted at rest and redacted from logs.
3. The health check verifies the principal; the System card shows the tenant, status, and last sync.
4. To enable actions, create a second service principal with only the write permissions the six actions need and grant it via the Grant write flow. Reads and writes never share a principal, and the write principal is held to the same forbidden-permission invariant.

Identity Protection risk signals require the appropriate Entra ID licence (P2) in the tenant.

Examples

A risky user becomes an incident. Identity Protection flags a user at high risk. The signal opens an incident on the user entity; sign-in logs and risk detections are pulled as evidence and show impossible-travel sign-ins from an unfamiliar network.

Governed containment. The responder proposes revoke_user_sessions and disable_user. Both are T3: nothing executes until a human approver signs off — and approver and proposer cannot be the same person. Execution, outcome, and the eventual enable_user restoring access all land on the audit trail.

The guardrail in action. A proposed add_group_member targeting the group that grants ISE its own admin role is refused structurally — before tiering, before approval — because ISE does not modify the groups its own access derives from.