Modifier

Partager via

Infrastructure de messagerie hybride à sécurité renforcée - Accès mobile

Microsoft Entra ID
Microsoft 365
Office 365

L'article montre comment implémenter l'authentification multifacteur pour les clients mobiles Outlook qui accèdent à Microsoft Exchange. Il existe deux architectures, qui correspondent à deux possibilités différentes pour l’instance Microsoft Exchange ayant la boîte aux lettres utilisateur :

Architecture (Exchange Online)

Diagram that shows an architecture for enhanced security in an Outlook mobile access scenario. The user's mailbox is in Exchange Online.

Dans ce scénario, les utilisateurs doivent utiliser la version mobile d’Outlook qui prend en charge l’authentification moderne. Nous vous recommandons la version mobile d’Outlook Mobile (Outlook pour iOS/Outlook pour Android), qui est prise en charge par Microsoft. Le flux de travail suivant utilise la version mobile d’Outlook.

Téléchargez un fichier Visio de tous les diagrammes de cet article.

Workflow (Exchange Online)

  1. L’utilisateur démarre la configuration du profil Outlook en entrant une adresse e-mail. La version mobile d’Outlook se connecte au service de détection automatique.
  2. Le service de détection automatique envoie une demande de détection automatique anonyme V2 à Exchange Online pour obtenir la boîte aux lettres. Exchange Online répond avec une réponse de redirection 302 qui contient l’adresse URL ActiveSync pour la boîte aux lettres, en pointant sur Exchange Online. Vous pouvez voir un exemple de ce type de demande ici.
  3. Maintenant que le service de détection automatique a des informations sur le point de terminaison du contenu de la boîte aux lettres, il peut appeler ActiveSync sans authentification.
  4. Comme décrit dans le processus de connexion ici, Exchange répond avec une authentification par réponse 401. Il comprend une URL d'autorisation qui identifie le point de terminaison Microsoft Entra que le client doit utiliser pour obtenir un jeton d'accès.
  5. Le service AutoDetect renvoie le point de terminaison d’autorisation Microsoft Entra au client.
  6. Le client se connecte à Microsoft Entra ID pour terminer l'authentification et saisir les informations de connexion (e-mail).
  7. Si le domaine est fédéré, la demande est redirigée vers le proxy d’application web.
  8. Le proxy d’application web transmet la demande d’authentification à AD FS. L’utilisateur voit une page de connexion.
  9. L’utilisateur entre les informations d’identification pour terminer l’authentification.
  10. L'utilisateur est redirigé vers Microsoft Entra ID.
  11. Microsoft Entra ID applique une stratégie d’accès conditionnel Azure.
  12. La stratégie peut appliquer des restrictions en fonction de l'état de l'appareil de l'utilisateur si l'appareil est inscrit dans Microsoft Endpoint Manager, appliquer des stratégies de protection des applications et/ou appliquer une authentification multifacteur. Vous trouverez un exemple détaillé de ce type de stratégie dans les étapes d’implémentation décrites ici.
  13. L'utilisateur met en œuvre toutes les exigences de la stratégie et complète la requête d'authentification multifacteur.
  14. Microsoft Entra ID renvoie les jetons d'accès et d'actualisation au client.
  15. Le client utilise le jeton d’accès pour se connecter à Exchange Online et récupérer le contenu de la boîte aux lettres.

Configuration (Exchange Online)

Pour bloquer les tentatives d’accès à Exchange Online ActiveSync effectuées par le biais de l’authentification héritée (la ligne pointillée rouge dans le diagramme), vous devez créer une stratégie d’authentification qui désactive l’authentification héritée pour les protocoles utilisés par le service mobile Outlook. Plus précisément, vous devez désactiver la détection automatique, ActiveSync et Outlook Service. Voici la configuration de la stratégie d’authentification correspondante :

AllowBasicAuthAutodiscover : False

AllowBasicAuthActiveSync : False

AllowBasicAuthOutlookService : False

Une fois que vous avez créé la stratégie d’authentification, vous pouvez l’affecter à un groupe pilote d’utilisateurs. Après avoir testé la stratégie, vous pouvez l’étendre à tous les utilisateurs. Pour appliquer la stratégie au niveau de l’organisation, utilisez la commande Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy>. Vous devez utiliser Exchange Online PowerShell pour cette configuration.

Pour les domaines fédérés, vous pouvez configurer AD FS pour déclencher l'authentification multifacteur au lieu d'utiliser une stratégie d'accès conditionnel. Toutefois, nous vous recommandons de contrôler la connexion et d’appliquer des restrictions au niveau de la stratégie d’accès conditionnel.

Architecture (Exchange local)

Diagram that shows an architecture for enhanced security in an Outlook mobile access scenario. The user's mailbox is in Exchange on-premises.

Téléchargez un fichier Visio de tous les diagrammes de cet article.

Dans ce scénario, les utilisateurs doivent utiliser un client mobile qui prend en charge l’authentification moderne, comme décrit dans Utilisation de l’authentification hybride moderne. Nous vous recommandons la version mobile d’Outlook Mobile (Outlook pour iOS/Outlook pour Android), qui est prise en charge par Microsoft. Le flux de travail suivant utilise la version mobile d’Outlook.

Workflow (Exchange local)

  1. L’utilisateur démarre la configuration du profil Outlook en entrant une adresse e-mail. La version mobile d’Outlook se connecte au service de détection automatique.
  2. Le service de détection automatique envoie une demande de détection automatique anonyme V2 à Exchange Online pour obtenir la boîte aux lettres.
  3. Une fois que la boîte aux lettres est localisée en local, Exchange Online répond avec une réponse de redirection 302 qui contient une URL de découverte automatique locale que la détection automatique peut utiliser pour récupérer l’adresse URL ActiveSync pour la boîte aux lettres.
  4. La détection automatique utilise l’URL locale qu’elle a reçue à l’étape précédente pour effectuer une demande de détection automatique v2 Exchange localement pour obtenir la boîte aux lettres. Exchange en local retourne une adresse URL ActiveSync pour la boîte aux lettres, en pointant sur Exchange en local. Vous pouvez voir un exemple de ce type de demande ici.
  5. Maintenant que le service de détection automatique a des informations sur le point de terminaison du contenu de la boîte aux lettres, il peut appeler le point de terminaison ActiveSync local sans authentification. Comme décrit dans le processus de connexion ici, Exchange répond avec une authentification par réponse 401. Il comprend une URL d'autorisation qui identifie le point de terminaison Microsoft Entra que le client doit utiliser pour obtenir un jeton d'accès.
  6. Le service AutoDetect renvoie le point de terminaison d’autorisation Microsoft Entra au client.
  7. Le client se connecte à Microsoft Entra ID pour terminer l'authentification et saisir les informations de connexion (e-mail).
  8. Si le domaine est fédéré, la demande est redirigée vers le proxy d’application web.
  9. Le proxy d’application web transmet la demande d’authentification à AD FS. L’utilisateur voit une page de connexion.
  10. L’utilisateur entre les informations d’identification pour terminer l’authentification.
  11. L'utilisateur est redirigé vers Microsoft Entra ID.
  12. Microsoft Entra ID applique une stratégie d’accès conditionnel Azure.
  13. La stratégie peut appliquer des restrictions en fonction de l'état de l'appareil de l'utilisateur si l'appareil est inscrit dans Microsoft Endpoint Manager, appliquer des stratégies de protection des applications et/ou appliquer une authentification multifacteur. Vous trouverez un exemple détaillé de ce type de stratégie dans les étapes d’implémentation décrites ici.
  14. L'utilisateur met en œuvre toutes les exigences de la stratégie et complète la requête d'authentification multifacteur.
  15. Microsoft Entra ID renvoie les jetons d'accès et d'actualisation au client.
  16. Le client utilise le jeton d’accès pour se connecter à Exchange Online et récupérer le contenu de la boîte aux lettres locale. Le contenu doit être fourni à partir du cache, comme décrit ici. Pour ce faire, le client émet une demande de provisionnement qui inclut le jeton d’accès de l’utilisateur et le point de terminaison ActiveSync local.
  17. L’API de provisionnement dans Exchange Online prend le jeton fourni en tant qu’entrée. L’API obtient une deuxième paire de jetons d’accès et d’actualisation pour accéder à la boîte aux lettres locale via un appel pour le compte d’Active Directory. Ce second jeton d’accès est considéré par le client comme Exchange Online et une audience du point de terminaison de l’espace de noms ActiveSync local.
  18. Si la boîte aux lettres n’est pas provisionnée, l’API de provisionnement crée une boîte aux lettres.
  19. L’API de provisionnement établit une connexion sécurisée au point de terminaison ActiveSync local. L’API synchronise les données de messagerie de l’utilisateur à l’aide du deuxième jeton d’accès comme mécanisme d’authentification. Le jeton d’actualisation est utilisé régulièrement pour générer un nouveau jeton d’accès afin que les données puissent être synchronisées en arrière-plan sans intervention de l’utilisateur.
  20. Les données sont retournées au client.

Configuration (Exchange local)

Pour bloquer les tentatives d’accès à Exchange ActiveSync en local effectuées par le biais de l’authentification héritée (la ligne pointillée rouge dans le diagramme), vous devez créer une stratégie d’authentification qui désactive l’authentification héritée pour les protocoles utilisés par le service mobile Outlook. Plus précisément, vous devez désactiver la détection automatique et ActiveSync. Voici la configuration de la stratégie d’authentification correspondante :

BlockLegacyAuthAutodiscover : True

BlockLegacyAuthActiveSync : True

Voici un exemple de commande permettant de créer cette stratégie d’authentification :

New-AuthenticationPolicy -Name BlockLegacyActiveSyncAuth -BlockLegacyAuthActiveSync -BlockLegacyAuthAutodiscover

Une fois que vous avez créé la stratégie d’authentification, vous pouvez d’abord l’affecter à un groupe pilote d’utilisateurs à l’aide de la commande Set-User user01 -AuthenticationPolicy <name_of_policy>. Après avoir testé la stratégie, vous pouvez l’étendre à tous les utilisateurs. Pour appliquer la stratégie au niveau de l’organisation, utilisez la commande Set-OrganizationConfig -DefaultAuthenticationPolicy <name_of_policy>. Vous devez utiliser Exchange en local PowerShell pour cette configuration.

Vous devez également prendre des mesures pour assurer la cohérence et autoriser l’accès uniquement à partir du client Outlook. Pour autoriser Outlook mobile comme seul client approuvé dans l’organisation, vous devez bloquer les tentatives de connexion à partir de clients qui ne sont pas des clients mobiles Outlook qui prennent en charge l’authentification moderne. Vous devez bloquer ces tentatives au niveau local d’Exchange en effectuant les étapes suivantes :

  • Bloquez les autres clients d’appareil mobile :

    Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Block

  • Autorisez Exchange Online à se connecter au site local :

    If ((Get-ActiveSyncOrganizationSettings).DefaultAccessLevel -ne "Allow") {New-ActiveSyncDeviceAccessRule -Characteristic DeviceType -QueryString "OutlookService" -AccessLevel Allow}

  • Bloquez l’authentification de base pour Outlook pour iOS et Android :

    New-ActiveSyncDeviceAccessRule -Characteristic DeviceModel -QueryString "Outlook for iOS and Android" -AccessLevel Block

Pour plus d’informations sur ces étapes, consultez Utilisation de l’authentification moderne hybride avec Outlook pour iOS et Android.

Pour les domaines fédérés, vous pouvez configurer AD FS pour déclencher l'authentification multifacteur au lieu d'utiliser une stratégie d'accès conditionnel. Toutefois, nous vous recommandons de contrôler la connexion et d’appliquer des restrictions au niveau de la stratégie d’accès conditionnel.

Composants

  • Microsoft Entra ID. Microsoft Entra ID est un service de gestion des identités et des accès basé sur le cloud Microsoft. Il fournit une authentification moderne essentiellement basée sur EvoSTS (un service de jeton de sécurité utilisé par Microsoft Entra ID). Il est utilisé comme serveur d’authentification pour Exchange Server en local.
  • Authentification multifacteur Microsoft Entra. L'authentification multifacteur est un processus dans lequel les utilisateurs sont invités, lors du processus de connexion, à fournir une autre forme d'identification, comme un code sur leur téléphone portable ou une analyse d'empreintes digitales.
  • Accès conditionnel Microsoft Entra. L'accès conditionnel est la fonctionnalité que Microsoft Entra ID utilise pour appliquer des politiques organisationnelles telles que l'authentification multifacteur.
  • AD FS. AD FS permet la gestion fédérée des identités et des accès en partageant l’identité numérique et les droits d’accès au-delà des limites de la sécurité et de l’entreprise avec une sécurité renforcée. Dans ces architectures, il est utilisé pour faciliter la connexion des utilisateurs avec une identité fédérée.
  • Proxy d’application web. Proxy d’application web pré-authentifie l’accès aux applications web à l’aide d’AD FS. Il fonctionne également comme un proxy AD FS.
  • Microsoft Intune. Intune est notre outil basé sur le cloud de gestion unifiée des points de terminaison. Il gère les points de terminaison sur les systèmes d’exploitation Windows, Android, Mac, iOS et Linux.
  • Exchange Server. Exchange Server héberge les boîtes aux lettres des utilisateurs localement. Dans ces architectures, il utilise des jetons délivrés à l'utilisateur par Microsoft Entra ID pour autoriser l'accès aux boîtes aux lettres.
  • Services Active Directory. Les services Active Directory stockent des informations sur les membres d’un domaine, notamment les appareils et utilisateurs. Dans ces architectures, les comptes utilisateurs appartiennent aux services Active Directory et sont synchronisés avec Microsoft Entra ID.

Autres solutions

Vous pouvez utiliser des clients mobiles tiers qui prennent en charge l’authentification moderne comme alternative à Outlook mobile. Si vous choisissez cette alternative, le fournisseur tiers est responsable de la prise en charge du client.

Détails du scénario

L’infrastructure de messagerie d’entreprise est un service clé pour les organisations. La transition de méthodes plus anciennes et moins sécurisées d’authentification et d’autorisation vers l’authentification moderne constitue un enjeu crucial dans un monde où le recours au télétravail a pris de l’ampleur. La mise en œuvre d’exigences d’authentification multifacteur pour l’accès aux services de messagerie est l’un des moyens les plus efficaces de relever ce défi.

Cet article décrit deux architectures pour vous aider à améliorer votre sécurité dans un scénario d'accès mobile Outlook à l'aide de l'authentification multifacteur Microsoft Entra.

Ces scénarios sont décrits dans cet article :

  • Accès mobile Outlook lorsque la boîte aux lettres de l’utilisateur se trouve dans Exchange Online
  • Accès mobile Outlook lorsque la boîte aux lettres de l’utilisateur se trouve dans Exchange en local

Les deux architectures couvrent Outlook pour iOS et Outlook pour Android.

Pour plus d’informations sur l’application de l’authentification multifacteur dans d’autres scénarios de messagerie hybride, consultez ces articles :

Cet article ne traite pas d’autres protocoles, tels qu’IMAP ou POP. En règle générale, ces scénarios n’utilisent pas ces protocoles.

Remarques générales

  • Ces architectures utilisent le modèle d'identité fédéré Microsoft Entra. Pour les modèles de synchronisation de hachage du mot de passe et d’authentification directe, la logique et le flux sont les mêmes. La seule différence est liée au fait que Microsoft Entra ID ne redirigera pas la requête d'authentification vers les services de fédération Active Directory (AD FS) sur site.
  • Dans les diagrammes, les lignes pointillées noires montrent les interactions de base entre les composants Active Directory locaux, Microsoft Entra Connect, Microsoft Entra ID, AD FS et Proxy d’application Web. Vous pouvez en savoir plus sur ces interactions dans Ports et protocoles nécessaires à l’identité hybride.
  • Par Exchange en local, nous entendons Exchange 2019 avec les dernières mises à jour et un rôle Boîte aux lettres.
  • Dans un environnement réel, vous n’aurez pas qu’un seul serveur. Vous aurez un groupe de serveurs Exchange à charge équilibrée pour la haute disponibilité. Les scénarios décrits ici sont adaptés à cette configuration.

Cas d’usage potentiels

Cette architecture s’applique aux scénarios suivants :

  • Renforcement de la sécurité de l’infrastructure de messagerie d’entreprise.
  • Adoption d’une stratégie de sécurité Confiance Zéro.
  • Application de votre niveau de protection élevé standard à votre service de messagerie locale lors de la transition vers/dans le cadre de la coexistence avec Exchange Online.
  • Appliquer des exigences strictes en matière de sécurité ou de conformité dans des organisations fermées ou hautement sécurisées, comme celles du secteur financier.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d'informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour plus d’informations, consultez la page Vue d’ensemble du pilier de fiabilité.

Disponibilité

La disponibilité globale dépend de la disponibilité des composants impliqués. Pour plus d’informations sur la disponibilité, consultez les ressources suivantes :

La disponibilité des composants de la solution locale dépend de la conception implémentée, de la disponibilité du matériel et de vos opérations internes et routines de maintenance. Pour obtenir des informations sur la disponibilité de certains de ces composants, consultez les ressources suivantes :

Pour utiliser l'authentification moderne hybride, vous devez vous assurer que tous les clients de votre réseau peuvent accéder à Microsoft Entra ID. Vous devez également régulièrement mettre à jour les ports de pare-feu et les ouvertures de plage d’adresses IP d’Office 365.

Pour connaître les exigences en matière de protocole et de port pour Exchange Server, consultez la section « Configuration requise pour le client et le protocole Exchange » dans Vue d’ensemble de l’authentification moderne hybride pour une utilisation avec des serveurs Skype Entreprise et Exchange locaux.

Pour les plages d’adresses IP et les ports d’Office 365, consultez URL et plages d’adresses IP Office 365.

Pour plus d’informations sur l’authentification moderne hybride et les appareils mobiles, consultez la section relative au point de terminaison AutoDetect dans Autres points de terminaison non inclus dans le service web d’adresses IP et d’URL d’Office 365.

Résilience

Pour plus d’informations sur la résilience des composants de cette architecture, consultez les ressources suivantes.

Sécurité

Pour obtenir des conseils généraux sur la sécurité des appareils mobiles, consultez Protéger les données et les appareils avec Microsoft Intune.

Pour plus d’informations sur la sécurité et l’authentification moderne hybride, consultez Présentation approfondie : Fonctionnement de l’authentification hybride.

Pour les organisations fermées qui ont une forte protection traditionnelle du périmètre, il existe des problèmes de sécurité liés aux configurations Exchange hybride classique. La configuration Exchange hybride moderne ne prend pas en charge l’authentification moderne hybride.

Pour plus d’informations sur l’ID Microsoft Entra, consultez le guide des opérations de sécurité Microsoft Entra.

Pour plus d’informations sur les scénarios qui utilisent la sécurité d’AD FS, consultez les articles suivants :

Optimisation des coûts

Le coût de votre mise en œuvre dépend de votre identifiant Microsoft Entra et des coûts de votre licence Microsoft 365. Le coût total comprend également le coût des logiciels et du matériel pour les composants locaux, les opérations informatiques, la formation et l’implémentation des projets.

Ces solutions nécessitent au moins Microsoft Entra ID P1. Pour plus de détails sur les tarifs, consultez Tarification Microsoft Entra.

Pour plus d’informations sur AD FS et Proxy d’application web, consultez Tarification et licences pour Windows Server 2022.

Pour plus d’informations sur la tarification, consultez ces ressources :

Efficacité des performances

Les performances dépendent des performances des composants impliqués et de celles du réseau de votre entreprise. Pour plus d’informations, consultez Optimisation des performances d’Office 365 à l’aide de lignes de base et de l’historique des performances.

Pour plus d’informations sur les facteurs locaux qui influencent les performances dans le cadre des scénarios incluant les services AD FS, consultez les ressources suivantes :

Extensibilité

Pour plus d’informations sur la scalabilité d’AD FS, consultez Planification de la capacité des serveurs AD FS.

Pour plus d’informations sur la scalabilité d’Exchange Server en local, consultez Architecture recommandée pour Exchange 2019.

Déployer ce scénario

Pour implémenter cette infrastructure, vous devez suivre les étapes décrites dans les articles suivants. Les étapes principales sont les suivantes :

  1. Sécurisez l’accès mobile Outlook, comme décrit dans ces étapes d’implémentation pour l’authentification moderne.
  2. Bloquez toutes les autres tentatives d’authentification héritées au niveau Microsoft Entra ID.
  3. Bloquez les tentatives d’authentification héritées au niveau des services de messagerie à l’aide d’une stratégie d’authentification.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteurs principaux :

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes