Investigation des journaux de provisioning entra

Dans les infrastructures d’entreprise modernes, la gestion des identités dépasse largement la création manuelle d’utilisateurs. Les organisations s’appuient sur des moteurs d’approvisionnement automatisés qui ingèrent les dossiers des collaborateurs depuis les Systèmes d’Information des Ressources Humaines (SIRH tels que Workday ou SAP SuccessFactors) vers Microsoft Entra ID, puis répercutent ces identités vers les applications SaaS d’entreprise (Salesforce, AWS, ServiceNow, GitHub) via le protocole SCIM (System for Cross-domain Identity Management).

Lorsqu’un attaquant compromet un progiciel RH, dérobe des secrets d’API ou modifie les configurations de synchronisation, il peut créer silencieusement des comptes collaborateurs fantômes, manipuler des attributs pour détourner des groupes administratifs dynamiques, ou provoquer une suspension massive de comptes métiers.

Ces opérations de cycle de vie automatisées échappent aux journaux d’audit d’annuaire classiques et laissent leur trace exclusive au sein des journaux de provisioning de Microsoft Entra ID (Provisioning Logs).

Concept

Le service d’approvisionnement d’Entra ID fonctionne comme un moteur de réconciliation d’état automatisé exécutant des cycles de synchronisation récurrents (généralement toutes les 20 à 40 minutes) :

graph TD
    subgraph "Provisioning Inbound piloté par les RH"
        HR[SIRH amont<br/>Workday, SAP, Ceridian] -->|Appel API / Scrutation| SYNC_IN[Service de Provisioning Entra]
        SYNC_IN -->|Création / Mise à jour| ENTRA_IN[Magasin d'Identités Entra ID]
    end

    subgraph "Provisioning Outbound SaaS (SCIM)"
        ENTRA_IN -->|Évaluation du périmètre| SYNC_OUT[Moteur Client SCIM]
        SYNC_OUT -->|API REST SCIM 2.0| SAAS[Applications SaaS cibles<br/>Salesforce, AWS, ServiceNow, Box]
    end

    subgraph "Synchronisation Hybride Cloud Sync"
        ENTRA_IN -->|Agent Cloud Sync| ONPREM[Active Directory sur site]
    end

    SYNC_IN -->|Génération de télémétrie| PROV_LOGS["Journaux de Provisioning Entra<br/>(/auditLogs/provisioning | AADProvisioningLogs)"]
    SYNC_OUT -->|Génération de télémétrie| PROV_LOGS

Les 3 topologies d’approvisionnement

Provisioning inbound piloté par les RH : les comptes sont créés et mis à jour automatiquement à partir des dossiers d’employés du SIRH. Entra ID génère le compte cloud, calcule le nom d’utilisateur principal (UPN), affecte les mots de passe initiaux et synchronise les métadonnées organisationnelles.
Provisioning outbound vers les applications SaaS (SCIM 2.0) : entra ID approvisionne, met à jour et désactive les comptes au sein d’applications SaaS tierces dès lors que des utilisateurs sont assignés à l’application ou membres d’un groupe synchronisé.
Microsoft entra cloud sync (hybride) : assure la synchronisation bidirectionnelle des utilisateurs et groupes entre les forêts Active Directory locales et le cloud au moyen d’agents légers managés dans le cloud.

Pourquoi c’est important en DFIR

Les journaux de provisioning représentent un angle mort fréquent des équipes de sécurité, trop souvent focalisées sur les seuls logs de connexion et d’audit classique :

Création de comptes fantômes (shadow employees) : un attaquant ayant compromis des identifiants d’API sur un SIRH (ex. Workday) crée une fausse fiche de contractant. Le moteur de provisioning génère automatiquement un compte corporate légitime dans Entra ID, doté d’une boîte mail interne, sans déclencher la moindre alerte de création manuelle d’utilisateur.
Détournement de groupes dynamiques par altération d’attributs : les groupes dynamiques Entra octroient fréquemment des accès sensibles ou des exemptions d’accès conditionnel sur la base d’attributs (user.department -eq "IT Security"). Manipuler un attribut dans le SIRH permet d’hériter furtivement de privilèges d’administration.
Usurpation d’ImmutableID (détournement de fédération) : la modification de l’ancre source (onPremisesImmutableId / EmployeeId) permet de lier un compte cloud à un compte Active Directory local malveillant afin de contourner l’authentification.
Déni de service sur les applications métiers (déprovisionnement massif) : un attaquant altère les filtres de périmètre SCIM pour provoquer la désactivation immédiate de milliers de comptes utilisateurs dans AWS ou Salesforce en un seul cycle de synchronisation.

Dissection du schéma JSON : les champs clés

Lors de l’interrogation via Microsoft Graph API (/auditLogs/provisioning) ou Azure Log Analytics (AADProvisioningLogs), les champs suivants constituent la preuve forensique :

Champ (Graph API)	Champ (Log Analytics)	Signification forensique et interprétation
`id`	`CorrelationId` / `Id`	GUID unique représentant l’étape de synchronisation pour une identité donnée.
`activityDateTime`	`TimeGenerated`	Horodatage UTC exact du traitement de l’opération par le moteur de synchronisation.
`jobId`	`JobId`	Identifiant de la tâche de synchronisation configurée pour le connecteur.
`cycleId`	`CycleId`	GUID identifiant le lot d’exécution. Tous les comptes traités lors du même cycle partagent cet identifiant.
`provisioningAction`	`Action`	Type d’action : `create`, `update`, `delete`, `stageddelete`, `disable`, `other`.
`provisioningStatusInfo`	`Status` / `ResultDescription`	Statut du traitement : `success`, `failure`, `skipped`, `warning` et détails d’erreur.
`sourceSystem`	`SourceSystem`	Système d’origine : nom (ex. “Workday to Microsoft Entra ID”, “Microsoft Entra ID”) et identifiant.
`targetSystem`	`TargetSystem`	Système de destination : nom (ex. “Salesforce”, “Microsoft Entra ID”, “AWS SSO”) et identifiant.
`sourceIdentity`	`SourceIdentity`	Attributs de l’identité source : identifiant, type (`User`, `Group`) et nom d’affichage.
`targetIdentity`	`TargetIdentity`	Attributs de l’identité cible : identifiant, type et nom d’affichage.
`provisioningSteps`	`ProvisioningSteps`	Étapes internes : `IdentityMatching`, `EntryExport`, `EntryImport`. Révèle les règles de correspondance.
`modifiedProperties`	`ModifiedProperties`	Artefact forensique fondamental. Tableau détaillant `name`, `oldValue` et `newValue` pour chaque attribut modifié.

Actions de provisioning critiques pour le DFIR

L’analyste DFIR doit surveiller en priorité les actions de synchronisation suivantes :

Action de provisioning	Contexte / Scénario	Interprétation forensique et indicateurs
`create`	Source : Workday / SAP Cible : Entra ID	Création de compte fantôme : Compte généré automatiquement depuis un SIRH. Vérifier la validité RH.
`create`	Source : Entra ID Cible : AWS / Salesforce	Nouvel accès créé dans un environnement SaaS sensible. Vérifier les règles d’attribution de licences.
`update`	Tout système	Modification d’attributs. Inspecter `modifiedProperties` (changements de département, UPN, téléphone, rôle).
`disable`	Source : Entra ID Cible : App SaaS	Compte désactivé dans le SaaS. Un pic soudain trahit une manipulation de filtres SCIM.
`delete`	Tout système	Suppression définitive d’un compte. Utilisé pour saboter des accès ou effacer des comptes de rebond.
`stageddelete`	Tout système	Compte marqué pour suppression en phase de quarantaine avant purge définitive.

Ce qui est possible vs ce qui n’est pas possible

Ce qui est possible

Tracer l’origine formelle d’une identité : établir avec certitude si un compte a été créé manuellement par un administrateur dans le portail, ou automatiquement par un connecteur SIRH.
Reconstituer l’historique des modifications d’attributs : connaître l’ancienne et la nouvelle valeur de tout attribut synchronisé au cours des 30 derniers jours.
Détecter l’empoisonnement de règles SCIM : identifier le mappage d’attributs malveillants (ex. lier un e-mail externe à un compte à privilèges).
Relier des identités multi-plateformes : associer un matricule RH d’employé à ses identifiants SaaS cibles (ex. relier le matricule Workday EMP-8841 au compte Salesforce sales_bot@entreprise.fr).

Ce qui n’est pas possible

Tracer les actions de l’utilisateur dans l’application SaaS : les logs de provisioning confirment la création du compte dans AWS ; ils ne consignent aucunement les commandes AWS CLI exécutées par l’attaquant.
Auditer les modifications manuelles du portail entra : si un administrateur modifie directement un utilisateur dans le portail Entra, l’événement apparaît dans Directory Audit Logs (m365-10), jamais dans Provisioning Logs.
Récupérer l’historique au-delà de 30 jours sans log analytics : la rétention native est strictement bornée à 30 jours avec les licences Entra P1/P2.
Restituer le corps brut des requêtes d’origine : entra consigne les deltas d’attributs analysés (modifiedProperties), mais n’archive pas les payloads JSON/REST bruts reçus des webhooks du SIRH.

Méthodologie d’investigation : extraction et détection KQL

# ==============================================================================
# Hermes Codex - Extracteur des logs de provisioning Entra ID
# Exporte les événements de synchronisation SIRH et SCIM avec pagination
# ==============================================================================

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 "[*] Extraction des journaux de provisioning depuis $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 "    [+] $($allEvents.Count) événements collectés..." -ForegroundColor Gray
    Start-Sleep -Milliseconds 150
} while ($null -ne $provUri)

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

$hash = Get-FileHash -Path $outputFile -Algorithm SHA256
Write-Host "[✓] Extraction terminée : $($allEvents.Count) événements. SHA-256 : $($hash.Hash)" -ForegroundColor Green

// ==============================================================================
// Détection des créations de comptes pilotées par un connecteur RH
// Contexte : Création illégitime de collaborateurs fantômes via le SIRH
// ==============================================================================
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

// ==============================================================================
// Détection d'un pic anormal de désactivations / suppressions de comptes SaaS
// ==============================================================================
let FenetreTemps = 1h;
let SeuilSuppression = 25; // Plus de 25 comptes désactivés par heure

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

// ==============================================================================
// Détection de modifications d'attributs critiques sur les comptes
// ==============================================================================
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

Exemple d’investigation : le collaborateur fantôme

Contexte de l’incident

Le SOC détecte des requêtes suspectes sur les dépôts de code internes émanant du compte j.martin_prestataire@entreprise.fr. Aucun ticket de recrutement ou d’habilitation n’existe dans l’ITSM pour cette personne.

Déroulement de l’analyse

Impasse dans les logs d’audit d’annuaire : l’analyste cherche Add user dans AuditLogs (m365-10). La recherche renvoie 0 résultat, laissant croire à une faille critique inconnue.
Pivot vers les journaux de provisioning : l’analyste interroge AADProvisioningLogs :
- Action : create.
- TimeGenerated : 2026-09-02T14:18:22Z.
- SourceSystem : Workday to Microsoft Entra ID.
- TargetIdentity.UserPrincipalName : j.martin_prestataire@entreprise.fr.
- SourceIdentity.Id : RH-PREST-99120.
- ProvisioningSteps : succès de la correspondance des règles d’ingestion Workday.
Identification de la cause racine :
- La création du compte ne résulte pas d’une élévation de privilèges dans Entra ID, mais d’une compromission en amont de l’interface d’administration Workday.
- L’attaquant y a injecté une fiche de prestataire fictive.
- Le moteur de provisioning Inbound a ingéré la fiche lors de son cycle régulier de 40 minutes, a généré l’e-mail corporate et a affecté les licences par défaut.
Élévation par attribut dynamique :
- L’examen des logs de provisioning révèle une action update à 14h55:00Z modifiant le champ Department de Logistique à Platform Engineering.
- Cette modification a automatiquement intégré le compte dans un groupe dynamique Entra donnant accès aux environnements GitHub et Azure DevOps.

Sans l’examen des journaux de provisioning Entra, l’équipe DFIR aurait cherché en vain une session administrative compromise dans Entra ID, ignorant le vecteur d’intrusion initial situé dans le SIRH.

Doctrine transversale : télémétrie de provisioning vs preuve formelle

Les données extraites des journaux de provisioning s’inscrivent dans l’échelle de certitude technique de Hermes Codex :

+-------------------------------------------------------------------------------+
|                      LES 7 NIVEAUX DE CERTITUDE FORENSIQUE                     |
|                                                                               |
|  1. Possible     -> L'architecture prend en charge la synchronisation SCIM/RH. |
|  2. Configuré   -> Le connecteur est actif, les filtres et mappages définis.   |
|  3. Autorisé    -> Le connecteur dispose des droits d'écriture d'annuaire.    |
|  4. Accessible  -> Les endpoints d'API SIRH et SaaS sont mutuellement joints.|
|  5. Utilisé     -> Le moteur a déclenché un cycle de synchronisation effectif.|
|  6. Observé     -> L'enregistrement figure dans AADProvisioningLogs avec diff.|
|  7. Prouvé      -> La fraude RH ou l'injection de compte fantôme est validée. |
+-------------------------------------------------------------------------------+

Distinctions forensiques fondamentales

Configuré != utilisé : un connecteur SCIM vers Salesforce est configuré, mais si la tâche est en pause ou en quarantaine pour erreur de schéma, aucune modification n’a été utilisée.
Utilisé != malveillant : des volumes importants de mises à jour de comptes surviennent couramment lors des vagues de mobilités internes ou d’intégration de stagiaires. Prouver qu’un déprovisionnement massif était malveillant exige de démontrer :
- Que les filtres de périmètre ont été altérés par une identité compromise (tracé dans Directory Audits).
- Qu’aucune note de service ou campagne RH planifiée n’explique les suppressions.
Observé != prouvé : un log consignant la création d’un utilisateur depuis Workday constitue un fait technique observé. Pour prouver qu’il s’agit d’un « collaborateur fantôme », l’analyste doit faire valider par la direction des ressources humaines qu’aucune personne physique ne correspond au matricule généré.

Pièges et confusions fréquentes

Piège	Cause technique	Conséquence pour l’enquête	Action corrective
Chercher les comptes créés par le SIRH dans AuditLogs	Les créations automatisées par le moteur de synchronisation ne génèrent pas d’événement standard `Add user`.	L’analyste conclut faussement à l’existence d’une faille ou d’un compte invisible.	Interroger impérativement `AADProvisioningLogs` pour vérifier l’origine d’un compte.
Ignorer les événements « skipped »	Les logs consignent les comptes ignorés pour non-respect des filtres de portée.	Manque de contexte sur les raisons de la non-synchronisation d’un groupe ou compte.	Analyser les statuts `ProvisioningStatusInfo.Status == "skipped"`.
Penser que la révocation SCIM est instantanée	Le déprovisionnement SCIM fonctionne par cycles batch (toutes les 20 à 40 minutes).	Le compte désactivé dans Entra conserve son accès SaaS pendant la durée du cycle.	Pour un confinement d’urgence, révoquer manuellement les sessions directement dans le SaaS cible.
Confondre cloud sync et azure AD Connect	Cloud Sync consigne dans les Provisioning Logs du cloud ; Azure AD Connect consigne dans l’Event Viewer Windows local.	Recherche vaine dans le portail pour des erreurs d’un serveur AAD Connect traditionnel.	Connaître la topologie hybride : Cloud Sync = logs cloud ; AAD Connect = logs sur site.
Négliger les effets de cascade sur les groupes dynamiques	La modification d’un attribut par SCIM recalcule l’appartenance aux groupes dynamiques.	Incapacité à comprendre comment un attaquant a obtenu des droits sans attribution manuelle.	Auditer les règles des groupes dynamiques au regard des attributs modifiés dans le provisioning.

État de la fonctionnalité en 2026

Changements récents

Écosystème SIRH inbound étendu : prise en charge native d’API d’ingestion pour plus de 15 progiciels RH majeurs (Workday, SuccessFactors, Ceridian Dayforce, etc.).
Télémétrie renforcée de quarantaine : en cas de détection d’une suppression anormale dépassant le seuil de sécurité du tenant, le service bloque automatiquement le job et consigne des alertes critiques.
Écriture différée de groupes cloud sync : Microsoft Entra Cloud Sync enregistre désormais l’ensemble des opérations de rétro-écriture de groupes directement dans les journaux de provisioning cloud.

Fonctionnalités dépréciées

Outils graphiques locaux pour cloud sync : remplacés intégralement par l’administration centralisée dans le portail Entra et les API Microsoft Graph.
Authentification basique pour les endpoints SCIM : rejetée systématiquement. L’authentification par jeton Bearer OAuth 2.0 ou certificat est obligatoire.

Limitations actuelles

Fréquence des cycles inaltérable : les cycles de synchronisation automatique ne peuvent être configurés en deçà de la période par défaut de la plateforme (20 à 40 minutes). L’approvisionnement à la demande (provisionOnDemand) est requis pour forcer un compte unitaire.
Troncature des volumétries d’attributs : pour les groupes massifs comportant des milliers de membres, certains tableaux d’attributs peuvent être tronqués dans l’affichage standard Log Analytics.

Points clés à retenir

Les provisioning logs tracent le cycle de vie automatisé : indispensables pour les flux Inbound SIRH, Outbound SaaS (SCIM) et Cloud Sync hybride.
Le SIRH est un vecteur d’attaque initial à surveiller : la compromission d’un progiciel RH permet de générer des comptes collaborateurs furtifs sans alerte d’annuaire.
Surveiller les deltas dans modifiedProperties : l’altération d’attributs peut ouvrir des privilèges administratifs via les règles de groupes dynamiques.
Détecter les pics de déprovisionnement : les suppressions massives d’utilisateurs SaaS trahissent souvent un sabotage de connecteurs SCIM.
Corréler entre les plans : croiser la création dans les Provisioning Logs avec la première connexion dans SigninLogs et les accès fichiers dans l’UAL Purview.