Microsoft Entra PIM : diagnostiquer une activation de rôle Azure avant d'attribuer un accès permanent

Un incident de production est ouvert. L’opérateur doit modifier une ressource Azure, active son rôle Contributor dans Microsoft Entra Privileged Identity Management, puis reçoit encore AuthorizationFailed. Sous pression, le contournement paraît évident : créer une attribution permanente au niveau de l’abonnement et revenir au diagnostic plus tard.

Cette action mélange pourtant trois états différents : l’opérateur peut être éligible au rôle, sa demande d’activation peut être absente ou en attente, et une activation réussie peut ne pas encore être visible dans le jeton ou l’application utilisée. Ce runbook localise la rupture avant d’élargir l’accès. Sa sortie est une décision bornée : corriger la demande, attendre une approbation, renouveler le contexte d’accès, utiliser une procédure d’urgence contrôlée ou arrêter l’intervention.

Figer l’action refusée et l’accès attendu

Commencez par une opération précise. « PIM ne fonctionne pas » ne permet pas de distinguer un défaut d’activation d’un refus sur une action située hors du rôle ou du scope demandé. Conservez l’identité, le rôle, le scope, l’heure UTC, l’action ARM et l’identifiant de corrélation retourné par Azure.

incident: inc-20260915-017
operator_upn: <operator-upn>
operator_object_id: <principal-object-id>
tenant_id: <tenant-id>
expected_role: Contributor
eligible_scope: /subscriptions/<subscription-id>/resourceGroups/rg-payments-prod
target_resource_id: /subscriptions/<subscription-id>/resourceGroups/rg-payments-prod/providers/<provider>/<type>/<name>
requested_action: <provider>/<resource-type>/write
failed_at_utc: <timestamp>
arm_correlation_id: <correlation-id>

activation:
request_id: <request-id-or-none>
requested_scope: <scope>
requested_duration: PT1H
status: <not-created|pending-approval|active|failed|expired>

stop_conditions:
- no eligible assignment exists at the expected scope
- requested action is outside the role definition
- activation targets another tenant, subscription or principal
- emergency access has no owner, expiry or revocation path

Rejouez ensuite une lecture sans effet ou une commande what-if proche de l’action attendue. Ne testez pas l’accès en modifiant directement la ressource en incident : un succès partiel compliquerait le rollback et un second essai pourrait dupliquer l’effet.

Séparer éligibilité, demande et attribution active

PIM ne transforme pas une éligibilité en permission permanente. Pour un rôle Azure, l’éligibilité autorise une demande ; l’activation crée temporairement une attribution active ; l’autorisation effective dépend ensuite du rôle, du scope, des conditions éventuelles et du contexte d’accès présenté à ARM.

1. ELIGIBILITE
 Le principal est eligible au bon role et au bon scope.

2. DEMANDE
 SelfActivate porte le bon principal, le bon role, le bon scope et la bonne duree.
 MFA, justification, ticket, Conditional Access et approbation sont satisfaits.

3. ATTRIBUTION ACTIVE
 La demande est approuvee et l'instance active existe pendant la fenetre attendue.

4. ACCES EFFECTIF
 Le client utilise le bon tenant et un contexte rafraichi.
 Le role autorise l'action et aucune condition ou deny assignment ne la refuse.

Decision
 Corriger la premiere etape non prouvee, sans elargir les suivantes.

Ce modèle évite deux faux diagnostics. Une ligne « active » dans PIM ne prouve pas que Contributor autorise une action de gestion des rôles. À l’inverse, un AuthorizationFailed immédiatement après activation ne prouve pas que l’attribution est absente : le portail, un shell ou une application peuvent encore utiliser un contexte antérieur.

Lire les instances PIM au scope réel

Vérifiez d’abord le tenant et l’abonnement du shell, puis interrogez les instances d’éligibilité et d’attribution au scope concerné. Les API de planning PIM distinguent les schedules, leurs instances effectives et les demandes qui les modifient.

PRINCIPAL_ID="<principal-object-id>"
SCOPE="/subscriptions/<subscription-id>/resourceGroups/rg-payments-prod"

az account show \
--query '{tenantId:tenantId,subscriptionId:id,user:user.name}' \
--output yaml

az rest --method get \
--url "https://management.azure.com$SCOPE/providers/Microsoft.Authorization/roleEligibilityScheduleInstances?api-version=2020-10-01&$filter=principalId%20eq%20'$PRINCIPAL_ID'" \
--query 'value[].{name:name,principalId:properties.principalId,roleDefinitionId:properties.roleDefinitionId,scope:properties.scope,start:properties.startDateTime,end:properties.endDateTime}' \
--output yaml

az rest --method get \
--url "https://management.azure.com$SCOPE/providers/Microsoft.Authorization/roleAssignmentScheduleInstances?api-version=2020-10-01&$filter=principalId%20eq%20'$PRINCIPAL_ID'" \
--query 'value[].{name:name,assignmentType:properties.assignmentType,roleDefinitionId:properties.roleDefinitionId,scope:properties.scope,start:properties.startDateTime,end:properties.endDateTime}' \
--output yaml

Conservez les identifiants complets de rôle et de scope. Un même nom de rôle peut exister à plusieurs niveaux, et une éligibilité sur un resource group ne donne rien sur un resource group voisin. Si l’éligibilité vient d’un groupe PIM ou si des conditions RBAC limitent l’attribution, notez cette couche au lieu de réduire le diagnostic à l’utilisateur seul.

Qualifier la demande d’activation

Une activation peut ne jamais créer d’attribution active. La demande peut viser une heure future, demander un scope réduit différent de celui sélectionné dans le filtre, attendre une approbation, être refusée ou expirer. Lisez My requests et la demande ARM avant de conclure à un délai de propagation.

SCOPE="/subscriptions/<subscription-id>/resourceGroups/rg-payments-prod"

az rest --method get \
--url "https://management.azure.com$SCOPE/providers/Microsoft.Authorization/roleAssignmentScheduleRequests?api-version=2020-10-01" \
--query 'value[].{name:name,status:properties.status,requestType:properties.requestType,principalId:properties.principalId,roleDefinitionId:properties.roleDefinitionId,scope:properties.scope,createdOn:properties.createdOn,condition:properties.condition}' \
--output table

Filtrez hors incident avec le principalId, le rôle et une fenêtre UTC précise afin de ne pas confondre une ancienne demande avec l’activation courante. Pour une activation soumise à approbation, l’état PendingApproval est une décision de workflow, pas une panne RBAC. Identifiez au moins deux approbateurs opérationnels en amont ; ajouter un rôle permanent pendant que la demande attend contourne le contrôle au moment où il doit être utile.

Si la demande n’existe pas, revenez aux exigences d’activation : MFA, justification, numéro de ticket, durée autorisée et éventuel contexte d’authentification Conditional Access. Une erreur avant soumission ne se résout pas en attendant la propagation Azure.

Corréler Conditional Access, MFA et identité de session

Une policy Conditional Access peut exiger un contexte d’authentification, une méthode forte ou un appareil conforme au moment de l’activation. Vérifiez le compte réellement connecté et l’événement de connexion correspondant. Une session administrateur ouverte dans un autre tenant ou un navigateur avec plusieurs identités produit facilement un diagnostic trompeur.

Si SigninLogs et AuditLogs sont envoyés vers Log Analytics, utilisez une fenêtre courte autour de la demande :

let principal = "<operator-upn>";
let start = datetime(<start-utc>);
let stop = datetime(<stop-utc>);
union isfuzzy=true
(
SigninLogs
| where TimeGenerated between (start .. stop)
| where UserPrincipalName =~ principal
| project TimeGenerated, Evidence="SignIn", CorrelationId,
          ResultType, ResultDescription,
          ConditionalAccessStatus, AuthenticationRequirement
),
(
AuditLogs
| where TimeGenerated between (start .. stop)
| where tostring(InitiatedBy.user.userPrincipalName) =~ principal
| where Category has "RoleManagement" or LoggedByService has "PIM"
| project TimeGenerated, Evidence="Audit", CorrelationId,
          ResultType=tostring(Result), ResultDescription=tostring(ResultReason),
          ConditionalAccessStatus="", AuthenticationRequirement=OperationName
)
| order by TimeGenerated asc

L’absence de ligne n’est pas une preuve de succès ou d’échec si les journaux ne sont pas exportés, si la rétention ne couvre pas l’incident ou si la demande a été initiée dans un autre tenant. Dans ce cas, utilisez l’historique d’audit PIM et les journaux de connexion du tenant source, puis rattachez les exports au dossier d’incident.

Prouver l’accès ARM avec un contexte renouvelé

Une activation validée crée normalement l’attribution active rapidement. L’application utilisée peut néanmoins conserver une décision d’autorisation ou un contexte antérieur. Ouvrez un nouveau shell ou renouvelez explicitement la connexion, sélectionnez l’abonnement, puis testez une lecture du resource ID exact.

TENANT_ID="<tenant-id>"
SUBSCRIPTION_ID="<subscription-id>"
TARGET_RESOURCE_ID="<resource-id>"

az logout
az login --tenant "$TENANT_ID"
az account set --subscription "$SUBSCRIPTION_ID"

az account get-access-token \
--resource https://management.azure.com/ \
--query '{tenant:tenant,expiresOn:expiresOn}' \
--output yaml

az resource show \
--ids "$TARGET_RESOURCE_ID" \
--query '{id:id,name:name,type:type}' \
--output yaml

Le renouvellement du contexte est un test, pas un remède universel. S’il échoue encore, comparez l’action refusée au rôle effectif. Recherchez aussi une condition RBAC, un deny assignment, un verrou de ressource ou une policy Azure qui peut produire un refus après que l’authentification et le rôle ont réussi.

Gardez un témoin : une lecture autorisée au même scope, ou la même lecture par un opérateur dont le rôle actif est connu. Elle aide à séparer une panne générale ARM d’un problème lié au principal ou au scope.

Encadrer l’accès d’urgence sans rendre le privilège permanent

Un incident critique peut ne pas attendre la correction complète de PIM. Le plan d’urgence doit alors être préparé, limité et révocable. Il ne consiste pas à donner Owner sur l’abonnement « pour voir si cela marche ».

trigger:
- confirmed_user_impact
- required_action_is_time_critical
- normal_pim_path_is_blocked_and_evidenced

grant:
principal: <named-emergency-operator>
role: <smallest-role-that-allows-the-action>
scope: <smallest-resource-or-resource-group>
owner: <incident-commander>
expires_at_utc: <timestamp>
ticket: <incident-id>

controls:
- second-person approval
- no shared account
- activity logging preserved
- exact action and validation recorded
- revocation command prepared before grant

close:
- remove emergency assignment
- verify access is removed with a fresh session
- restore or repair the PIM path
- review why the standard activation was unavailable

Si la plateforme utilisée pour l’urgence ne sait pas imposer une expiration automatique, créez simultanément l’action de révocation, son propriétaire et une alerte avant échéance. L’attribution n’est pas « temporaire » parce que le ticket dit qu’elle l’est.

Décider correction, attente, urgence ou arrêt

CORRIGER LA DEMANDE
L'eligibilite existe, mais principal, role, scope, horaire ou duree sont incorrects.
Annuler la demande pending inutile et soumettre une demande exacte.

ATTENDRE OU ESCALADER L'APPROBATION
La demande est PendingApproval et l'action peut attendre.
Contacter l'approbateur prevu sans contourner le workflow.

RENOUVELER LE CONTEXTE
L'attribution active existe au bon scope.
Ouvrir une session propre, reprendre un token ARM et rejouer un test sans effet.

ACTIVER L'ACCES D'URGENCE
Impact critique, PIM indisponible ou bloque, action exacte connue.
Accorder le role minimal au scope minimal avec owner, expiry et revocation.

ARRETER
Role requis incertain, mauvais tenant, action irreversible ou scope non borne.
Ne pas transformer l'incertitude en Owner permanent.

Après l’intervention, désactivez l’activation PIM devenue inutile ou laissez expirer la fenêtre prévue, révoquez toute attribution d’urgence et testez la suppression d’accès depuis une nouvelle session. Une validation complète comporte la preuve de l’action métier, l’état final de la ressource, la disparition du privilège temporaire et la remise en service du chemin PIM standard.

Conclusion

Une activation PIM affichée dans le portail n’est qu’une étape du chemin d’autorisation. Le diagnostic utile relie l’éligibilité, la demande, ses exigences, l’attribution active, le contexte présenté à ARM et l’action exacte sur le bon scope.

N’accordez un accès permanent qu’à partir d’une décision de gouvernance, jamais comme test de dépannage. Pendant un incident, corrigez la première rupture prouvée ou utilisez un accès d’urgence déjà borné. Fermez ensuite avec une action validée, un privilège retiré et un chemin d’activation de nouveau exploitable.