L’article décrit comment implémenter l’authentification multifacteur pour des clients de bureau Outlook qui accèdent à Microsoft Exchange. Il existe quatre architectures, qui correspondent à quatre possibilités différentes pour l’instance Microsoft Exchange ayant la boîte aux lettres utilisateur :
Remarque
Dans les diagrammes, les lignes pointillées noires montrent les interactions de base entre Active Directory, Microsoft Entra Connect, Microsoft Entra ID, AD FS locaux et des composants Proxy d’application web. Vous pouvez en savoir plus sur ces interactions dans Ports et protocoles nécessaires à l’identité hybride.
Architecture (Exchange Online)
Téléchargez un fichier Visio de tous les diagrammes de cet article.
Dans ce scénario, les utilisateurs doivent utiliser la version du client Outlook qui prend en charge l’authentification moderne. Pour plus d’informations, consultez Fonctionnement de l’authentification moderne pour les applications clientes Office 2013, Office 2016 et Office 2019. Cette architecture couvre à la fois Outlook pour Windows et Outlook pour Mac.
Workflow (Exchange Online)
- L’utilisateur tente d’accéder à Exchange Online via Outlook.
- Exchange Online fournit l’URL d’un point de terminaison Microsoft Entra permettant de récupérer le jeton d’accès pour obtenir l’accès à la boîte aux lettres.
- Outlook se connecte à Microsoft Entra ID en utilisant cette URL.
- Dès que le domaine est fédéré, Microsoft Entra ID redirige la demande vers AD FS local.
- L’utilisateur entre ses informations d’identification sur une page de connexion AD FS.
- AD FS redirige la session vers Microsoft Entra ID.
- Microsoft Entra ID applique une stratégie d’accès conditionnel Azure avec une exigence d’authentification multifacteur pour des applications mobiles et des clients de bureau. Pour plus d’informations sur la configuration de cette stratégie, consultez la section relative au déploiement de cet article.
- La stratégie d’accès conditionnel appelle l’authentification multifacteur Microsoft Entra. L’utilisateur reçoit une demande pour terminer l’authentification multifacteur.
- L’utilisateur effectue une authentification multifacteur.
- Microsoft Entra ID émet des jetons d’accès et d’actualisation et les renvoie au client.
- En utilisant le jeton d’accès, le client se connecte à Exchange Online et récupère le contenu.
Configuration (Exchange Online)
Pour bloquer les tentatives d’accès à Exchange Online 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 Outlook. Voici les protocoles spécifiques que vous devez désactiver : Autodiscover, MAPI, Offline Address Books et EWS. Voici la configuration correspondante :
AllowBasicAuthAutodiscover : False
AllowBasicAuthMapi : False
AllowBasicAuthOfflineAddressBook : False
AllowBasicAuthWebServices : False
AllowBasicAuthRpc : False
Le protocole d’appel de procédure distante (RPC) n’étant plus pris en charge par Office 365, le dernier paramètre n’impacte pas les clients.
Voici un exemple de commande permettant de créer cette stratégie d’authentification :
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false
Notes
Par défaut, après la création de la stratégie, l’authentification héritée pour tous les autres protocoles (comme IMAP, POP et ActiveSync) est également désactivée. Pour modifier ce comportement, vous pouvez activer les protocoles à l’aide d’une commande PowerShell comme celle-ci :
Set-AuthenticationPolicy -Identity BlockOutlook -AllowBasicAuthImap:$true
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 Online PowerShell pour cette configuration.
Architecture (Exchange Online, AD FS)
Téléchargez un fichier Visio de tous les diagrammes de cet article.
Ce scénario est identique au précédent, à ceci près qu’il utilise un déclencheur différent pour l’authentification multifacteur. Dans le scénario précédent, nous avons utilisé AD FS local pour l’authentification. Nous avons ensuite redirigé les informations relatives à l’authentification réussie vers Microsoft Entra ID, où une stratégie d’accès conditionnel a appliqué l’authentification multifacteur. Dans ce scénario, au lieu d’utiliser l’accès conditionnel pour appliquer l’authentification multifacteur, nous créons une stratégie de contrôle d’accès au niveau de AD FS et y appliquons l’authentification multifacteur. Le reste de l’architecture est identique à la précédente.
Notes
Nous recommandons ce scénario uniquement si vous ne pouvez pas utiliser le précédent.
Dans ce scénario, les utilisateurs doivent utiliser la version du client Outlook qui prend en charge l’authentification moderne. Pour plus d’informations, consultez Fonctionnement de l’authentification moderne pour les applications clientes Office 2013, Office 2016 et Office 2019. Cette architecture couvre à la fois Outlook pour Windows et Outlook pour Mac.
Workflow (Exchange Online, AD FS)
L’utilisateur tente d’accéder à Exchange Online via Outlook.
Exchange Online fournit l’URL d’un point de terminaison Microsoft Entra permettant de récupérer le jeton d’accès pour obtenir l’accès à la boîte aux lettres.
Outlook se connecte à Microsoft Entra ID en utilisant cette URL.
Si le domaine est fédéré, Microsoft Entra ID redirige la demande vers AD FS local.
L’utilisateur entre ses informations d’identification sur une page de connexion AD FS.
En réponse à une stratégie de contrôle d’accès AF DS, AD FS appelle l’authentification multifacteur Microsoft Entra pour terminer l’authentification. Voici un exemple de ce type de stratégie de contrôle d’accès AD FS :
L’utilisateur reçoit une demande pour terminer l’authentification multifacteur.
L’utilisateur effectue une authentification multifacteur.
AD FS redirige la session vers Microsoft Entra ID.
Microsoft Entra ID émet des jetons d’accès et d’actualisation et les renvoie au client.
En utilisant le jeton d’accès, le client se connecte à Exchange Online et récupère le contenu.
Configuration (Exchange Online, AD FS)
Notes
La stratégie de contrôle d’accès implémentée à l’étape 6 est appliquée au niveau des approbations de partie de confiance. Par conséquent, elle concerne toutes les requêtes d’authentification pour tous les services Office 365 qui passent par AD FS. Vous pouvez utiliser des règles d’authentification AD FS pour appliquer un filtrage supplémentaire. Toutefois, nous vous recommandons d’utiliser une stratégie d’accès conditionnel (décrite dans l’architecture précédente) plutôt que d’utiliser une stratégie de contrôle d’accès AD FS pour les services Microsoft 365. Le scénario précédent est plus courant et, en l’utilisant, vous pouvez obtenir une meilleure flexibilité.
Pour bloquer les tentatives d’accès à Exchange Online 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 Outlook. Voici les protocoles spécifiques que vous devez désactiver : Autodiscover, MAPI, Offline Address Books et EWS. Voici la configuration correspondante :
AllowBasicAuthAutodiscover : False
AllowBasicAuthMapi : False
AllowBasicAuthOfflineAddressBook : False
AllowBasicAuthWebServices : False
AllowBasicAuthRpc : False
Le protocole RPC n’étant plus pris en charge par Office 365, le dernier paramètre n’impacte pas les clients.
Voici un exemple de commande permettant de créer cette stratégie d’authentification :
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -AllowBasicAuthRpc:$false -AllowBasicAuthMapi:$false -AllowBasicAuthAutodiscover:$false
-AllowBasicAuthWebServices:$false -AllowBasicAuthOfflineAddressBook:$false
Architecture (Exchange local)
Téléchargez un fichier Visio de tous les diagrammes de cet article.
Cette architecture couvre à la fois Outlook pour Windows et Outlook pour Mac.
Workflow (Exchange local)
- Un utilisateur disposant d’une boîte aux lettres sur Exchange Server démarre le client Outlook. Le client Outlook se connecte à Exchange Server et spécifie qu’il dispose de capacités d’authentification modernes.
- Exchange Server envoie une réponse au client lui demandant d’obtenir un jeton à partir de Microsoft Entra ID.
- Le client Outlook se connecte à une URL Microsoft Entra fournie par Exchange Server.
- Azure identifie que le domaine de l’utilisateur est fédéré, il envoie donc des demandes à AD FS (via Proxy d’application web).
- L’utilisateur entre ses informations d’identification sur une page de connexion AD FS.
- AD FS redirige la session vers Microsoft Entra ID.
- Microsoft Entra ID applique une stratégie d’accès conditionnel Azure avec une exigence d’authentification multifacteur pour des applications mobiles et des clients de bureau. Pour plus d’informations sur la configuration de cette stratégie, consultez la section relative au déploiement de cet article.
- La stratégie d’accès conditionnel appelle l’authentification multifacteur Microsoft Entra. L’utilisateur reçoit une demande pour terminer l’authentification multifacteur.
- L’utilisateur effectue une authentification multifacteur.
- Microsoft Entra ID émet des jetons d’accès et d’actualisation et les renvoie au client.
- L’utilisateur présente le jeton d’accès à Exchange Server, et Exchange autorise l’accès à la boîte aux lettres.
Configuration (Exchange local)
Pour bloquer les tentatives d’accès à Exchange 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 Outlook. Voici les protocoles spécifiques que vous devez désactiver : Autodiscover, MAPI, Offline Address Books, EWS et RPC. Voici la configuration correspondante :
BlockLegacyAuthAutodiscover : True
BlockLegacyAuthMapi : True
BlockLegacyAuthOfflineAddressBook : True
BlockLegacyAuthRpc : True
BlockLegacyAuthWebServices : True
Le protocole RPC ne prend pas en charge l’authentification moderne ; il ne prend donc pas en charge l’authentification multifacteur Microsoft Entra. Microsoft recommande d’utiliser le protocole MAPI pour les clients Outlook pour Windows.
Voici un exemple de commande permettant de créer cette stratégie d’authentification :
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc
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.
Architecture (Exchange local, AD FS)
Téléchargez un fichier Visio de tous les diagrammes de cet article.
Ce scénario est semblable au précédent. Toutefois, dans ce scénario, l’authentification multifacteur est déclenchée par AD FS. Cette architecture couvre à la fois Outlook pour Windows et Outlook pour Mac.
Notes
Nous recommandons ce scénario uniquement si vous ne pouvez pas utiliser le précédent.
Workflow (Exchange local, AD FS)
L’utilisateur démarre le client Outlook. Le client se connecte à Exchange Server et spécifie qu’il dispose de capacités d’authentification modernes.
Exchange Server envoie une réponse au client lui demandant d’obtenir un jeton à partir de Microsoft Entra ID. Exchange Server fournit au client une URL vers Microsoft Entra ID.
Le client utilise l’URL pour accéder à Microsoft Entra ID.
Dans ce scénario, le domaine est fédéré. Microsoft Entra ID redirige le client vers AD FS via Proxy d’application web.
L’utilisateur entre ses informations d’identification sur une page de connexion AD FS.
AD FS déclenche l’authentification multifacteur. Voici un exemple de ce type de stratégie de contrôle d’accès AD FS :
L’utilisateur reçoit une demande pour terminer l’authentification multifacteur.
L’utilisateur effectue une authentification multifacteur.
AD FS redirige la session vers Microsoft Entra ID.
Microsoft Entra ID émet les jetons d’accès et d’actualisation pour l’utilisateur.
Le client présente le jeton d’accès au serveur Exchange en local. Exchange autorise l’accès à la boîte aux lettres de l’utilisateur.
Configuration (Exchange local, AD FS)
Notes
La stratégie de contrôle d’accès implémentée à l’étape 6 est appliquée au niveau de confiance de la partie de confiance. Par conséquent, elle concerne toutes les demandes d’authentification pour tous les services Office 365 qui passent par AD FS. Vous pouvez utiliser des règles d’authentification AD FS pour appliquer un filtrage supplémentaire. Toutefois, nous vous recommandons d’utiliser une stratégie d’accès conditionnel (décrite dans l’architecture précédente) plutôt que d’utiliser une stratégie de contrôle d’accès AD FS pour les services Microsoft 365. Le scénario précédent est plus courant et, en l’utilisant, vous pouvez obtenir une meilleure flexibilité.
Pour bloquer les tentatives d’accès à Exchange 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 Outlook. Voici les protocoles spécifiques que vous devez désactiver : Autodiscover, MAPI, Offline Address Books, EWS et RPC. Voici la configuration correspondante :
BlockLegacyAuthAutodiscover : True
BlockLegacyAuthMapi : True
BlockLegacyAuthOfflineAddressBook : True
BlockLegacyAuthRpc : True
BlockLegacyAuthWebServices : True
Le protocole RPC ne prend pas en charge l’authentification moderne ; il ne prend donc pas en charge l’authentification multifacteur Microsoft Entra. Microsoft recommande d’utiliser le protocole MAPI pour les clients Outlook pour Windows.
Voici un exemple de commande permettant de créer cette stratégie d’authentification :
New-AuthenticationPolicy -Name BlockLegacyOutlookAuth -BlockLegacyAuthAutodiscover -BlockLegacyAuthMapi -BlockLegacyAuthOfflineAddressBook -BlockLegacyAuthRpc
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.
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 d’émission 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 d’utilisateurs appartiennent aux services Active Directory et sont synchronisés avec Microsoft Entra ID.
- Outlook pour les entreprises. Outlook est une application cliente qui prend en charge l’authentification moderne.
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 quatre architectures conçues pour renforcer votre sécurité dans un scénario d’accès au client de bureau Outlook en utilisant l’authentification multifacteur Microsoft Entra.
Ce sont quatre architectures qui correspondent à quatre possibilités différentes pour Microsoft Exchange :
Ces quatre architectures couvrent à la fois Outlook pour Windows et Outlook pour Mac.
Pour plus d’informations sur l’application de l’authentification multifacteur dans d’autres scénarios de messagerie hybride, consultez ces articles :
- Infrastructure de messagerie hybride à sécurité renforcée dans un scénario d’accès web
- Infrastructure de messagerie hybride à sécurité renforcée dans un scénario d’accès via un appareil mobile
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 redirige pas la requête d’authentification vers les services de fédération Active Directory (AD FS) sur site.
- 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 :
- Amélioration de la disponibilité de Microsoft Entra
- Services cloud fiables : Disponibilité d’Office 365
- Qu'est-ce que l'architecture Microsoft Entra ?
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 :
- Configuration d’un déploiement d’AD FS avec des groupes de disponibilité AlwaysOn
- Déploiement de la haute disponibilité et de la résilience de site dans Exchange Server
- Proxy d’application web dans Windows Server
Pour utiliser l’authentification moderne hybride, vous devez vérifier 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.
- Pour Microsoft Entra ID : amélioration de la disponibilité de Microsoft Entra
- Pour consulter des scénarios qui utilisent AD FS : Déploiement des services AD FS haute disponibilité par-delà les frontières dans Azure avec Azure Traffic Manager
- Pour la solution locale Exchange : Haute disponibilité d’Exchange
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.
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 obtenir plus d’informations sur Microsoft Entra ID, 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 :
- Meilleures pratiques pour la sécurisation d’AD FS et de Proxy d’application web
- Configurer Extranet Smart Lockout d’AD FS
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.
Le coût de votre implémentation dépend des coûts de votre licences Microsoft Entra ID et 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. Si vous souhaitez obtenir plus d’informations 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
L’efficacité des performances est la capacité de votre charge de travail à s’adapter efficacement pour répondre aux besoins des utilisateurs. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.
Les performances des charges de travail dépendent des performances des composants impliqués et de celles du réseau. Pour plus d’informations, consultez Optimisation des performances d’Office 365 à l’aide de lignes de référence 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 :
- Configurer la surveillance des performances
- Optimisation de SQL et résolution des problèmes de latence avec AD FS
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
Les étapes principales sont les suivantes :
- Protéger l’accès au bureau Outlook en configurant Exchange hybride et en activant l’authentification moderne hybride.
- Bloquez toutes les tentatives d’authentification héritées au niveau de Microsoft Entra ID. Bloquez les tentatives d’authentification héritées au niveau des services de messagerie à l’aide d’une stratégie d’authentification.
Configurer une stratégie d’accès conditionnel
Pour configurer une stratégie d’accès conditionnel Microsoft Entra qui applique l’authentification multifacteur, comme décrit dans certaines des architectures de cet article :
Dans la fenêtre Applications clientes, sélectionnez Applications mobiles et clients de bureau :
Appliquez l’exigence d’authentification multifacteur dans la fenêtre Accorder :
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteurs principaux :
- Pavel Kondrashov | Architecte de solution cloud
- Ella Parkum | Architecte principale de solutions client - Ingénierie
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- Annonce de la mise en place de l’authentification moderne hybride pour Exchange en local
- Vue d’ensemble de l’authentification moderne hybride et configuration requise pour son utilisation avec les serveurs Exchange locaux
- Utiliser l’authentification basée sur les revendications AD FS avec Outlook sur le web
- Guide pratique pour configurer Exchange Server localement en vue d’utiliser l’authentification moderne hybride
- Architecture recommandée pour Exchange 2019
- Déploiement des services AD FS haute disponibilité par-delà les frontières dans Azure avec Azure Traffic Manager
- Utilisation de l’authentification moderne hybride avec Outlook pour iOS et Android
- Configuration du compte avec l’authentification moderne dans Exchange Online