Microsoft Entra Token Protection : réduire la réutilisation des jetons volés

Un jeton volé peut contourner une connexion déjà protégée par MFA

Une connexion réussie avec MFA ne rend pas tous les jetons qui suivent impossibles à réutiliser. Microsoft Entra Token Protection ajoute un contrôle de session Conditional Access : pour les flux pris en charge, Entra exige un jeton de session de connexion lié à l’appareil lorsqu’une application demande l’accès à une ressource protégée. Le gain recherché est de limiter le rejeu depuis un autre appareil.

Ce guide propose un déploiement mesuré, pas une case à activer sur tout le locataire. Commencez par les applications natives, documentez les exceptions, puis traitez séparément l’aperçu web. Les noms de groupes, identifiants et commandes ci-dessous sont fictifs.

• Microsoft : fonctionnement et portée de Token Protection ↗

PRT, jeton d’accès et cookie : comprendre la limite de protection

Le Primary Refresh Token (PRT) sert au SSO et à l’obtention de jetons par un courtier d’identité. Sous Windows, WAM joue notamment ce rôle. La liaison cryptographique s’appuie sur des clés de l’appareil; la présence d’un PRT ne signifie pas à elle seule que chaque requête d’une application respecte votre stratégie.

Ne présentez pas Token Protection comme une liaison universelle de tous les jetons d’accès et cookies de toutes les applications. Un poste compromis reste dangereux : un attaquant peut agir dans le contexte du poste autorisé. Le contrôle ne remplace ni la réponse à incident, ni une MFA résistante à l’hameçonnage, ni la conformité des appareils. La prise en charge d’un PRT sur une plateforme n’établit pas automatiquement sa prise en charge par cette stratégie.

• Microsoft : architecture du Primary Refresh Token ↗
• Vol de jetons et attaques AiTM →

Établir une matrice de compatibilité avant le pilote

Le tableau de disponibilité de Microsoft annonce la disponibilité générale pour les applications natives Windows, iOS/iPadOS et macOS. L’accès web reste en aperçu pour certains portails qui utilisent Azure Resource Manager. Une sous-section de la page générale conserve encore le libellé Apple « Preview » : utilisez aussi le guide de déploiement Apple et confirmez les options présentes dans votre locataire avant d’étendre le pilote.

• Microsoft : disponibilité et appareils ↗

Windows : client, courtier et mode d’inscription comptent

Le guide Windows inclut notamment Outlook, OneDrive, Teams, Office Microsoft 365 et Graph PowerShell avec EnableLoginByWAM. Le support de la connexion au profil Edge ne signifie pas que tous les sites ouverts dans Edge sont protégés. Maintenez les clients à jour et testez leurs versions réelles, plutôt que leur seul nom.

Les clients Office perpétuels, certains modules SharePoint PowerShell et certaines extensions VS Code ne sont pas compatibles. Teams Rooms Windows et Surface Hub exigent aussi une attention particulière. Les inscriptions de certains Cloud PCs et hôtes AVD joints à Entra, l’inscription en masse et Autopilot en mode auto-déploiement font partie des exceptions documentées. Protéger la ressource Windows 365 ne garantit donc pas que tous les postes Cloud PC peuvent servir de client compatible.

Collectez l’état du poste en lecture seule. Comparez AzureAdJoined, DomainJoined, WorkplaceJoined et AzureAdPrt avec la session et le compte concernés. Une valeur favorable n’est pas une preuve complète de conformité Token Protection; les journaux Entra restent nécessaires. Masquez les identifiants de locataire, d’appareil et d’utilisateur avant de partager la sortie.

# Read-only. Run in the affected user's Windows session.
dsregcmd /status
Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber
Get-ItemProperty -LiteralPath 'HKLM:\SOFTWARE\Policies\Microsoft\BrowserCore'     -Name EnablePlatformAuth -ErrorAction SilentlyContinue

• Microsoft : clients Windows et inscriptions non prises en charge ↗

Apple : MDM, courtier et inscription sécurisée

Sur iPhone/iPad, Authenticator sert de courtier; sur Mac, Company Portal joue ce rôle. Déployez le profil Enterprise SSO requis par MDM, ou Platform SSO sur Mac selon votre architecture, puis suivez la configuration d’inscription sécurisée du guide Apple. Installer simplement Outlook ne remplit pas tous les prérequis.

Les applications Mail et Calendar natives d’Apple ne prennent pas en charge ce contrôle et peuvent être bloquées. Un appareil Apple non géré n’est pas couvert par ce scénario. Certains appareils déjà enregistrés ont besoin d’une réauthentification et d’une mise à niveau de leur inscription : un état unbound en observation ne se traduit pas toujours par une incompatibilité définitive. Prévenez les utilisateurs et testez ce parcours.

• Microsoft : déploiement Apple et mise à niveau de l’inscription ↗

Licences, responsabilités et données nécessaires

Token Protection exige Microsoft Entra ID P1 pour les utilisateurs couverts. Confirmez les droits inclus dans vos abonnements. La conformité Intune, la gestion MDM et les fonctions de risque Entra sont des capacités distinctes avec leurs propres droits; P1 n’est pas un forfait couvrant automatiquement chaque composante de l’architecture.

Nommez un responsable du pilote, un administrateur Conditional Access autorisé à modifier la stratégie et une personne capable de consulter les journaux. Pour Log Analytics, configurez l’export des connexions interactives et non interactives, les droits de lecture du workspace et sa rétention. L’ingestion et la conservation peuvent générer des coûts Azure. Les requêtes ne reconstituent pas les données qui n’ont jamais été exportées.

• Microsoft : licence et administration du contrôle ↗
• Microsoft : intégration des journaux à Azure Monitor ↗

Créer une stratégie native en Report-only, puis un anneau d’application

Exemple : le groupe CA-TokenProtection-Pilot contient quelques personnes TI et utilisateurs représentatifs. Consignez la configuration initiale, les comptes d’urgence exclus et le moyen de revenir à Report-only. Séparez Windows et Apple pour faciliter le diagnostic. Cette création est un changement de configuration, même si Report-only n’applique pas le blocage.

• Dans Entra ID > Conditional Access > Policies, créez une stratégie nommée CA-TP-Windows-Native-Pilot et incluez le groupe pilote, avec les comptes d’urgence exclus et surveillés.
• Sélectionnez explicitement Exchange Online et SharePoint Online pour le premier scénario. Ajoutez Teams ou les ressources Windows App uniquement avec un cas d’essai documenté; pour Windows App, suivez aussi la sélection Windows Cloud Login indiquée par Microsoft.
• Conditions : plateforme Windows, Client apps configuré et uniquement Mobile apps and desktop clients. Ne laissez pas Browser sélectionné pour cette stratégie native.
• Session : Require token protection for sign-in sessions. Enregistrez en Report-only, puis observez des cycles de travail complets, y compris connexions silencieuses et applications moins fréquentes.
• Ne ciblez pas toutes les ressources ni le groupe global Office 365 : cette fonctionnalité fait exception à la recommandation habituelle de regroupement Office 365.
• Après résolution des incompatibilités, activez On pour un petit anneau validé. Gardez une stratégie d’observation pour les prochains groupes et examinez l’effet cumulé des autres stratégies.

• Microsoft : création de la stratégie native ↗
• Passer de Report-only à Enforced →

Interpréter les journaux et les codes sans confondre observation et blocage

Ouvrez une connexion dans Entra, examinez Conditional Access ou Report-only, la stratégie exacte et Token Protection – Sign-in Session. Corrélez les requêtes avec CorrelationId : un événement bound isolé ne prouve pas que toutes les demandes de la connexion satisfont le contrôle. Un résultat Report-only défavorable décrit un effet potentiel, pas un refus réel.

La première requête KQL montre les clients, ressources et états rencontrés. La deuxième isole votre stratégie par ID et expose son résultat. Remplacez l’ID fictif. Si une table ou colonne manque, vérifiez le schéma et l’export avant de conclure. N’interprétez pas une valeur vide comme bound. Ces exemples sont des modèles de collecte; ils doivent être validés dans votre workspace.

// Read-only: both log categories must be exported to this workspace.
// Empty properties mean unknown, not a passing result.
union withsource=LogCategory SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| extend TP = parse_json(tostring(TokenProtectionStatusDetails))
| extend Binding = tostring(TP.signInSessionStatus),
         BindingCode = tostring(TP.signInSessionStatusCode)
| summarize Requests=count(), Users=dcount(UserPrincipalName),
    FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated)
    by LogCategory, AppDisplayName, ResourceDisplayName, Binding, BindingCode
| order by Requests desc

// Replace with the exact ID of your pilot policy; keep the quotes.
let PilotPolicyId = "00000000-0000-0000-0000-000000000000";
union withsource=LogCategory SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| mv-expand Policy = ConditionalAccessPolicies
| where tostring(Policy.id) == PilotPolicyId
| extend PolicyResult=tostring(Policy.result),
    TP=parse_json(tostring(TokenProtectionStatusDetails))
| project TimeGenerated, LogCategory, UserPrincipalName, AppDisplayName,
    ResourceDisplayName, PolicyResult, ResultType, CorrelationId,
    Binding=tostring(TP.signInSessionStatus),
    BindingCode=tostring(TP.signInSessionStatusCode),
    SessionControls=Policy.enforcedSessionControls
| order by TimeGenerated desc

• Microsoft : codes et analyse Windows ↗
• Microsoft : interprétation Apple ↗

L’aperçu web ARM nécessite une stratégie distincte

Le guide web limite le scénario à Azure portal, Intune admin center, Entra admin center, Microsoft Engage Center et Engage Hub. La ressource Conditional Access est Windows Azure Service Management API. D’autres applications utilisant ARM, dont Power BI ou Power Platform admin center selon la liste Microsoft, peuvent être bloquées. Il ne s’agit pas d’une stratégie protégeant indistinctement Outlook Web et tous les portails d’administration.

Le pilote Windows exige les builds Windows 11 documentées, EnablePlatformAuth=1 sous HKLM\SOFTWARE\Policies\Microsoft\BrowserCore et l’extension Microsoft Single Sign-On dans Edge ou Chrome. Sur Mac, il faut le courtier, l’inscription sécurisée et l’extension. Distribuez ces réglages par un mécanisme géré, consignez leurs valeurs précédentes et attendez au moins 24 heures avant d’évaluer la préparation.

Créez ensuite une stratégie séparée : groupe pilote, Windows/macOS compatibles, ressource ARM et Client apps = Browser uniquement, contrôle de session Token Protection, d’abord Report-only. Testez chaque portail autorisé et les applications ARM utilisées par le pilote. Ne passez pas à On si un usage essentiel reste incompatible. Pour revenir en arrière, remettez la stratégie en observation puis restaurez le réglage et l’affectation d’extension précédents selon le plan approuvé.

• Microsoft : exigences et limites de l’aperçu web ARM ↗

Valider, corriger et revenir en arrière sans ouvrir tout le locataire

Pour un pilote fictif de 12 utilisateurs, tenez une ligne par combinaison appareil/client/ressource. Testez Outlook, synchronisation OneDrive, fichiers Teams, réauthentification après fermeture du client, renouvellement silencieux, Apple Mail s’il est utilisé et un appareil non compatible de laboratoire. Documentez le résultat attendu et observé. Aucun test ne nécessite de voler ou d’exporter un jeton.

Une exclusion doit avoir un propriétaire, une raison, une portée minimale, un contrôle compensatoire et une échéance. Préférez corriger le client ou l’inscription plutôt qu’exclure durablement un groupe entier. Les filtres d’appareils pour Cloud PCs ou AVD doivent correspondre aux modes d’inscription réellement présents, pas à une supposition.

En cas de blocage, relevez heure UTC, utilisateur, client/version, ressource, ID de stratégie et corrélation avant de modifier la portée. Revenez à Report-only ou désactivez uniquement la nouvelle stratégie selon le plan. Les autres stratégies restent actives; attendez leur propagation et retestez une nouvelle demande d’authentification. Ne supprimez pas des appareils ni ne révoquez tous les utilisateurs pour résoudre une simple incompatibilité.

• Critère de sortie : tous les usages essentiels du groupe testés, incidents expliqués, exceptions approuvées et accès d’urgence validé.
• Ne calculez pas une réussite globale seulement sur le volume de connexions : un utilisateur rare peut porter une fonction critique.
• Pour un compte réellement compromis, déclenchez la réponse à incident, préservez les preuves et révoquez les accès selon le scénario; le pilote ne remplace pas le confinement.

• Microsoft : exclusions selon inscription Windows ↗

Fermer les chemins non couverts et maintenir le contrôle

Une stratégie limitée à Windows ne suffit pas si un chemin non protégé reste disponible sur une autre plateforme. Évaluez les règles de conformité et les plateformes inconnues recommandées par Microsoft, avec leurs propres pilotes. Le contrôle de plateforme n’est pas une preuve cryptographique de confiance; combinez identité d’appareil, conformité, MFA résistante à l’hameçonnage et détection sur les postes.

Après chaque changement de client, de mode d’inscription ou de MDM, reprenez les tests. Surveillez les nouveaux codes unbound et les exceptions expirées. Gardez une fiche de service : portée protégée, usages non couverts, responsables et procédure d’incident. Un audit Microsoft 365 et Entra ID permet de vérifier ces dépendances à l’échelle de l’environnement et de prioriser les prochaines mesures.

• Accompagnement : audit Microsoft 365 et Entra ID →
• Microsoft : défense complémentaire et portée ↗