Microsoft Entra ID: The Identity Plane

DFIR Epistemology: The Identity Boundary

In cloud environments, identity is the sole perimeter. There are no internal firewalls or network segments enclosing your SaaS data. If an adversary compromises an Entra ID token or credential, the entire resource access surface granted to that identity is directly reachable across the public internet.

Concept

Microsoft Entra ID (formerly Azure Active Directory) is the centralized, cloud-native Identity and Access Management (IAM) plane powering Microsoft 365, Microsoft Azure, and thousands of federated enterprise SaaS applications.

Unlike on-premises Active Directory Domain Services (AD DS)—which relies on a hierarchical LDAP database, Kerberos ticket-granting services, and Windows-specific RPC protocols (Fiche 38: AD to Entra)—Entra ID is a multi-tenant, flat, REST-driven identity directory. It exposes modern authentication standards:

• OAuth 2.0: Authorization framework issuing scoped Access Tokens.
• OpenID Connect (OIDC): Identity layer on top of OAuth 2.0 issuing cryptographically signed ID Tokens.
• SAML 2.0 & WS-Federation: Legacy federation standards for enterprise Single Sign-On (SSO).

Every security boundary, authentication event, conditional access policy, and role assignment in Microsoft 365 is evaluated within the Entra ID identity plane.

+---------------------------------------------------------------------------------------------------+
|                                 MICROSOFT ENTRA ID IDENTITY ENGINE                                |
|                                                                                                   |
|   +-------------------------------------------------------------------------------------------+   |
|   |                               DIRECTORY OBJECT SCHEMA                                     |   |
|   |   User Principals | Guest Accounts (B2B) | Workload Identities (Apps & Service Principals)    |   |
|   |   Security Groups | M365 Unified Groups | Devices (Registered, Joined, Hybrid Joined)     |   |
|   +---------------------------------------------+---------------------------------------------+   |
|                                                 |                                                 |
|                                                 v                                                 |
|   +-------------------------------------------------------------------------------------------+   |
|   |                          CONDITIONAL ACCESS POLICY ENGINE                                 |   |
|   |   SIGNALS: Identity | IP / Named Location | Device Compliance | App Context | Risk Level  |   |
|   |   DECISION: Block | Grant (MFA, Compliant Device, Hybrid Joined, Password Change, CAE)   |   |
|   +---------------------------------------------+---------------------------------------------+   |
|                                                 |                                                 |
|                                                 v                                                 |
|   +-------------------------------------------------------------------------------------------+   |
|   |                            TOKEN ISSUANCE & ARTIFACT FABRIC                               |   |
|   |   Primary Refresh Tokens (PRT) | OAuth 2.0 Access Tokens (JWT) | ESTSAUTH Session Cookies |   |
|   +---------------------------------------------+---------------------------------------------+   |
|                                                 |                                                 |
|                                                 v                                                 |
|   +-------------------------------------------------------------------------------------------+   |
|   |                                  WORKLOAD CONSUMPTION                                     |   |
|   |   Exchange Online | SharePoint Online / OneDrive | Microsoft Teams | Microsoft Graph API  |   |
|   +-------------------------------------------------------------------------------------------+   |
+---------------------------------------------------------------------------------------------------+

---

Why It Matters in DFIR

For the digital forensic investigator, Entra ID is the primary source of truth for:

1. Initial Access Reconstruction: Tracing whether an attacker gained access via password spraying, credential stuffing, phishing, or session hijacking (Fiche 19: Kill Chain).
2. Session Identification: Correlating client IP addresses, User-Agents, and device identifiers (DeviceId) with specific token lifetimes.
3. Policy Bypass Analysis: Explaining why Multi-Factor Authentication (MFA) was or was not enforced during a suspicious sign-in.
4. Identity Risk Telemetry: Evaluating machine-learning threat indicators flagged by Microsoft Entra ID Protection (e.g., Anonymous IP address, Atypical travel, Malicious IP address, Suspicious browser).
5. Backdoor Identification: Discovering rogue service principals, application certificates, or secondary MFA methods added by the threat actor to preserve access (Fiche 29: OAuth Persistence and Fiche 30: Auth Methods).

---

How It Works

1. The Directory Hierarchy & Core Objects

• The Tenant (TenantId): The root container represented by an immutable GUID.
• User Objects: Identified by their immutable ObjectId (GUID) and their logon UserPrincipalName (UPN, e.g., alice@company.com).
• Device Objects:
  • Entra Registered: Personal/BYOD devices registered for workplace access.
  • Entra Joined: Corporate devices joined exclusively to cloud Entra ID.
  • Microsoft Entra Hybrid Joined: Corporate domain-joined machines synchronized from on-premises Active Directory.
• Workload Identities: Non-human identities used by software services:
  • App Registrations: The global blueprint and definition of an application.
  • Enterprise Applications (Service Principals): The local representation and security principal of an application within the specific tenant (Fiche 03: Accounts & Roles).
  • Managed Identities: Azure-managed service accounts eliminating credential storage.

2. The Conditional Access Evaluation Engine

Conditional Access operates as an If-Then policy gate evaluated in real-time during authentication:

• Input Signals:
  • Who: User identity, group memberships, assigned directory roles.
  • Where: Named locations, trusted IP ranges, GPS coordinates, country code.
  • What Device: OS platform, device compliance state (Intune), hybrid join status.
  • What App: Targeted cloud application (e.g., Office 365, Azure Management, custom SAML app).
  • Risk: User Risk and Sign-in Risk calculated by Entra ID Protection.
• Access Decisions:
  • Block Access.
  • Grant Access with required controls: Require MFA, require compliant device, require password change, require approved client app.
  • Session Controls: Enforce app-enforced restrictions, Conditional Access App Control (Defender for Cloud Apps), sign-in frequency.

3. Tokens and Session Lifetimes

• Primary Refresh Token (PRT): Issued to Entra Joined or Registered devices, stored securely in the Windows TPM or Apple Secure Enclave. Grants Single Sign-On (SSO) across applications without repeated MFA prompts.
• Refresh Token: Issued to OAuth clients upon successful authentication, used to acquire new access tokens silently.
• Access Token: Short-lived JSON Web Token (JWT) (60–90 min) containing claims (upn, oid, roles, scp, ipaddr, uti) passed in the Authorization: Bearer <token> HTTP header to workloads.

---

What Is Possible

Through Entra ID forensic examination, the investigator can:

• Differentiate Authentication Flows: Distinguish interactive browser logins from background non-interactive sync, service principal calls, and managed identity operations (Fiche 09: Sign-in Logs).
• Detect Session Hijacking: Identify when an existing session was replayed from an unauthorized IP or unexpected ISP without triggering an MFA prompt.
• Inspect Policy Application: Review the exact Conditional Access policies that evaluated, succeeded, failed, or were excluded during an authentication request.
• Audit Administrative Tampering: Trace who created, modified, or deleted an account, role assignment, application secret, or security group (Fiche 10: Audit Logs).

---

What Is Not Possible

• No Application Activity Tracing: Entra ID logs tell you that an access token for Exchange Online was issued; they do not tell you what emails were read or exported.
• No Password Recovery: Entra ID stores cryptographic representations; an analyst cannot recover the cleartext password entered by an attacker or victim.
• No Historical Policy Rollback: Entra ID shows the policy evaluation at the time of the event, but does not keep a versioned configuration history of past policy definitions unless audit logs capturing policy changes are preserved.

---

Prerequisites & Necessary Conditions

To investigate the Entra ID identity plane:

• Licensing:
  • Entra ID Free: Basic sign-in and audit logs retained for 7 days only. No risk-based conditional access.
  • Entra ID P1: Standard sign-in and audit logs retained for 30 days. Conditional Access enabled.
  • Entra ID P2: Full Entra ID Protection (User Risk, Sign-in Risk, risk-based CA policies), Privileged Identity Management (PIM).
• Forensic Roles: Global Reader or Security Reader + Reports Reader (Fiche 05: Global Reader).

---

Artifacts and Evidence Sources

Log Stream	Endpoint / Graph Resource	Description	Key Forensic Fields
Interactive Sign-ins	/auditLogs/signIns	User entered credentials directly into browser/app.	ipAddress, location, clientAppUsed, conditionalAccessStatus, mfaDetail
Non-Interactive Sign-ins	/auditLogs/signIns (signInEventTypes)	Background token refresh on behalf of user.	originalRequestId, resourceDisplayName, appId, correlationId
Service Principal Sign-ins	/auditLogs/signIns	Automated authentication by an application/daemon.	servicePrincipalId, servicePrincipalName, resourceDisplayName
Directory Audits	/auditLogs/directoryAudits	Changes to directory objects, roles, and settings.	activityDisplayName, initiatedBy, targetResources, additionalDetails
Risk Detections	/identityProtection/riskDetections	Real-time and offline threat detections.	riskType, riskLevel, riskState, detectionTimingType

---

Investigation Methodology

1. Identify the Target Identity: Retrieve the immutable ObjectId corresponding to the UPN using PowerShell:

   Get-MgUser -UserId "victim@enterprise.com" | Select-Object Id, UserPrincipalName, AccountEnabled

2. Extract Interactive and Non-Interactive Sign-Ins: Query all sign-in events for the suspected window:

   Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'victim@enterprise.com' and createdDateTime ge 2026-09-01T00:00:00Z" `
     -All | Select-Object CreatedDateTime, IpAddress, Location, AppDisplayName, Status, ConditionalAccessStatus

3. Examine Authentication Details & MFA: Inspect the AuthenticationDetails JSON array to verify which authentication methods were evaluated (e.g., Password, Mobile app notification, FIDO2).

4. Verify Conditional Access Satisfaction: Examine the AppliedConditionalAccessPolicies property. Did the attacker bypass MFA because they connected from a “Trusted Named Location” or a legacy client application?

5. Correlate with Directory Audit Logs: Search for administrative changes initiated by or targeted at this user:

   Get-MgAuditLogDirectoryAudit -Filter "targetResources/any(t:t/userPrincipalName eq 'victim@enterprise.com')" -All

---

Practical Example / Case Walkthrough

Scenario: The “Compliant” Foreign Login

An enterprise SOC detected an unusual login for a senior engineer from a residential IP in Eastern Europe. However, the sign-in log indicated:

• ResultType: 0 (Success)
• ConditionalAccessStatus: success
• MFA Requirement: Satisfied

Investigation:

1. Inspecting Authentication Steps: Querying the sign-in details revealed:

   {
     "authenticationMethod": "Previously satisfied",
     "authenticationStepRequirement": "MultiFactorAuthentication",
     "status": "success"
   }

   Observation: The user did not actually complete an MFA prompt at that timestamp. The MFA requirement was fulfilled by a previously issued Primary Refresh Token (PRT) or valid session cookie (Fiche 23: Session Cookies & Token Theft).
2. Correlating IP and User-Agent: The IP was identified as a commercial SOCKS5 residential proxy. The browser User-Agent was an exact bit-for-bit duplicate of the engineer’s legitimate workstation.
3. Forensic Finding: The adversary deployed an AiTM phishing reverse proxy (e.g., Evilginx) 2 hours earlier (Fiche 21: AiTM). The user legitimately authenticated and completed MFA on the attacker’s proxy; the attacker extracted the ESTSAUTH cookie and replayed it from their proxy infrastructure.

---

Common Pitfalls and Traps

Pitfall	Reality	Consequence
Ignoring Non-Interactive Sign-Ins	Once an access token expires, workloads silently refresh via non-interactive sign-ins.	Missing the primary timeline of attacker activity conducted via automated scripts.
Trusting “MFA Satisfied” blindly	”Previously satisfied” often indicates token replay or PRT reuse, not a fresh live challenge.	Incorrectly assuming the user approved an MFA push request during the malicious session.
Relying on Country Code alone	Threat actors extensively use residential proxy networks (e.g., Luminati/BrightData) located in the victim’s home country.	Dismissing malicious logins because the IP geolocation matches the corporate headquarters’ country.

---

Key Takeaways

1. Entra ID is the central identity broker: All M365 authentication flows through Entra ID and issues OAuth 2.0 / OIDC tokens.
2. Conditional Access is an evaluation engine: It decides access in real-time based on identity, device, location, and risk signals.
3. Session Replay bypasses MFA: Stolen cookies and tokens bypass authentication gates without generating new MFA challenges.
4. Log retention is brief: Without external export, Entra logs vanish in 7 or 30 days.

---

Feature State in 2026

Recent Changes

• Continuous Access Evaluation (CAE): Fully enforced across Exchange Online, SharePoint, and Teams. Revoking a user’s session or changing their password revokes access within minutes rather than waiting for token expiration.
• Phishing-Resistant MFA Enforcement: Broad adoption of FIDO2 security keys, Windows Hello for Business, and Microsoft Authenticator number matching to eliminate legacy push fatigue.

Deprecated Features

• Legacy Per-User MFA settings portal is deprecated in favor of Entra Conditional Access authentication strengths.
• Basic Authentication is completely eliminated.

Current Limitations

• Geolocation Inaccuracy: IP-to-location mapping can lag or report cellular carrier gateways hundreds of kilometers away from the physical device.

---

References

• Microsoft Learn: What is Microsoft Entra ID?
• Microsoft Learn: Conditional Access Architecture and Documentation
• Microsoft Learn: Microsoft Entra Sign-In Logs Overview
• Hermes Codex: Active Directory to Microsoft Entra ID Architectural Bridge