Activation de l’authentification moderne dans Exchange en local

  • Article

Vue d’ensemble

Avec la publication de Exchange Server 2019 CU13, Exchange Server prend en charge OAuth 2.0 (également appelée authentification moderne) pour les environnements locaux purs utilisant ADFS en tant que service de jeton de sécurité (STS). Ce document fournit les prérequis et les étapes pour activer cette fonctionnalité.

Pour utiliser l’authentification moderne, les utilisateurs ont besoin de clients (Outlook ou tout autre client de système d’exploitation natif) qui prennent en charge l’authentification moderne à l’aide d’ADFS. Initialement, cette fonctionnalité est disponible uniquement pour Outlook sur Windows, mais la prise en charge de l’authentification moderne sera ajoutée à d’autres clients Outlook à l’avenir.

L’authentification moderne dans Exchange Server 2019 ne doit pas être confondue avec l’authentification moderne hybride, qui utilise Microsoft Entra ID pour l’authentification moderne. En fait, HMA est toujours la seule méthode recommandée pour activer l’authentification moderne pour tous les utilisateurs locaux et cloud dans une configuration Exchange Hybride. Cette nouvelle fonctionnalité permet l’utilisation de l’authentification moderne par les clients qui n’ont pas de Microsoft Entra ID ou qui ne sont pas dans une configuration Exchange Hybride.

Comment l’authentification moderne fonctionne-t-elle et cette fonctionnalité s’applique-t-elle à moi ?

Avec l’authentification moderne, les utilisateurs peuvent s’authentifier auprès d’Exchange à l’aide d’ADFS. Lorsque l’authentification moderne est activée pour un utilisateur, son client Outlook est redirigé vers ADFS. Les utilisateurs peuvent ensuite s’authentifier en fournissant des informations d’identification ou en effectuant une authentification multifacteur. Une fois qu’ADFS authentifie un utilisateur, il génère des jetons d’accès. Ces jetons d’accès sont validés par Exchange Server pour fournir un accès client à la boîte aux lettres de l’utilisateur.

Le diagramme suivant illustre la coordination entre Exchange Server, ADFS et Outlook pour authentifier un utilisateur à l’aide de l’authentification moderne.

Diagramme montrant le flux de travail d’établissement d’une liaison d’authentification moderne Exchange Server 2019. Dans le graphique ci-dessus, les étapes 3a, 4a, 5a et 6a ont lieu lorsque l’authentification moderne est activée pour l’utilisateur final. Les étapes 3b et 4b se produisent lorsque l’authentification moderne est désactivée pour un utilisateur.

Reportez-vous au tableau suivant pour évaluer si cette fonctionnalité vous est applicable.

Configuration d’Exchange Cette fonctionnalité est-elle applicable ? Remarques
Exchange local organization avec uniquement Exchange Server 2019 Oui N/A
Exchange local organization avec combinaison de Exchange Server 2019, Exchange Server 2016 et Exchange Server 2013 Non Exchange Server 2013 est hors support.
Exchange local organization avec combinaison de Exchange Server 2019 et Exchange Server 2016 Oui Seuls les serveurs Exchange 2019 peuvent être utilisés comme serveurs Front-End (accès au client).
Exchange Hybrid organization utilisant HMA Non HMA utilisant Microsoft Entra ID est la solution recommandée. Reportez-vous aux conseils sur l’utilisation de nouvelles stratégies d’authentification.
Exchange Hybrid organization sans HMA Non Utilisez HMA avec Microsoft Entra ID.

Prérequis pour activer l’authentification moderne dans Exchange

Exchange Server 2019 CU13 ou version ultérieure

Pour utiliser l’authentification moderne, tous les serveurs utilisés pour les connexions client doivent avoir Exchange Server 2019 CU13 installé.

ADFS 2019 ou version ultérieure

Pour activer l’authentification moderne dans un environnement Exchange local, Services ADFS (ADFS) sur Windows Server 2019 ou version ultérieure est nécessaire.

Vous pouvez également avoir besoin de Web Proxy d'application Server (sur Windows Server 2019 ou version ultérieure) pour activer l’accès client à partir de l’extérieur du réseau d’entreprise.

Remarque

Le rôle ADFS ne peut pas être configuré sur un Exchange Server. Pour plus d’informations, consultez Planifier votre topologie de déploiement AD FS.

Conditions préalables du client

Outlook sur Windows

La prise en charge de l’authentification moderne via ADFS est disponible dans les versions suivantes de Microsoft Outlook.

Outlook dans Microsoft 365 Apps :

Canal Pris en charge Version Build (ou version ultérieure)
Canal Insider Oui 2304 16327.20200
Canal actuel Oui 2304 16327.20214
Canal mensuel des entreprises Oui 2304 16327.20324
Canal Entreprise semi-annuel (préversion) Non S/O S/O
Canal Entreprise semestriel Non S/O S/O

Outlook pour Windows (licence en volume & vente au détail) :

Version Pris en charge Version Build (ou version ultérieure)
Outlook 2016 (n’importe quelle version) Non S/O S/O
Outlook 2019 (n’importe quelle version) Non S/O S/O
Outlook 2021 (Vente au détail) Oui 2304 16327.20214
Outlook 2021 (licence en volume) Non S/O S/O

Vous pouvez case activée le numéro de build de votre Office en suivant les étapes mentionnées ici.

Capture d’écran montrant le numéro de build outlook Microsoft 365 Apps edition.

Remarque

La prise en charge d’autres clients tels qu’Outlook sur Mac, Outlook mobile, application de messagerie iOS, etc., sera ajoutée ultérieurement.

Système d’exploitation Windows

Le client Windows doit être et la mise à jour du 14 mars 2023 doit être Windows 11 22H2 or later installée.

Vous pouvez consulter Windows Update’historique pour vérifier que KB5023706 est installé.

Capture d’écran montrant l’historique des mises à jour d’un ordinateur qui s’exécute Windows 11 22H2.

Étapes de configuration de l’authentification moderne dans Exchange Server à l’aide d’ADFS en tant que STS

Cette section fournit des détails sur l’implémentation de l’authentification moderne dans Exchange Server 2019 CU13.

Installer Exchange 2019 CU13 sur tous les serveurs FE (au moins)

Tous les serveurs utilisés pour les connexions client doivent être mis à niveau vers Exchange 2019 CU13. Cela garantit que les connexions clientes initiales à Exchange 2019 utilisent OAuth, et que les connexions proxiées à Exchange Server 2016 utilisent Kerberos.

Remarque

La configuration de l’authentification moderne est prise en charge uniquement sur Exchange Server 2019 CU13 et versions ultérieures.

Exchange 2019 CU13 ajoute la prise en charge des nouvelles stratégies d’authentification pour autoriser ou bloquer l’authentification moderne au niveau de l’utilisateur. Le blocage de l’authentification moderne est utilisé pour garantir que les clients qui ne prennent pas en charge l’authentification moderne peuvent toujours se connecter.

L’exécution /PrepareAD avec le programme d’installation est nécessaire pour ajouter plusieurs nouveaux paramètres de stratégie d’authentification à Exchange Server.

  1. BlockModernAuthActiveSync
  2. BlockModernAuthAutodiscover
  3. BlockModernAuthImap
  4. BlockModernAuthMapi
  5. BlockModernAuthOfflineAddressBook
  6. BlockModernAuthPop
  7. BlockModernAuthRpc
  8. BlockModernAuthWebServices

Après l’installation de CU13, les paramètres ci-dessus sont désactivés pour toutes les stratégies d’authentification préexistantes (y compris la stratégie d’authentification par défaut). Cela signifie que les clients qui utilisent HMA n’ont pas besoin de modifier leurs stratégies d’authentification préexistantes.

Aucune nouvelle stratégie d’authentification requise pour les clients Exchange hybrides

Les clients Exchange Hybride existants doivent utiliser l’authentification moderne hybride. Les clients hybrides utilisant HMA peuvent laisser les valeurs des paramètres BlockModernAuth* à 0 pour continuer à utiliser HMA.

Remarque

Les étapes suivantes pour configurer l’authentification moderne à l’aide d’ADFS s’appliquent uniquement aux clients hybrides Exchange (locaux purs).

Configurer Services ADFS (ADFS)

Les clients doivent installer et configurer ADFS dans l’environnement pour permettre aux clients Exchange d’utiliser l’authentification Forms (OAuth) pour se connecter à Exchange Server.

Exigences de certificat pour la configuration ADFS dans Exchange Server Organisation

ADFS nécessite deux types de certificats de base (reportez-vous à cet article pour plus d’informations) :

  1. Un certificat SSL (Secure Sockets Layer) de communication de service pour le trafic de services web chiffrés entre le serveur ADFS, les clients, les serveurs Exchange et le serveur web Proxy d'application facultatif. Nous vous recommandons d’utiliser un certificat émis par une autorité de certification interne ou commerciale, car tous les clients doivent approuver ce certificat.
  2. Certificat de signature de jeton pour la communication et l’authentification chiffrées entre le serveur ADFS, les contrôleurs de domaine Active Directory et les serveurs Exchange. Vous pouvez obtenir un certificat de signature de jeton en en demandant un certificat auprès d’une autorité de certification ou en créant un certificat auto-signé.

Pour plus d’informations sur la création et l’importation de certificats SSL dans Windows, consultez Certificats de serveur.

Voici un résumé des certificats que nous utilisons dans ce scénario :

Nom commun (CN) dans le certificat (dans l’objet, l’autre nom de l’objet ou une correspondance de certificat générique) Type Requis sur les serveurs Commentaires
adfs.contoso.com
enterpriseregistration.contoso.com		 Émis par une autorité de certification Serveur ADFS,
Serveur Proxy d'application web (facultatif)		 Les serveurs de fédération utilisent un certificat SSL pour sécuriser le trafic des services Web pour la communication SSL avec les clients et les proxys de serveur de fédération.

Étant donné que le certificat SSL doit être approuvé par les ordinateurs clients, nous vous recommandons d'utiliser un certificat signé par une autorité de certification approuvée. Tous les certificats que vous sélectionnez doivent posséder une clé privée correspondante.
Signature de jeton ADFS - adfs.contoso.com Auto-signé ou problème par une autorité de certification Serveur ADFS,
Serveur Proxy d'application web (facultatif)		 Un certificat de signature de jeton est un certificat X509. Les serveurs de fédération utilisent des paires de clés publiques/privées associées pour signer numériquement tous les jetons de sécurité qu’ils produisent. Cela inclut la signature des métadonnées de fédération publiées et des demandes de résolution d’artefact.

Vous pouvez avoir plusieurs certificats de signature de jeton configurés dans le composant logiciel enfichable Gestion AD FS pour autoriser la substitution de certificat lorsqu’un certificat arrive à expiration. Par défaut, tous les certificats de la liste sont publiés, mais seul le certificat de signature de jeton principal est utilisé par AD FS pour signer les jetons. Tous les certificats que vous sélectionnez doivent posséder une clé privée correspondante.

Vous pouvez obtenir un certificat de signature de jeton en demandant un certificat auprès d’une autorité de certification d’entreprise ou d’une autorité de certification publique ou en créant un certificat auto-signé.
mail.contoso.com
autodiscover.contoso.com		 Émis par une autorité de certification Serveurs Exchange,
Serveur Proxy d'application web (facultatif)		 Il s’agit du certificat classique utilisé pour chiffrer les connexions client externes à Outlook sur le web (et à d’autres services Exchange). Pour plus d'informations, consultez la section relative aux Conditions requises les certificats des services Exchange.

Déployer et configurer le serveur ADFS

Utilisez Windows Server 2019 ou version ultérieure pour déployer un serveur ADFS. Suivez les étapes suivantes : Déployer un serveur ADFS et Configurer et tester le serveur ADFS. Vérifiez que vous pouvez ouvrir l’URL des métadonnées de fédération dans un navigateur web à partir du serveur Exchange et d’au moins un ordinateur client.

L’URL utilise la syntaxe :

https://<FederationServiceName>/federationmetadata/2007-06/federationmetadata.xml

Par exemple,

https://adfs.contoso.com/federationmetadata/2007-06/federationmetadata.xml

Choisir la durée de vie de l’authentification unique appropriée

Choisissez une durée de vie d’authentification unique appropriée afin que les utilisateurs finaux ne soient pas obligés de se réauthentifier fréquemment. Pour configurer une durée de vie de l’authentification unique, ouvrez la gestion ADFS sur le serveur ADFS et choisissez Edit Federation Service Properties Actions (présente sur le côté droit de la fenêtre de gestion ADFS).

Capture d’écran montrant les propriétés de durée de vie de l’authentification unique ADFS.

Entrez , Web SSO lifetime (minutes)qui est la durée maximale après laquelle les utilisateurs doivent se réauthentifier.

Capture d’écran montrant le paramètre Durée de vie de l’authentification unique ADFS en minutes.

Configurer la méthode d’authentification dans ADFS

Pour utiliser l’authentification moderne dans Outlook sur Windows, vous devez configurer les méthodes d’authentification principales. Nous vous recommandons de choisir Forms Authentification pour l’extranet et l’intranet, comme indiqué ci-dessous.

Capture d’écran montrant les méthodes d’authentification ADFS.

Activer l’inscription des appareils dans ADFS

Vérifiez que l’inscription des appareils est configurée et que l’authentification de l’appareil est activée en consultant la vue d’ensemble de l’inscription des appareils. Cette étape est recommandée pour réduire le nombre d’invites d’authentification pour les utilisateurs et peut aider à appliquer des stratégies Access Control dans ADFS.

Capture d’écran montrant la page de vue d’ensemble de l’inscription des appareils ADFS.

Effectuez toutes les étapes de configuration de la découverte du service d’inscription des appareils et du certificat SSL du serveur de découverte d’inscription des appareils, comme indiqué [ici](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn614658(v=ws.11).

Create groupe d’applications ADFS pour Outlook

  1. Cliquez avec le bouton droit sur Application Groups , puis cliquez sur Add Application Group.

    Capture d’écran montrant les paramètres ADFS. Il s’affiche comme une invite de menu contextuel. Le paramètre Ajouter un groupe d’applications est sélectionné.

  2. Sélectionnez Native Application accessing a web API.

  3. Tapez un nom, Outlook par exemple, et cliquez sur Suivant.

    Capture d’écran montrant l’assistant du groupe d’applications ADFS Add.

  4. Sur , Native application pageajoutez les éléments suivants client identifier et redirect Uri pour Outlook, puis cliquez sur Suivant.

    • Identificateur du client : d3590ed6-52b3-4102-aeff-aad2292ab01c

    • URI de redirection (ajoutez les deux URI suivants) :

      urn:ietf:wg:oauth:2.0:oob

      ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c

      Capture d’écran montrant les paramètres d’application natifs d’une application portant le nom Outlook.

  5. Dans l’onglet Configure Web API , ajoutez tous les noms de domaine complets utilisés par votre environnement Exchange, notamment la découverte automatique, les noms de domaine complets d’équilibrage de charge, les noms de domaine complets du serveur, etc. Par exemple :

    • https://autodiscover.contoso.com/
    • https://mail.contoso.com/

    Importante

    Il est important ici de s’assurer que toutes les URL côté client sont couvertes, sinon cela ne fonctionnera pas. Incluez les /'s de fin et vérifiez que les URL commencent par https://.

    Capture d’écran montrant aDFS Ajouter un groupe d’applications assistant. Il affiche la page de configuration de l’API web.

  6. Dans l’onglet Apply Access Control Policy , Autoriser tout le monde à commencer par, puis à modifier ultérieurement si nécessaire. Ne case activée pas la case à cocher en bas de la page.

  7. Dans Configure Application Permissions, choisissez Native Application app, puis sous Permitted Scopes case activée user_impersonation en plus de openid, qui est cochée par défaut.

    Capture d’écran montrant aDFS Ajouter un groupe d’applications assistant. Elle affiche la page permettant de configurer les autorisations de l’application.

  8. Terminez la assistant.

Ajouter des règles de transformation d’émission dans le groupe d’applications Outlook

Pour le groupe Outlookd’applications créé ci-dessus, ajoutez Règles de transformation d’émission. Cliquez avec le bouton droit sur le groupe d’applications Outlook et sélectionnez propriétés.

Modifiez le Web API settings, puis sous Issuance Transform Rules ajoutez les règles personnalisées suivantes :

Capture d’écran montrant les paramètres d’application ADFS d’une application nommée Outlook. Le bouton Modifier est sélectionné.

Nom de la règle de revendication Règle personnalisée
ActiveDirectoryUserSID c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"] => issue(claim = c);
ActiveDirectoryUPN c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"] => issue(claim = c);
AppIDACR => issue(Type = "appidacr", Value = "2");
SCP => issue(Type = "http://schemas.microsoft.com/identity/claims/scope", Value ="user_impersonation");

Après avoir ajouté les règles, le Outlook - Web API Properties doit se présenter comme suit :

Capture d’écran montrant les paramètres d’application ADFS d’une application nommée Outlook. L’onglet Règles de transformation d’émission est sélectionné.

Si vous le souhaitez, les Proxy d'application web peuvent être configurés pour l’accès extranet

Le Proxy d'application web fait partie du rôle serveur d’accès à distance dans Windows Server. Il fournit des fonctionnalités de proxy inverse pour permettre aux utilisateurs d’accéder à vos applications web à partir de l’extérieur du réseau d’entreprise. Web Proxy d'application préauthentifie l’accès aux applications web à l’aide d’ADFS et fonctionne comme un proxy ADFS.

Si vous envisagez d’utiliser le proxy d’application web, suivez les étapes mentionnées dans Installer et configurer le serveur web Proxy d'application pour le configurer. Une fois configuré, vous pouvez publier des règles pour Autodiscover.contoso.com ou/et mail.contoso.com en suivant les étapes mentionnées dans Publier une application qui utilise OAuth2.

Si vous le souhaitez, l’authentification multifacteur peut également être configurée pour l’accès au client

  1. Reportez-vous aux liens suivants pour configurer ADFS avec un fournisseur MFA de votre choix.

  2. Configurez Access Control stratégie nécessitant l’authentification multifacteur.

Client-Side configuration de l’authentification moderne

Nous vous recommandons de tester l’authentification moderne avec peu d’utilisateurs avant de procéder au déploiement sur tous les utilisateurs. Une fois qu’un groupe pilote d’utilisateurs peut utiliser l’authentification moderne, d’autres utilisateurs peuvent être déployés.

  1. Mise à niveau du client et mise à niveau du système d’exploitation :

    Comme indiqué dans la section Conditions préalables du client , l’authentification moderne est prise en charge uniquement pour Outlook sur Windows. Pour utiliser l’authentification moderne, le canal Insider client Outlook doit être installé sur Windows 11 OS 22H2 avec la mise à jour du 14 mars 2023 ou une version ultérieure.

  2. Modifications du Registre dans les ordinateurs clients :

    Les administrateurs doivent configurer les valeurs de Registre pour les utilisateurs.

    Activez l’authentification moderne et ajoutez votre domaine ADFS en tant que domaine approuvé dans Outlook :

    1. Ajoutez les clés suivantes pour ajouter un domaine ADFS en tant que domaine approuvé :

      • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://ADFS domain/
      • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://ADFS domain

      Remarque

      Ajoutez deux clés avec et sans « / » à la fin du domaine ADFS.

      Capture d’écran montrant la clé de Registre AuthTrustedDomains.

    2. Pour activer l’authentification moderne via ADFS dans Outlook sur Windows, ajoutez la valeur suivante REG_DWORD dans HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity\:

      Nom Valeur
      EnableExchangeOnPremModernAuth 1

      Capture d’écran montrant la clé de Registre d’identité située sous HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common.

      Pour faciliter le déploiement, ces modifications de Registre peuvent être configurées à l’aide de stratégie de groupe. Si stratégie de groupe n’est pas utilisé par votre organization, les utilisateurs doivent configurer leur registre manuellement (ou avec un script que vous fournissez).

stratégies d’authentification Create pour les utilisateurs finaux

Il est possible que tous les utilisateurs de votre organization n’aient pas de clients de messagerie qui prennent en charge l’authentification moderne à l’aide d’ADFS. Dans ce scénario, nous vous recommandons d’activer l’authentification moderne pour les utilisateurs qui ont pris en charge les clients et de bloquer les utilisateurs d’authentification moderne qui ne le font pas.

Pour activer l’authentification moderne pour un ensemble d’utilisateurs et bloquer l’authentification moderne pour vos utilisateurs restants, vous devez créer au moins deux stratégies d’authentification :

  • Stratégie à l’échelle de l’organisation pour bloquer l’authentification moderne par défaut.
  • Deuxième stratégie pour autoriser de manière sélective l’authentification moderne pour certains utilisateurs.

Create organization stratégie pour bloquer l’authentification moderne par défaut

Une fois l’authentification moderne activée, tous les clients Outlook essaient d’utiliser des jetons OAuth, mais certains clients (par exemple, Outlook sur Mac) peuvent extraire des jetons OAuth uniquement à partir de Microsoft Entra ID. Par conséquent, si l’authentification moderne est activée, ces clients ne pourront pas se connecter.

Pour éviter ce scénario, vous pouvez définir une stratégie de niveau organization pour désactiver l’authentification moderne. Dans l’exemple ci-dessous, nous créons une stratégie d’authentification appelée Block Modern auth.

New-AuthenticationPolicy "Block Modern auth" -BlockModernAuthWebServices -BlockModernAuthActiveSync -BlockModernAuthAutodiscover -BlockModernAuthImap -BlockModernAuthMapi -BlockModernAuthOfflineAddressBook -BlockModernAuthPop -BlockModernAuthRpc

Cette stratégie peut être définie au niveau de l’organisation à l’aide de la commande suivante.

Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Modern auth"

Create stratégie d’authentification au niveau de l’utilisateur pour activer l’authentification moderne

Ensuite, créez une deuxième stratégie d’authentification qui active l’authentification moderne. Cette stratégie d’authentification est affectée à tous les utilisateurs disposant d’un client Outlook pris en charge pour permettre à leur client d’utiliser l’authentification moderne.

Dans l’exemple ci-dessous, nous créons une authentification appelée Allow Modern auth à l’aide de la commande suivante :

New-AuthenticationPolicy "Allow Modern auth"

Configurer Exchange Server pour utiliser des jetons OAuth ADFS

  1. Vérifiez si oauth est activé sur les répertoires virtuels suivants. Si cette option n’est pas activée, activez oauth dans tous les répertoires virtuels suivants :

    Get-MapiVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*

Get-WebServicesVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*

Get-OabVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*

Get-AutodiscoverVirtualDirectory -Server <ExchangeServerName> | Format-List *auth*

  2. Exécutez la commande suivante :

    New-AuthServer -Type ADFS -Name MyADFSServer -AuthMetadataUrl https://<adfs server FQDN>/FederationMetadata/2007-06/FederationMetadata.xml

    Cette commande est nécessaire pour créer un objet serveur d’authentification dans Exchange Server pour ADFS. Les objets serveur d’authentification sont une liste d’émetteurs approuvés. Seuls les jetons OAuth de ces émetteurs sont acceptés.

  3. Exécutez la commande suivante :

    Set-AuthServer -Identity MyADFSServer -IsDefaultAuthorizationEndpoint $true

    Définissez le serveur d’authentification que nous venons d’ajouter DefaultAuthorizationEndpointen tant que . Lors de la publicité de l’en-tête d’authentification moderne, Exchange Server publie l’URL d’authentification DefaultAuthorizationEndpointdu . C’est ainsi que les clients savent quel point de terminaison utiliser pour l’authentification.

  4. Nous devons exécuter cette commande pour activer l’authentification moderne au niveau organization :

    Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

  5. Activez l’authentification moderne pour les utilisateurs avec des clients pris en charge en affectant la stratégie d’authentification Allow Modern auth :

    Set-User -Identity User -AuthenticationPolicy "Allow Modern auth"

Vérifier le flux d’authentification moderne

Une fois configurés correctement, les utilisateurs rencontrent l’invite de connexion ADFS lorsqu’ils se connectent à un serveur Exchange.

Effet sur d’autres clients lorsque l’authentification moderne est activée pour un utilisateur

Les utilisateurs activés pour l’authentification moderne qui ont plusieurs clients (par exemple, Outlook sur Windows et Outlook Mobile) ont des expériences différentes pour chaque client. Voici un résumé du comportement des clients lorsque l’authentification moderne est activée.

Remarque

Le tableau suivant suppose que Bloquer l’authentification moderne est appliqué en tant que DefaultAuthenticationPolicy au niveau de l’organisation.

Client Comportement
Outlook sur Windows (nouvelles versions) Utilise l’authentification moderne par défaut.
Outlook sur Windows (anciennes versions) Tente d’utiliser l’authentification moderne, mais échoue.
Outlook Mac Tente d’utiliser l’authentification moderne, mais échoue ; prise en charge ultérieure.
Outlook iOS Revenir à l’authentification de base.
Outlook Android Revenir à l’authentification de base.
Application de messagerie iOS Revenir à l’authentification de base.
Application Gmail Revenir à l’authentification de base.
OWA/ECP N’utilise pas de stratégie d’authentification.
Selon la façon dont elle est configurée, utilise l’authentification moderne ou l’authentification de base.
Application Windows Mail Ne revient pas à l’authentification de base.
Client Thunderbird Ne revient pas à l’authentification de base.
PowerShell Utilise l’authentification de base.

Effet sur OWA/ECP lorsque l’authentification moderne est activée pour d’autres clients

Les clients peuvent ou non utiliser l’authentification basée sur les revendications ADFS pour Outlook sur le web. Les étapes mentionnées ci-dessus sont nécessaires pour activer OAuth pour d’autres clients et n’affectent pas la façon dont OWA/ECP est configuré.

Utiliser l’authentification basée sur les revendications AD FS avec Outlook sur le web

Temps d’attente après modification de la stratégie d’authentification

Après avoir modifié la stratégie d’authentification pour autoriser l’authentification moderne ou bloquer l’authentification héritée :

  • Patientez 30 minutes pour que les nouvelles stratégies soient lues par les serveurs frontaux

    ou

  • Effectuez une réinitialisation IIS sur tous les serveurs frontaux.

Migration vers l’authentification moderne hybride après avoir activé l’authentification moderne pour Exchange Server

Les clients qui utilisent l’authentification moderne avec ADFS qui décident ultérieurement de configurer Exchange Hybrid doivent passer à l’authentification moderne hybride. Les étapes détaillées de migration seront ajoutées à une version ultérieure de ce document.

Renouvellement des certificats

Évaluer la configuration de certificat actuelle

En ce qui concerne les connexions clientes à Exchange Server, le certificat qui doit être évalué est celui lié au site IIS frontal. Pour un serveur ADFS, il est idéal de s’assurer que tous les certificats retournés dans Get-AdfsCertificate sont à jour.

  1. Pour identifier le certificat approprié sur un Exchange Server, effectuez les opérations suivantes dans Exchange Management Shell :

    Import-Module WebAdministration
(Get-ChildItem IIS:SSLBindings | Where-Object {($_.Sites -ne $null) -and ($_.Port -eq "443")}).Thumbprint | ForEach-Object {Get-ExchangeCertificate $_ | Where-Object {$_.Services -Match "IIS"} | Format-Table Thumbprint, Services, RootCAType, Status, NotAfter, Issuer -AutoSize -Wrap}

  2. Pour passer en revue les certificats actifs sur un serveur ADFS, effectuez les opérations suivantes dans PowerShell :

    Get-AdfsCertificate | Format-Table CertificateType, Thumbprint, Certificate -AutoSize -Wrap

Mettre à jour les certificats sur Exchange Server

S’il a été trouvé que le certificat Exchange doit être mis à jour pour la connectivité du client, un nouveau certificat doit être émis et importé sur les serveurs Exchange. Ensuite, le certificat doit être activé pour IIS au minimum. Évaluez si d’autres services doivent être activés pour le nouveau certificat en fonction de votre configuration.

Voici un exemple de création, d’exécution, d’activation et d’importation d’un nouveau certificat sur tous les serveurs en fonction du certificat existant dans Exchange Management Shell :

  1. Générez une nouvelle demande de certificat dans Exchange Management Shell en fonction de votre certificat existant :

    $txtrequest = Get-ExchangeCertificate <Thumbprint> | New-ExchangeCertificate -GenerateRequest -PrivateKeyExportable $true

  2. Phasez une variable contenant le chemin de sortie souhaité de votre nouvelle demande de certificat :

    $requestFile = "C:\temp\CertRequest.req"

  3. Create le fichier de demande de certificat :

    [System.IO.File]::WriteAllBytes($requestFile, [System.Text.Encoding]::Unicode.GetBytes($txtrequest))

    Remarque

    Le chemin d’accès au dossier de la demande de certificat doit déjà exister.

  4. Partagez le fichier de demande avec votre autorité de certification. Les étapes requises pour obtenir un certificat complet varient en fonction de votre autorité de certification.

    Remarque

    .p7b est le format préféré pour la demande terminée.

  5. Étape d’une variable contenant le chemin d’accès complet de la demande terminée :

    $certFile = "C:\temp\ExchangeCert.p7b"

  6. Importez la demande sur le serveur qui a généré la demande à l’origine :

    Import-ExchangeCertificate -FileData ([System.IO.File]::ReadAllBytes($certFile)) -PrivateKeyExportable $true

  7. Variable d’étape pour le mot de passe afin de protéger le certificat terminé :

    $pw = Read-Host "Enter password" -AsSecureString

  8. Exportez le certificat Binary dans une variable :

    $binCert = Export-ExchangeCertificate <Thumbprint> -BinaryEncoded

  9. Variable de phase pour le chemin de sortie souhaité du certificat terminé :

    $certificate = "\\$env:computername\c$\temp\CompletedExchangeCert.pfx"

  10. Exportez la demande terminée pour l’importer sur d’autres serveurs :

    [System.IO.File]::WriteAllBytes($certificate, $binCert.FileData)

  11. Activez les services qui doivent être liés au certificat :

    Enable-ExchangeCertificate <Thumbprint> -Services IIS

    Remarque

    Vous devrez peut-être ajouter d’autres services à l’exemple ci-dessus en fonction de la configuration de vos certificats précédents.

  12. Vérifiez que le certificat fonctionne comme prévu en dirigeant un client vers le serveur pour tous les espaces de noms clients avec un fichier hôte.

  13. Importez le certificat Exchange sur tous les autres serveurs Exchange :

    Import-ExchangeCertificate -PrivateKeyExportable $true -FileData ([System.IO.File]::ReadAllBytes($certificate)) -Password $pw -Server <Server-Name>

    Remarque

    L’inclusion du -PrivateKeyExportable paramètre est facultative lors de l’importation vers d’autres serveurs Exchange.

  14. Activez le certificat Exchange pour les services Exchange nécessaires sur tous les autres serveurs Exchange :

    Enable-ExchangeCertificate <Thumbprint> -Services IIS -Server <Server-Name>

    Remarque

    Vous devrez peut-être ajouter d’autres services à l’exemple ci-dessus en fonction de la configuration de vos certificats précédents.

Mettre à jour le certificat sur ADFS

Selon le type de certificat qui nécessite une mise à jour sur ADFS, détermine si vous devez suivre les étapes décrites ci-dessous.

certificat Service-Communications

Cet exemple fournit le PowerShell requis pour importer un certificat au .pfx format, tel que celui généré en suivant les étapes de certificat Exchange Server. Vérifiez que vous êtes connecté au serveur ADFS principal.

  1. Phasez une variable contenant le mot de passe du certificat :

    $pw = Read-Host "Enter password" -AsSecureString

  2. Étape d’une variable contenant le chemin d’accès complet du certificat :

    $certificate = "\\E2k19-1\c$\temp\CompletedExchangeCert.pfx"

  3. Importez le certificat dans le magasin personnel de LocalMachine :

    Import-PfxCertificate -FilePath $certificate -CertStoreLocation Cert:\LocalMachine\my -Password $pw

  4. Mettez à jour le certificat Service-Communications :

    Set-AdfsSslCertificate -Thumbprint <Thumbprint>

Token-Signing et certificats Token-Decryption

Suivez les étapes décrites dans la documentation Obtenir et configurer des certificats TS et TD pour AD FS .

Remarque

L’utilisation du certificat auto-signé par défaut pour Token-Signing dans l’authentification basée sur les revendications ADFS pour Outlook sur le web nécessite l’installation du certificat sur les serveurs Exchange.