01 · Sécuriser l'accès aux ressources avec Microsoft Entra ID

Version : 1.3 · Date : 2026-10-21 · Domaine 1 de l'examen : Manage identity, access, and governance (20 à 25 %)

En une phrase : Microsoft Entra ID authentifie chaque identité (humaine ou non), Conditional Access décide si l'accès est accordé et à quelles conditions, PIM ne donne les privilèges qu'au moment où l'on en a besoin, et les managed identities suppriment les secrets des applications.

Ce que l'examen demande#

Repris mot pour mot du guide d'étude SC-500 :

La section 11 ajoute la culture identité de l'ancienne AZ-500 (ID Protection, identité hybride, SSPR, invités B2B, administrative units, gouvernance, journaux) : hors compétences mesurées, mais souvent présente dans le contexte des questions.

1. Les bases à maîtriser avant tout#

1.1 Les identités dans Microsoft Entra ID#

Un locataire (tenant) Microsoft Entra est l'annuaire d'une organisation. Il contient deux grandes familles d'identités :

1.2 Deux systèmes de rôles à ne jamais confondre#

C'est le piège le plus fréquent du domaine identité.

À retenir : être Global Administrator de l'annuaire ne donne aucun droit sur les ressources Azure par défaut. Il peut seulement s'élever en User Access Administrator à la racine (Elevate access), ce qui doit rester exceptionnel.

1.3 Les licences, souvent au cœur d'une question#

Pour PIM, la licence est due pour : chaque utilisateur avec une attribution éligible ou limitée dans le temps, chaque membre ou propriétaire éligible d'un groupe PIM, chaque approbateur, chaque personne revue ou qui fait une access review.

Si la licence expire : les stratégies Conditional Access ne sont ni désactivées ni supprimées (on peut les voir et les supprimer, plus les modifier) ; pour PIM, les attributions éligibles aux rôles Entra sont supprimées, les attributions permanentes restent.

1.4 Le cadre : Zero Trust#

Toutes les fonctionnalités de ce chapitre servent les trois principes de Zero Trust (Confiance nulle) :

1. Vérifier explicitement : authentification forte, signaux de l'appareil, de l'emplacement et du risque (Conditional Access).
2. Utiliser le privilège minimum : rôles juste-à-temps (PIM), consentement maîtrisé, rôles RBAC ciblés.
3. Supposer une violation : sessions réévaluées en continu, comptes d'urgence surveillés, secrets supprimés (managed identities).

2. Authentication methods : MFA et passwordless#

2.1 Où se configurent les méthodes#

Depuis le 30 septembre 2025, les méthodes ne se gèrent plus dans les anciennes stratégies MFA et SSPR : tout passe par l'Authentication methods policy (Microsoft Entra admin center > Entra ID > Authentication methods > Policies). Un assistant de migration automatique existe ; l'état passe de Migration in progress à Migration complete.

Avantage clé de la nouvelle stratégie : chaque méthode s'active pour des utilisateurs ou des groupes précis (l'ancienne valait pour tout le locataire).

2.2 Les méthodes et leurs usages#

Recommandation Microsoft : privilégier les méthodes résistantes au hameçonnage (FIDO2, Windows Hello for Business, CBA, Platform Credential for macOS). Le SMS, la voix et les codes ponctuels restent vulnérables au hameçonnage à distance.

2.3 Le Temporary Access Pass (TAP) : démarrer sans mot de passe#

Un TAP est un code limité dans le temps, à usage unique ou multiple, qui permet à un utilisateur de s'inscrire à une méthode sans mot de passe (premier jour, appareil perdu) sans recevoir de mot de passe.

Points d'examen :

• il faut le rôle Authentication Policy Administrator pour modifier la stratégie TAP, et l'utilisateur doit être dans l'étendue de la stratégie pour pouvoir s'en servir ;
• avec un TAP à usage unique, l'inscription d'une méthode sans mot de passe doit se faire dans les 10 minutes ;
• pour un domaine fédéré, le TAP l'emporte sur la fédération (l'authentification se fait dans Entra ID) ;
• un TAP ne remplace pas le mot de passe ; il ne peut pas être donné à un invité externe.

flowchart LR
    A[Administrateur<br/>crée un TAP] --> B[Utilisateur se connecte<br/>avec le TAP]
    B --> C[Inscrit une passkey FIDO2<br/>ou Windows Hello for Business]
    C --> D[Le TAP expire<br/>ou a été utilisé]
    D --> E[Connexions suivantes<br/>sans mot de passe]

Création d'un TAP par Microsoft Graph (API REST) :

POST https://graph.microsoft.com/v1.0/users/{id-utilisateur}/authentication/temporaryAccessPassMethods
Content-Type: application/json

{ "lifetimeInMinutes": 60, "isUsableOnce": true }

2.4 Les authentication strengths (forces d'authentification)#

Une authentication strength est un contrôle Conditional Access qui précise quelles combinaisons de méthodes sont acceptées pour une ressource. Trois authentication strengths sont intégrées (built-in, non modifiables, tenues à jour par Microsoft) :

Pièges :

• On ne peut pas mettre Require multifactor authentication et Require authentication strength dans la même stratégie : l'authentication strength intégrée « Multifactor authentication » est équivalente.
• La force s'applique après le premier facteur : un utilisateur peut taper son mot de passe, puis il doit satisfaire l'authentication strength (par exemple une clé FIDO2) avant de continuer.
• On peut créer des custom authentication strengths (par exemple « FIDO2 avec un modèle de clé précis »).

2.5 La MFA obligatoire pour Azure#

Microsoft impose la MFA, sans possibilité de refus, à tout compte utilisateur qui gère Azure :

Piège d'examen : les managed identities et les service principals ne sont pas concernés. Un compte utilisateur utilisé comme compte de service, lui, l'est : il faut le migrer vers une workload identity. Le flux OAuth ROPC (nom d'utilisateur + mot de passe dans le code) est incompatible avec la MFA. Les comptes d'urgence sont aussi concernés : leur donner une clé FIDO2 ou un certificat.

3. Conditional Access#

3.1 Le principe : « si… alors… »#

Conditional Access est le moteur de stratégie Zero Trust de Microsoft : il rassemble des signaux, prend une décision et l'applique. Une stratégie se lit : si tel utilisateur veut accéder à telle ressource dans telles conditions, alors il doit faire telle chose (ou il est bloqué).

Important : Conditional Access s'applique après l'authentification du premier facteur. Ce n'est pas une protection contre le déni de service.

3.2 Comment les stratégies sont évaluées#

• Toutes les stratégies applicables s'appliquent : si l'une exige la MFA et une autre un appareil conforme, il faut les deux.
• Dans une stratégie, les assignments se combinent par ET (utilisateur ET application ET condition).
• Dans les grant controls : Require all the selected controls (par défaut) ou Require one of the selected controls.
• Un Block l'emporte sur tout.

flowchart TD
    A[Connexion : premier facteur réussi] --> B[Phase 1 : collecte des détails de session<br/>emplacement, appareil, risque, application]
    B --> C{Une stratégie applicable<br/>contient Block ?}
    C -- Oui --> X[Accès bloqué]
    C -- Non --> D[Phase 2 : contrôles d'octroi non satisfaits<br/>dans l'ordre : MFA, appareil conforme, jonction hybride,<br/>application approuvée, protection d'application,<br/>changement de mot de passe, Terms of use]
    D --> E{Tous satisfaits ?}
    E -- Non --> X
    E -- Oui --> F[Contrôles de session appliqués<br/>Sign-in frequency, Defender for Cloud Apps…]
    F --> G[Jeton émis, accès accordé]

La phase 1 tourne aussi pour les stratégies en mode Report-only ; la phase 2 seulement pour les stratégies activées.

3.3 Les bonnes pratiques de déploiement#

1. Toujours commencer en mode Report-only, regarder l'impact dans les sign-in logs (onglet Report-only), utiliser l'outil What If, puis activer.
2. Exclure les comptes d'accès d'urgence de toute stratégie qui bloque ou restreint (voir 4.5) ; les stratégies en Report-only n'ont pas besoin de l'exclusion.
3. Bloquer la legacy authentication (protocoles qui ne savent pas faire la MFA).
4. Cibler les rôles d'administration avec une authentication strength résistante au hameçonnage.
5. Les stratégies qui ciblent des rôles ou des groupes ne sont évaluées qu'à l'émission d'un jeton : un utilisateur ajouté à un rôle n'est pas concerné tant qu'il n'a pas un nouveau jeton. Avec PIM, exiger Conditional Access pendant l'activation (authentication context, 4.3).

Exemple : créer en Report-only une stratégie MFA pour un rôle, avec Microsoft Graph PowerShell :

Connect-MgGraph -Scopes "Policy.ReadWrite.ConditionalAccess"
$params = @{
  displayName = "CA01 - MFA résistante au hameçonnage pour les administrateurs"
  state       = "enabledForReportingButNotEnforced"   # Report-only
  conditions  = @{
    users        = @{ includeRoles = @("62e90394-69f5-4237-9190-012177145e10")   # Global Administrator (ID du modèle de rôle)
                      excludeGroups = @("<id-groupe-comptes-urgence>") }
    applications = @{ includeApplications = @("All") }
  }
  grantControls = @{ operator = "OR"; builtInControls = @("mfa") }
}
New-MgIdentityConditionalAccessPolicy -BodyParameter $params

3.4 Continuous Access Evaluation (CAE)#

Sans CAE, un jeton d'accès reste valable jusqu'à son expiration (environ 1 heure). Avec la CAE, les services compatibles (Exchange Online, SharePoint Online, Teams, Microsoft Graph) révoquent la session quasi en temps réel sur un événement critique : compte désactivé ou supprimé, mot de passe changé ou réinitialisé, MFA activée, révocation explicite des jetons, user risk élevé. Le changement d'emplacement réseau est appliqué immédiatement si une stratégie d'emplacement existe. En contrepartie, les jetons CAE durent jusqu'à 28 heures (latence possible jusqu'à 15 minutes pour les événements critiques).

4. Privileged Identity Management (PIM)#

4.1 À quoi sert PIM#

PIM réduit la surface d'attaque des comptes à privilèges : personne n'est administrateur en permanence. On est éligible à un rôle et on l'active quand on en a besoin, pour une durée limitée, avec MFA, justification, voire approbation.

Fonctions clés : accès juste-à-temps, attributions limitées dans le temps (dates de début et de fin), approbation, MFA à l'activation, justification et numéro de ticket, notifications, access reviews, historique d'audit, protection contre la suppression des dernières attributions actives de Global Administrator et de Privileged Role Administrator.

PIM gère trois catégories :

• Microsoft Entra roles ;
• Azure resources (rôles RBAC à l'échelle d'un management group, d'un abonnement, d'un resource group, d'une ressource) ;
• Groups (PIM for Groups : appartenance ou propriété juste-à-temps d'un security group ou Microsoft 365 group).

4.2 Le vocabulaire (très demandé)#

Qui gère quoi :

• rôles Entra : seuls le Privileged Role Administrator et le Global Administrator gèrent les attributions ;
• ressources Azure : l'administrateur de l'abonnement, l'Owner de la ressource ou le User Access Administrator. Par défaut, le Privileged Role Administrator ne voit pas les attributions des ressources Azure.

4.3 Les role settings#

Appelés aussi « stratégies PIM » (unifiedRoleManagementPolicy dans Microsoft Graph), ils se règlent par rôle (toutes les attributions d'un rôle partagent les mêmes paramètres) :

Piège mortel : si tous les Global Administrators et Privileged Role Administrators sont éligibles (aucun actif), que l'activation exige une approbation et qu'aucun approbateur n'est configuré, le locataire est verrouillé. Parade : des comptes d'urgence actifs en permanence et des approbateurs nommés.

Pour l'authentication context, créer d'abord la stratégie Conditional Access qui le cible (portée : tous les utilisateurs ou les éligibles, jamais limitée au rôle, puisque l'utilisateur n'a pas encore le rôle pendant l'activation), puis le configurer dans PIM. Une seconde stratégie qui cible le rôle d'annuaire protège l'usage du rôle une fois activé (sinon on peut activer depuis un appareil conforme et l'utiliser depuis un autre).

sequenceDiagram
    actor U as Utilisateur éligible
    participant P as PIM
    participant CA as Conditional Access
    actor A as Approbateur
    U->>P: Activer « Security Administrator » (2 h, justification)
    P->>CA: Authentication context exigé
    CA-->>U: Authentication strength Phishing-resistant MFA (FIDO2)
    U->>CA: Authentification FIDO2
    P->>A: Demande d'approbation (e-mail)
    A->>P: Approuve
    P-->>U: Rôle actif pendant 2 h
    Note over P: Après 2 h, le rôle redevient éligible

4.4 PIM for Groups#

• Appartenance ou propriété juste-à-temps d'un groupe : chaque groupe a deux stratégies (Member, Owner).
• Sert à donner en une fois l'accès à des rôles Entra, des rôles Azure, Azure SQL, Key Vault, Intune, des applications.
• Pour élever vers des rôles Entra, utiliser des role-assignable groups et exiger l'approbation : sinon un administrateur moins privilégié capable de réinitialiser le mot de passe d'un membre éligible pourrait activer à sa place.
• Un role-assignable group ne peut pas contenir d'autres groupes (appartenance active) ; un groupe peut en revanche être membre éligible d'un autre.
• Une attribution ne peut pas durer moins de 5 minutes ni être retirée dans les 5 minutes.
• Une fois sous gestion PIM, un groupe ne peut plus en être retiré.
• Pour Exchange, SharePoint ou Purview, préférer PIM for Microsoft Entra roles (l'activation par groupe peut tarder).

4.5 Les comptes d'accès d'urgence#

En anglais emergency access accounts, appelés aussi comptes « break glass » : ils servent quand plus personne ne peut se connecter (stratégie mal configurée, panne de la fédération, administrateurs verrouillés).

Alerte Azure Monitor sur les sign-in logs envoyés dans Log Analytics :

SigninLogs
| where UserId in ("<id-objet-compte-urgence-1>", "<id-objet-compte-urgence-2>")
| project TimeGenerated, UserPrincipalName, IPAddress, ResultType, ResultDescription

Règle d'alerte : seuil statique « supérieur à 0 », Severity 0 - Critical, action group vers les administrateurs.

5. L'identité des applications#

5.1 App registration et Enterprise application#

Les trois types de service principal :

1. Application : instance d'une App registration (le cas courant).
2. Managed identity : représente une managed identity ; pas d'application object, non modifiable directement.
3. Legacy : application créée avant les App registrations ; utilisable seulement dans son locataire.

Inscrire une application dans le portail crée l'application object et le service principal ; par l'API Graph, ce sont deux étapes distinctes. Supprimer l'application object supprime le service principal du locataire de base, mais restaurer l'objet ne restaure pas le service principal. Pour suspendre une application sans la supprimer : la désactiver (plus aucun jeton émis).

# Trouver le service principal d'une application
az ad sp list --filter "appId eq '<appId>'"

5.2 Les credentials d'une application (Certificates & secrets)#

5.3 Delegated permissions et application permissions#

5.4 Restreindre l'accès à une application#

Par défaut, tout utilisateur du locataire peut se connecter à une Enterprise application. Pour limiter : propriétés de l'Enterprise application > Assignment required = Oui, puis affecter des utilisateurs ou des groupes. Cela vaut même si un administrateur a déjà consenti pour tout le locataire.

6. Le consentement OAuth#

6.1 User consent et admin consent#

• User consent : l'utilisateur accorde à l'application des delegated permissions sur ses données, à sa première connexion, si l'organisation le permet pour cette application et ces autorisations.
• Admin consent : un administrateur accorde l'accès au nom de toute l'organisation (ou d'un seul utilisateur, par l'API Graph) ; obligatoire pour les application permissions et les delegated permissions sensibles. Opération sensible : elle peut ouvrir toutes les boîtes aux lettres, tous les sites, la gestion des rôles.

6.2 Les user consent settings#

Entra ID > Enterprise applications > Consent and permissions :

Permission classifications : Low (et Medium, High en préversion), seulement pour les autorisations déléguées qui n'exigent pas l'admin consent. Les quatre autorisations minimales d'une connexion sont openid, profile, email et offline_access. Rôle requis : Application Administrator ou Cloud Application Administrator.

Pour un contrôle plus fin : des custom app consent policies (PowerShell ou Graph). Un changement de paramètre ne vaut que pour les futurs consentements : pour retirer un consentement existant, examiner et révoquer les autorisations de l'Enterprise application.

6.3 L'admin consent workflow#

Quand un utilisateur ne peut pas consentir, il voit « Approval required », justifie et envoie une demande aux reviewers désignés, qui reçoivent un e-mail. Points clés :

• le Global Administrator active le workflow ;
• désigner un réviseur ne lui donne aucun droit : il doit déjà avoir les rôles qui permettent d'accorder ce consentement ;
• une seule demande par utilisateur et par application est transmise ; l'utilisateur est prévenu de la décision.

flowchart TD
    A[Utilisateur ouvre une application] --> B{Consentement déjà accordé ?}
    B -- Oui --> OK[Accès]
    B -- Non --> C{Le user consent est-il permis<br/>pour cette application et ces autorisations ?}
    C -- Oui --> D[Invite de consentement] --> OK
    C -- Non --> E{Admin consent workflow<br/>activé ?}
    E -- Non --> KO[Accès refusé : contacter un administrateur]
    E -- Oui --> F[Approval required : demande envoyée aux reviewers]
    F --> G{Réviseur approuve ?}
    G -- Oui --> H[Admin consent accordé] --> OK
    G -- Non --> KO

7. Les managed identities#

7.1 Le principe#

Une managed identity donne à une ressource Azure (VM, App Service, Functions, AKS, Logic Apps…) une identité Entra dont Azure gère seul les informations d'identification : on n'y a même pas accès, elles tournent automatiquement, et c'est gratuit. Le code obtient un jeton par le SDK Azure.Identity (ou MSAL), puis accède aux services qui acceptent l'authentification Entra (Key Vault, Azure Storage, Azure SQL, Cosmos DB…), selon les rôles RBAC donnés à l'identité.

7.2 System-assigned ou user-assigned#

Recommandation Microsoft : la managed identity user-assigned est le type recommandé pour les services Microsoft.

Mise en œuvre avec Azure CLI :

# 1. Créer une user-assigned managed identity
az identity create --resource-group rg-app-prd --name id-app-prd

# 2. L'affecter à une application web
az webapp identity assign --resource-group rg-app-prd --name app-web-prd \
  --identities /subscriptions/<sub>/resourceGroups/rg-app-prd/providers/Microsoft.ManagedIdentity/userAssignedIdentities/id-app-prd

# 3. Lui donner le droit de lire les secrets d'un Key Vault (permission model Azure RBAC)
az role assignment create --assignee-object-id <principalId-de-l-identite> --assignee-principal-type ServicePrincipal \
  --role "Key Vault Secrets User" \
  --scope /subscriptions/<sub>/resourceGroups/rg-app-prd/providers/Microsoft.KeyVault/vaults/kv-app-prd

7.3 La workload identity federation#

Hors d'Azure (GitHub Actions, Kubernetes, autre cloud, autre fournisseur OpenID Connect), pas de managed identity possible. Au lieu d'un secret, on crée une relation d'approbation : un federated credential sur une App registration ou sur une user-assigned managed identity indique quel jeton externe accepter. La charge de travail échange son jeton externe (par exemple le jeton OIDC de GitHub) contre un jeton Entra.

Pour GitHub Actions : Certificates & secrets > Federated credentials > scénario GitHub Actions deploying Azure resources, puis l'organisation, le dépôt et l'Entity type (Environment, Branch, Pull request, Tag). Les valeurs issuer, subject et audience doivent correspondre exactement (sensible à la casse) au jeton reçu ; pas de joker pour les branches et étiquettes.

Une managed identity peut aussi servir de federated credential d'une App registration (au plus 20 federated credentials de ce type) : la méthode recommandée pour qu'une charge de travail Azure agisse comme une application Entra sans secret.

8. Labs conseillés#

Dans un locataire de test (jamais celui de l'entreprise) avec une licence Entra ID P2 (version d'essai), et un abonnement Azure de test pour le lab 5. Commencer par créer deux comptes d'accès d'urgence et un groupe qui les contient, à exclure de chaque stratégie Conditional Access.

Lab 1. Un rôle juste-à-temps avec PIM.

1. PIM > Microsoft Entra roles > Security Administrator > Settings : activation 2 h, MFA, justification, approbation par un second compte de test.
2. Attribuer le rôle éligible à un utilisateur de test.
3. Avec cet utilisateur : My roles > Activate ; avec l'approbateur : approuver la demande.
4. Résultat attendu : le rôle est actif 2 h, puis redevient éligible ; l'activation apparaît dans l'audit PIM.

Lab 2. Une stratégie Conditional Access en Report-only.

1. Créer CA01 - MFA résistante au hameçonnage pour les administrateurs (rôles d'administration, authentication strength intégrée), groupe d'urgence exclu, état Report-only.
2. Se connecter avec un administrateur de test qui n'a qu'un mot de passe et une notification Authenticator.
3. Sign-in logs > la connexion > onglet Report-only : résultat Failure (la stratégie aurait bloqué).
4. Rejouer le cas avec l'outil What If, puis activer la stratégie après l'inscription d'une passkey (lab 3).

Lab 3. Démarrer sans mot de passe avec un TAP.

1. Authentication methods > Temporary Access Pass : activer pour un groupe de test (usage unique, 1 h).
2. Créer un TAP pour un utilisateur de ce groupe.
3. Avec ce TAP, se connecter sur https://aka.ms/mysecurityinfo et inscrire une passkey (Authenticator ou clé FIDO2).
4. Résultat attendu : la méthode apparaît sur l'utilisateur ; le TAP ne fonctionne plus.

Lab 4. Le consentement maîtrisé.

1. Consent and permissions : Allow user consent for apps from verified publishers, for selected permissions ; classer User.Read en Low.
2. Activer l'admin consent workflow avec vous comme réviseur.
3. Inscrire une application de test qui demande une delegated permission plus large (par exemple User.Read.All) et s'y connecter avec un utilisateur.
4. Résultat attendu : l'écran Approval required, puis la demande dans Admin consent requests.

Lab 5. Une managed identity qui lit un secret.

1. Créer une petite VM Linux avec une managed identity system-assigned, et un Key Vault en Azure RBAC.
2. Donner Key Vault Secrets User à l'identité de la VM sur le Key Vault.
3. Depuis la VM : curl -H Metadata:true "http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://vault.azure.net" renvoie un jeton, utilisé ensuite contre l'API du Key Vault.
4. Résultat attendu : aucun secret n'a été stocké sur la VM ; la connexion apparaît dans les Managed identity sign-ins.

9. Les pièges d'examen#

10. Scénarios d'entraînement#

1. Contoso veut que les Security Administrators n'aient leurs droits que 2 heures par jour, avec une clé FIDO2 et l'accord du RSSI. Que configurer ?

Dans PIM for Microsoft Entra roles : attribution Eligible au rôle Security Administrator ; role settings : durée maximale d'activation 2 h, authentication context relié à une stratégie Conditional Access exigeant l'authentication strength Phishing-resistant MFA, approbation par le RSSI. Licence P2 ou ID Governance pour les administrateurs et l'approbateur.

2. Une Function App doit lire un secret de Key Vault ; l'équipe propose de mettre la chaîne de connexion dans les paramètres de l'application. Meilleure solution ?

Activer une managed identity sur la Function App, donner le rôle Key Vault Secrets User sur le Key Vault (permission model Azure RBAC), et lire le secret par le SDK ou une Key Vault reference. Aucun secret n'est stocké.

3. Un utilisateur ne peut pas ajouter une application SaaS : il voit « Approval required ». Pourquoi, et que faire pour qu'un administrateur traite la demande ?

Le user consent n'est pas permis pour cette application ou ces autorisations. L'admin consent workflow est activé : un réviseur ayant les droits d'accorder ce consentement approuve ou refuse.

4. Fabrikam a une licence Microsoft Entra ID P1. Elle veut bloquer les connexions à risque élevé. Est-ce possible ?

Non avec P1 seul : les conditions de risque viennent de Microsoft Entra ID Protection (P2). Avec P1 : MFA, appareils conformes, emplacements, blocage de l'authentification héritée.

5. Le pipeline GitHub de déploiement Terraform utilise un secret client qui expire tous les 6 mois. Comment le supprimer ?

Sur l'App registration (ou une user-assigned managed identity), ajouter un federated credential « GitHub Actions deploying Azure resources » pour le dépôt et l'environnement de production ; le workflow utilise azure/login avec client-id, tenant-id, subscription-id et le jeton OIDC. Supprimer ensuite le secret.

6. Une stratégie Conditional Access exigeant un appareil conforme pour tous les utilisateurs est prête. Comment la déployer sans risque ?

L'activer en Report-only, analyser les sign-in logs et l'outil What If, vérifier l'exclusion des comptes d'urgence, puis passer en On.

7. Une application multilocataire développée par Adatum est utilisée par Contoso. Où l'administrateur de Contoso voit-il les autorisations accordées et les utilisateurs affectés ?

Dans les Enterprise applications de Contoso : c'est le service principal de Contoso. L'App registration (application object) n'existe que dans le locataire d'Adatum.

8. Le seul Global Administrator est éligible dans PIM, l'activation exige une approbation, aucun approbateur n'est défini. Que risque-t-on, et comment l'éviter ?

Le verrouillage du locataire : personne d'actif pour approuver. Parade : deux comptes d'urgence Global Administrator actifs permanents, et des approbateurs nommés.

11. Compléments AZ-500 : la culture identité à connaître#

Ces sujets ne figurent pas dans les compétences mesurées de la SC-500, mais ils étaient au programme de l'AZ-500 et servent de décor à beaucoup de questions (« l'entreprise a une identité hybride… », « un invité B2B… », « le support technique ne doit pas pouvoir réinitialiser le mot de passe du PDG… »). Ils font aussi partie du quotidien de tout ingénieur sécurité Azure.

11.1 Microsoft Entra ID Protection#

ID Protection détecte, permet d'examiner et de corriger les risques liés à l'identité. Ses signaux viennent de l'analyse de milliards d'événements (Active Directory, comptes Microsoft, Xbox) et de produits Defender. Elle alimente Conditional Access (décision d'accès) et un SIEM (enquête). Licence : Microsoft Entra ID P2 (ou Entra Suite).

Le contrôle Require risk remediation gère seul le bon flux selon la méthode : changement de mot de passe sécurisé (et révocation des sessions) si un mot de passe est compromis, simple révocation des sessions et reconnexion pour un utilisateur sans mot de passe, désactivation de l'appareil si un attaquant en a ajouté un. Il corrige le user risk (pas le sign-in risk), applique automatiquement une authentication strength et la Sign-in frequency Every time, et n'est pas pris en charge pour les invités (Entra ID ne peut pas révoquer leurs sessions). Si un utilisateur est visé par plusieurs stratégies de risque : Block l'emporte sur tout, puis Require risk remediation sur Require password change.

Date clé : les anciennes stratégies de risque configurées dans ID Protection (user risk policy, sign-in risk policy) sont retirées depuis le 1er octobre 2026. Tout se configure dans Conditional Access (mode Report-only, combinaison avec l'emplacement, plusieurs stratégies par groupe, API Graph). La MFA registration policy d'ID Protection reste disponible pour faire inscrire les nouveaux utilisateurs dès le premier jour.

Examiner et corriger à la main : trois rapports, Risky users, Risky sign-ins et Risk detections (90 jours de données filtrables). Sur un utilisateur, l'administrateur peut Reset password (révoque les sessions), Confirm user compromised (risque passé à élevé), Confirm safe (faux positif, risque supprimé), Dismiss user risk (vrai mais bénin, par exemple un test d'intrusion), Block user, ou ouvrir l'enquête dans Microsoft Defender. Les données s'exportent par les diagnostic settings (Log Analytics, stockage, Event Hubs) et vers Microsoft Sentinel (connecteur Microsoft Entra ID Protection).

11.2 L'identité hybride#

Une identité hybride, c'est un compte Active Directory local synchronisé dans Entra ID, pour que l'utilisateur garde le même nom et le même mot de passe partout. Deux décisions distinctes : quel outil synchronise et qui valide le mot de passe (la méthode d'authentification ne dépend pas de l'outil de synchronisation).

L'outil de synchronisation

La méthode d'authentification

• Synchronisation : la PHS fait partie du cycle Connect Sync et tourne toutes les deux minutes (2 à 5 minutes avec Cloud Sync).
• Recommandation Microsoft : activer la PHS dans tous les cas. Elle sert de secours quand la pass-through authentication ou la fédération tombe (bascule manuelle dans Entra Connect). Elle est aussi nécessaire au rapport Leaked credentials d'ID Protection et à Microsoft Entra Domain Services.
• Seamless SSO (SSO transparent) : connexion sans ressaisie depuis un poste joint au domaine sur le réseau de l'entreprise, avec PHS ou PTA ; pris en charge par Connect Sync comme par Cloud Sync. Les appareils joints à Entra ou joints hybrides offrent aussi le SSO.
• Changer de méthode (par exemple de la fédération vers l'authentification cloud) se teste par Staged Rollout (déploiement intermédiaire), groupe par groupe.

flowchart TD
    A{"Faut-il une fonction qu'Entra ID ne gère pas ?<br/>MFA tierce, sAMAccountName, solution tierce"} -- Oui --> F["Federation (AD FS)<br/>+ PHS en secours"]
    A -- Non --> B{"Faut-il appliquer à chaque connexion<br/>la politique de compte locale ?<br/>verrouillage, heures, expiration"}
    B -- Oui --> P["Pass-through authentication (3 agents)<br/>+ PHS en secours"]
    B -- Non --> H["Password hash synchronization<br/>+ Seamless SSO"]

11.3 Self-service password reset (SSPR)#

SSPR permet de changer, réinitialiser et déverrouiller son mot de passe sans le support technique (https://aka.ms/sspr), avec en hybride le password writeback vers AD.

Piège : sans writeback, un utilisateur dont le mot de passe est géré sur site (PHS, PTA, fédération) ne peut pas réinitialiser son mot de passe par SSPR. Et une réinitialisation par SSPR après un Smart Lockout remet le compteur à zéro (option « J'ai oublié mon mot de passe »).

11.4 Password Protection et Smart Lockout#

Microsoft Entra Password Protection : à chaque changement ou réinitialisation, le nouveau mot de passe est comparé à deux listes.

• Global banned password list : tenue par Microsoft à partir de la télémétrie des attaques réelles, toujours active, non désactivable, non publiée.
• Custom banned password list : jusqu'à 1 000 termes propres à l'organisation (marque, produits, ville du siège). Mettre les termes de base (« Contoso »), pas leurs variantes : l'algorithme les bloque tout seul.
• Évaluation :
  1. normalisation (minuscules, substitutions 0→o, 1→l, $→s, @→a) ;
  2. correspondance approximative à une distance d'édition de 1 ;
  3. recherche du prénom, du nom et du nom du locataire (termes de 4 caractères et plus) ;
  4. score : 1 point par terme interdit trouvé, 1 point par autre caractère ; il faut au moins 5 points.
• Sur site (AD DS) : le Password Protection proxy (sur un serveur joint au domaine) télécharge la stratégie, et le DC agent (filtre de mot de passe sur chaque contrôleur de domaine) l'applique. Points clés :
  • les contrôleurs de domaine ne parlent jamais à Internet ;
  • aucun port ouvert, aucune modification de schéma ;
  • aucun lien avec la PHS ;
  • à installer sur tous les contrôleurs de domaine pour une protection homogène ;
  • commencer en mode Audit, puis passer en mode Enforced.
• Licences :

Smart Lockout (toujours actif) : il distingue les vrais utilisateurs des attaquants, avec des compteurs séparés pour les emplacements familiers et non familiers.

• Valeurs par défaut : verrouillage après 10 échecs (3 dans Azure Government), pendant 60 secondes, durée qui augmente à chaque nouveau verrouillage.
• Même mauvais mot de passe : les trois derniers hachages erronés sont mémorisés, donc ressaisir le même mauvais mot de passe n'incrémente pas le compteur (sauf avec la pass-through authentication).
• Personnaliser les valeurs : licence P1.
• Avec la pass-through authentication : le seuil Entra doit être inférieur à celui d'AD (deux à trois fois plus bas), et la durée Entra plus longue que celle d'AD. Ainsi, une pulvérisation de mots de passe ne verrouille pas les comptes sur site.

11.5 Les identités externes : B2B, inter-locataires, clients#

Cross-tenant access settings (Entra ID > External Identities) : pour les autres organisations Microsoft Entra.

• Outbound : ce que vos utilisateurs peuvent faire chez les autres.
• Inbound : qui, chez les autres, peut accéder à quoi chez vous.
• Trust settings : faire confiance à la MFA, aux compliant devices et aux appareils hybrid joined déjà vérifiés dans le locataire d'origine, pour ne pas redemander la MFA.
• Par défaut :
  • collaboration B2B autorisée ;
  • B2B direct connect bloquée ;
  • revendications MFA et appareil non approuvées ;
  • aucune cross-tenant synchronization.
• Priorité : les paramètres propres à une organisation l'emportent sur les paramètres par défaut.
• Rôle et licences : il faut au moins Security Administrator. La licence P1 est nécessaire pour l'approbation et le ciblage d'utilisateurs ou d'applications ; pour B2B direct connect, il faut P1 dans les deux locataires.
• Automatic redemption des invitations : supprime l'invite de consentement seulement si elle est cochée des deux côtés (sortant chez l'un, entrant chez l'autre).
• Redemption order : il est configurable, et on peut interdire les comptes Microsoft personnels (le code par e-mail reste alors en secours).

Ce qui se règle ailleurs :

• External collaboration settings : qui peut inviter, domaines autorisés ou bloqués, ce que les invités voient de l'annuaire (pour les identités non Entra).
• Tenant restrictions v2 : empêcher vos utilisateurs, sur vos appareils, d'utiliser des comptes d'autres locataires (exfiltration).
• Facturation d'External ID : au nombre d'utilisateurs actifs mensuels (MAU).
• Azure AD B2C : il n'est plus vendu aux nouveaux clients depuis le 1er mai 2025. La cible est External ID dans un locataire externe.

11.6 Les administrative units#

Une administrative unit est un conteneur d'utilisateurs, groupes ou appareils qui sert d'étendue à un rôle Entra : un Helpdesk Administrator limité à l'unité « Paris » ne réinitialise que les mots de passe des utilisateurs de Paris.

• Contraintes :
  • pas d'imbrication ;
  • un utilisateur peut appartenir à plusieurs unités ;
  • un rôle attribué hors unité vaut pour tout le locataire.
• Groupe placé dans une unité : le groupe entre dans l'étendue (nom, membres), pas ses membres. Pour gérer les utilisateurs, il faut les ajouter eux-mêmes à l'unité.
• Dynamic membership : possible pour les utilisateurs ou les appareils, pas pour les groupes.
• Lecture : l'unité limite seulement la gestion, pas la lecture de l'annuaire.
• Licences : P1 pour chaque administrateur de l'unité, Gratuit pour les membres, P1 pour les membres d'une unité dynamique. La création est faite au moins par un Privileged Role Administrator.
• Restricted management administrative unit (isMemberManagementRestricted, non modifiable après création) :
  • seuls les administrateurs nommés à l'étendue de l'unité peuvent modifier ses objets ;
  • un Global Administrator ou un Privileged Role Administrator de niveau locataire en est bloqué, sauf s'il s'attribue lui-même un rôle sur l'unité, ce qui est audité ;
  • membres possibles : utilisateurs, appareils, security groups ;
  • cas typique : les comptes de la direction générale.

Connect-MgGraph -Scopes "AdministrativeUnit.ReadWrite.All"
New-MgDirectoryAdministrativeUnit -BodyParameter @{
  DisplayName = "Direction générale"
  Description = "Comptes de la direction, gérés uniquement par le support dédié"
  IsMemberManagementRestricted = $true   # restricted management administrative unit, non modifiable ensuite
}

11.7 Identity Governance : access reviews, entitlement management, lifecycle workflows#

Licence : Microsoft Entra ID Governance ou Entra Suite (certaines fonctions marchent avec P2).

Access reviews : faire reconfirmer périodiquement (hebdomadaire, mensuelle, trimestrielle, annuelle) que l'accès est toujours justifié.

Paramètres de fin :

• Auto apply results to resource, ou application manuelle.
• If reviewers don't respond : No change, Remove access, Approve access ou Take recommendations (basées sur la dernière connexion). Attention, Remove access ou Take recommendations combinés à l'application automatique peuvent retirer tous les accès si personne ne répond.
• Invités refusés : retirer leur accès à la ressource, ou les bloquer 30 jours puis les supprimer du locataire.
• Les décisions ne s'appliquent qu'à la date de fin de la révision ; la révision photographie les accès au démarrage.

flowchart LR
    A["Création de la révision<br/>étendue, réviseurs, récurrence"] --> B["Début : photo des accès,<br/>e-mail aux réviseurs"]
    B --> C["Réviseurs : approuver ou refuser,<br/>aidés des recommandations"]
    C --> D{"Date de fin atteinte"}
    D --> E["Sans réponse : aucun changement,<br/>retrait, approbation ou recommandations"]
    E --> F["Application automatique ou manuelle<br/>des refus"]
    F --> G["Invité refusé : bloqué 30 jours<br/>puis supprimé"]

Entitlement management (gestion des droits d'utilisation) :

Lifecycle workflows (workflows de cycle de vie) : ils automatisent les trois moments de la vie d'un employé.

Le déclenchement se fait sur des attributs (employeeHireDate, employeeLeaveDateTime, service), avec une extension possible par Logic Apps. Le PIM (section 4) et les Terms of use complètent la gouvernance.

11.8 Les security defaults#

Un ensemble de protections de base, gratuit, tout ou rien :

• inscription de tous les utilisateurs à la MFA (avec Microsoft Authenticator, notifications et correspondance de nombre) ;
• MFA à chaque connexion pour les rôles d'administration (Global Administrator, Security Administrator, Conditional Access Administrator, Exchange Administrator, SharePoint Administrator, User Administrator…) ;
• MFA quand c'est nécessaire pour les utilisateurs ;
• blocage de l'authentification héritée et du device code flow (pour tous les nouveaux locataires depuis le 1er juillet 2026) ;
• MFA pour l'accès à Azure Resource Manager : portail, CLI, PowerShell.

Calendrier :

• Activation : les paramètres sont actifs sur les locataires créés depuis le 22 octobre 2019, avec 24 h de grâce après la création.
• Grâce de 14 jours pour s'inscrire à la MFA : supprimée depuis le 29 juillet 2024.

Piège : pour utiliser Conditional Access, on désactive les security defaults, puis on active immédiatement des stratégies équivalentes. Microsoft propose des Microsoft-managed Conditional Access policies qui reprennent les mêmes protections. Les comptes de synchronisation d'annuaire sont exclus des security defaults.

11.9 Les groupes#

Types d'appartenance :

• Assigned : membres ajoutés à la main.
• Dynamic User ou Dynamic Device : règle sur des attributs.
  • Licence P1 pour chaque membre unique d'un groupe dynamique.
  • Pas de règle mêlant utilisateurs et appareils.
  • Plafond : 15 000 groupes dynamiques par locataire.
  • Sécurité : vérifier qui peut écrire les attributs utilisés par la règle, y compris dans l'AD source.
  • L'opérateur memberOf (préversion) cesse de se mettre à jour le 3 novembre 2026.

Role-assignable groups (isAssignableToRole) : ce sont les seuls groupes auxquels on peut donner un rôle Entra. Leurs règles protègent contre l'élévation de privilèges :

• la propriété se fixe à la création seulement et n'est pas modifiable ;
• l'appartenance est attribuée uniquement (jamais dynamique) ;
• pas d'imbrication ;
• au plus 500 groupes de ce type par locataire ;
• création par un Privileged Role Administrator au minimum ;
• seul un Privileged Authentication Administrator (ou plus) peut changer les identifiants des membres ;
• licence P1.

C'est ce type de groupe qu'il faut utiliser avec PIM for Groups pour élever vers des rôles Entra (section 4.4).

11.10 Les journaux Microsoft Entra#

Points clés :

• Garder plus longtemps : passer par les diagnostic settings d'Entra ID vers un espace Log Analytics (tables SigninLogs, AuditLogs…, requêtes KQL, alertes, Microsoft Sentinel), un storage account (archive) ou Event Hubs (SIEM tiers).
• Délai : les journaux peuvent mettre jusqu'à trois jours à apparaître dans la destination.
• Passage à une licence supérieure : il n'est pas rétroactif, les données déjà expirées sont perdues.
• Microsoft Purview Audit (Premium) : il garde aussi les enregistrements d'audit Entra pendant un an.

// Ajouts de membres à un rôle d'annuaire (à surveiller en continu)
AuditLogs
| where OperationName == "Add member to role"
| project TimeGenerated, InitiatedBy, TargetResources

11.11 Pièges d'examen (compléments)#

12. Pour aller plus loin (au-delà de l'examen)#

• Authentication context et actions sensibles : exiger une authentification plus forte pour une action précise dans une application (par exemple ouvrir un site SharePoint étiqueté « Confidentiel ») ou à l'activation PIM.
• Conditional Access pour les workload identities (licence Workload ID) : bloquer un service principal en dehors d'emplacements connus, ou selon son risque.
• Conditional Access Optimization Agent (Security Copilot) : suggère des stratégies selon Zero Trust ; voir le chapitre 12.
• Identités d'agents IA (Microsoft Entra Agent ID) : Conditional Access s'étend aux agents ; voir le chapitre 07.
• Récupération de compte à haute assurance : vérification d'identité (pièce d'identité et correspondance faciale, Verified ID) pour remplacer le support technique quand toutes les méthodes sont perdues.
• Infrastructure as Code : les stratégies Conditional Access, les paramètres PIM (unifiedRoleManagementPolicy) et les federated credentials se gèrent aussi par Microsoft Graph, donc par script ou Terraform (fournisseur azuread).

13. Fiche à retenir#

• Rôles Entra (annuaire) ≠ rôles Azure RBAC (ressources).
• Conditional Access : P1 ; conditions de risque : P2 ; PIM : P2 ou ID Governance.
• Méthodes gérées dans l'Authentication methods policy (anciennes stratégies MFA et SSPR retirées le 30/09/2025).
• Résistantes au hameçonnage : FIDO2, Windows Hello for Business, CBA, Platform Credential for macOS, passkey dans Authenticator.
• TAP : 1 h par défaut, 10 min à 30 jours, usage unique possible, 10 minutes pour inscrire la méthode.
• Authentication strength et Require multifactor authentication : jamais dans la même stratégie.
• MFA obligatoire pour Azure : phase 1 les portails, phase 2 CLI, PowerShell, IaC, API (écritures) ; pas pour les workload identities.
• Conditional Access : après le premier facteur ; toutes les stratégies s'appliquent ; assignments en ET ; Block l'emporte ; Report-only d'abord.
• PIM : éligible ≠ actif ; activation 1 à 24 h ; MFA, authentication context, justification, approbation ; attention au verrouillage.
• Comptes d'urgence : 2, cloud uniquement, actifs permanents, FIDO2, exclus de Conditional Access, alerte, test tous les 90 jours.
• Application object = global (1) ; service principal = local (n) ; les autorisations accordées vivent sur le service principal.
• Application permissions = toujours un administrateur ; Assignment required pour limiter les utilisateurs.
• Consentement : éditeurs vérifiés + faible impact classifié ; admin consent workflow ; réviseur sans droit ajouté.
• Managed identity system-assigned (liée, non partagée) ou user-assigned (autonome, partagée, recommandée).
• Hors d'Azure : workload identity federation (federated credential, valeurs exactes).
• ID Protection (P2) : sign-in risk → MFA ; user risk → correction ou changement de mot de passe ; stratégies héritées retirées le 01/10/2026.
• Hybride : PHS toujours activée (secours, fuites) ; PTA = politique AD à chaque connexion (3 agents) ; fédération = besoins non gérés par Entra ; Cloud Sync = cible.
• SSPR : 1 ou 2 méthodes ; administrateurs en two-gate ; writeback = P1.
• Mots de passe interdits : global + custom banned password list (1 000 termes), score ≥ 5 ; DC agent sur tous les contrôleurs ; verrouillage 10 échecs / 60 s.
• B2B : invité dans l'annuaire ; B2B direct connect = Teams, sans invité, bloquée par défaut ; restricted management administrative unit contre les administrateurs du locataire ; access reviews : invités refusés bloqués 30 jours puis supprimés.

Références#

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

• Guide d'étude de l'examen SC-500
• Qu'est-ce que Microsoft Entra Privileged Identity Management ?
• Configurer les role settings Microsoft Entra dans PIM
• PIM for Groups
• Principes fondamentaux des licences Microsoft Entra ID Governance
• Qu'est-ce que Conditional Access ?
• Créer une stratégie Conditional Access
• Continuous Access Evaluation
• Vue d'ensemble de l'authentification Microsoft Entra (méthodes)
• Authentication strengths de Conditional Access
• Gérer les méthodes d'authentification (migration des stratégies MFA et SSPR)
• Configurer le Temporary Access Pass
• Authentification multifacteur obligatoire pour Azure et les portails d'administration
• Gérer les comptes d'accès d'urgence
• Objets application et service principal
• Vue d'ensemble du user consent et de l'admin consent
• Configurer le consentement des utilisateurs
• Configurer les permission classifications
• Configurer l'admin consent workflow
• Qu'est-ce que les managed identities pour les ressources Azure ?
• Workload identity federation
• Configurer une application pour approuver un fournisseur d'identité externe

Compléments AZ-500 (section 11) :

• Qu'est-ce que Microsoft Entra ID Protection ?
• Stratégies d'accès basées sur les risques (risk-based access policies)
• Détections de risque
• Choisir la méthode d'authentification pour l'identité hybride
• Qu'est-ce que Microsoft Entra Cloud Sync ?
• Migrer de Connect Sync vers Cloud Sync : guide de décision
• Fonctionnement du Self-service password reset
• Stratégies de mot de passe et restrictions de compte (stratégie deux portes)
• Licences du Self-service password reset
• Microsoft Entra Password Protection
• Password Protection pour AD DS
• Smart Lockout
• Présentation de Microsoft Entra External ID
• Accès inter-locataires avec External ID
• Administrative units
• Restricted management administrative units
• Que sont les access reviews ?
• Créer une access review de groupes et d'applications
• Entitlement management
• Lifecycle workflows
• Security defaults
• Types de groupes et d'appartenance
• Role-assignable groups
• Groupes d'appartenance dynamique
• Rétention des données Microsoft Entra
• Fonctionnement du password writeback SSPR (sortant 443 par Azure Service Bus)
• Catégories et activités des audit logs Microsoft Entra (« Add member to role »)