PIM Entra ID : configurer l'accès privilégié juste-à-temps

Le problème invisible de l'accès administrateur permanent

Dans la majorité des tenants Microsoft 365 et Azure, les comptes administrateurs conservent leurs privilèges élevés en permanence. Un compte avec le rôle Conditional Access Administrator ou Global Administrator dispose de ces droits 24 heures sur 24, 365 jours par an — qu'il s'en serve une fois par semaine ou jamais.

Ce modèle, appelé standing access (accès permanent), constitue l'un des vecteurs d'attaque les plus sous-estimés en environnement cloud. Si le compte est compromis — phishing, fuite d'identifiants, session détournée — l'attaquant hérite immédiatement de tous les privilèges attachés au rôle, sans fenêtre de temps limitée.

Faire le calcul : combien d'heures d'exposition réduisez-vous ?

Prenons un cas concret : un administrateur qui doit intervenir sur les politiques d'accès conditionnel environ deux fois par semaine, pour une session de travail de 8 heures maximum.

• Accès permanent : 8 760 heures d'exposition par an
• Accès limité aux besoins réels : 2 activations × 8 heures × 52 semaines ≈ 832 heures par an

On passe donc d'une exposition permanente à environ 832 heures, soit une réduction de plus de 90 % du temps pendant lequel le compte est réellement privilégié.

À l'échelle d'une équipe de sept administrateurs effectuant des actions cinq fois par semaine avec la même fenêtre de 8 heures, on passe d'environ 61 320 heures cumulées (7 × 8 760) à environ 14 560 heures (7 × 5 × 52 × 8) — une réduction supérieure à 75 % de la surface d'attaque globale.

C'est exactement ce que résout Privileged Identity Management (PIM), le module de gouvernance des identités privilégiées de Microsoft Entra ID.

Qu'est-ce que PIM dans Microsoft Entra ID ?

PIM introduit le concept d'accès juste-à-temps (just-in-time access) : au lieu d'assigner un rôle de façon permanente (active), on rend l'utilisateur éligible. L'utilisateur doit alors explicitement activer son rôle lorsqu'il en a besoin, pour une durée limitée, avec ou sans contrôles supplémentaires (MFA, justification, approbation).

Cette fonctionnalité se trouve dans le Centre d'administration Microsoft Entra, sous Identity Governance > Privileged Identity Management, puis Manage access.

Prérequis et licence

Autres prérequis :

• Un rôle Privileged Role Administrator ou Global Administrator pour gérer les assignations PIM (principe du moindre privilège : évitez d'utiliser Global Admin si Privileged Role Administrator suffit).
• Le module Microsoft.Graph.Identity.Governance si vous préférez l'automatisation en PowerShell.

Configurer une attribution éligible via le portail

Automatiser l'assignation avec Microsoft Graph PowerShell

Pour industrialiser la mise en place de PIM sur plusieurs comptes, le module Microsoft.Graph.Identity.Governance (SDK Microsoft Graph PowerShell) permet de créer des attributions éligibles sans passer par le portail.

Connexion avec les scopes nécessaires :

1Connect-MgGraph -Scopes "RoleManagement.ReadWrite.Directory", "RoleEligibilitySchedule.ReadWrite.Directory"

Récupération de l'identifiant du rôle et de l'utilisateur cible :

1$role = Get-MgRoleManagementDirectoryRoleDefinition -Filter "displayName eq 'Conditional Access Administrator'"
2$user = Get-MgUser -Filter "userPrincipalName eq 'rick.jones@contoso.com'"

Création de l'attribution éligible avec une expiration au 30 novembre :

1$params = @{
2    Action = "AdminAssign"
3    PrincipalId = $user.Id
4    RoleDefinitionId = $role.Id
5    DirectoryScopeId = "/"
6    ScheduleInfo = @{
7        StartDateTime = Get-Date
8        Expiration = @{
9            Type = "AfterDateTime"
10            EndDateTime = "2025-11-30T23:59:59Z"
11        }
12    }
13}
14 
15New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $params

Vérification que l'attribution a bien été créée et propagée (la propagation prend généralement quelques minutes) :

1Get-MgRoleManagementDirectoryRoleEligibilitySchedule -Filter "principalId eq '$($user.Id)'"

Côté utilisateur, l'activation self-service peut également être scriptée pour des scénarios d'automatisation (runbooks, pipelines) :

1$activationParams = @{
2    Action = "SelfActivate"
3    PrincipalId = $user.Id
4    RoleDefinitionId = $role.Id
5    DirectoryScopeId = "/"
6    Justification = "Mise à jour planifiée des politiques d'accès conditionnel"
7    ScheduleInfo = @{
8        StartDateTime = Get-Date
9        Expiration = @{
10            Type = "AfterDuration"
11            Duration = "PT8H"
12        }
13    }
14}
15 
16New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $activationParams

L'expérience utilisateur côté administrateur éligible

Une fois l'attribution éligible en place, l'utilisateur ne voit aucun accès au rôle tant qu'il ne l'a pas activé. Dans notre exemple, Rick tente d'ouvrir les politiques d'accès conditionnel : l'accès est refusé malgré l'éligibilité.

Pour activer le rôle, Rick se rend dans My Roles > Privileged Identity Management > Activate, fournit une justification (obligatoire si configuré ainsi), confirme la durée (8 heures par défaut, réductible mais rarement rallongeable), puis valide. La demande passe au statut Activation request is scheduled, et l'accès devient disponible immédiatement — sans standing access.

Dépannage des erreurs courantes

• Erreur de licence lors de la création d'une assignation : le tenant ne dispose pas d'Entra ID P2. Vérifiez l'attribution de licence sur l'utilisateur concerné (ou sur le tenant en cas de licence Entra Suite).
• Le rôle activé n'apporte pas immédiatement l'accès attendu : le jeton de session de l'utilisateur doit être rafraîchi. Demandez une déconnexion/reconnexion si le portail cible (Intune, Purview, etc.) ne reflète pas encore le rôle actif.
• Impossible d'activer sans MFA satisfaite : si la politique du rôle exige la MFA à l'activation, l'utilisateur doit d'abord compléter une réauthentification MFA récente dans la session en cours.
• New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest renvoie une erreur 403 : le compte exécutant le script n'a pas le rôle Privileged Role Administrator ni les scopes Graph nécessaires (RoleManagement.ReadWrite.Directory).
• La demande d'activation reste en attente : si l'option Require approval to activate est activée (fonctionnalité en préversion), un approbateur doit valider manuellement la demande avant qu'elle ne prenne effet.

Points clés à retenir

• Le standing access (accès permanent) est un vecteur de risque majeur trop souvent ignoré au profit d'autres contrôles de sécurité.
• PIM transforme les rôles à privilèges en attributions éligibles, activables juste-à-temps pour une durée limitée.
• Sur un seul compte, passer d'un accès permanent à une activation ciblée peut réduire l'exposition de plus de 90 % ; à l'échelle d'une équipe, la réduction dépasse souvent 75 %.
• Entra ID P2 (M365 E5 ou Entra Suite) est un prérequis non négociable — vérifiez la licence avant de configurer quoi que ce soit.
• L'automatisation via Microsoft Graph PowerShell (module Microsoft.Graph.Identity.Governance) permet d'industrialiser les attributions éligibles sur plusieurs comptes ou groupes.
• Réservez les contraintes fortes (approbation obligatoire, fenêtre d'activation très courte) aux rôles les plus critiques comme Global Administrator, pour ne pas freiner inutilement les équipes sur les rôles opérationnels.

La prochaine étape logique consiste à auditer l'ensemble des rôles administrateurs actifs de votre tenant et à identifier lesquels peuvent basculer en éligibilité PIM sans casser les processus existants.