Partager via


Accès conditionnel : Accorder

Dans une stratégie d’accès conditionnel, un administrateur peut utiliser des contrôles d’accès pour accorder ou bloquer l’accès aux ressources.

Capture d’écran d’une stratégie d’accès conditionnel montrant un contrôle d’octroi nécessitant une authentification multifacteur résistante au hameçonnage.

Bloquer l’accès

Le contrôle de blocage de l’accès évalue les affectations et empêche l’accès en fonction de la configuration de la stratégie d’accès conditionnel.

Bloquer l’accès est un contrôle puissant qui nécessite une application minutieuse. Les stratégies avec des instructions de bloc peuvent entraîner des effets secondaires inattendus. Les tests et la validation appropriés sont essentiels avant d’activer le contrôle à grande échelle. Les administrateurs doivent utiliser des outils tels que le mode rapport d’accès conditionnel uniquement et l’outil What If dans l’accès conditionnel lors de modifications.

Accorder l’accès

Les administrateurs peuvent choisir d’appliquer un ou plusieurs contrôles lors de l’octroi de l’accès. Ces contrôles incluent les options suivantes :

Lorsque les administrateurs choisissent de combiner ces options, ils peuvent utiliser les méthodes suivantes :

  • Demander tous les contrôles sélectionnés (contrôle et contrôle)
  • Demander un des contrôles sélectionnés (contrôle ou contrôle)

Par défaut, l’accès conditionnel exige tous les contrôles sélectionnés.

Exiger l’authentification multifacteur

Si vous cochez cette case, les utilisateurs doivent effectuer Microsoft Entra authentification multifacteur. Pour en savoir plus sur le déploiement de l’authentification multi-facteur Microsoft Entra, consultez Planification d’un déploiement cloud de l’authentification multi-facteur Microsoft Entra.

Windows Hello Entreprise répond aux exigences de l’authentification multifacteur dans les stratégies d’accès conditionnel.

Exiger la force de l’authentification

Les administrateurs peuvent choisir d’exiger des forces d’authentification spécifiques dans leurs stratégies d’accès conditionnel. Ces forces d'authentification sont définies dans le centre d'administration Microsoft Entra, sous Entra ID, Méthodes d’authentification et Forces d'authentification. Les administrateurs peuvent choisir de créer leurs propres versions ou d’utiliser les versions intégrées.

Exiger que l’appareil soit marqué comme conforme

Les organisations qui déploient Intune peuvent identifier les appareils remplissant les conditions de conformité à des stratégies spécifiques à l’aide des informations renvoyées par leurs appareils. Intune envoie les informations de conformité à Microsoft Entra ID, donc l’accès conditionnel peut décider d’accorder ou de bloquer l’accès aux ressources. Pour plus d’informations sur les stratégies de conformité, consultez Définir des règles sur les appareils pour autoriser l’accès aux ressources de votre organisation à l’aide d’Intune.

Un appareil peut être marqué comme conforme par Intune pour n’importe quel système d’exploitation d’appareil ou par un système de gestion des appareils mobiles non Microsoft pour les appareils Windows. Vous trouverez la liste des systèmes de gestion des appareils mobiles non Microsoft pris en charge dans les partenaires de conformité des appareils non-Microsoft dans Intune.

Les appareils doivent être inscrits dans Microsoft Entra ID pour pouvoir être marqués comme conformes. Vous trouverez plus d’informations sur l’inscription des appareils dans Qu’est-ce qu’une identité d’appareil ?.

Le contrôle Exiger que l’appareil soit marqué comme conforme :

  • Prend uniquement en charge les appareils Windows 10+, iOS, Android, macOS et Linux Ubuntu inscrits auprès de Microsoft Entra ID et d’Intune.
  • Microsoft Edge en mode InPrivate sur Windows est considéré comme un appareil non conforme.

Note

Sur Windows, iOS, Android, macOS et certains navigateurs web non-Microsoft, Microsoft Entra ID identifie l’appareil à l’aide d’un certificat client approvisionné lorsque l’appareil est inscrit auprès de l’ID Microsoft Entra. Lorsqu’un utilisateur se connecte pour la première fois via le navigateur, l’utilisateur est invité à sélectionner le certificat. L’utilisateur doit sélectionner ce certificat pour pouvoir continuer à utiliser le navigateur.

Vous pouvez utiliser l’application Microsoft Defender pour point de terminaison avec la stratégie Application cliente approuvée dans Intune afin de définir les stratégies d’accès conditionnel en fonction de la stratégie de conformité des appareils. Aucune exclusion n’est nécessaire pour l’application Microsoft Defender pour point de terminaison durant la configuration de l’accès conditionnel. Bien que Microsoft Defender pour point de terminaison sur Android et iOS (ID d’application - dd47d17a-3194-4d86-bfd5-c6ae6f5651e3) ne soit pas une application approuvée, elle est autorisée à signaler la posture de sécurité de l’appareil. Cette autorisation active le flux des informations de conformité vers l’accès conditionnel.

De même, exiger que l'appareil soit marqué comme conforme ne bloque pas l’accès de l’application Microsoft Authenticator à la portée UserAuthenticationMethod.Read. L'authentificateur doit avoir accès à l'étendue UserAuthenticationMethod.Read pendant l'enregistrement de l'authentificateur pour déterminer quels identifiants un utilisateur peut configurer. L’authentificateur a besoin d’accéder à UserAuthenticationMethod.ReadWrite pour enregistrer les informations d’identification, ce qui ne contourne pas la vérification Exiger que l’appareil soit marqué comme conforme.

Exiger un appareil à jointure hybride Microsoft Entra

Les organisations peuvent choisir d’utiliser l’identité de l’appareil dans le cadre de leur stratégie d’accès conditionnel. Elles peuvent exiger que les appareils soient à jointure hybride Microsoft Entra à l’aide de cette case à cocher. Pour plus d’informations sur les identités d’appareils, consultez Qu’est-ce qu’une identité d’appareil ?.

Lorsque vous utilisez le flux OAuth du code d’appareil, le contrôle d’octroi requis pour l’appareil géré ou une condition d’état d’appareil n’est pas pris en charge. Cela est dû au fait que l’appareil qui effectue l’authentification ne peut pas fournir son état d’appareil à l’appareil qui fournit un code. En outre, l’état de l’appareil dans le jeton est verrouillé sur l’appareil effectuant l’authentification. Utilisez plutôt le contrôle Exiger l’authentification multifacteur.

Le contrôle Exiger un appareil à jointure hybride Microsoft Entra :

  • ne prend en charge que les Windows joints à un domaine de niveau inférieur (avant Windows 10) et les appareils Windows actuels (Windows 10 et versions ultérieures) ;
  • ne considère pas Microsoft Edge en mode InPrivate comme un appareil à jointure hybride Microsoft Entra.

Exiger une application cliente approuvée

Les organisations peuvent exiger qu’une application cliente approuvée soit utilisée pour accéder aux applications cloud sélectionnées. Ces applications clientes approuvées prennent en charge les stratégies de protection des applications Intune, quelle que soit votre solution de gestion des périphériques mobiles.

Avertissement

L’octroi d’application cliente approuvé sera mis hors service début mars 2026. Les organisations doivent passer toutes les stratégies d’accès conditionnel actuelles qui utilisent uniquement l’octroi d’application cliente approuvée pour exiger une application cliente approuvée ou une stratégie de protection des applications d’ici mars 2026. En outre, pour toute nouvelle stratégie d’accès conditionnel, appliquez uniquement l’octroi d’une stratégie de protection d’application. Pour en savoir plus, consultez l’article Migrer une application cliente approuvée vers une stratégie de protection d’application dans l’accès conditionnel.

Pour appliquer ce contrôle d’octroi, l’appareil doit être inscrit dans Microsoft Entra ID, ce qui nécessite l’utilisation d’une application de broker. L’application de broker peut être Microsoft Authenticator pour iOS ou soit Microsoft Authenticator, soit le portail d’entreprise Microsoft pour appareils Android. Si aucune application de broker n’est installée sur l’appareil lorsque l’utilisateur tente de s’authentifier, l’utilisateur est redirigé vers le magasin d’applications approprié pour installer l’application de broker requise.

Les applications clientes suivantes prennent en charge ce paramètre. Cette liste n’est pas exhaustive et peut faire l’objet de modifications :

  • Microsoft Azure Protection des informations
  • Microsoft Cortana
  • Microsoft Dynamics 365
  • Microsoft Edge
  • Microsoft Excel
  • Le Microsoft Power Automate
  • Facturation Microsoft
  • Microsoft Kaizala
  • Microsoft Launcher
  • Listes Microsoft
  • Microsoft Office
  • Microsoft OneDrive
  • Microsoft OneNote
  • Microsoft Outlook
  • Planificateur Microsoft
  • Microsoft Power Apps
  • Microsoft Power BI
  • Microsoft PowerPoint
  • Microsoft SharePoint
  • Microsoft Skype Entreprise
  • Microsoft Stream
  • Microsoft Teams
  • Microsoft To Do
  • Microsoft Visio
  • Microsoft Word
  • Microsoft Yammer
  • Tableau blanc Microsoft
  • Administration Microsoft 365

Remarques

  • Les applications clientes approuvées prennent en charge la fonctionnalité de gestion des applications mobiles Intune.
  • Exigence Nécessite une application cliente approuvée :
    • elle prend uniquement en charge iOS et Android pour la condition de plateforme d’appareil.
    • Nécessite une application de broker pour inscrire l’appareil. L’application de broker peut être Microsoft Authenticator pour iOS ou soit Microsoft Authenticator, soit le portail d’entreprise Microsoft pour appareils Android.
  • L’accès conditionnel ne peut considérer Microsoft Edge en mode InPrivate comme une application cliente approuvée.
  • Les stratégies d’accès conditionnel qui nécessitent Microsoft Power BI en tant qu’application cliente approuvée ne prennent pas en charge la connexion de l’application mobile Power BI au serveur de rapports Power BI local à l’aide du proxy d’application Microsoft Entra.
  • Les vues web hébergées en dehors de Microsoft Edge ne respectent pas la stratégie d’application cliente approuvée. Par exemple, si une application tente de charger SharePoint dans une vue web, les stratégies de protection des applications échouent.

Consultez Exiger des applications clientes approuvées pour l’accès aux applications cloud avec l’accès conditionnel donnant des exemples de configuration.

Exiger une stratégie de protection des applications

Dans votre stratégie d’accès conditionnel, vous pouvez exiger qu’une stratégie de protection des applications Intune soit présente sur l’application cliente afin qu’il soit possible d’accéder aux applications sélectionnées. Ces stratégies de protection des applications de gestion des applications mobiles (GAM) vous permettent de gérer et protéger les données de votre organisation au sein d’applications spécifiques.

Pour appliquer ce contrôle d’octroi, l’accès conditionnel exige que l’appareil soit inscrit dans Microsoft Entra ID, ce qui requiert l’utilisation d’une application de broker. L’application de broker peut être Microsoft Authenticator pour iOS ou le portail d’entreprise Microsoft pour les appareils Android. Si aucune application de broker n’est installée sur l’appareil lorsque l’utilisateur tente de s’authentifier, l’utilisateur est redirigé vers l’App Store pour installer cette application. L’application Microsoft Authenticator peut être utilisée comme application de broker, mais elle ne peut pas être ciblée comme application cliente approuvée. Les stratégies de protection des applications sont généralement disponibles pour iOS et Android, et en préversion publique pour Microsoft Edge sur Windows. Les appareils Windows ne prennent pas en charge plus de trois comptes d’utilisateur Microsoft Entra dans la même session. Pour en savoir plus sur l’application d’une stratégie à des appareils Windows, consultez l’article Exiger une stratégie de protection d’application sur les appareils Windows (préversion).

Les applications doivent répondre à certaines exigences pour prendre en charge les stratégies de protection des applications. Les développeurs peuvent consulter la section Applications que vous pouvez gérer avec des stratégies de protection des applications pour en savoir plus sur ces exigences.

Les applications clientes suivantes prennent en charge ce paramètre. Cette liste n’est pas exhaustive et peut faire l’objet de modifications. Si votre application ne figure pas dans la liste, vérifiez auprès du fournisseur de l’application si elle prend bien en charge les stratégies de protection des applications :

  • Application mobile Adobe Acrobat Reader
  • iAnnotate pour Office 365
  • Microsoft Cortana
  • Microsoft Dynamics 365 pour téléphones
  • Microsoft Dynamics 365 Sales
  • Microsoft Edge
  • Microsoft Excel
  • Le Microsoft Power Automate
  • Microsoft Launcher
  • Listes Microsoft
  • Boucle Microsoft
  • Microsoft Office
  • Microsoft OneDrive
  • Microsoft OneNote
  • Microsoft Outlook
  • Planificateur Microsoft
  • Microsoft Power BI
  • Microsoft PowerApps
  • Microsoft PowerPoint
  • Microsoft SharePoint
  • Microsoft Stream Mobile Native 2.0
  • Microsoft Teams
  • Microsoft To Do
  • Microsoft Word
  • Les services Microsoft Whiteboard
  • MultiLine pour Intune
  • Nine Mail - Courrier électronique et calendrier
  • Notate pour Intune
  • Provectus : sécuriser les contacts
  • Viva Engage (Android, iOS et iPadOS)
  • Application Windows (Android, iOS/iPadOS et Microsoft Edge sur Windows)

Note

Kaizala, Skype Entreprise et Visio ne prennent pas en charge l’octroi Exiger une stratégie de protection des applications. Si vous avez besoin que ces applications fonctionnent, utilisez exclusivement l’octroi Exiger une stratégie de protection des applications. L’utilisation de la clause « ou » entre les deux subventions ne fonctionnera pas pour ces trois applications.

Consultez Exiger une stratégie de protection d’application et une application cliente approuvée pour l’accès aux applications cloud avec l’accès conditionnel pour des exemples de configuration.

Exiger la modification du mot de passe

Lorsque le risque utilisateur est détecté, les administrateurs peuvent utiliser les conditions de stratégie de risque utilisateur pour que l’utilisateur modifie en toute sécurité un mot de passe à l’aide de la réinitialisation de mot de passe en libre-service de Microsoft Entra. Les utilisateurs peuvent effectuer une réinitialisation de mot de passe en libre-service pour corriger cela automatiquement. Ce processus ferme l’événement de risque utilisateur pour empêcher les alertes inutiles pour les administrateurs.

Lorsqu’un utilisateur est invité à modifier un mot de passe, il doit d’abord procéder à une authentification multifacteur. Vérifiez que tous vos utilisateurs sont inscrits pour l’authentification multifacteur, afin qu’ils soient prêts au cas où un risque serait détecté pour leur compte.

Avertissement

Les utilisateurs doivent s’être inscrits pour l’authentification multifacteur avant de déclencher la stratégie de risque utilisateur.

Les restrictions suivantes s’appliquent lorsque vous configurez une stratégie à l’aide du contrôle de modification de mot de passe :

  • La stratégie doit être affectée à Toutes les ressources. Cette exigence empêche un attaquant de modifier le mot de passe de l’utilisateur et réinitialiser le risque du compte à l’aide d’une autre application en se connectant à une autre application.
  • Exiger la modification du mot de passe ne peut pas être utilisé avec d’autres contrôles, comme l’exigence d’un appareil conforme.
  • Le contrôle de modification du mot de passe ne peut être utilisé qu’avec la condition d’affectation d’utilisateurs et de groupes, la condition d’affectation d’applications cloud (qui doit être définie sur « tous ») et les conditions de risque utilisateur.

Exiger une correction des risques

Lorsque le risque utilisateur est détecté, les utilisateurs peuvent se corriger eux-mêmes en effectuant le flux de correction approprié, quelle que soit leur méthode d’authentification. La stratégie de correction gérée par Microsoft dans l’accès conditionnel accepte toutes les méthodes d’authentification, notamment les mots de passe et sans mot de passe. Pour plus d’informations, consultez Exiger la remédiation des risques avec une remédiation gérée par Microsoft (préversion).

Lorsque vous sélectionnez Exiger une correction des risques en tant que contrôle d’octroi, les paramètres suivants sont automatiquement appliqués à la stratégie :

  • Exiger la force de l’authentification
  • Fréquence de connexion - À chaque fois

Lorsqu’un utilisateur est tenu de corriger les risques avec ce contrôle sélectionné, les utilisateurs sont invités à se connecter immédiatement après la révocation de leurs sessions. La sélection de ce contrôle d’octroi signifie que si l’utilisateur vient de se connecter, mais qu’il est en danger, il est invité à se reconnecter. Le risque est corrigé après que l’utilisateur se connecte correctement à la deuxième fois.

Conditions d’utilisation

Si votre organisation a créé des conditions d’utilisation, d’autres options peuvent être visibles sous les contrôles d’octroi. Ces options permettent aux administrateurs d’exiger l’accusé de réception des conditions d’utilisation en tant que condition d’accès aux ressources protégées par la stratégie. Pour en savoir plus sur les conditions d’utilisation, consultez Conditions d’utilisation de Microsoft Entra.

Contrôles d’octroi multiples

Lorsque plusieurs contrôles d’octroi s’appliquent à un utilisateur, comprenez que les stratégies d’accès conditionnel suivent un ordre de validation spécifique par conception. Par exemple, si un utilisateur a deux stratégies nécessitant l’authentification multifacteur (MFA) et les conditions d’utilisation (ToU), l’accès conditionnel valide d’abord la revendication MFA de l’utilisateur, puis la toU.

  • Si une revendication MFA valide n’est pas dans le jeton, vous voyez une « interruption » (en attente d’authentification multifacteur) et un échec pour les toU dans les journaux, même si l’utilisateur a été accepté dans une connexion précédente.
  • Une fois l’authentification multifacteur terminée, une deuxième entrée de journal s’affiche, en validant l’authentification multifacteur. Si l’utilisateur a déjà accepté les conditions, les journaux indiquent une réussite pour l’authentification multifacteur et les conditions d’utilisation.
  • Si le jeton comporte déjà une revendication MFA valide, une seule entrée de journal s’affiche pour indiquer une réussite pour l’authentification multifacteur et les conditions d’utilisation.

Si plusieurs stratégies sont appliquées à un utilisateur nécessitant l’authentification multifacteur, l’état de l’appareil et les conditions d’utilisation, le processus est similaire. L’ordre de validation est MFA, État de l’appareil, puis ToU.

Contrôles personnalisés (préversion)

Les contrôles personnalisés sont une fonctionnalité en préversion de Microsoft Entra ID. L’utilisation de contrôles personnalisés redirige vos utilisateurs vers un service compatible pour répondre aux exigences d’authentification distinctes de l’ID Microsoft Entra. Pour plus d’informations, consultez l’article Contrôles personnalisés.

Étapes suivantes