Synchronisation Identité Hybride Entra Cloud-Only Privilégié Orphelin : l'Angle Mort de l'Audit Hybride

Synchronisation Identité Hybride Entra Cloud-Only Privilégié Orphelin Expliqués

Synchronisation identité hybride Entra cloud-only privilégié orphelin : les deux angles morts que couvre cet article sont les comptes cloud-only détenant un rôle Microsoft Entra privilégié qui n'entrent jamais dans le périmètre de gouvernance Tier 0 on-premises, et les utilisateurs synchronisés orphelins qu'Entra Connect laisse derrière lui après la suppression de leur compte on-premises. Les deux passent entre les mailles du pipeline de synchronisation qui fait normalement circuler proprement la plupart des objets entre l'Active Directory on-premises et Microsoft Entra ID, et les deux sont des angles morts d'audit propres aux environnements hybrides, et non à l'un ou l'autre des deux côtés pris isolément.

Le premier est le compte cloud-only privilégié : un utilisateur créé directement dans Entra ID, jamais synchronisé depuis l'AD on-premises, et détenant un rôle Microsoft Entra actif ou éligible PIM. Le second est l'utilisateur synchronisé orphelin : un objet qu'Entra Connect a autrefois synchronisé depuis l'AD, dont le compte source on-premises a depuis été supprimé ou exclu du périmètre de synchronisation, mais dont l'objet Entra ID n'est jamais proprement retiré. Aucun des deux n'apparaît dans les audits que la plupart des organisations hybrides mènent déjà, car ces audits sont construits autour d'un seul côté de la frontière de synchronisation — une revue de tiering on-premises scanne l'AD, et même un audit de sécurité Entra ID large part généralement du principe que chaque identité a encore une contrepartie on-premises active.

Comptes cloud-only privilégiés : un écart volontaire que les audits on-premises ne voient pas

Exclure les comptes Tier 0 de la synchronisation d'annuaire n'est pas une erreur — c'est une recommandation documentée par Microsoft. Microsoft indique explicitement que « Les comptes administrateur Tier 0 ne sont utilisés que pour les comptes AD on-premises. Ces comptes ne sont généralement pas synchronisés avec Microsoft Entra ID dans le cloud », et précise par ailleurs que « Les comptes Administrateur général (et autres groupes privilégiés) doivent être des comptes cloud-only sans lien avec l'Active Directory on-premises » (Secure access practices for administrators in Microsoft Entra ID).

L'angle mort n'est pas l'architecture — c'est l'écart de gouvernance qui s'ouvre autour d'elle. Une revue de tiering on-premises (qu'il s'agisse d'un audit manuel par rapport à un modèle comme le modèle de tiering d'Active Directory, ou d'un outil tel que PingCastle scannant l'AD) n'a aucune visibilité sur les affectations de rôles Entra ID, tout simplement parce qu'un compte cloud-only n'a jamais existé on-premises. Si le programme de gouvernance côté cloud n'a pas été construit avec la même rigueur — affectation éligible PIM plutôt qu'accès permanent, Conditional Access exigeant le MFA et un appareil conforme à l'activation, et revues d'accès périodiques — un Administrateur général cloud-only peut se retrouver avec une affectation active permanente, sans application du MFA et sans journalisation d'activation, invisible aux deux moitiés du programme d'audit à la fois.

Cet écart s'accompagne d'une surface d'attaque concrète. SyncJacking est une technique de prise de contrôle par hard-match, confirmée par le Microsoft Security Response Center comme un problème d'élévation de privilèges de sévérité Importante, dans laquelle un attaquant qui contrôle des attributs sur un objet AD on-premises peut forcer Entra Connect à faire correspondre (hard-match) cet objet à un utilisateur cloud-managed existant — y compris un utilisateur privilégié — et en prendre le contrôle de la source d'autorité (source of authority). La technique « ne laisse aucune trace dans les journaux AD on-premises et seulement une trace minimale dans les journaux Entra ID » (Semperis: Syncjacking Could Enable Entra ID Account Takeover).

Microsoft a depuis livré une mitigation au niveau de la plateforme. Selon la documentation de dépannage de Microsoft elle-même : « À partir du 1er juillet 2026, Microsoft Entra ID applique automatiquement le durcissement de sécurité du hard match », bloquant un hard match dès lors que le compte cloud cible a déjà onPremisesObjectIdentifier positionné, détient un rôle Entra privilégié actif, ou y est éligible (Microsoft Entra Connect: Troubleshoot errors during synchronization — InvalidHardMatch). Ce durcissement protège le chemin de prise de contrôle — il ne referme en rien l'écart de gouvernance qui a permis à un admin cloud-only non surveillé d'exister en premier lieu, ce qui est précisément ce que ciblent les sections détection et remédiation de cet article. Il vaut aussi la peine d'associer cette revue côté accès aux comptes d'accès d'urgence que chaque tenant conserve pour un véritable scénario break-glass — voir hygiène des comptes break-glass Entra ID pour savoir comment ceux-ci doivent (et ne doivent pas) être scopés.

Utilisateurs synchronisés orphelins : que se passe-t-il quand Entra Connect ne supprime pas un compte on-premises supprimé

De l'autre côté de la frontière, supprimer un utilisateur dans l'AD on-premises ne garantit pas la disparition de son jumeau Entra ID. Deux mécanismes documentés laissent des objets synchronisés derrière eux :

Protection contre la suppression accidentelle. Microsoft Entra Connect est livré avec une protection contre la suppression activée par défaut, plafonnée à 500 suppressions d'objets par cycle d'export. Si un nettoyage on-premises en masse, un déplacement d'OU, ou un filtre de synchronisation cassé entraîne la suppression de plus que ce seuil en une seule exécution, l'export s'arrête tout simplement — le Synchronization Service Manager rapporte stopped-deletion-threshold-exceeded sur l'étape Export, et chacune de ces suppressions reste non appliquée dans Entra ID jusqu'à ce qu'un administrateur revoie et relance le job (Microsoft Entra Connect Sync: Prevent accidental deletes). En pratique, cela signifie qu'un seul dépassement de seuil passé inaperçu peut laisser des dizaines de comptes on-premises supprimés toujours pleinement actifs et apparemment synchronisés dans le cloud.

Exclusion du périmètre sans conversion. Lorsqu'un objet est sorti du périmètre de synchronisation (un changement de filtre d'OU/de groupe, par exemple) plutôt que directement supprimé, Entra Connect soft-delete l'objet Entra ID et bascule DirSyncEnabled sur False — mais, selon la documentation de Microsoft elle-même, « ce processus ne convertit toutefois pas l'objet en cloud managed, il est toujours considéré comme un objet synchronisé depuis l'Active Directory on-premises », et reste éligible à un nouveau hard match ultérieurement (Microsoft Entra Connect: Troubleshoot errors during synchronization). Un utilisateur dans cet état n'est ni proprement supprimé, ni véritablement cloud-native — c'est un objet à moitié migré pour lequel la plupart des revues d'accès n'ont pas de case adaptée, dans un esprit similaire aux comptes privilégiés obsolètes que les audits on-premises signalent déjà, sauf que celui-ci est invisible côté AD car l'objet source a déjà disparu.

Détection : repérer les comptes cloud-only privilégiés et les comptes synchronisés orphelins

La propriété onPremisesSyncEnabled de la ressource user de Microsoft Graph est le point d'ancrage des deux contrôles : elle renvoie true pour un objet activement synchronisé, false pour un objet qui était synchronisé mais ne l'est plus, et null pour un objet qui n'a jamais été synchronisé — c'est-à-dire véritablement cloud-native.

Interroger Microsoft Graph pour trouver les candidats orphelins

Pour extraire directement la liste des candidats orphelins / SOA revenue en arrière, Microsoft documente cette requête Graph :

GET https://graph.microsoft.com/v1.0/users?$count=true&$filter=OnPremisesSyncEnabled ne true and OnPremisesImmutableId ne null

(Source : How to audit and monitor User Source of Authority (SOA) in Microsoft Entra ID.) Les filtres avancés sur onPremisesSyncEnabled peuvent nécessiter l'en-tête ConsistencyLevel: eventual et $count=true pour renvoyer des résultats fiables.

Croiser les rôles privilégiés avec l'état de synchronisation

Pour le volet cloud-only privilégié, croisez les affectations de rôles (éligibles PIM et actives) avec l'état de synchronisation :

# Utilisateurs avec un rôle Entra actif ou éligible qui n'ont jamais été synchronisés depuis l'on-premises
Get-MgUser -Filter "onPremisesSyncEnabled eq null" -ConsistencyLevel eventual -CountVariable c -All |
    Where-Object { (Get-MgUserMemberOf -UserId $_.Id) -match "RoleAssignable" }

Remédiation

Combler l'écart cloud-only privilégié

1. Étendre la gouvernance Tier 0 aux comptes cloud-only privilégiés. Chaque compte cloud-only avec un rôle Entra actif ou éligible devrait avoir : une affectation éligible PIM (et non permanente), une politique Conditional Access exigeant le MFA et un appareil conforme/managé à l'activation (de nombreux tenants ont des lacunes ici — voir lacunes de couverture de la politique de base Conditional Access), et une inclusion dans la même revue d'accès périodique que le Tier 0 on-premises — voir hygiène des groupes imbriqués et attribuables à un rôle pour l'équivalent côté groupes de ce même écart.
2. Garder l'exception étroite. Les seuls comptes qui devraient échapper entièrement au contrôle PIM et Conditional Access sont les véritables comptes d'accès d'urgence break-glass — deux, cloud-only, surveillés, selon les recommandations de Microsoft (voir hygiène des comptes break-glass). Tout le reste étiqueté « cloud-only parce que le Tier 0 ne doit pas synchroniser » a quand même besoin d'un propriétaire et d'une cadence de revue.

Nettoyer les utilisateurs synchronisés orphelins

3. Ajuster la protection contre la suppression accidentelle plutôt que de l'augmenter à l'aveugle. Confirmez que le seuil de suppression à l'export (Enable-ADSyncExportDeletionThreshold) est défini délibérément pour votre environnement, routez la notification d'arrêt vers une boîte mail surveillée, et traitez chaque événement stopped-deletion-threshold-exceeded comme un déclencheur d'investigation avant de relancer l'export — relancer sans revue est exactement ce qui transforme un changement de config en dizaines d'orphelins actifs.
4. Réconcilier l'état de synchronisation obsolète selon un calendrier régulier. Interrogez onPremisesSyncEnabled = false avec un onPremisesLastSyncDateTime ancien, vérifiez auprès de l'AD on-premises si l'objet source existe encore, et soit restaurez le mapping, soit déprovisionnez formellement l'objet cloud — ne le laissez pas dans cet état à moitié migré.
5. Rattacher les suppressions à un processus de départ gouverné. Les Lifecycle Workflows de Microsoft Entra ID Governance peuvent déclencher des tâches de désactivation/retrait d'accès/suppression planifiée à partir d'un signal faisant autorité (flux RH ou attribut AD) plutôt que de compter uniquement sur l'export de synchronisation pour propager un offboarding — cela permet de rattraper le cas où l'export échoue silencieusement.

Se préparer au durcissement du hard match

6. Planifier le durcissement du hard match dès maintenant, pas le 1er juillet 2026. Tout processus qui dépend d'un nouveau matching d'un compte cloud privilégié ou éligible PIM vers un objet on-premises (récupération de forêt, runbooks de migration de tenant) sera bloqué par défaut une fois le durcissement de Microsoft entré en vigueur. Testez vos runbooks de récupération avec le contournement documenté — retirer temporairement le rôle ou l'éligibilité, effectuer le hard match, puis le restaurer — avant d'en avoir besoin sous la pression d'un incident.

Comment EtcSec détecte cela

Les contrôles Entra ID d'EtcSec signalent directement les deux côtés de cet écart : HYBRID_CLOUD_ONLY_PRIVILEGED fait remonter les utilisateurs cloud-only détenant un rôle privilégié, et HYBRID_ORPHANED_CLOUD_USER fait remonter les objets dont l'état de synchronisation indique un orphelin probable. Ces contrôles sont couplés à UNRESOLVED_PRIVILEGED_MEMBERS (affectations de rôles privilégiés référençant un principal qui ne se résout plus), PA_ADMIN_STALE_ACCOUNT (comptes administratifs sans activité récente), et PA_GLOBAL_ADMIN_NOT_MFA (Administrateurs généraux sans MFA appliqué), afin qu'un compte cloud-only privilégié ne soit pas seulement repéré, mais aussi vérifié selon le même niveau d'hygiène d'accès que toute autre identité Tier 0.