Microsoft Entra ID (formerly Azure AD) — identity platform internals, telemetry, and attack detection. Covers the full Entra ID surface including sign-in logs (interactive, non-interactive, service principal, managed identity), audit logs, Identity Protection risk signals, Conditional Access evaluation, directory role management, OAuth/consent grants, PRT/token mechanics, cross-tenant B2B/B2C, and workload identities. Includes SKU gating (P1 vs P2), ResultType code catalogue, identity attack patterns (password spray, AiTM, MFA fatigue, token theft, OAuth abuse, Golden SAML), and entity alignment for cross-platform correlation. Use for any work involving Entra ID telemetry, identity-focused detection, or directory security posture. Pair with the relevant platform skill for query mechanics (microsoft-sentinel, splunk-spl-processing, crowdstrike-falcon, etc.).
Instalação
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Microsoft Entra ID (formerly Azure AD) — identity platform internals, telemetry, and attack detection. Covers the full Entra ID surface including sign-in logs (interactive, non-interactive, service principal, managed identity), audit logs, Identity Protection risk signals, Conditional Access evaluation, directory role management, OAuth/consent grants, PRT/token mechanics, cross-tenant B2B/B2C, and workload identities. Includes SKU gating (P1 vs P2), ResultType code catalogue, identity attack patterns (password spray, AiTM, MFA fatigue, token theft, OAuth abuse, Golden SAML), and entity alignment for cross-platform correlation. Use for any work involving Entra ID telemetry, identity-focused detection, or directory security posture. Pair with the relevant platform skill for query mechanics (microsoft-sentinel, splunk-spl-processing, crowdstrike-falcon, etc.).
Microsoft Entra ID — identity platform & detection
This skill encodes the identity-platform tribal knowledge for Microsoft Entra ID (formerly Azure AD) — the central identity provider for Microsoft 365, Azure, and thousands of SaaS applications. It covers the platform's architecture, telemetry surfaces, security features, and attack detection patterns.
Workload identities — service principals, managed identities, federated credentials
Naming: "Azure AD" was renamed to "Microsoft Entra ID" in July 2023. The diagnostic log categories retain the legacy names (SigninLogs, AADNonInteractiveUserSignInLogs, AuditLogs). These names are used by Sentinel, but the same data is available in any SIEM via Event Hubs, Graph API, or diagnostic settings — field names and schemas are identical regardless of destination. This skill uses "Entra ID" for the product and the canonical log category names throughout.
0. Entra ID architecture overview
Entra ID is a multi-tenant, cloud-based identity and access management service. Every Microsoft 365 and Azure subscription has an Entra ID tenant. Key concepts:
Concept
Description
Tenant
A dedicated instance of Entra ID representing an organisation. Identified by a tenant ID (GUID) and one or more verified domains.
User principal
A human identity (user@domain.com). Can be a member or a guest (B2B).
Service principal
An application identity in a tenant. Created when an app registration is consented to or provisioned.
Managed identity
An Azure-managed service principal bound to an Azure resource (VM, Function, etc.). No credential management required.
App registration
The global definition of an application (multi-tenant). The service principal is the per-tenant instance.
Risk-based detection engine (P2) that scores sign-in risk and user risk.
PIM (Privileged Identity Management)
Just-in-time role activation for privileged roles (P2).
Entra ID log categories
These are the canonical diagnostic log categories emitted by Entra ID. The names below are used in Sentinel, but the same schema and field names apply when ingested into Splunk (via Event Hubs / Azure Monitor Add-on), CrowdStrike NG-SIEM, Elastic, or any other SIEM.
Global Secure Access (Entra Internet/Private Access)
Separate licence
Diagnostic settings
SIEM mapping note: In Sentinel, NonInteractiveUserSignInLogs maps to the AADNonInteractiveUserSignInLogs table. In Splunk, the same data arrives via the azure:aad:signin sourcetype. In Elastic, it lands in azure.signinlogs. The field names within each record (e.g., ResultType, UserPrincipalName, IPAddress) are consistent across all destinations because they originate from the same Entra ID diagnostic schema.
1. SKU gating — what you can and cannot detect
Identity Protection features are licence-dependent. Detection content must declare which tier it requires.
Feature
Entra ID P1
Entra ID P2
Free
SigninLogs table
Yes
Yes
Yes (limited)
RiskLevelDuringSignIn column
No
Yes
No
RiskState, RiskDetail columns
No
Yes
No
RiskEventTypes_V2 column
No
Yes
No
risky Users / riskDetections APIs
No
Yes
No
Conditional Access policy evaluation logs
Yes
Yes
No
AADNonInteractiveUserSignInLogs
Yes
Yes
No
ManagedIdentitySignInLogs
Yes
Yes
No
ServicePrincipalSignInLogs
Yes
Yes
No
Gotcha: A detection that filters on RiskLevelDuringSignIn == "high" silently returns zero results in P1 tenants — the column exists but contains only "none". In KQL, use column_ifexists() for P2-only columns. In SPL/other SIEMs, apply equivalent null-safe field access. Always declare the SKU tier requirement in detection content.
2. Sign-in risk vs user risk
Two distinct risk models that are often confused:
Concept
Sign-in risk
User risk
Scope
Per-authentication event
Per-user entity (cumulative)
Column
RiskLevelDuringSignIn
RiskLevelAggregated (via risky Users API)
Triggers
Anomalous IP, impossible travel, AiTM proxy, malware-linked IP
Detection discipline: Use sign-in risk for real-time detection rules. Use user risk for enrichment and escalation logic, not as a primary detection signal (it lags).
3. ResultType code catalogue (critical subset)
ResultType in SigninLogs is a string, not an integer. Always compare as string.
The signals below describe what Entra ID emits when specific identity-layer activity occurs. They are not attack descriptions — pair with threat vector objects (TVMs) for adversary context.
OperationName in ("Add service principal credentials", "Update application – Certificates and secrets management")
Federated credential added
AuditLogs
OperationName has "federatedIdentityCredential"
4.5 Directory and policy changes
Signal
Log category
Key fields
Conditional Access policy modified
AuditLogs
OperationName has "conditional access", TargetResources
Permanent role assignment
AuditLogs
OperationName == "Add member to role"
PIM role activation
AuditLogs
OperationName == "Add member to role completed (PIM activation)"
Service principal sign-in from new IP
ServicePrincipalSignInLogs
ServicePrincipalId, IPAddress
5. Telemetry split — user vs service principal vs managed identity
Principal type
Sign-in log category
Audit log category
Interactive user
SigninLogs
AuditLogs
Non-interactive user
NonInteractiveUserSignInLogs
AuditLogs
Service principal
ServicePrincipalSignInLogs
AuditLogs
Managed identity
ManagedIdentitySignInLogs
AuditLogs
Common mistake: Querying only interactive sign-ins and missing non-interactive activity. Token refresh, background app activity, and service-to-service calls appear in the non-interactive and service principal log categories.
For comprehensive identity coverage, query across all relevant sign-in categories. Example (KQL — adapt to your SIEM's query language):
// Sentinel / KQL example — adapt for Splunk, Elastic, etc.
union isfuzzy=true SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(14d)
| where ResultType == "0"
// ... detection logic
6. Cross-tenant and B2B considerations
Scenario
Column
Value
Home tenant sign-in
HomeTenantId == ResourceTenantId
Normal
Guest user (B2B)
HomeTenantId != ResourceTenantId
Cross-tenant access
External identity provider
TokenIssuerType
"External"
Detection discipline: B2B guest access is legitimate but high-risk. Detections should distinguish between established B2B relationships and novel cross-tenant access.
7. Nested JSON field paths
Many sign-in and audit log fields contain nested JSON objects. The field paths below are consistent across all SIEMs — only the extraction syntax differs (KQL parse_json(), SPL spath, Elastic nested field access, etc.).
SigninLogs nested fields
Top-level field
Nested path
Type
Use
LocationDetails
.city
string
Geo-anomaly detection
LocationDetails
.countryOrRegion
string
Impossible travel
LocationDetails
.state
string
Regional baselining
DeviceDetail
.browser
string
User agent anomaly
DeviceDetail
.operatingSystem
string
Platform baselining
DeviceDetail
.isCompliant
bool
Device compliance check
DeviceDetail
.deviceId
string
Device identity correlation
ConditionalAccessPolicies
[].displayName
string (array)
Which CA policies evaluated
ConditionalAccessPolicies
[].result
string (array)
"success", "failure", "notApplied"
AuthenticationDetails
[].authenticationMethod
string (array)
MFA method used
AuthenticationDetails
[].succeeded
bool (array)
Per-step auth result
AuthenticationProcessingDetails
[].key
string (array)
Contains "Is Primary Refresh Token" for PRT usage
AuditLogs nested fields
Top-level field
Nested path
Type
Use
InitiatedBy
.user.userPrincipalName
string
Who performed the action
InitiatedBy
.app.displayName
string
App-initiated changes
TargetResources
[0].displayName
string
Target object name
TargetResources
[0].userPrincipalName
string
Target user
TargetResources
[0].modifiedProperties
array
What changed (old/new values)
8. Directory role and PIM monitoring
Critical directory roles
Role
Risk
Why
Global Administrator
Critical
Full tenant control — can reset any password, modify any policy
Privileged Role Administrator
Critical
Can assign any role including Global Admin
Application Administrator
High
Can create/modify app registrations and consent to permissions
Cloud Application Administrator
High
Same as above minus on-prem app proxy
Exchange Administrator
High
Mailbox access, mail flow rules — BEC enabler
Security Administrator
High
Can modify security policies, read all security data
Understanding token types is critical for detecting token theft and replay:
Token
Lifetime
Storage
Theft vector
Access token
60–90 min (configurable)
Memory
Process memory dump, AiTM proxy
Refresh token
90 days (sliding)
Disk/browser
Malware, AiTM, device compromise
Primary Refresh Token (PRT)
14 days
TPM-bound (ideally)
mimikatz, ROADtools, device compromise
Session cookie
Varies
Browser
Cookie theft, AiTM proxy
FOCI token
Varies
Shared across FOCI apps
One compromised FOCI app exposes others
FOCI (Family of Client IDs)
Microsoft first-party apps share refresh tokens via FOCI. If an attacker steals a refresh token for one FOCI app (e.g., Outlook), they can exchange it for tokens to other FOCI apps (e.g., Teams, OneDrive) without re-authenticating. Key FOCI client IDs:
Cross-platform correlation happens at the SIEM/SOAR layer. The UserPrincipalName is the most reliable cross-platform join key for identity.
12. Detection cheatsheet
For example KQL queries covering password spray, MFA fatigue, AiTM chains, OAuth consent, SP credential addition, cross-tenant anomalies, and PIM activations, see references/Detection-Cheatsheet.md. The logic and field names are portable — adapt the syntax to your SIEM.
13. Quality checklist
SKU tier requirement declared (P1 vs P2).
column_ifexists() used for P2-only columns.
ResultType compared as string, not integer.
ResultType codes commented inline with meaning.
All relevant sign-in tables queried (interactive + non-interactive + SP where applicable).
Nested JSON parsed via parse_json() / todynamic().
Cross-tenant scenarios considered (B2B guest access).
Risk columns used for enrichment, not as sole detection signal in P1 environments.
Directory role changes monitored (permanent assignments, PIM activations).
Token type and theft vector documented for token-based detections.
Dangerous application permissions flagged in consent-based detections.
FOCI token sharing considered for token theft scope assessment.
MITRE technique mapping accurate (T1078, T1098, T1556, T1621, T1557 as applicable).
Coordinate with the relevant platform skill for query mechanics (microsoft-sentinel, splunk-spl-processing, crowdstrike-falcon, etc.) and detection-engineering for lifecycle.
