Accès conditionnel : Conditions

Dans une stratégie d’accès conditionnel, un administrateur peut utiliser un ou plusieurs signaux pour améliorer ses décisions en matière de stratégie.

Il est possible de combiner plusieurs conditions pour créer des stratégies d’accès conditionnel spécifiques parfaitement adaptées aux besoins.

Lorsque des utilisateurs accèdent à une application sensible, un administrateur peut prendre en compte plusieurs conditions dans ses décisions d’accès, comme :

• Informations sur les risques de connexion à partir d’ID Protection
• Emplacement réseau
• Informations sur l'appareil

Risque de l’utilisateur

Les administrateurs ayant accès à ID Protection peuvent évaluer le risque utilisateur dans le cadre d’une stratégie d’accès conditionnel. Le risque utilisateur reflète la probabilité qu'une identité ou un compte donné soit compromis. Pour plus d’informations sur le risque utilisateur, consultez les articles Que sont les risques ? et Guide pratique pour configurer et activer des stratégies de risque.

Risque à la connexion

Les administrateurs ayant accès à ID Protection peuvent évaluer le risque de connexion dans le cadre d’une stratégie d’accès conditionnel. Le risque de connexion reflète la probabilité qu’une requête d’authentification donnée ne soit pas faite par le propriétaire de l’identité. Pour plus d’informations sur les connexions à risque, consultez les articles Que sont les risques ? et Guide pratique pour configurer et activer des stratégies de risque.

Risque interne

Les administrateurs disposant d’un accès à protection adaptative Microsoft Purview peuvent incorporer des signaux de risque de Microsoft Purview dans les décisions de stratégie d’accès conditionnel. Les risques internes prennent en compte la gouvernance des données, la sécurité des données et les configurations de conformité de Microsoft Purview. Ces signaux sont basés sur des facteurs contextuels tels que :

• Comportement de l’utilisateur
• Les tendances historiques
• La détection d’anomalies

Cette condition permet aux administrateurs d’utiliser des stratégies d’accès conditionnel pour prendre des mesures telles que le blocage d’accès, la nécessité de méthodes d’authentification plus fortes ou l’acceptation des conditions d’utilisation.

Cette fonctionnalité implique l’incorporation de paramètres qui répondent spécifiquement aux risques potentiels provenant d’une organisation. En configurant l’accès conditionnel pour prendre en compte les risques internes, les administrateurs peuvent adapter les autorisations d’accès en fonction de facteurs contextuels tels que le comportement de l’utilisateur, les modèles historiques et la détection d’anomalies.

Pour plus d’informations, consultez l’article Configurer et activer les stratégies de risques internes.

Plateformes d’appareils

L’accès conditionnel identifie la plateforme de l’appareil à l’aide des informations fournies par l’appareil, telles que des chaînes d’agent utilisateur. Étant donné que les chaînes d’agent utilisateur peuvent être modifiées, ces informations ne sont pas vérifiées. La plateforme d’appareil doit être utilisée conjointement avec des stratégies de conformité d’appareil Microsoft Intune ou dans le cadre d’une instruction de bloc. Le comportement par défaut est l’application à toutes les plateformes d’appareil.

L’accès conditionnel prend en charge les plateformes d’appareil suivantes :

• Android
• iOS
• Windows
• macOS
• Linux

Si vous bloquez l’authentification héritée à l’aide de la condition Autres clients, vous pouvez également définir la condition de plateforme de l’appareil.

Nous ne prenons pas en charge la sélection de plateformes d’appareils macOS ou Linux lorsque vous sélectionnez Exiger une application cliente approuvée ou Exiger une stratégie de protection des applications comme seuls contrôles d’octroi, ou lorsque vous choisissez Exiger tous les contrôles sélectionnés.

Emplacements

La condition d’emplacement a été déplacée.

Applications clientes

Par défaut, toutes les stratégies d’accès conditionnel nouvellement créées s’appliquent à tous les types d’applications clientes, même si la condition des applications clientes n’est pas configurée.

Lorsqu’il est réglé sur Oui, le bouton bascule Configuration s’applique aux éléments cochés, tandis que lorsqu’il est réglé sur Non, il s’applique à toutes les applications clientes, y compris les clients d’authentification modernes et hérités. Ce bouton bascule n’apparaît pas dans les stratégies créées avant août 2020.

• Clients d’authentification moderne
  • Browser
    • Cette option inclut les applications web qui utilisent des protocoles comme SAML, WS-Federation, OpenID Connect, ou les services inscrits en tant que clients confidentiels OAuth.
  • Applications mobiles et clients de bureau
    • Cette option inclut les applications comme les applications de bureau et de téléphone Office.
• Clients d’authentification hérités
  • Clients Exchange ActiveSync
    • Cette sélection inclut toute utilisation du protocole EAS (Exchange ActiveSync).
    • Lorsqu’une stratégie bloque l’utilisation d’Exchange ActiveSync, l’utilisateur concerné reçoit un e-mail de mise en quarantaine. Cet e-mail contient des informations sur la raison du blocage et fournit éventuellement des instructions de correction.
    • Les administrateurs peuvent appliquer la stratégie uniquement aux plateformes prises en charge (par exemple, iOS, Android et Windows) via l’API Microsoft Graph d’accès conditionnel.
  • Autres clients
    • Cette option inclut les clients qui utilisent des protocoles d’authentification de base/hérités qui ne prennent pas en charge l’authentification moderne.
      • SMTP : utilisé par les clients POP et IMAP pour envoyer des e-mails.
      • Découverte automatique : utilisé par les clients Outlook et EAS pour rechercher des boîtes aux lettres dans Exchange Online et s’y connecter.
      • Exchange Online PowerShell : utilisé pour se connecter à Exchange Online à l’aide de PowerShell à distance. Si vous bloquez l’authentification de base pour Exchange Online PowerShell, vous devez utiliser le module Exchange Online PowerShell pour vous connecter. Pour obtenir des instructions, consultez Se connecter à Exchange Online PowerShell à l’aide de l’authentification multifacteur.
      • Exchange Web Services (EWS) : interface de programmation utilisée par Outlook, Outlook pour Mac et des applications tierces.
      • IMAP4 : utilisé par les clients de messagerie IMAP.
      • MAPI sur HTTP (MAPI/HTTP) : utilisé par Outlook 2010 et versions ultérieures.
      • Carnet d’adresses hors connexion (OAB) : copie des collections de listes d’adresses qui sont téléchargées et utilisées par Outlook.
      • Outlook Anywhere (RPC sur HTTP) : utilisé par Outlook 2016 et antérieur.
      • Service Outlook : utilisé par l’application Courrier et calendrier pour Windows 10.
      • POP3 : utilisé par les clients de messagerie POP.
      • Reporting Web Services : utilisé pour récupérer des données de rapports dans Exchange Online.

Ces conditions sont couramment utilisées pour :

• Exiger un appareil géré
• Bloquer l’authentification héritée
• Bloquer les applications web, mais autoriser les applications mobiles ou de bureau

Navigateurs pris en charge

Ce paramètre fonctionne avec tous les navigateurs. Toutefois, pour satisfaire à une stratégie d’appareil, telle qu’une exigence d’appareil conforme, les systèmes d’exploitation et navigateurs suivants sont pris en charge. Les systèmes d’exploitation et navigateurs qui ne sont pas pris en charge par le support standard ne figurent pas dans cette liste :

Ces navigateurs prennent en charge l’authentification des appareils, ce qui permet de les identifier et de les valider par rapport à une stratégie. La vérification de l’appareil se solde par un échec si le navigateur s’exécute en mode privé, ou si les cookies sont désactivés.

Pourquoi une invite de saisie de certificat s’affiche-t-elle dans mon navigateur ?

Sur Windows 7, les appareils iOS, Android et macOS sont identifiés à l’aide d’un certificat client. Ce certificat est approvisionné lorsque l’appareil est inscrit. Lorsqu’un utilisateur se connecte pour la première fois via le navigateur, l’utilisateur est invité à sélectionner le certificat. Il doit sélectionner ce certificat avant d’utiliser le navigateur.

Prise en charge Chrome

Windows

Dans Windows 10 Creators Update (version 1703) ou ultérieure, la prise en charge de Chrome nécessite l’installation de l’extension Authentification unique Microsoft ou l’activation de CloudAPAuthEnabled dans Chrome. Ces configurations sont nécessaires lorsqu’une stratégie d’accès conditionnel exige des informations spécifiques à l’appareil pour des plateformes Windows de manière spécifique.

Pour activer automatiquement la stratégie CloudAPAuthEnabled dans Chrome, créez la clé de Registre suivante :

• Chemin d’accès : HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome
• Nom : CloudAPAuthEnabled
• Valeur: 0x00000001
• Type de propriété : DWORD

Pour déployer automatiquement l’extension Authentification unique Microsoft sur les navigateurs Chrome, créez la clé de Registre suivante à l’aide de la stratégie ExtensionInstallForcelist dans Chrome :

• Chemin d’accès : HKEY_LOCAL_MACHINE\Software\Policies\Google\Chrome\ExtensionInstallForcelist
• Nom : 1
• Entrez : REG_SZ (String)
• Données : ppnbnpeolgkicgegkbkbjmhlideopiji;https://clients2.google.com/service/update2/crx

Pour la prise en charge de Chrome dans Windows 8.1 et 7, créez la clé de Registre suivante :

• Chemin d’accès : HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome\AutoSelectCertificateForUrls
• Nom : 1
• Entrez : REG_SZ (String)
• Données : {"pattern":"https://device.login.microsoftonline.com","filter":{"ISSUER":{"CN":"MS-Organization-Access"}}}

macOS

Les appareils macOS utilisant le plug-in Enterprise SSO nécessitent l’extension Authentification unique Microsoft pour prendre en charge l’authentification unique et l’accès conditionnel basé sur les appareils dans Google Chrome.

Pour les déploiements basés sur GPM de Google Chrome et la gestion des extensions, reportez-vous à Configurer le navigateur Chrome sur Mac et ExtensionInstallForcelist.

Applications mobiles et clients de bureau pris en charge

Les administrateurs peuvent sélectionner Applications mobiles et clients de bureau comme application cliente.

Ce paramètre a un effet sur les tentatives d’accès provenant des applications mobiles et des clients de bureau suivants :

Clients Exchange ActiveSync

• Les administrateurs peuvent uniquement sélectionner des clients Exchange ActiveSync lors de l’attribution d’une stratégie à des utilisateurs ou à des groupes. La sélection des options Tous les utilisateurs, Tous les utilisateurs invités et externes ou Rôles d’annuaire a pour effet de soumettre tous les utilisateurs à la stratégie.
• Quand les administrateurs créent une stratégie attribuée à des clients Exchange ActiveSync, Exchange Online doit être la seule application cloud attribuée à la stratégie.
• Les administrateurs peuvent limiter l’étendue de cette stratégie à des plateformes spécifiques à l’aide de la condition Plateformes d’appareils.

Si le contrôle d’accès affecté à la stratégie a l’option Demander une application cliente approuvée activée, l’utilisateur est invité à installer et à utiliser le client mobile Outlook. Dans le cas où une authentification multifacteur, des conditions d’utilisation ou des contrôles personnalisés sont requis, les utilisateurs impactés sont bloqués, car l’authentification de base ne prend pas en charge ces contrôles.

Pour plus d’informations, consultez les articles suivants :

• Bloquer l’authentification héritée avec l’accès conditionnel
• Exiger des applications clientes approuvées avec l’accès conditionnel

Autres clients

En sélectionnant Autres clients, vous pouvez spécifier une condition affectant les applications qui utilisent l’authentification de base avec des protocoles de messagerie comme IMAP, MAPI, POP et SMTP ainsi que les applications Office plus anciennes qui n’utilisent pas l’authentification moderne.

État de l’appareil (déconseillé)

Cette condition est déconseillée. Les clients doivent utiliser la condition de Filtre pour les appareils dans la stratégie d’accès conditionnel afin d’activer les scénarios précédemment obtenus à l’aide de la condition d’état de l’appareil.

Filtre pour les appareils

Lorsque les administrateurs configurent un filtre pour appareils comme condition, ils peuvent choisir d’inclure ou d’exclure des appareils en fonction d’un filtre à l’aide d’une expression de règle sur les propriétés de l’appareil. L’expression de règle pour le filtre pour appareils peut être créée à l’aide du générateur de règles ou de la syntaxe de règle. Cette expérience est semblable à celle utilisée pour les règles des groupes d’appartenance dynamique pour les groupes. Si vous souhaitez en savoir plus, veuillez consulter l’article Accès conditionnel : filtre pour appareils.

Flux d’authentification (préversion)

Les flux d’authentification contrôlent la façon dont votre organisation utilise certains protocoles et octrois d’authentification et d’autorisation. Ces flux peuvent fournir une expérience transparente aux appareils susceptibles de ne pas posséder de périphérique d’entrée locaux tels que les appareils partagés ou de signalisation numérique. Utilisez ce contrôle pour configurer des méthodes de transfert telles que le flux de code d’appareil ou le transfert d’authentification.

Étapes suivantes

• Accès conditionnel : Accorder
• Stratégies d’accès conditionnel courantes