Microsoft Entra Provisioning Logs Investigation

In modern enterprise architectures, identity management extends far beyond manual account creation. Organizations rely on automated identity synchronization engines that ingest employee records from Human Resources Information Systems (HRIS like Workday or SAP SuccessFactors) into Microsoft Entra ID, and push identities outbound to software-as-a-service (SaaS) applications (such as Salesforce, AWS, ServiceNow, and GitHub) via SCIM (System for Cross-domain Identity Management).

When threat actors compromise upstream HR platforms, third-party API credentials, or provisioning configurations, they can silently spawn rogue corporate accounts, manipulate attributes to hijack dynamic administrative groups, or trigger catastrophic mass account deprovisioning.

These automated lifecycle actions bypass standard directory audit workflows and leave their exclusive evidentiary trail within Microsoft Entra ID Provisioning Logs.

---

Concept

The Entra ID provisioning service operates as an automated state-reconciliation engine running recurring synchronization cycles (typically every 20 to 40 minutes):

graph TD
    subgraph "Inbound HR Provisioning"
        HR[Upstream HR / HRIS<br/>Workday, SAP, Ceridian] -->|API Push / Poll| SYNC_IN[Entra Provisioning Service]
        SYNC_IN -->|Create / Update User| ENTRA_IN[Entra ID Directory Store]
    end

    subgraph "Outbound SCIM App Provisioning"
        ENTRA_IN -->|Evaluate Scope & Group| SYNC_OUT[SCIM Client Engine]
        SYNC_OUT -->|SCIM 2.0 REST API| SAAS[Downstream SaaS Applications<br/>Salesforce, AWS, ServiceNow, Box]
    end

    subgraph "Hybrid & Cloud Sync"
        ENTRA_IN -->|Cloud Sync Agent| ONPREM[On-Premises Active Directory]
    end

    SYNC_IN -->|Generate Telemetry| PROV_LOGS["Entra ID Provisioning Logs<br/>(/auditLogs/provisioning | AADProvisioningLogs)"]
    SYNC_OUT -->|Generate Telemetry| PROV_LOGS

The Three Provisioning Topologies

1. Inbound HR-driven Provisioning: Accounts are created and managed based on employee records in external HR applications. Entra ID generates cloud identities, generates User Principal Names (UPNs), sets initial passwords, and updates organizational metadata.
2. Outbound SaaS Application Provisioning (SCIM 2.0): Entra ID provisions, updates, and deprovisions user and group accounts in external SaaS applications whenever users are assigned to enterprise applications or added to synced groups.
3. Microsoft Entra Cloud Sync (Hybrid): Synchronizes users, groups, and contacts between on-premises Active Directory forests and Entra ID using lightweight cloud-managed agents, including group writeback and cross-forest provisioning.

---

Why It Matters in DFIR

Provisioning logs represent a blindspot for many incident responders who focus solely on sign-in and directory audit logs. Adversaries leverage the automated provisioning plane for high-impact tactics:

• Rogue Account Seeding (Shadow Employees): An attacker with compromised credentials on an upstream HR system (e.g., Workday API) creates a fake contractor record. The provisioning engine automatically generates a legitimate corporate Entra account, complete with valid email and internal domain membership, evading SOC alerts that watch for manual user creations.
• Dynamic Group Hijacking via Attribute Tampering: Entra ID dynamic groups frequently grant elevated permissions or Conditional Access exemptions based on user attributes (e.g., user.department -eq "IT Security"). Manipulating synced HR attributes allows an adversary to silently inherit administrative roles.
• ImmutableID Hijacking (Federation Takeover): Modifying the source anchor attribute (onPremisesImmutableId / EmployeeId) allows an attacker to bind a target cloud account to a rogue on-premises identity, facilitating federation authentication bypass.
• SaaS Denial of Service (Mass Deprovisioning): An adversary alters SCIM scoping filters or application assignment groups to trigger mass account suspension across enterprise tools (disabling thousands of accounts in AWS or Salesforce within a single cycle).

---

JSON Schema Deep Dive: The Critical Forensic Fields

When querying provisioning logs via Microsoft Graph API (/auditLogs/provisioning) or Azure Log Analytics (AADProvisioningLogs), the following fields form the core evidentiary structure:

Field Name (Graph API)	Field Name (Log Analytics)	Forensic Significance & Investigative Interpretation
id	CorrelationId / Id	Unique GUID representing the specific provisioning synchronization step for a single identity.
activityDateTime	TimeGenerated	UTC timestamp when the synchronization action was processed by the provisioning engine.
jobId	JobId	Identifier of the synchronization job configuration. Connects all actions from the same connector.
cycleId	CycleId	GUID identifying the execution batch. All accounts modified in the same 40-minute sync cycle share this ID.
provisioningAction	Action	The synchronization operation: create, update, delete, stageddelete, disable, other.
provisioningStatusInfo	Status / ResultDescription	Status object: status (success, failure, skipped, warning) and errorInformation.
sourceSystem	SourceSystem	Origin of identity data: contains name (e.g., “Workday to Microsoft Entra ID”, “Microsoft Entra ID”) and id.
targetSystem	TargetSystem	Destination of identity data: contains name (e.g., “Salesforce”, “Microsoft Entra ID”, “AWS SSO”) and id.
sourceIdentity	SourceIdentity	Identity attributes in the source system: id, identityType (“User”, “Group”), displayName.
targetIdentity	TargetIdentity	Identity attributes in the destination system: id, identityType, displayName.
provisioningSteps	ProvisioningSteps	Array detailing stage progression: IdentityMatching, EntryExport, EntryImport. Reveals matching rules.
modifiedProperties	ModifiedProperties	Primary forensic artifact. Dynamic array showing name, oldValue, and newValue for all synced attributes.

---

Critical Provisioning Actions for DFIR

Responders must monitor and hunt for the following high-risk provisioning operations:

Provisioning Action	Context / Scenario	Forensic Significance & Threat Indicators
create	Source: Workday / SAP Target: Entra ID	Rogue User Creation: An account was generated automatically from an HR source. Verify HR ticket validity.
create	Source: Entra ID Target: AWS / Salesforce	New account provisioned into high-value SaaS environment. Check application assignment permissions.
update	Any	Attribute alteration. Inspect modifiedProperties for changes to department, roles, telephoneNumber, or ImmutableId.
disable	Source: Entra ID Target: SaaS App	Account deactivated in downstream SaaS. Look for sudden spikes indicating malicious scoping filter manipulation.
delete	Any	Permanent account removal. Used by attackers to scrub temporary service accounts or sabotage corporate operations.
stageddelete	Any	Account flagged for deletion in quarantine/staging mode before permanent purging.

---

What Is Possible vs What Is Not Possible

What Is Possible

• Tracking Identity Provenance: Proving definitively whether an account was created by a human administrator in the portal/Graph, or spawned automatically by an HR synchronization connector.
• Auditing Attribute Synchronization History: Identifying the exact previous and updated values for attributes synchronized across systems over the past 30 days.
• Detecting SCIM Poisoning: Uncovering unauthorized attribute mappings (e.g., mapping a malicious external email to an administrative user attribute).
• Correlating Cross-Platform Identities: Mapping an on-premises or HR employee ID to its downstream SaaS usernames (e.g., matching Workday ID EMP-8841 to Salesforce user sales_bot@corp.com).

What Is Not Possible

• Tracking User Actions Inside Downstream SaaS: Provisioning logs confirm that an account was created in AWS IAM Identity Center; they do not record which AWS CLI commands the attacker executed.
• Auditing Direct Portal Changes: If an administrator edits an account attribute directly in the Entra ID admin center, this is recorded in Directory Audit Logs (m365-10), not in Provisioning Logs.
• Recovering Logs Beyond 30 Days Without Log Analytics: Native retention for provisioning telemetry is strictly 30 days under Entra P1/P2.
• Recovering Discarded Source Payloads: Entra logs the parsed attribute delta (modifiedProperties), but does not archive the entire raw REST payload received from upstream HRIS webhooks.

---

Investigation Methodology: Forensic Extraction and KQL Playbooks

PowerShell Provisioning Extractor

# ==============================================================================
# Hermes Codex - Entra ID Provisioning Log Extractor (Microsoft.Graph)
# Extracts automated lifecycle events, HR sync records, and SCIM operations
# ==============================================================================

Import-Module Microsoft.Graph.Authentication, Microsoft.Graph.Reports -ErrorAction Stop
Connect-MgGraph -Scopes "AuditLog.Read.All", "Directory.Read.All" -NoWelcome

$DaysBack = 30
$StartDate = (Get-Date).AddDays(-$DaysBack).ToUniversalTime().ToString("yyyy-MM-ddTHH:mm:ssZ")
$OutDir = "./Entra_Provisioning_$(Get-Date -Format 'yyyyMMdd')"
New-Item -ItemType Directory -Path $OutDir -Force | Out-Null

Write-Host "[*] Extracting Entra Provisioning Logs since $StartDate..." -ForegroundColor Cyan

$filter = "activityDateTime ge $StartDate"
$provUri = "https://graph.microsoft.com/v1.0/auditLogs/provisioning?`$filter=$filter&`$top=500"

$allEvents = [System.Collections.Generic.List[PSObject]]::new()
do {
    $resp = Invoke-MgGraphRequest -Method GET -Uri $provUri
    if ($resp.value) { $allEvents.AddRange($resp.value) }
    $provUri = $resp.'@odata.nextLink'
    Write-Host "    [+] Collected $($allEvents.Count) provisioning events..." -ForegroundColor Gray
    Start-Sleep -Milliseconds 150
} while ($null -ne $provUri)

$outputFile = "$OutDir/ProvisioningLogs_Last30Days.jsonl"
$allEvents | ForEach-Object { $_ | ConvertTo-Json -Compress -Depth 10 } | Set-Content -Path $outputFile

$hash = Get-FileHash -Path $outputFile -Algorithm SHA256
Write-Host "[✓] Extraction Complete. Total: $($allEvents.Count) events. SHA-256: $($hash.Hash)" -ForegroundColor Green

KQL: HR-Inbound Rogue Account Creation

// ==============================================================================
// Detect Inbound HR User Creations (Workday / SuccessFactors -> Entra ID)
// Threat Context: Unauthorized creation of corporate accounts via HR integration
// ==============================================================================
AADProvisioningLogs
| where TimeGenerated >= ago(30d)
| where SourceSystem has_any ("Workday", "SAP", "SuccessFactors", "Ceridian")
| where Action =~ "create"
| where ResultType =~ "success"
| extend TargetUPN = tostring(TargetIdentity.UserPrincipalName),
         TargetDisplayName = tostring(TargetIdentity.DisplayName),
         SourceEmployeeId = tostring(SourceIdentity.Id)
| project TimeGenerated, Action, SourceSystem, TargetSystem, SourceEmployeeId,
          TargetUPN, TargetDisplayName, CorrelationId
| order by TimeGenerated desc

KQL: Mass Account Deprovisioning (DoS)

// ==============================================================================
// Detect Mass Account Disable / Deletion Spikes in SaaS via SCIM
// Threat Context: Adversary modifying SCIM scopes to cause corporate disruption
// ==============================================================================
let SpanningWindow = 1h;
let DeletionThreshold = 25; // More than 25 deprovisions per hour

AADProvisioningLogs
| where TimeGenerated >= ago(7d)
| where Action in ("disable", "delete", "stageddelete")
| where ResultType =~ "success"
| summarize
    AffectedUsersCount = dcount(TargetIdentity.Id),
    SampleUsers = make_set(TargetIdentity.DisplayName, 10),
    TotalActions = count()
    by TargetSystem, bin(TimeGenerated, SpanningWindow)
| where AffectedUsersCount >= DeletionThreshold
| order by AffectedUsersCount desc

KQL: Critical Attribute Tampering

// ==============================================================================
// Detect Suspicious Synced Attribute Changes on Privileged / Sensitive Accounts
// ==============================================================================
AADProvisioningLogs
| where TimeGenerated >= ago(30d)
| where Action =~ "update"
| mv-expand ModifiedProperties
| extend PropName = tostring(ModifiedProperties.Name),
         OldValue = tostring(ModifiedProperties.OldValue),
         NewValue = tostring(ModifiedProperties.NewValue),
         TargetUser = tostring(TargetIdentity.UserPrincipalName)
| where PropName in ("Department", "JobTitle", "ImmutableId", "EmployeeId", "Role", "Manager")
| project TimeGenerated, TargetSystem, TargetUser, PropName, OldValue, NewValue, CorrelationId
| order by TimeGenerated desc

---

Investigation Scenario: The “Ghost Employee” Incident

Incident Context

The SOC detects unauthorized access to internal development repositories using an account named j.miller_contractor@corp.com. Identity records show no ticket in the IT Service Management system approving this user.

Forensic Investigation Path

1. Directory Audits Dead End: The investigator searches AuditLogs (m365-10) for Add user. The search returns zero results, leading the tier-1 analyst to believe the account was created through an undocumented backdoor.
2. Pivoting to Provisioning Logs: The investigator executes a query on AADProvisioningLogs:
   • Action: create.
   • TimeGenerated: 2026-09-02T14:18:22Z.
   • SourceSystem: Workday to Microsoft Entra ID.
   • TargetIdentity.UserPrincipalName: j.miller_contractor@corp.com.
   • SourceIdentity.Id: HR-CONT-99120.
   • ProvisioningSteps: Status indicates successful matching against Workday employee feed.
3. Root Cause Analysis:
   • The user creation was not an internal Entra compromise, but an upstream compromise of the corporate Workday HR administrative interface.
   • The threat actor used compromised HR credentials to insert a ghost contractor profile.
   • The automated Entra ID Inbound Provisioning engine ingested the record during its standard 40-minute cycle, automatically generated the email address, and provisioned the user with standard corporate licenses.
4. Subsequent Attribute Elevation:
   • Further inspection of AADProvisioningLogs shows a subsequent update action at 14:55:00Z updating Department from Logistics to Platform Engineering.
   • This attribute change automatically placed the user into a dynamic Entra security group that granted access to Azure DevOps and internal GitHub repositories.

Without inspecting the Entra ID Provisioning Logs, the incident response team would have spent days investigating phantom Entra ID administrative sessions, missing the true initial access vector inside the HR platform.

---

The Transversal Doctrine: Provisioning Telemetry vs Malicious Proof

Evidence extracted from provisioning logs must be classified according to the Hermes Codex certainty scale:

+-------------------------------------------------------------------------------+
|                      THE 7 LEVELS OF FORENSIC CERTAINTY                       |
|                                                                               |
|  1. Possible     -> Workload supports automated SCIM/HR synchronization.      |
|  2. Configured   -> Provisioning job enabled, scope defined, mapping active.  |
|  3. Authorized   -> Sync connector service principal holds API permissions.   |
|  4. Accessible   -> Network reachability between Entra and target SaaS API.   |
|  5. Utilized     -> Provisioning engine triggered synchronization cycle.      |
|  6. Observed     -> Entry recorded in AADProvisioningLogs with attribute diff.|
|  7. Proven       -> Upstream HR fraud or rogue SCIM manipulation confirmed.   |
+-------------------------------------------------------------------------------+

Forensic Distinctions in Provisioning Logs

1. Configured != Utilized: A SCIM connector to Salesforce is configured, but if the synchronization schedule is paused or in quarantine due to schema errors, account updates are not utilized.
2. Utilized != Malicious: High-volume account updates are normal in dynamic corporate environments (e.g., end-of-month employee offboarding). Proving that a mass deprovisioning event was malicious requires demonstrating that:
   • The provisioning configuration was altered by an unauthorized actor (observable in Directory Audits).
   • Scoping filters were deliberately modified to exclude active users.
   • No authorized HR change freeze or restructuring was scheduled.
3. Observed != Proven: An entry showing a user created via Workday is an observed platform event. Proving it was a fraudulent “ghost employee” requires verifying with the corporate HR and payroll departments that no legal individual corresponds to the employee ID.

---

Common Pitfalls and Traps

Trap	Technical Root Cause	Investigative Impact	Corrective Action
Searching Directory Audits for HR-Created Users	Inbound HR provisioning events do not register under standard Add user directory audits.	Responders falsely conclude that accounts were created by an invisible zero-day.	Always search AADProvisioningLogs whenever investigating the origin of suspect accounts.
Ignoring “Skipped” Events	Provisioning logs record users skipped due to scoping filter mismatches.	Missing context on why an attacker’s target account was not modified or protected.	Inspect ProvisioningStatusInfo.Status == "skipped" to analyze scoping filter evaluations.
Assuming SCIM Deletion is Instantaneous	SCIM deprovisioning runs on batch cycles (every 20-40 minutes).	Expecting an account disabled in Entra ID to lose SaaS access immediately.	For emergency containment, manually revoke sessions directly in downstream SaaS applications.
Confusing Cloud Sync with Azure AD Connect	Entra Cloud Sync logs appear in Provisioning Logs; legacy Azure AD Connect logs appear on on-premises Windows Event Logs.	Looking in the cloud portal for sync errors caused by an on-premises AAD Connect server.	Know your hybrid architecture: Cloud Sync = cloud logs; AAD Connect Sync = on-prem Event Viewer.
Overlooking Dynamic Group Cascade Effects	An attribute updated via SCIM triggers automated group membership recalculation.	Failing to identify how an attacker obtained administrative rights after a minor profile change.	Audit Entra ID dynamic group membership rules against attributes tracked in provisioning logs.

---

2026 Feature State: Entra ID Provisioning Logs

Recent Changes

• Expanded Inbound HR Ecosystem: Native API-driven inbound provisioning connectors now support direct integration with over 15 major HR platforms, including Workday, SAP SuccessFactors, Ceridian Dayforce, and custom API webhooks.
• Enhanced Quarantine & Safeguard Telemetry: When the provisioning engine detects an abnormal spike in deletions (exceeding tenant threshold limits), it halts synchronization, places the job in quarantine, and logs high-priority warning events.
• Cloud Sync Cross-Forest Group Writeback: Microsoft Entra Cloud Sync now logs all hybrid group writeback operations natively within the central cloud provisioning logs.

Deprecated Features

• Legacy Synchronization Service Manager GUI for Cloud Sync: On-premises GUI tools for Cloud Sync management have been superseded by centralized cloud portal reporting and Graph APIs.
• Basic Auth on SCIM Endpoints: Outbound SCIM connectors reject basic authentication. OAuth 2.0 bearer tokens or certificate-bound credentials are required.

Current Limitations

• Cycle Latency: Automated synchronization cycles cannot be configured to run faster than the platform default interval (typically 20-40 minutes). On-demand provisioning (provisionOnDemand) is required for immediate single-user testing.
• Payload Truncation: For extremely large objects with hundreds of multi-valued attributes (e.g., large distribution groups), nested property arrays can be truncated in standard Log Analytics views.

---

Key Takeaways

1. Provisioning logs track automated identity lifecycle: Essential for investigating inbound HR creation, outbound SaaS accounts (SCIM), and hybrid Cloud Sync.
2. HR platforms can be initial access vectors: Compromised HR systems can seed unauthorized “ghost” corporate accounts without triggering directory creation alerts.
3. Watch attribute deltas in modifiedProperties: Attribute changes can silently grant administrative privileges via dynamic group membership rules.
4. Monitor deprovisioning spikes: Mass disable or delete actions in SCIM indicate potential malicious tampering with synchronization filters.
5. Cross-correlate across logging planes: Connect provisioning events (AADProvisioningLogs) to authentication logs (SigninLogs) and application activity (Purview UAL).

---

References

• Microsoft Entra ID: Provisioning logs documentation
• Microsoft Graph API: provisioningObjectSummary resource type
• Microsoft Learn: How provisioning integrates with Microsoft Sentinel
• RFC 7644: System for Cross-domain Identity Management (SCIM) Protocol