09 · Planifier et automatiser la gouvernance des identités

Version : 1.1 · Date : 2026-10-21 · Domaine 4 de l'examen : Plan and automate identity governance (20 à 25 %)

En une phrase : l'entitlement management donne l'accès par une policy (qui demande, qui approuve, combien de temps), les access reviews le font reconfirmer périodiquement, PIM rend les privilèges temporaires et traçables, et deux emergency access accounts gardent une porte de secours quand tout le reste est verrouillé.

Ce que l'examen demande#

Texte officiel du guide d'étude SC-300 (compétences au 28 octobre 2026), blocs 4.1 à 4.3. Le bloc 4.4 (journaux, workbooks, Identity Secure Score) est traité au chapitre 10.

Déjà vu dans SC-500 : les fondamentaux de PIM (vocabulaire eligible / active, role settings, authentication context, piège du verrouillage), PIM for Groups et les emergency access accounts sont au chapitre 01 de SC-500, section 4 ; les bases d'access reviews, d'entitlement management et de lifecycle workflows à la section 11.7. Ce chapitre ne les redit pas : il va au niveau administrateur (configuration détaillée, délégation, circuits, audit).

1. Les bases à maîtriser#

1.1 Licences : ID Governance d'abord, P2 pour une partie#

À l'examen : si une question parle de « Logic App déclenchée par une demande d'access package » ou d'« auto assignment », la réponse licence est ID Governance, pas P2.

1.2 Les rôles d'administration utiles dans ce domaine#

Piège : le User Administrator ne peut plus créer de catalogs ni gérer les access packages d'un catalog qu'il ne possède pas. Microsoft recommande l'Identity Governance Administrator.

2. Entitlement management#

2.1 Planifier les entitlements#

Un access package n'est pas la solution à tout : il remplace l'attribution manuelle quand l'accès doit être demandé, approuvé, limité dans le temps ou revu. Microsoft le recommande notamment quand :

• l'accès est temporaire, pour une tâche ou un projet ;
• l'accès demande l'approbation d'un manager ou d'une autre personne désignée ;
• l'accès doit être attribué automatiquement à une population (service, centre de coût) et rester demandable par d'autres ;
• un service veut gérer ses propres règles d'accès sans passer par l'IT ;
• plusieurs organisations collaborent et des invités B2B doivent arriver en nombre.

Pour l'accès de base de tout le monde (une boîte Exchange pour chaque employé, par exemple), un dynamic group et la group-based licensing restent plus simples.

2.2 Les catalogs#

Un catalog est un conteneur de ressources et d'access packages, qui sert à déléguer. Chemin : ID Governance > Catalogs > New catalog. Ses deux réglages clés :

• Enabled : les access packages du catalog peuvent être demandés ;
• Enabled for external users : des utilisateurs d'annuaires externes (connected organizations) peuvent demander. Activé par défaut à la création ; un filtre de la liste des catalogs permet de retrouver ceux qui l'ont.

Rôles d'entitlement management (propres à ce service, distincts des rôles Entra) :

L'approver et le requestor ont des droits définis par la policy, mais ne sont pas des rôles.

Ajouter une ressource exige deux droits : être catalog owner et pouvoir agir sur la ressource (rôle Entra qui la gère ou propriétaire de la ressource). Le Global Administrator peut tout ajouter ; l'Identity Governance Administrator peut ajouter des applications mais pas des groupes sans rôle supplémentaire ; un simple utilisateur catalog owner n'ajoute que les groupes et applications dont il est owner.

2.3 Les access packages et leurs policies#

Un access package liste des resource roles (Member ou Owner d'un groupe, app role d'une application, rôle d'un site SharePoint) et contient une ou plusieurs policies. Chemin : ID Governance > Entitlement management > Access packages.

Combien de policies ?

Si plusieurs policies s'appliquent à un utilisateur, il choisit la policy au moment de la demande.

Onglet Requests : qui peut obtenir l'accès

Puis Who can request access : Self, Admin, Manager (l'ancien réglage « Enable new requests and assignments » correspond aujourd'hui à Self). Les managers qui demandent pour leurs employés sont en préversion.

Approval

• How many stages : 1, 2 ou 3. Un seul approbateur par stage suffit ; un refus dans un stage arrête la demande.
• Approbateurs : utilisateurs ou groupes choisis, Manager (avec fallback si le manager n'est pas renseigné), Internal sponsor ou External sponsor pour les externes.
• Decision must be made in how many days? : sans décision, la demande expire et doit être refaite.
• Require approver justification, Require requestor justification.
• Alternate approvers : transfert après N jours si personne n'a agi ; transfert possible au plus tôt un jour après la demande, et le délai total doit être d'au moins 4 jours. Avec le manager en premier stage, le second level manager peut être l'alternate approver.
• Un approbateur ne peut pas approuver sa propre demande.

Requestor information : questions en texte court, texte long ou Multiple Choice, avec localisation, contrôle par expression régulière et caractère obligatoire. Les réponses sont visibles des approbateurs.

Lifecycle

• Access package assignments expire : On date, Number of days (0 à 3 660), Number of hours ou Never.
• Users can request specific timeline, Allow users to extend access (e-mails 14 jours puis 1 jour avant l'échéance ; l'utilisateur doit encore être dans le périmètre de la policy), Require approval to grant extension.
• Require an access review : une access review récurrente des assignments de ce package.

Separation of duties (au niveau de l'access package, pas de la policy) : liste d'incompatible access packages et d'incompatible groups. Un utilisateur qui a déjà l'un d'eux ne peut pas demander ce package. La relation est à sens unique : pour une exclusion mutuelle, la déclarer dans les deux packages. Les utilisateurs qui ont déjà les deux accès apparaissent dans la colonne Additional access.

Custom extensions (Logic Apps) : créées dans le catalog (Catalog > Custom Extensions), puis branchées dans l'onglet Rules / Custom Extensions de la policy.

En launch and wait, la Logic App peut refuser la demande aux étapes created ou approved (contrôle externe de séparation des tâches, par exemple).

Autres réglages de l'access package

• Hidden : le package n'apparaît pas dans My Access, mais reste demandable par son lien (https://myaccess.microsoft.com/@<directory_hint>#/access-packages/<id>).
• Auto assignment policy : attribution automatique selon une règle sur les attributs (comme un dynamic group), au plus 15 000 utilisateurs par policy.

Créer une policy d'assignation directe par Microsoft Graph PowerShell (exemple de la documentation, permission EntitlementManagement.ReadWrite.All) :

Connect-MgGraph -Scopes "EntitlementManagement.ReadWrite.All"

$params = @{
    displayName          = "Assignation directe"
    description          = "Seul l'administrateur assigne, sans approbation"
    allowedTargetScope   = "notSpecified"
    specificAllowedTargets = @()
    expiration           = @{ type = "noExpiration" }
    requestorSettings    = @{
        enableTargetsToSelfAddAccess = $false   # pas de demande en libre-service
        allowCustomAssignmentSchedule = $true
    }
    requestApprovalSettings = @{ isApprovalRequiredForAdd = $false; stages = @() }
    accessPackage        = @{ id = "<id-access-package>" }
}
New-MgEntitlementManagementAssignmentPolicy -BodyParameter $params

2.4 Gérer les access requests#

Qui peut demander dépend de quatre couches : le catalog (Enabled, Enabled for external users), l'access package (Hidden, separation of duties) et la policy.

stateDiagram-v2
    [*] --> Submitted
    Submitted --> PendingApproval: policy avec approbation
    Submitted --> Delivering: sans approbation
    PendingApproval --> Denied: un approbateur refuse
    PendingApproval --> Expired: aucune décision dans le délai
    PendingApproval --> Delivering: approuvée
    Delivering --> Delivered: toutes les ressources attribuées
    Delivering --> PartiallyDelivered: une partie seulement
    Delivered --> AccessExtended: extension accordée
    Delivered --> AccessExpired: fin de l'assignment
    Denied --> [*]
    Expired --> [*]
    AccessExpired --> [*]

Fenêtre de reprocess : 14 jours après la fin de la demande, selon la page dédiée au reprocess et la référence de l'API Graph (accessPackageAssignmentRequest: reprocess) ; la page de dépannage parle encore d'une semaine. Au-delà, l'utilisateur annule et refait une demande dans My Access.

Les e-mails aux demandeurs « You now have access », « Extend access » et « Access has ended » sont désactivés par défaut. Une assignation directe par l'admin n'envoie pas d'e-mail de résultat.

Audit : catégorie EntitlementManagement des audit logs, avec par exemple les activités Deny access package assignment request, Access package assignment request timed out (no approver action taken) et Remove access package assignment.

AuditLogs
| where Category == "EntitlementManagement"
| where OperationName in ("Deny access package assignment request",
                          "Access package assignment request timed out (no approver action taken)")
| project TimeGenerated, OperationName, InitiatedBy, TargetResources

2.5 Les terms of use#

Les terms of use (ToU) affichent un document PDF avant l'accès et gardent la preuve de l'acceptation. Ils s'appliquent par une grant control de Conditional Access. Chemin : Entra ID > Conditional Access > Terms of use > New terms.

Points d'examen :

• licence P1 ; création par un Conditional Access Administrator, lecture par un Security Reader ; 40 terms au plus par tenant ;
• un utilisateur qui refuse est bloqué ; on ne peut pas « désaccepter » ;
• un consentement expiré n'est redemandé qu'à l'expiration de la session ;
• une ToU ne s'accepte qu'en authentification interactive : exclure les comptes de service du Conditional Access ;
• pour les invités B2B, la ToU est présentée lors du redeem de l'invitation ; c'est le moyen de faire accepter une charte aux externes arrivés par un access package (Conditional Access ciblant les invités) ;
• compteurs Accepted / Declined conservés pendant toute la vie de la ToU, audit logs 30 jours, export CSV de l'historique ; une nouvelle version du PDF peut exiger la réacceptation (Require reaccept).

2.6 Le cycle de vie des utilisateurs externes#

Quand un externe qui n'est pas encore dans l'annuaire est approuvé, entitlement management l'invite automatiquement (compte B2B créé, sans e-mail d'invitation : il reçoit l'e-mail de livraison de l'accès). À l'expiration, ses accès sont retirés.

Réglage global : ID Governance > Entitlement management > Control configurations > Lifecycle of external users :

Ces actions ne visent que les invités arrivés par entitlement management (ou dont le compte a été « converti en governed »). Un invité qui existait déjà avant ses access packages reste. Un invité bloqué ne peut plus refaire de demande : ne pas activer le blocage si les externes doivent revenir demander d'autres packages.

Prérequis côté tenant pour que les externes puissent demander :

• catalog Enabled for external users et policy For users not in your directory ;
• External collaboration settings : recommandé Guests can invite = No, pour que les invitations passent par la gouvernance ; B2B allow / block list cohérente avec les partenaires ;
• email one-time passcode activé pour une policy All users ;
• cross-tenant access settings (inbound B2B collaboration) qui autorisent les tenants partenaires ;
• Conditional Access : exclure l'application Entitlement Management (et, si une policy vise toutes les ressources, Request Approvals Read Platform) des policies qui touchent les invités, sinon ils ne peuvent pas atteindre My Access.

2.7 Les connected organizations#

Une connected organization représente un partenaire dont les utilisateurs pourront demander des access packages. Chemin : ID Governance > Entitlement management > Connected organizations. Rôles : Identity Governance Administrator ou Connected Organization Administrator.

Sources d'identité possibles : un autre tenant Microsoft Entra (même cloud ou autre cloud Microsoft), un IdP SAML/WS-Fed, un domaine dont les utilisateurs s'authentifient par one-time passcode, ou les Microsoft Accounts. Pour un tenant Entra, tous ses domaines vérifiés sont reconnus.

Sponsors : internal sponsors (membres de votre annuaire) et external sponsors (invités déjà présents, de l'organisation partenaire). Ils peuvent être approbateurs dans les policies.

Piège : ne pas passer en Configured une connected organization proposée pour un IdP social si des policies « All configured connected organizations » n'exigent pas d'approbation : n'importe quel compte social pourrait demander.

Lister les connected organizations et leurs sources d'identité (exemple de la documentation) :

Connect-MgGraph -Scopes "EntitlementManagement.ReadWrite.All"
$co = Get-MgEntitlementManagementConnectedOrganization -All
foreach ($c in $co) {
    foreach ($i in $c.IdentitySources) {
        Write-Output $c.Id $c.DisplayName $i.AdditionalProperties["@odata.type"]
    }
}

3. Access reviews#

3.1 Planifier les access reviews#

Questions de cadrage : quel risque (invités, accès dormants, privilèges) ? quelle fréquence (weekly à annually) ? qui connaît le besoin (owner, manager, l'utilisateur lui-même) ? que faire sans réponse ? appliquer automatiquement ou pas ?

Piège : les groupes et utilisateurs d'une restricted management administrative unit ne peuvent pas être gouvernés par les access reviews.

3.2 Créer et configurer une access review#

Chemin : ID Governance > Access Reviews > New access review > Review access to a resource type.

Scope

• Teams + Groups : All Microsoft 365 groups with guest users (sans les dynamic groups ni les role-assignable groups, avec exclusions possibles ; seul le scope Guest users only est alors possible) ou Select Teams + groups.
• Applications : une ou plusieurs applications. Choisir 5 ressources crée 5 reviews.
• Guest users only ou Everyone ; Inactive users (on tenant level) avec Days inactive jusqu'à 730 jours (les comptes créés depuis moins longtemps sont exclus, pour leur laisser le temps de se connecter).
• Les nested groups sont aplatis : un utilisateur refusé n'est retiré que de l'appartenance directe.

Reviewers : Group owner(s), Selected user(s) or group(s), Users review their own access, Managers of users ; un fallback reviewer pour les managers absents ou les groupes sans owner. Seuls les owners au démarrage de la review sont reviewers. Pour PIM for Groups, un fallback reviewer est obligatoire quand les owners sont reviewers (seuls les owners actifs comptent).

Recurrence : Duration (in days), Start date, End (Never, date, nombre d'occurrences). Dans PIM, la durée maximale d'une review mensuelle est de 27 jours pour éviter les chevauchements.

Settings

• Auto apply results to resource ; sinon, application manuelle.
• If reviewers don't respond : No change, Remove access, Approve access, Take recommendations.
• Action to apply on denied guest users (scope invités seulement) : Remove user's membership from the resource (défaut) ou Block user from signing-in for 30 days, then remove user from the tenant (réactivation possible par un admin pendant 30 jours).
• At end of review, send notification to : d'autres destinataires du résultat.
• Enable review decision helpers : No sign-in within 30 days (dernière connexion, interactive ou non ; pour une application, la connexion à l'application) et User-to-Group Affiliation (distance dans l'organigramme ; ID Governance).
• Advanced settings : Justification required, Email notifications, Reminders (à mi-parcours), Additional content for reviewer email.

Multi-stage review

• 2 ou 3 stages, chacun avec ses reviewers, sa durée et son fallback.
• Specify reviewees to go to next stage : Approved, Denied, Not reviewed, Don't know, ou All.
• Show previous stage(s) decisions to later stage reviewers (révélation des décisions précédentes) ou revue indépendante.
• La décision d'un stage suivant remplace la précédente ; la durée d'une occurrence est la somme des stages.

Délégation aux owners : Access Reviews > Settings > Group owners can create and manage access reviews for groups they own = Yes (défaut : No).

Créer une self-review ponctuelle d'un groupe de sécurité par Microsoft Graph PowerShell (exemple de la documentation, abrégé ; permission AccessReview.ReadWrite.All) :

Connect-MgGraph -Scopes "AccessReview.ReadWrite.All"
$params = @{
    displayName = "Self-review des membres de Building security"
    scope = @{ query = "/groups/<id-groupe>/transitiveMembers"; queryType = "MicrosoftGraph" }
    instanceEnumerationScope = @{ query = "/groups/<id-groupe>"; queryType = "MicrosoftGraph" }
    settings = @{
        mailNotificationsEnabled       = $true
        reminderNotificationsEnabled   = $true
        justificationRequiredOnApproval = $true
        defaultDecisionEnabled         = $true
        defaultDecision                = "Deny"      # If reviewers don't respond = Remove access
        instanceDurationInDays         = 5
        autoApplyDecisionsEnabled      = $true       # Auto apply results to resource
        recommendationsEnabled         = $true
        recurrence = @{ pattern = $null; range = @{ type = "numbered"; numberOfOccurrences = 0;
                        startDate = "2026-11-02"; endDate = "2026-11-07" } }
    }
}
New-MgIdentityGovernanceAccessReviewDefinition -BodyParameter $params

3.3 Surveiller l'activité des access reviews#

Aucun droit ne change pendant la review : elle photographie l'accès au démarrage, et les changements faits entre-temps ne sont pris en compte qu'à l'occurrence suivante.

3.4 Répondre manuellement aux access reviews#

Côté reviewer (https://myaccess.microsoft.com > Access reviews) :

• Approve, Deny ou Don't know (l'accès reste, le choix est audité), avec Reason si exigé ;
• Accept recommendations : pour une sélection, ou pour tous les non revus ; ne modifie pas les décisions déjà prises ;
• la réponse reste modifiable jusqu'à la fin ; avec plusieurs reviewers, la dernière décision soumise l'emporte.

Côté administrateur :

Résultats non applicables : groupes synchronisés depuis l'AD local (appliquer dans l'AD à partir du CSV), groupes à extension mail, dynamic groups, appartenance par groupe imbriqué, application affectée par groupe (les membres du groupe gardent l'accès).

4. Privileged Identity Management côté administrateur#

Rappel des fondamentaux (vocabulaire, role settings, authentication context, verrouillage) : SC-500 chapitre 01, section 4.3.

4.1 Microsoft Entra roles dans PIM#

Planifier : inventaire des rôles privilégiés, passage des attributions permanentes en eligible, role settings par rôle (durée d'activation 1 à 24 h, MFA ou authentication context, justification, ticket, approbation, durée maximale des attributions), au moins deux comptes d'urgence actifs permanents avant d'exiger l'approbation partout.

Gérer : PIM > Microsoft Entra roles > Roles > (rôle) > Add assignments, type Eligible ou Active, permanent ou borné. Seuls le Privileged Role Administrator et le Global Administrator gèrent ces attributions.

Créer une attribution eligible par Microsoft Graph (exemple de la documentation) :

POST https://graph.microsoft.com/v1.0/roleManagement/directory/roleEligibilityScheduleRequests
Content-Type: application/json

{
  "action": "adminAssign",
  "justification": "Éligibilité permanente au rôle Global Reader pour l'auditeur",
  "roleDefinitionId": "f2ef992c-3afb-46b9-b7cf-a126ee74c451",
  "directoryScopeId": "/",
  "principalId": "<id-utilisateur>",
  "scheduleInfo": { "startDateTime": "2026-11-02T00:00:00Z", "expiration": { "type": "noExpiration" } }
}

Activation par l'utilisateur (roleAssignmentScheduleRequests, action selfActivate) en PowerShell :

$params = @{
    Action           = "SelfActivate"
    PrincipalId      = "<id-utilisateur>"
    RoleDefinitionId = "<id-role>"
    DirectoryScopeId = "/"
    Justification    = "Changement CHG-1234"
    ScheduleInfo     = @{ StartDateTime = Get-Date; Expiration = @{ Type = "AfterDuration"; Duration = "PT1H" } }
}
New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $params

Les role settings correspondent à l'objet Graph unifiedRoleManagementPolicy.

4.2 Azure resources dans PIM#

• Rôles intégrés (Owner, User Access Administrator, Contributor, Security Admin…) et custom roles Azure.
• Étendue : management group, subscription, resource group ou resource. Chemin : PIM > Azure resources > (choisir l'étendue) > Roles > Add assignments.
• Qui gère : Owner ou User Access Administrator de la ressource (et le Global Administrator qui a activé la gestion des abonnements). Le Privileged Role Administrator ne voit pas ces attributions par défaut.
• Les role settings se règlent par rôle et par ressource.
• Conditions ABAC sur une attribution eligible pour certains rôles de données (Storage Blob Data Contributor, Owner, Reader).
• Une attribution ne dure pas moins de 5 minutes et ne se retire pas dans les 5 minutes.
• API : Azure Resource Manager, Microsoft.Authorization/roleEligibilityScheduleRequests (PowerShell : New-AzRoleAssignmentScheduleRequest pour l'activation).

Piège : dans une access review de rôle Azure, un utilisateur refusé qui tient son rôle par un groupe n'est pas retiré du groupe : l'administrateur doit appliquer le changement. Pour un rôle Entra attribué à un role-assignable group, c'est le groupe entier qui est revu.

4.3 PIM for Groups#

Rappel des règles (membre ou owner juste-à-temps, approbation recommandée pour les role-assignable groups) : SC-500 chapitre 01, section 4.4. Côté administrateur :

• Mettre un groupe sous gestion : PIM > Groups > Discover groups > Manage groups. Une fois géré, un groupe ne peut plus sortir de PIM.
• Droits : pour un role-assignable group, un rôle avec microsoft.directory/groupsAssignableToRoles/members/update et .../owners/update (Privileged Role Administrator, Global Administrator) ou être owner actif ; pour les autres groupes, microsoft.directory/groups/members/update et .../owners/update (Groups Administrator, Identity Governance Administrator) ou owner actif.
• Non pris en charge : dynamic groups, groupes synchronisés depuis l'AD local, groupes d'une restricted management administrative unit.
• Deux jeux de role settings par groupe : Member et Owner.
• Un owner ou un admin peut encore modifier le groupe hors de PIM, ce qui contourne PIM : le surveiller.

4.4 Le circuit de demande et d'approbation#

sequenceDiagram
    actor U as Utilisateur éligible
    participant P as PIM
    actor A as Approbateur
    actor G as Global Admin / Privileged Role Admin
    U->>P: Activer le rôle (durée, justification, ticket)
    P->>A: E-mail avec lien vers la demande
    Note over A: 24 h pour décider, non configurable
    A->>P: Approve ou Deny (justification)
    P-->>U: Rôle actif pour la durée demandée
    P-->>G: Notification : utilisateur approuvé devenu actif
    Note over P: La première décision l'emporte, tous les approbateurs sont prévenus

• Approbation : PIM > Approve requests > Requests for role activations.
• Un approbateur ne peut pas approuver sa propre activation ; un service principal ne peut pas approuver.
• Sans décision en 24 heures, la demande tombe et l'utilisateur la refait ; ce délai n'est pas configurable et vaut pour les rôles Microsoft Entra, les rôles Azure resources et PIM for Groups.
• Les admins (Global Administrator, Privileged Role Administrator) ne sont pas prévenus des demandes s'ils ne sont pas approbateurs, mais ils voient et peuvent annuler toute demande en attente, et retirer une attribution active approuvée.
• Extend et Renew passent aussi par une approbation d'administrateur.
• Graph : demandes en attente pour l'approbateur courant :

GET https://graph.microsoft.com/v1.0/roleManagement/directory/roleAssignmentScheduleRequests/filterByCurrentUser(on='approver')?$filter=status eq 'PendingApproval'

4.5 Audit, alertes et rapports PIM#

Audit

• Resource audit (toutes les activités : attributions, activations, changements de role settings) et My audit (ses propres activités) : 30 jours. Lecteurs : Global Administrator, Global Reader, Privileged Role Administrator, Security Administrator, Security Reader.
• Pour conserver plus longtemps : diagnostic settings des audit logs vers Log Analytics ou un Storage account (voir le chapitre 10).
• Une activation peut produire plusieurs CorrelationId (activation planifiée, approbation) : corréler par roleAssignmentRequestId dans AdditionalDetails.

// Retrouver tout le cycle d'une activation (requête de la documentation)
let roleAssignmentRequestId = "<roleAssignmentRequestId>";
let relatedCorrelationIds = AuditLogs
   | where AdditionalDetails has roleAssignmentRequestId
   | summarize make_set(CorrelationId);
AuditLogs
| where AdditionalDetails has roleAssignmentRequestId
   or CorrelationId in (relatedCorrelationIds)

Alertes PIM (rôles Entra, PIM > Microsoft Entra roles > Alerts > Setting) :

Rapports : export des attributions par rôle (bouton Export de la liste des assignments) et access reviews de rôles (section 3.1).

4.6 Les emergency access accounts#

Exigences complètes et requête d'alerte : SC-500 chapitre 01, section 4.5. Ce que l'administrateur SC-300 vérifie en plus :

5. Labs conseillés#

Tenant de test avec licences d'essai Microsoft Entra ID Governance (ou P2) ; quelques comptes de test et un invité.

1. Catalog et délégation : créer un groupe « Délégués Marketing », l'ajouter au rôle Catalog creator ; avec un délégué, créer le catalog « Marketing », y ajouter un groupe dont il est owner ; essayer d'ajouter un groupe dont il n'est pas owner. Attendu : refus du second ajout (il faut être owner de la ressource ou avoir le rôle Entra qui la gère).
2. Access package à deux stages : package « Campagne » avec un groupe et un site SharePoint, policy Specific users and groups, stage 1 = Manager (fallback défini), stage 2 = un approbateur nommé, expiration 1 jour, une question obligatoire. Demander depuis My Access, approuver, refuser une seconde demande. Attendu : états Pending approval → Delivered, réponses visibles par les approbateurs, activité Deny access package assignment request dans les audit logs.
3. Externes et connected organization : activer l'email one-time passcode, créer une connected organization pour un domaine de test, une policy Specific connected organizations, envoyer le lien My Access à une adresse externe, approuver ; régler Number of days before removing external user à 0, retirer l'assignment. Attendu : compte invité créé à l'approbation, puis bloqué et supprimé.
4. Access review des invités : review d'un groupe, Guest users only, self-review, If reviewers don't respond = Remove access, Block 30 days, then remove, durée 1 jour, auto apply. Un invité refuse, un autre ne répond pas. Attendu : les deux bloqués à la fin ; réactivation possible d'un compte par l'admin.
5. PIM : approbation et alertes : rendre un compte eligible au rôle Security Reader avec approbation par un second compte ; activer, approuver, regarder Resource audit ; attribuer un rôle directement dans Roles and administrators. Attendu : alerte Roles are being assigned outside of Privileged Identity Management ; corrélation par roleAssignmentRequestId.

Nettoyage : supprimer access packages, catalogs, connected organizations, reviews et attributions de test ; vérifier qu'aucun compte d'urgence n'a été touché.

6. Pièges d'examen#

7. Scénarios d'entraînement#

1. Contoso veut que le service Juridique crée et gère lui-même ses access packages, sans voir ceux des autres services et sans rôle d'administration Entra. Que configurer ?

Ajouter le responsable du Juridique au rôle Catalog creator (Identity Governance Administrator). Il crée le catalog « Juridique », en devient catalog owner, y ajoute les groupes et sites dont il est propriétaire, puis délègue la création de packages à des access package managers. Un catalog creator ne voit pas les catalogs qu'il ne possède pas.

2. Un access package doit être demandable par les employés (approbation du manager) et par les consultants de Fabrikam (approbation de deux personnes). Combien de policies et lesquelles ?

Deux : une policy For users in your directory (stage 1 = Manager, avec fallback) et une policy For users not in your directory > Specific connected organizations = Fabrikam, 2 stages (External sponsor puis un approbateur interne). Une même policy ne peut pas viser internes et externes.

3. Après l'approbation, le système de facturation tiers doit vérifier le centre de coût du demandeur et pouvoir refuser. Quelle solution ?

Une custom extension de type Request workflow en Launch and wait, branchée sur l'étape Request is approved : la Logic App appelle le système tiers puis renvoie resume (ou un refus) par Graph dans le délai (au plus 14 jours). Licence ID Governance.

4. Les consultants externes doivent accepter la charte de confidentialité avant d'ouvrir le site SharePoint du projet, et la réaccepter tous les 90 jours. Que faire ?

Créer une terms of use (PDF, Duration before re-acceptance required = 90) puis une Conditional Access policy ciblant les invités et la ressource SharePoint, grant control Terms of use. Pas de consent on every device : non pris en charge pour les invités B2B. Licence P1.

5. Les comptes invités créés par entitlement management restent dans l'annuaire des mois après la fin des projets. Comment corriger sans toucher aux invités ajoutés manuellement ?

Entitlement management > Control configurations > Lifecycle of external users : Block external user from signing in et Remove external user, avec le délai voulu. Seuls les invités invités par entitlement management (ou convertis en governed) sont concernés ; ceux qui existaient avant restent.

6. Le RSSI veut une revue trimestrielle de tous les invités des Microsoft 365 groups, par les owners, avec suppression des invités non confirmés. Quelle configuration ?

Access review Teams + Groups > All Microsoft 365 groups with guest users (scope forcé à Guest users only), reviewers Group owner(s) avec fallback, récurrence trimestrielle, Auto apply, If reviewers don't respond = Remove access. L'action Block 30 days, then remove n'est pas configurable pour ce type de review : les invités refusés perdent l'appartenance au groupe.

7. Une review sur un groupe se termine, mais les utilisateurs refusés gardent l'accès. Le groupe vient d'Active Directory local. Pourquoi et que faire ?

Les résultats ne s'appliquent pas aux groupes synchronisés depuis l'AD local. Télécharger le CSV des résultats et retirer les membres dans l'AD local, la synchronisation fera le reste.

8. Une banque veut que la revue des droits sur l'application de paiement passe d'abord par les managers, puis par le propriétaire de l'application pour les seuls refus et les « Don't know ». Que configurer ?

Access review Applications, Multi-stage review : stage 1 = Managers of users (fallback), stage 2 = le propriétaire en Selected user, Specify reviewees to go to next stage = Denied et Reviewees marked as "Don't know". Option : Show previous stage(s) decisions. La décision du stage 2 remplace celle du stage 1.

9. Un audit demande la liste des activations du rôle Global Administrator des 6 derniers mois, avec l'approbateur. PIM ne montre que 30 jours. Comment faire maintenant et à l'avenir ?

Le passé au-delà de 30 jours n'est disponible que si les audit logs étaient déjà exportés. Mettre en place des diagnostic settings des audit logs vers Log Analytics (ou un Storage account), puis requêter AuditLogs en corrélant par roleAssignmentRequestId.

10. L'alerte PIM Roles are being assigned outside of Privileged Identity Management se déclenche. Que signifie-t-elle et quelle est la bonne réaction ?

Un rôle privilégié a été attribué directement (portail Roles and administrators, PowerShell, Graph) sans passer par PIM : sévérité High, signe possible d'attaque. Vérifier qui a fait l'attribution (audit logs), retirer l'attribution si elle n'est pas justifiée, la recréer en eligible dans PIM et bloquer ce chemin.

11. Un administrateur veut placer le groupe dynamique « Admins Tier 0 » sous PIM for Groups pour donner l'appartenance juste-à-temps. Est-ce possible ?

Non : PIM for Groups ne gère ni les dynamic groups ni les groupes synchronisés. Créer un groupe assigné (role-assignable si le groupe porte des rôles Entra), le mettre sous gestion PIM, rendre les membres eligible et exiger l'approbation.

12. Les deux comptes d'urgence sont eligible au rôle Global Administrator et l'activation exige une approbation. Quel est le risque, et quelle correction ?

En cas d'incident (approbateurs indisponibles, Conditional Access cassé), personne ne peut activer : verrouillage du tenant. Rendre les comptes d'urgence actifs permanents, les exclure des Conditional Access qui bloquent, leur donner une méthode FIDO2 et une alerte sur chaque connexion.

8. Pour aller plus loin#

• Lifecycle workflows : joiner, mover, leaver déclenchés par employeeHireDate ou employeeLeaveDateTime, avec une tâche Request user access package assignment qui crée automatiquement la demande d'access package (rôles Identity Governance Administrator et Lifecycle Workflows Administrator). Bases dans le SC-500, section 11.7.
• Agents et service principals dans les access packages (préversion, Microsoft Entra Agent ID).
• PIM custom extensions (préversion) : appeler un point de terminaison externe lors d'une activation.

9. Fiche à retenir#

• Entitlement management et access reviews : ID Governance (une partie avec P2) ; custom extensions et auto assignment : ID Governance seul ; terms of use : P1.
• Rôle d'administration recommandé : Identity Governance Administrator (plus le User Administrator).
• Rôles d'entitlement management : catalog creator, catalog owner, access package manager, access package assignment manager, catalog reader, Connected Organization Administrator.
• Ajouter une ressource = catalog owner + droit sur la ressource.
• Policy : Requests (in directory / not in directory / None), Approval (1 à 3 stages, fallback, alternate ≥ 4 jours), Requestor information, Lifecycle (0 à 3 660 jours, extension, review), Custom extensions.
• Internes + externes = deux policies ; separation of duties à sens unique.
• Demande : Submitted → Pending approval → Delivering → Delivered ; sans décision → Expired.
• Terms of use : grant control Conditional Access, PDF par langue, per-device pas pour B2B, 40 terms par tenant, refus = blocage.
• Lifecycle of external users : blocage puis suppression après 30 jours par défaut, seulement pour les invités venus par entitlement management.
• Connected organization : Entra ID, SAML/WS-Fed, domaine (OTP), Microsoft Account ; Configured vs Proposed ; sponsors internes et externes.
• Access review : scope (Guest users only, Inactive users jusqu'à 730 j), reviewers (owners, selected, self, managers + fallback), récurrence, auto apply, If reviewers don't respond, invités refusés bloqués 30 jours puis supprimés.
• Multi-stage : 2 ou 3 stages, reviewees to next stage, la dernière décision l'emporte.
• Reviews de rôles Entra et Azure : dans PIM (Privileged Role Administrator ; Owner ou User Access Administrator).
• PIM : approbation en 24 h non configurable (rôles Entra, Azure resources, groupes), pas d'auto-approbation, audit 30 jours → diagnostic settings, corrélation par roleAssignmentRequestId.
• Alerte PIM la plus grave : Roles are being assigned outside of PIM (High).
• PIM for Groups : pas de dynamic, synchronisé ou RMAU ; un groupe géré ne sort plus de PIM.
• Emergency access : actifs permanents, FIDO2, exclus du Conditional Access qui bloque, alerte, test tous les 90 jours.

Références#

Toutes lues le 21/10/2026 sur Microsoft Learn :

• Study guide for Exam SC-300
• What is entitlement management?
• Delegation and roles in entitlement management
• Change request settings for an access package
• Change approval and requestor information settings for an access package
• Change lifecycle settings for an access package
• Configure separation of duties checks for an access package
• Trigger Logic Apps with custom extensions in entitlement management
• Request process and email notifications in entitlement management
• View and remove requests for an access package
• Reprocess requests for an access package
• Troubleshoot entitlement management
• View reports and logs in entitlement management
• Govern access for external users in entitlement management
• Manage connected organizations in entitlement management
• Microsoft Entra terms of use
• Create an access review of groups and applications
• Manage user and guest user access with access reviews
• Complete an access review of groups and applications
• Review access to groups and applications in access reviews
• Create an access review of Azure resource and Microsoft Entra roles in PIM
• Assign Azure resource roles in Privileged Identity Management
• Bring groups into Privileged Identity Management
• Approve or deny requests for Microsoft Entra roles in PIM
• View audit history for Microsoft Entra roles in PIM
• Configure security alerts for Microsoft Entra roles in PIM
• Assign Microsoft Entra roles in PIM (Microsoft Graph)
• Tutorial: Assign Microsoft Entra roles through PIM with Microsoft Graph
• Tutorial: Review a security group with access reviews APIs
• Microsoft Entra ID Governance licensing fundamentals
• Manage emergency access accounts in Microsoft Entra ID