04 · Planifier, implémenter et gérer l'authentification des utilisateurs Microsoft Entra

Version : 1.1 · Date : 2026-10-22 · Domaine 2 de l'examen : Implement authentication and access management (25 à 30 %)

En une phrase : l'administrateur choisit pour chaque population les méthodes qu'elle peut inscrire (Authentication methods policy), pousse les plus sûres (registration campaign, system-preferred authentication), règle les cas particuliers (certificats, passkeys, Windows Hello for Business, Kerberos hybride), protège les mots de passe qui restent, et sait couper un accès en urgence.

Ce chapitre va au niveau administrateur. Les bases sont déjà dans le cours SC-500, à relire avant : tableau des méthodes, Temporary Access Pass, authentication strengths, MFA obligatoire pour Azure, SSPR et Password Protection, Smart Lockout.

Ce que l'examen demande#

Bloc Plan, implement, and manage Microsoft Entra user authentication du guide d'étude SC-300 (compétences au 28/10/2026) :

1. Les bases à maîtriser avant tout#

1.1 Qui règle quoi : les trois rôles d'authentification#

C'est le piège n° 1 de ce bloc : trois rôles proches, trois périmètres différents.

Raccourci : Policy = le tenant ; sans Policy = les utilisateurs ; Privileged = y compris les admins.

1.2 Où tout se trouve dans le Microsoft Entra admin center#

1.3 Migration terminée : un seul endroit pour les méthodes#

Depuis le 30 septembre 2025, les méthodes ne se gèrent plus dans les anciennes policies MFA et SSPR. La migration a trois états (Manage migration) :

Seule exception : les security questions, encore gérées dans la legacy SSPR policy (elles n'existent pas dans la nouvelle policy). Correspondance utile pour les questions de migration :

Piège : dans la legacy MFA policy, Authenticator OTP, third-party software OATH et hardware OATH étaient un seul interrupteur. Dans la nouvelle policy, ce sont trois contrôles séparés.

2. Planifier l'authentification#

Microsoft recommande une démarche par personas et par paires utilisateur / appareil, vers des méthodes phishing-resistant.

flowchart LR
    A["1. Personas<br/>admins et utilisateurs régulés,<br/>non-admins"] --> B["2. Choisir les credentials<br/>portable + local par persona"]
    B --> C["3. Inscrire<br/>TAP pour amorcer,<br/>registration campaign"]
    C --> D["4. Mesurer<br/>Authentication methods activity,<br/>workbooks"]
    D --> E["5. Imposer<br/>Conditional Access :<br/>Phishing-resistant MFA"]

Portable ou local : chaque utilisateur doit avoir au moins un credential portable (utilisable sur plusieurs appareils) et, si possible, un credential local sur chacun de ses appareils.

Ordre d'imposition conseillé : admins sur Windows et iOS, puis admins sur macOS et Android, puis les autres sur Windows et macOS, puis sur iOS et Android. Une stratégie Conditional Access par plateforme et par groupe « prêt », avec l'authentication strength Phishing-resistant MFA (chapitre 05). Les OS trop anciens (Windows 8.1, iOS 16, Android 13, macOS 12) passent par une clé FIDO2 ou une carte à puce. Ralentir le rythme si les tickets du support augmentent.

3. Les authentication methods en détail#

3.1 Règles communes à toutes les méthodes#

• Chaque méthode a un onglet Enable and Target (groupes inclus et exclus : l'exclusion l'emporte) et un onglet Configure.
• Un utilisateur dans l'étendue d'une méthode qui exige une preuve (CBA, par exemple) est considéré capable de MFA : s'il n'a pas de certificat, il est bloqué et ne peut pas inscrire autre chose. D'où la règle : jamais All users pour la CBA.
• Certaines options sont Microsoft managed : Microsoft décide de les activer ou non (valeur default dans Graph).

3.2 Certificate-based authentication (CBA)#

La CBA authentifie avec un certificat X.509 (carte à puce, certificat logiciel) directement contre Entra ID, sans AD FS. Elle est phishing-resistant. Mise en place en cinq étapes :

1. Trust store : déclarer les CA dans le PKI-based trust store (Entra ID > Identity Secure Score > Public key infrastructure > Create PKI). Jusqu'à 250 CA, 8 KB par CA, upload d'un fichier .p7b en une fois (licence P1/P2 ; en Free, upload CA par CA). Rôle : Privileged Authentication Administrator. Pour chaque CA : root ou intermédiaire, CRL URL (sinon aucun contrôle de révocation), delta CRL, issuer hints. Le PKI-based store est prioritaire sur l'ancien classic store.
2. Activer la méthode pour des groupes d'utilisateurs qui ont un certificat (Authentication Policy Administrator).
3. Authentication binding : niveau par défaut single-factor et affinité Low ; des règles par Issuer, Policy OID ou les deux donnent multifactor et/ou High affinity à certains certificats. Une règle Policy OID l'emporte sur une règle Issuer. Entrer l'OID au format numérique (2.5.29.32.0, pas « All Issuance Policies »).
4. Username binding : quel champ du certificat correspond à quel attribut. Par défaut PrincipalName → userPrincipalName. Les liaisons High affinity (SKI, SHA1 public key, Issuer + Serial number) utilisent l'attribut certificateUserIds. Ordre = priorité ; si une valeur ne trouve personne, la liaison suivante est essayée.
5. Tester sur MyApps, puis lire le sign-in log (liaison utilisée, détails du certificat).

Pièges :

• forcer High affinity au niveau du tenant sans certificateUserIds à jour verrouille les comptes ;
• les attributs synchronisés (certificateUserIds, onPremisesUserPrincipalName) peuvent être modifiés par un administrateur AD : la sécurité de la CBA dépend aussi de l'AD local ;
• désactiver l'inspection TLS sur *.certauth.login.microsoftonline.com, sinon le certificat client n'arrive pas.

Configuration par Microsoft Graph PowerShell (extrait) :

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
$group = Get-MgGroup -Filter "displayName eq 'CBA-Users'"
$body = @{
  "@odata.type" = "#microsoft.graph.x509CertificateAuthenticationMethodConfiguration"
  id = "X509Certificate"; state = "enabled"
  certificateUserBindings = @(
    @{ x509CertificateField = "SubjectKeyIdentifier"; userProperty = "certificateUserIds"; priority = 1 },  # high affinity
    @{ x509CertificateField = "PrincipalName"; userProperty = "userPrincipalName"; priority = 2 })
  authenticationModeConfiguration = @{
    x509CertificateAuthenticationDefaultMode = "x509CertificateMultiFactor"
    rules = @(@{ x509CertificateRuleType = "policyOID"; identifier = "1.3.6.1.4.1.311.21.1"
                 x509CertificateAuthenticationMode = "x509CertificateMultiFactor" }) }
  includeTargets = @(@{ targetType = "group"; id = $group.Id; isRegistrationRequired = $false })
} | ConvertTo-Json -Depth 5
Invoke-MgGraphRequest -Method PATCH -ContentType "application/json" -Body $body `
  -Uri "https://graph.microsoft.com/v1.0/policies/authenticationMethodsPolicy/authenticationMethodConfigurations/x509Certificate"

3.3 Microsoft Authenticator#

Piège NPS : la NPS extension ne fait pas de number matching. À partir de la version 1.2.2216.1, elle demande un TOTP aux utilisateurs qui en ont un. Si l'équipement RADIUS ne le supporte pas (MSCHAPv2, RD Gateway), la clé de registre OVERRIDE_NUMBER_MATCHING_WITH_OTP = FALSE revient à Approve / Deny.

3.4 Passkeys (FIDO2) et passkey profiles#

Les passkeys sont disponibles dans toutes les éditions, Free compris. Les passkey profiles remplacent le réglage unique du tenant : à l'activation, l'ancien réglage devient le Default passkey profile. Trois profils maximum, policy limitée à 20 KB.

Règles d'évaluation :

• un utilisateur ciblé par plusieurs profils peut inscrire et utiliser une passkey qui satisfait au moins un profil ;
• un utilisateur exclu de la méthode Passkey (FIDO2) est bloqué partout ;
• retirer un AAGUID autorisé empêche la connexion des passkeys déjà inscrites ;
• l'attestation ne joue qu'à l'inscription : activer Enforce attestation après coup ne bloque pas les passkeys existantes ;
• l'inscription exige une MFA de moins de 5 minutes ; Allow self-service setup doit être activé pour la registration campaign ;
• les invités ne peuvent pas (encore) utiliser de passkey.

Pour imposer les passkeys sur une ressource : Conditional Access avec l'authentication strength intégrée Phishing-resistant MFA, ou une custom authentication strength limitée à certains AAGUID.

3.5 Temporary Access Pass (TAP)#

Les paramètres (durée 1 h par défaut, 10 min à 30 jours, usage unique, 8 à 48 caractères) sont dans le cours SC-500. Côté administrateur :

• créer un TAP pour un utilisateur demande Authentication Administrator (non-admins) ou Privileged Authentication Administrator (admins) ; régler la policy TAP demande Authentication Policy Administrator ;
• le TAP est le mieux classé de l'ordre system-preferred : un utilisateur qui en a un le voit proposé en premier ;
• c'est l'outil d'amorçage recommandé : premier jour, appareil perdu, inscription d'une passkey dans Authenticator, Authenticator Lite.

3.6 OATH tokens, SMS et voice#

SMS et voix restent phishable : Microsoft les place en bas de l'ordre system-preferred et la registration campaign Microsoft managed cible justement les utilisateurs qui les utilisent.

4. Les réglages MFA du tenant#

4.1 Trois façons d'exiger la MFA#

Security defaults et Conditional Access ne cohabitent pas : remplacer les security defaults par Conditional Access impose de les désactiver, et des stratégies Conditional Access existantes empêchent de les réactiver (Plan a Conditional Access deployment). Les Microsoft-managed policies reprennent leurs protections après la désactivation.

4.2 Registration campaign#

Le nudge propose, après une MFA interactive réussie, d'inscrire la méthode cible.

Conditions et exceptions :

• Authenticator campaign : utilisateur activé pour Authenticator en mode Any ou Push, sans push déjà configuré ; le nudge n'apparaît qu'après une MFA par SMS ou voice ; pas de nudge sur mobile ;
• Passkey campaign : méthode Passkey (FIDO2) activée avec Allow self-service setup ; nudge par couple OS / navigateur sans passkey locale ; pas pour les invités ;
• pas de nudge si Conditional Access bloque l'action Register security information, si des terms of use s'affichent ou en cas de custom controls ; pas de nudge dans la session où l'utilisateur vient d'inscrire une autre méthode ;
• en Microsoft managed : passkey ciblée si les utilisateurs sont dans un profil passkey éligible, sinon Authenticator ; snooze 1 jour.

4.3 System-preferred authentication#

L'utilisateur se voit proposer la méthode la plus sûre qu'il a inscrite (il peut toujours choisir Sign in another way).

Conditional Access et les authentication strengths gardent la priorité. Les utilisateurs fédérés ne sont concernés qu'au second facteur ; la NPS extension n'est pas affectée. Inclusion et exclusion : un seul groupe chacune par Graph.

4.4 Report suspicious activity#

Remplace Fraud alert, Block/unblock users et Notifications (supprimés le 1er mars 2025). Un utilisateur qui signale une invite MFA suspecte passe en High user risk (détection User Reported Suspicious Activity) :

• avec P2, une stratégie Conditional Access sur le user risk bloque ou exige un changement de mot de passe ;
• avec P1, l'administrateur traite à la main (sign-in log MFA denied, audit log, rapport Risk detections) ou automatise par Graph (riskEventType: userReportedSuspiciousActivity).

À activer dans Authentication methods > Settings : en Microsoft managed, il reste désactivé. Pas de High risk si l'utilisateur fait une authentification passwordless.

4.5 Les réglages legacy encore visibles#

Dans MFA service settings : trusted IPs (P1, IP publiques seulement en cloud ; préférer les named locations de Conditional Access, qui gèrent IPv6), remember multifactor authentication (cookie persistant, 1 à 365 jours ; la page de configuration se contredit, « 90 jours ou moins » puis « 90 ou plus », mais la recommandation Entra Minimize MFA prompts from known devices demande au moins 90 jours et s'affiche sous 30 jours ; non compatible avec la sign-in frequency de Conditional Access ni avec les invités B2B), app passwords. Microsoft recommande de tout porter vers Conditional Access.

5. Déployer SSPR#

Les paramètres (méthodes, 1 ou 2 méthodes exigées, reconfirmation 0 à 730 jours, stratégie two-gate des administrateurs, licences du writeback) sont détaillés dans le cours SC-500. Le déroulé de déploiement :

1. Password reset > Properties : Self service password reset enabled = Selected (un groupe pilote), puis All.
2. Authentication methods : depuis la migration, les méthodes viennent de l'Authentication methods policy ; régler ici le nombre de méthodes exigées (1 ou 2) et, si besoin, les security questions (seule méthode encore dans la legacy policy).
3. Registration : Require users to register when signing in et le délai de reconfirmation. L'inscription est combinée MFA + SSPR (https://aka.ms/mysecurityinfo).
4. Notifications : prévenir l'utilisateur, prévenir les administrateurs quand un administrateur réinitialise.
5. On-premises integration : activer le password writeback dans Entra Connect Sync ou Cloud Sync, puis l'option côté Entra (et éventuellement Allow users to unlock accounts without resetting their password).
6. Protéger l'inscription par une stratégie Conditional Access sur l'action Register security information (emplacement de confiance ou TAP), et suivre l'adoption dans le rapport Authentication methods activity.

Smart lockout et SSPR : I forgot my password remet la durée de verrouillage à zéro ; I know my password ne la remet pas.

SSPR et user risk : SSPR n'est pas un prérequis de l'auto-remédiation du user risk. Il faut que l'utilisateur soit inscrit à la MFA ; pour un compte synchronisé, le password writeback doit être activé (le secure password change n'utilise pas SSPR), et l'option Allow on-premises password change to reset user risk exige la PHS (voir chapitre 06).

6. Windows Hello for Business#

WHfB remplace le mot de passe Windows par une clé liée à l'appareil, déverrouillée par PIN ou biométrie. Il est phishing-resistant. Deux choix d'architecture :

Mise en œuvre du cloud Kerberos trust :

1. créer le Microsoft Entra Kerberos server object dans chaque domaine (Set-AzureADKerberosServer, voir 9) ;
2. stratégies (Intune ou GPO) : Use Windows Hello for Business et Use cloud trust for on-premises authentication (recommandé : Use a hardware security device). Si Use certificate for on-premises authentication est activé, le certificate trust prend le dessus ;
3. avoir assez de DC en écriture dans chaque site ; un poste hybrid joined doit voir un DC au premier sign-in.

Limites à connaître : pas de cloud Kerberos trust dans un AD purement local, pas pour Run as ni pour RDP / VDI avec identifiants fournis (sauf certificat inscrit dans WHfB ou Remote Credential Guard). Migration : key trust → cloud Kerberos trust en activant la stratégie ; certificate trust → cloud Kerberos trust impose de supprimer le conteneur Hello (certutil.exe -deletehellocontainer) et de se réinscrire.

7. Désactiver un compte et révoquer les sessions#

Connect-MgGraph -Scopes "User.ReadWrite.All","Directory.AccessAsUser.All"
$user = Get-MgUser -UserId "[email protected]"
Update-MgUser -UserId $user.Id -AccountEnabled:$false           # plus aucun nouveau jeton
Revoke-MgUserSignInSession -UserId $user.Id                      # refresh tokens et cookies Entra invalidés
Get-MgUserRegisteredDevice -UserId $user.Id -All | ForEach-Object { Update-MgDevice -DeviceId $_.Id -AccountEnabled:$false }

Quand l'accès tombe vraiment :

• access token : valable jusqu'à son expiration (1 heure par défaut) ;
• application compatible CAE : quasi en temps réel sur événement critique (SC-500) ;
• cookie de session émis par l'application : Entra ne peut pas le révoquer ; seule l'application (ou son deprovisioning) coupe la session.

Revoke sessions retire aussi le statut trusted des appareils qui avaient remember MFA. Bonne pratique : automatiser le deprovisioning (app provisioning, Lifecycle workflows).

8. Microsoft Entra Password Protection et smart lockout#

8.1 Dans le cloud#

Entra ID > Authentication methods > Password protection :

Personnaliser le smart lockout demande P1. Le smart lockout garde les 3 derniers hachages erronés (ressaisir le même mauvais mot de passe ne compte pas), sauf avec la pass-through authentication : dans ce cas, seuil Entra plus bas et durée Entra plus longue que ceux d'AD.

8.2 Sur Active Directory#

# Sur le serveur proxy (une fois par proxy, puis une fois par forêt)
Register-AzureADPasswordProtectionProxy -AccountUpn '[email protected]'   # 1re fois : Global Administrator ; ensuite Security Administrator
Register-AzureADPasswordProtectionForest -AccountUpn '[email protected]'   # Global Administrator ou Security Administrator + Enterprise Admin AD
Test-AzureADPasswordProtectionProxyHealth -TestAll

Points d'examen : une forêt ne s'enregistre qu'auprès d'un seul tenant ; aucun DC n'a besoin d'Internet, aucun port entrant, aucun changement de schéma ; démarrer en Audit (événements dans le journal du DC agent) puis passer en Enforced ; seuls les mots de passe changés ou réinitialisés après le déploiement sont contrôlés (pas ceux qui n'expirent jamais) ; Password Protection complète la stratégie AD, elle ne la remplace pas. Licences : P1 ou P2 pour les utilisateurs synchronisés.

9. Microsoft Entra Kerberos pour les identités hybrides#

Microsoft Entra Kerberos permet à Entra ID de jouer un rôle de KDC Kerberos. Deux objets à ne pas confondre :

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
$domain = $env:USERDNSDOMAIN
$cloudUserName = "[email protected]"   # Hybrid Identity Administrator, avec MFA : utiliser -UserPrincipalName
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUserName        # Kerberos server object
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUserName         # vérifier
# Rotation de la clé : au plus une fois par 24 h, sinon -Force
Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUserName -RotateServerKey

À exécuter sur le serveur Entra Connect (ou un serveur qui a la DLL de synchronisation), dans chaque domaine qui contient des utilisateurs Entra. Côté clients pour Azure Files : la stratégie Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logon (CloudKerberosTicketRetrievalEnabled). Sur Azure Files, un seul identity source par storage account (SC-500 04).

10. Labs conseillés#

À faire dans un tenant de test (essai Microsoft Entra ID P2 ou Microsoft 365 E5 développeur). Coût : nul hors clé FIDO2 ; aucune ressource Azure facturée, sauf le lab 5 (un storage account et une VM de test, à supprimer).

1. Passkey profiles et campagne : activer les passkey profiles ; créer un profil « admins » device-bound attesté avec AAGUID d'Authenticator et un profil « standard » device-bound + synced ; lancer une registration campaign Passkey sur un groupe pilote. Résultat attendu : après une MFA, l'utilisateur pilote reçoit le nudge ; un admin ne peut pas inscrire une synced passkey.
2. CBA de bout en bout : créer une petite PKI de test (CA + certificat utilisateur), l'importer dans le PKI-based trust store avec une CRL, activer la CBA pour un groupe, une règle Policy OID → multifactor. Résultat attendu : connexion sur MyApps par certificat, sign-in log qui montre la liaison et le niveau MFA ; un certificat révoqué est refusé.
3. System-preferred et report suspicious activity : un utilisateur avec mot de passe + SMS + Authenticator ; passer system-preferred en Enabled, activer Report suspicious activity, signaler une invite. Résultat attendu : Authenticator est proposé avant le SMS ; détection User Reported Suspicious Activity en High dans ID Protection.
4. Révoquer : se connecter avec un utilisateur sur Outlook web et Teams, puis Account enabled = No et Revoke-MgUserSignInSession. Résultat attendu : nouvelle connexion refusée ; Exchange et Teams (CAE) coupent la session en quelques minutes ; une application tierce à cookie propre reste ouverte jusqu'à son expiration.
5. Password Protection et Entra Kerberos (lab hybride, VM AD dans un abonnement de test) : installer proxy et DC agent en mode Audit, ajouter « Contoso » à la custom list, changer un mot de passe en Contoso2026!. Résultat attendu : événement d'audit sur le DC ; en Enforced, refus du mot de passe. Puis Set-AzureADKerberosServer et Get-AzureADKerberosServer. Nettoyage : supprimer le groupe de ressources, retirer le Kerberos server object (Remove-AzureADKerberosServer).

11. Les pièges d'examen#

12. Scénarios d'entraînement#

1. Contoso veut que ses 40 administrateurs se connectent uniquement avec des clés FIDO2 d'un modèle validé par la RSSI, et que les autres utilisateurs puissent utiliser des synced passkeys. Que configurer ?

Activer les passkey profiles. Profil « admins » : Device-bound, Enforce attestation, Target specific AAGUIDs en Allow avec les AAGUID du modèle validé, ciblé sur le groupe des admins. Profil « standard » : Device-bound + Synced, ciblé sur les autres. Puis Conditional Access avec une custom authentication strength limitée à ces AAGUID pour les rôles d'administration.

2. Après l'activation de la CBA pour « All users », une partie du support ne peut plus se connecter ni inscrire de méthode. Cause et correction ?

Un utilisateur dans l'étendue de la CBA est réputé capable de MFA ; sans certificat, il est bloqué. Retirer All users et cibler un groupe d'utilisateurs qui ont réellement un certificat ; débloquer les autres avec un TAP.

3. Un auditeur constate qu'un certificat utilisateur révoqué hier permet toujours la connexion CBA. Que vérifier en premier ?

La CRL URL de la CA (et la delta CRL) dans le PKI-based trust store : sans CRL, Entra ID ne vérifie pas la révocation. La CRL doit être publiée sur une URL accessible depuis Internet.

4. Fabrikam a 3 000 utilisateurs qui font leur MFA par SMS. Elle veut qu'ils passent à Microsoft Authenticator, en leur laissant au plus trois reports. Quelle solution, avec quel réglage ?

Registration campaign en état Enabled, Authentication method = Microsoft Authenticator, Limited number of snoozes = Enabled, Days allowed to snooze au choix (0 à 14). Vérifier que ces utilisateurs sont activés pour Authenticator en mode Any ou Push.

5. Un utilisateur dit avoir reçu une invite Authenticator qu'il n'a pas demandée. L'organisation a Entra ID P2. Comment traiter automatiquement ce type d'événement ?

Activer Report suspicious activity (Authentication methods > Settings). L'utilisateur qui signale passe en High user risk ; une stratégie Conditional Access sur user risk High impose un changement de mot de passe sécurisé ou bloque l'accès.

6. Une entreprise hybride veut déployer Windows Hello for Business sur 5 000 postes Entra hybrid joined, sans gérer de certificats. Quel trust type et quelles étapes ?

Cloud Kerberos trust. Créer le Kerberos server object (Set-AzureADKerberosServer) dans chaque domaine, puis par Intune ou GPO Use Windows Hello for Business et Use cloud trust for on-premises authentication, en laissant Use certificate for on-premises authentication non configuré. Prévoir assez de DC en écriture par site.

7. Un commercial quitte l'entreprise dans un conflit. Il est connecté à Exchange Online, Teams et une application SaaS qui gère sa propre session. Que faire, et qu'est-ce qui reste ouvert ?

Dans AD : désactiver le compte, réinitialiser deux fois le mot de passe. Dans Entra : Account enabled = No, Revoke sessions, désactiver ses appareils. Exchange et Teams (compatibles CAE) coupent quasi en temps réel ; l'application SaaS garde sa session jusqu'à l'expiration de son cookie : il faut la déprovisionner.

8. La RSSI veut interdire les mots de passe contenant le nom de l'entreprise, aussi bien dans Entra ID que dans l'AD local, sans ouvrir Internet aux contrôleurs de domaine. Que déployer ?

Custom banned password list (« Contoso », etc.) et Microsoft Entra Password Protection pour AD : 2 proxy services sur des serveurs membres (seuls à sortir vers Internet), DC agent sur tous les DC en écriture (redémarrage), enregistrement de la forêt, mode Audit puis Enforced. Licence P1 pour les utilisateurs synchronisés.

9. Des utilisateurs hybrides doivent accéder à des partages Azure Files depuis des postes joints à AD qui n'ont pas de ligne de vue vers les DC. Quelle fonctionnalité ?

Microsoft Entra Kerberos pour les identités hybrides : Entra ID délivre les tickets Kerberos pour Azure Files. Pour le flux incoming trust-based, créer le Trusted Domain Object avec Set-AzureADKerberosServer -SetupCloudTrust et activer CloudKerberosTicketRetrievalEnabled sur les clients.

10. Un VPN authentifie par RADIUS avec la NPS extension. Depuis la mise à jour de l'extension, les utilisateurs ne voient plus Approve / Deny et la connexion échoue. Pourquoi, et quelle solution temporaire ?

La NPS extension 1.2.2216.1 et plus demande un TOTP (number matching non géré par NPS) ; le VPN en MSCHAPv2 ne supporte pas le TOTP. Passer le serveur NPS en PAP ou, temporairement, créer OVERRIDE_NUMBER_MATCHING_WITH_OTP = FALSE dans HKLM\SOFTWARE\Microsoft\AzureMfa et redémarrer le service.

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

• External authentication methods : brancher un fournisseur MFA tiers comme méthode reconnue par Entra ID (classé 5e dans l'ordre system-preferred).
• Microsoft Entra passkey on Windows et Platform SSO pour macOS : credentials locaux phishing-resistant pour les postes non gérés par WHfB ou les Mac.
• Provisionner des clés FIDO2 par Microsoft Graph pour les remettre déjà inscrites aux administrateurs.
• Account recovery avec Verified ID : vérification d'identité (pièce d'identité, reconnaissance faciale) quand toutes les méthodes sont perdues ; ce n'est pas une méthode d'authentification.
• Phishing-Resistant Passwordless Workbook : suivi par persona et par plateforme de la préparation à l'imposition.
• Kerberos key rotation : pour retirer complètement les anciennes clés, faire la rotation deux fois après expiration des tickets.

14. Fiche à retenir#

• Authentication Policy Administrator = la policy du tenant ; Authentication Administrator = les méthodes des non-admins ; Privileged Authentication Administrator = tout le monde + trust store CBA.
• Méthodes gérées dans l'Authentication methods policy (Migration Complete) ; seules les security questions restent dans la legacy SSPR policy.
• CBA : trust store PKI (250 CA, .p7b, CRL obligatoire pour la révocation) → username binding (low / high affinity, certificateUserIds) → authentication binding (Policy OID > Issuer) → groupes, jamais All users.
• Authenticator : number matching toujours ; app name et location activables séparément ; Authenticator Lite dans Outlook mobile ; NPS ≥ 1.2.2216.1 demande un TOTP.
• Passkeys : Free, 3 passkey profiles, attestation à l'inscription, AAGUID Allow / Block, MFA < 5 min pour s'inscrire, exclusion prioritaire.
• Hardware OATH (preview) : inventaire et assignation par Graph, 5 tokens max par utilisateur, un token = un utilisateur.
• Registration campaign : Authenticator ou passkey, snooze 0 à 14 j, 3 reports si limité, nudge après une MFA interactive.
• System-preferred : TAP › passkey › CBA › Authenticator › external MFA › TOTP › SMS/voice ; Microsoft managed = 1er et 2e facteur.
• Report suspicious activity → High user risk ; remplace Fraud alert (retiré le 01/03/2025).
• WHfB : cloud Kerberos trust recommandé, sans PKI ; key et certificate trust exigent une PKI ; certificate trust prioritaire si sa stratégie est activée.
• Couper un accès : désactiver + Revoke-MgUserSignInSession + appareils ; access token 1 h, CAE quasi temps réel, cookies d'application hors de portée.
• Password Protection : custom list 1 000 termes ; AD = proxy (2 par forêt, seul en ligne) + DC agent (reboot, pas sur RODC), Audit puis Enforced.
• Smart lockout : 10 échecs, 60 s, personnalisation P1 ; avec PTA, seuil Entra < AD et durée Entra > AD.
• Entra Kerberos : Kerberos server object (WHfB, FIDO2) ≠ Trusted Domain Object -SetupCloudTrust (Azure Files, SQL MI).

Références#

Toutes lues le 21/10/2026 :

• Study guide for Exam SC-300
• Manage authentication methods for Microsoft Entra ID
• How to migrate MFA and SSPR policy settings to the Authentication methods policy
• Protecting authentication methods in Microsoft Entra ID (Microsoft managed settings)
• Plan a phishing-resistant passwordless authentication deployment
• Set up Microsoft Entra certificate-based authentication
• How number matching works in MFA push notifications
• Use additional context in Authenticator notifications
• Enable Authenticator Lite for Outlook mobile
• How to enable passkeys (FIDO2) in Microsoft Entra ID
• Enable passkeys in Authenticator
• How to manage OATH tokens in Microsoft Entra ID (Preview)
• Configure Microsoft Entra multifactor authentication settings
• Run a registration campaign to set up a passkey or Microsoft Authenticator
• System-preferred authentication
• Plan a Windows Hello for Business deployment
• Cloud Kerberos trust deployment guide
• Common questions about Windows Hello for Business
• Revoke user access in Microsoft Entra ID
• Revoke-MgUserSignInSession
• Protect user accounts from attacks with Microsoft Entra smart lockout
• Tutorial: Configure custom banned passwords
• Plan and deploy on-premises Microsoft Entra Password Protection
• Enforce on-premises Microsoft Entra Password Protection for AD DS
• Enable passwordless security key sign-in to on-premises resources
• Configure Microsoft Entra Kerberos trust
• Enable Microsoft Entra Kerberos authentication for hybrid and cloud-only identities on Azure Files