Protection des jetons dans l’accès conditionnel Microsoft Entra

La protection des jetons est un contrôle de session d’accès conditionnel qui tente de réduire les attaques par relecture de jetons en garantissant uniquement les jetons de session de connexion liés à l’appareil, tels que les jetons d’actualisation principal (PRT), sont acceptés par Entra ID lorsque les applications demandent l’accès aux ressources protégées.

Lorsqu’un utilisateur inscrit un appareil Windows 10 ou version ultérieure auprès de Microsoft Entra, un PRT est émis et lié par chiffrement à cet appareil. Cette liaison garantit que même si un acteur de menace vole un jeton, il ne peut pas être utilisé à partir d’un autre appareil. Avec la protection des jetons appliquée, Microsoft Entra valide que seuls ces jetons de session de connexion liés sont utilisés par les applications prises en charge.

Vous pouvez appliquer la stratégie de protection des jetons sur les ressources Exchange Online, SharePoint Online et Teams. Elle est prise en charge par de nombreuses applications natives Microsoft 365. Pour obtenir la liste complète des applications et ressources prises en charge, reportez-vous à la section « Configuration requise ».

Requirements

L'utilisation de cette fonctionnalité nécessite des licences Microsoft Entra ID P1. Pour trouver la licence adaptée à vos besoins, consultez Comparer les fonctionnalités en disponibilité générale de Microsoft Entra ID.

Les appareils et applications suivants prennent en charge l’accès aux ressources où une stratégie d’accès conditionnel de protection des jetons est appliquée :

Appareils pris en charge

• Les appareils Windows 10 ou version ultérieure joints à Microsoft Entra ou à Microsoft Entra hybride, ou bien enregistrés sur Microsoft Entra. Consultez la section limitations connues pour les types d’appareils non pris en charge.
• Windows Server 2019 ou version ultérieure joints à Microsoft Entra hybride.

Applications prises en charge

• Client de synchronisation OneDrive version 22.217 ou ultérieure
• Client natif Teams version 1.6.00.1331 ou ultérieure
• Power BI Desktop version 2.117.841.0 (mai 2023) ou ultérieure
• Module Exchange PowerShell version 3.7.0 ou ultérieure
• Microsoft Graph PowerShell version 2.0.0 ou ultérieure avec l’option EnableLoginByWAM
• Visual Studio 2022 ou version ultérieure lors de l’utilisation de l’option de connexion « Broker d’authentification Windows »
• Windows App version 2.0.379.0 ou ultérieure

Les ressources suivantes prennent en charge la protection des jetons :

• Office 365Exchange Online
• Office 365 SharePoint Online
• Services Microsoft Teams
• Azure Virtual Desktop
• Windows 365

Limitations connues

• Les clients perpétuels Office ne sont pas pris en charge.
• Les applications suivantes ne prennent pas en charge la connexion à l’aide de flux de jetons protégés et les utilisateurs sont bloqués lors de l’accès à Exchange et SharePoint :
  • Modules PowerShell accédant à SharePoint
  • Extension PowerQuery pour Excel
  • Extensions à Visual Studio Code qui accèdent à Exchange ou SharePoint
• Les appareils clients Windows suivants ne sont pas pris en charge :
  • Surface Hub
  • Systèmes de Salles Microsoft Teams (MTR) basés sur Windows
• Les utilisateurs externes qui répondent aux exigences d'inscription des appareils de protection des jetons dans leur locataire d'origine sont pris en charge. Toutefois, les utilisateurs qui ne répondent pas à ces exigences voient un message d’erreur peu clair sans indication de la cause racine.
• Les appareils inscrits auprès de Microsoft Entra ID à l’aide des méthodes suivantes ne sont pas pris en charge :
  • Microsoft Entra a rejoint les hôtes de session Azure Virtual Desktop.
  • Appareils Windows déployés à l’aide de l’inscription en bloc.
  • PC cloud déployés par Windows 365 joints à Microsoft Entra.
  • Groupes d’ordinateurs hébergés par Power Automate joints à Microsoft Entra.
  • Appareils Windows Autopilot déployés à l’aide du mode de déploiement automatique.
  • Machines virtuelles Windows déployées dans Azure à l’aide de l’extension de machine virtuelle activée pour l’authentification Microsoft Entra ID.

Pour identifier les appareils affectés en raison de types d’inscription non pris en charge répertoriés précédemment, inspectez l’attribut tokenProtectionStatusDetails dans les journaux de connexion. Les demandes de jeton bloquées en raison d’un type d’inscription d’appareil non pris en charge peuvent être identifiées avec la signInSessionStatusCode valeur de 1003.

Pour éviter toute interruption lors de l’intégration, modifiez la stratégie d’accès conditionnel de protection des jetons en ajoutant une condition de filtre d’appareil qui exclut les appareils de la catégorie de déploiement décrite précédemment. Par exemple, pour exclure :

• Pour les PC cloud reliés à Microsoft Entra, vous pouvez utiliser systemLabels -eq "CloudPC" and trustType -eq "AzureAD".
• Pour les machines Azure Virtual Desktops joints à Microsoft Entra, vous pouvez utiliser systemLabels -eq "AzureVirtualDesktop" and trustType -eq "AzureAD".
• Pour les groupes de machines hébergés par Power Automate, joints à Microsoft Entra, vous pouvez utiliser systemLabels -eq "MicrosoftPowerAutomate" and trustType -eq "AzureAD".
• Les appareils Windows Autopilot déployés en mode auto-déploiement permettent d’utiliser la propriété enrollmentProfileName. Par exemple, si vous avez créé un profil d’inscription dans Intune pour vos appareils en mode autodéploiement Autopilot en tant que « profil autodéploiement Autopilot », vous pouvez utiliser `enrollmentProfileName -eq "Profil autodéploiement Autopilot"`.
• Les machines virtuelles Windows dans Azure qui sont associées à Microsoft Entra peuvent être utilisées avec profileType -eq "SecureVM" and trustType -eq "AzureAD".

Deployment

Pour les utilisateurs, le déploiement d’une stratégie d’accès conditionnel pour appliquer la protection par jeton est invisible lors de l’utilisation de plateformes clientes compatibles sur des appareils inscrits et des applications compatibles.

Pour réduire la probabilité d’interruption de l’utilisateur en raison de l’incompatibilité de l’application ou de l’appareil, suivez ces recommandations :

• Commencez par un groupe pilote d’utilisateurs et développez-les au fil du temps.
• Créez une stratégie d’accès conditionnel en mode rapport uniquement avant d’appliquer la protection des jetons.
• Capturez les journaux de connexion interactifs et non interactifs.
• Analysez ces journaux suffisamment longtemps pour couvrir l’utilisation normale de l’application.
• Ajoutez des utilisateurs connus et fiables à une stratégie d’application.

Ce processus permet d’évaluer la compatibilité du client et de l’application de vos utilisateurs pour l’application de la protection des jetons.

Créer une stratégie d’accès conditionnel

Les utilisateurs qui effectuent des rôles spécialisés comme ceux décrits dans les niveaux de sécurité d’accès privilégié sont des cibles possibles pour cette fonctionnalité. Nous vous recommandons de commencer avec un petit sous-ensemble.

Les étapes suivantes vous aident à créer une stratégie d’accès conditionnel pour exiger la protection des jetons pour Exchange Online et SharePoint Online sur les appareils Windows.

1. Connectez-vous au Centre d’administration Microsoft Entra en tant qu’administrateur d’accès conditionnel au moins.
2. Accédez à Entra ID>Accès conditionnel>Politiques.
3. Sélectionnez Nouvelle stratégie.
4. Donnez un nom à votre stratégie. Nous recommandons aux organisations de créer une norme explicite pour les noms de leurs stratégies.
5. Sous Affectations, sélectionnez Utilisateurs ou identités de charge de travail.
   1. Sous Inclure, sélectionnez les utilisateurs ou les groupes qui testent cette stratégie.
   2. Sous Exclure, sélectionnez Utilisateurs et groupes, puis choisissez les comptes d'accès d'urgence ou les comptes 'break-glass' de votre organisation.
6. Sous Ressources cibles>Ressources (anciennement ressources cloud)>Inclure>Sélectionner des ressources

   1. Sous Sélectionner, sélectionnez les applications suivantes :

      1. Office 365Exchange Online
      2. Office 365 SharePoint Online
      3. Services Microsoft Teams
      4. Si vous avez déployé l’application Windows dans votre environnement, incluez :
         1. Azure Virtual Desktop
         2. Windows 365
         3. Connexion au cloud Windows

      Warning

      Votre stratégie d’accès conditionnel doit être configurée uniquement pour ces applications. La sélection du groupe d’applications Office 365 peut entraîner des échecs inattendus. Cette modification est une exception à la règle générale selon laquelle le groupe d’applications Office 365 doit être sélectionné dans une stratégie d’accès conditionnel.

   2. Choisissez Sélectionner.

7. Sous Conditions :
   1. Sous plateformes d’appareils :
      1. Définissez Configurer à Oui.
      2. Inclure>Sélectionner des plateformes> d’appareilsWindows.
      3. Cliquez sur Terminé.
   2. Sous Applications clientes :

      1. Définissez Configurer à Oui.

         Warning

         Si vous ne configurez pas la condition Applications clientes ou que le navigateur est sélectionné, les applications qui utilisent MSAL.js, telles que Teams Web, doivent être bloquées.

      2. Sous Clients d’authentification moderne, sélectionnez uniquement les applications mobiles et les clients de bureau. Laissez les autres éléments décochés.

      3. Cliquez sur Terminé.

8. Sous > d’accès, sélectionnez Exiger la protection des jetons pour les sessions de connexion, puis sélectionnez Sélectionner.
9. Confirmez vos paramètres et définissez Activer la politique sur Mode rapport uniquement.
10. Sélectionnez Créer pour activer votre stratégie.

Après avoir confirmé vos paramètres à l’aide de l’impact de la stratégie ou du mode Rapport uniquement, déplacez le bouton bascule Activer la stratégie de rapport uniquement vers Activé.

Capturer les journaux et analyser

Surveillez l’application de l’accès conditionnel de la protection des jetons avant et après l’application à l’aide de fonctionnalités telles que l’impact de la stratégie, les journaux de connexion et Log Analytics.

Historique de connexions

Utilisez le journal de connexion Microsoft Entra pour vérifier le résultat d’une stratégie d’application de protection des jetons en mode rapport uniquement ou en mode activé.

1. Connectez-vous au Centre d’administration Microsoft Entra en tant qu’administrateur d’accès conditionnel au moins.
2. Accédez à Entra ID>Surveillance et santé>Journaux de connexion.
3. Sélectionnez une demande spécifique pour déterminer si la stratégie est appliquée ou non.
4. Accédez au volet Accès conditionnel ou Rapport uniquement en fonction de son état et sélectionnez le nom de votre stratégie nécessitant une protection par jeton.
5. Sous Contrôles de session , vérifiez si les exigences de stratégie ont été satisfaites ou non.
6. Pour plus d’informations sur l’état de liaison de la demande, sélectionnez le volet Informations de base et consultez le champ Protection des jetons - Session de connexion. Les valeurs possibles sont les suivantes :
   1. Lié : la requête utilisait des protocoles liés. Certaines tentatives de connexion peuvent inclure plusieurs requêtes, et toutes les requêtes doivent être liées pour être conformes à la stratégie de protection des jetons. Même si une demande individuelle semble liée, elle ne garantit pas la conformité à la stratégie si d’autres demandes ne sont pas liées. Pour afficher toutes les demandes de connexion, vous pouvez filtrer toutes les demandes pour un utilisateur spécifique ou rechercher par correlation ID.
   2. Non lié : la requête n’utilisait pas de protocoles liés. statusCodes possible(s) lorsque la requête n’est pas liée :
      1. 1002 : la requête n’est pas liée car l’état de l’appareil Microsoft Entra ID n’apparaît pas.
      2. 1003 : la requête n’est pas liée car l’état de l’appareil Microsoft Entra ID n’est pas conforme aux exigences de la stratégie d’accès conditionnel pour la protection des jetons. Cette erreur peut être due à un type d’inscription d’appareil non pris en charge, ou l’appareil n’a pas été inscrit avec de nouvelles informations d’identification de connexion.
      3. 1005 : la requête n’est pas liée pour d’autres raisons non spécifiées.
      4. 1006 : la requête n’est pas liée car la version du système d’exploitation n’est pas prise en charge.
      5. 1008 : La requête n’est pas reliée, car le client n’est pas intégré au courtier de plateforme, tel que le Gestionnaire de comptes Windows (WAM).

Log Analytics

Vous pouvez également utiliser Log Analytics pour interroger les journaux de connexion (interactifs et non interactifs) pour les demandes bloquées en raison d’un échec d’application de la protection des jetons.

Voici un exemple de requête Log Analytics qui recherche les journaux de connexion non interactifs au cours des sept derniers jours, mettant en surbrillance les requêtes bloquées et autorisées par application. Ces requêtes ne sont que des exemples et peuvent être modifiées.

//Per Apps query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, Status,UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]' 
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies["sessionControlsNotSatisfied"] 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id,UserPrincipalName, AppDisplayName, Result 
| summarize Requests = count(), Users = dcount(UserPrincipalName), Block = countif(Result == "Block"), Allow = countif(Result == "Allow"), BlockedUsers = dcountif(UserPrincipalName, Result == "Block") by AppDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by Requests desc 

Le résultat de la requête précédente doit être similaire à la capture d’écran suivante :

L’exemple de requête suivant examine le journal de connexion non interactif pour les sept derniers jours, mettant en surbrillance les demandes bloquées et autorisées par l’utilisateur.

//Per users query 
// Select the log you want to query (SigninLogs or AADNonInteractiveUserSignInLogs ) 
//SigninLogs 
AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| project Id,ConditionalAccessPolicies, UserPrincipalName, AppDisplayName, ResourceDisplayName 
| where ConditionalAccessPolicies != "[]" 
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" or ResourceDisplayName =="Azure Virtual Desktop" or ResourceDisplayName =="Windows 365" or ResourceDisplayName =="Windows Cloud Login"
| where ResourceDisplayName == "Office 365 Exchange Online" or ResourceDisplayName =="Office 365 SharePoint Online" 
//Add userPrincipalName if you want to filter  
// | where UserPrincipalName =="<user_principal_Name>" 
| mv-expand todynamic(ConditionalAccessPolicies) 
| where ConditionalAccessPolicies ["enforcedSessionControls"] contains '["Binding"]' or ConditionalAccessPolicies ["enforcedSessionControls"] contains '["SignInTokenProtection"]'
| where ConditionalAccessPolicies.result !="reportOnlyNotApplied" and ConditionalAccessPolicies.result !="notApplied" 
| extend SessionNotSatisfyResult = ConditionalAccessPolicies.sessionControlsNotSatisfied 
| extend Result = case (SessionNotSatisfyResult contains 'SignInTokenProtection' or SessionNotSatisfyResult contains 'SignInTokenProtection', 'Block','Allow')
| summarize by Id, UserPrincipalName, AppDisplayName, ResourceDisplayName,Result  
| summarize Requests = count(),Block = countif(Result == "Block"), Allow = countif(Result == "Allow") by UserPrincipalName, AppDisplayName,ResourceDisplayName 
| extend PctAllowed = round(100.0 * Allow/(Allow+Block), 2) 
| sort by UserPrincipalName asc   

L’exemple de requête suivant analyse le journal de connexion non interactif des sept derniers jours, en mettant en évidence les utilisateurs qui se servent des appareils, où l’état de l’appareil Microsoft Entra ID n’est pas conforme aux exigences de la stratégie d’accès conditionnel de protection des jetons.

AADNonInteractiveUserSignInLogs 
// Adjust the time range below 
| where TimeGenerated > ago(7d) 
| where TokenProtectionStatusDetails!= "" 
| extend parsedBindingDetails = parse_json(TokenProtectionStatusDetails) 
| extend bindingStatus = tostring(parsedBindingDetails["signInSessionStatus"]) 
| extend bindingStatusCode = tostring(parsedBindingDetails["signInSessionStatusCode"]) 
| where bindingStatusCode == 1003 
| summarize count() by UserPrincipalName 

Expérience de l’utilisateur final

Un utilisateur qui a inscrit ou inscrit son appareil pris en charge n’a pas de différences dans l’expérience de connexion sur une application prise en charge par la protection des jetons lorsque l’exigence de protection des jetons est activée.

Un utilisateur qui n’a pas inscrit ou inscrit son appareil et si la stratégie de protection des jetons est activée voit la capture d’écran suivante après l’authentification.

Un utilisateur qui n’utilise pas d’application prise en charge lorsque la stratégie de protection des jetons est activée voit la capture d’écran suivante après l’authentification.

Contenu connexe

Qu’est-ce qu’un jeton d’actualisation principal ?