Activation de l’authentification moderne dans Exchange en local

2025-05-09

S’APPLIQUE À : no-img-16 2016 oui-img-19 2019 oui-img-se Édition d’abonnement

Vue d’ensemble

À compter de Exchange Server 2019 CU13, Exchange Server prend en charge OAuth 2.0 (également appelé Modern Authentication) pour les environnements locaux purs utilisant ADFS en tant que service d’émission de jeton de sécurité (STS). Ce document fournit les prérequis et les étapes pour activer cette fonctionnalité.

L’authentification moderne dans Exchange Server 2019 ne doit pas être confondue avec l’authentification moderne hybride (HMA), qui utilise Microsoft Entra ID pour l’authentification moderne. En fait, HMA est toujours la 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 d’utiliser l’authentification moderne pour les organisations qui n’ont pas 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. Exchange Server valide ces jetons d’accès 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.

Dans le graphique précédent, les étapes 3a, 5a4aet 6a ont lieu lorsque l’authentification moderne est activée pour l’utilisateur final. Les étapes 3bse 4b 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. L’installation et la configuration du rôle ADFS sur un Exchange Server ne sont pas prises en charge. Pour plus d’informations, consultez Planifier votre topologie de déploiement AD FS.

Vous aurez peut-être également 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. Pour plus d’informations, consultez la section Configurer l’Proxy d'application web peut être configuré pour l’accès extranet.

Conditions préalables du client

Pour utiliser l’authentification moderne, les utilisateurs ont besoin d’applications clientes, telles qu’Outlook ou d’autres clients de système d’exploitation natifs, qui sont compatibles avec l’authentification moderne via ADFS.

Outlook sur Windows

La prise en charge de l’authentification moderne via ADFS est disponible dans les versions suivantes de Microsoft Outlook for Windows. Le client Microsoft Outlook Windows, à partir du numéro 16.0.17628.10000de build , utilise la dernière version MSAL library pour l’authentification. Pour vous assurer que vous utilisez la pile d’authentification la plus récente, il est recommandé d’installer la dernière version :

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)	Oui	2402	17328.20184
Canal Entreprise semestriel	Oui	2402	17328.20452

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 (volume)	Non	S/O	S/O
Outlook 2024 (Vente au détail)	Oui	2410	18129.20158
Outlook 2024 (volume)	Oui	2408	17932.20162

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

Outlook sur Mac

La prise en charge de l’authentification moderne via ADFS est disponible dans Outlook for Mac (Microsoft 365) via Microsoft 365 à partir du numéro 16.95.4 (25040241)de build . Notez que l’authentification moderne via ADFS n’est actuellement pas prise en charge dans les versions autonomes telles que Outlook 2024 for Mac.

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é.

Plateformes Apple

La prise en charge de l’authentification moderne via ADFS est disponible dans l’application Apple Mail en commençant par macOS Sequoia et iOS 17.6.1et en Outlook for Mac (Microsoft 365) commençant par macOS Sequoia.

Protocoles qui fonctionnent avec l’authentification moderne ADFS

Le tableau suivant décrit les protocoles accessibles en utilisant des jetons d’authentification moderne ADFS. Nous travaillons en permanence à l’ajout de la prise en charge de l’authentification moderne ADFS à d’autres protocoles Exchange Server.

Protocole	Authentification moderne ADFS prise en charge
MAPI sur HTTP (MAPI/HTTP)	Oui
Outlook Anywhere (RPC/HTTP)	Non
Exchange Active Sync (EAS)	Oui
Services Web Exchange (EWS)	Oui
Outlook sur le web (OWA)	Oui (authentification basée sur les revendications)
Exchange Administration Center (ECP)	Oui (authentification basée sur les revendications)
Carnet d’adresses en mode hors connexion	Oui
IMAP	Non
POP	Non

É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. Cette approche garantit que les connexions clientes initiales à Exchange 2019 utilisent OAuth, et que les connexions proxiées à Exchange Server 2016 utilisent Kerberos.

Exchange 2019 CU13 ajoute la prise en charge de nouvelles stratégies d’authentification pour autoriser ou bloquer l’authentification moderne au niveau de l’utilisateur. Le blocage de l’authentification moderne permet de s’assurer 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.

BlockModernAuthActiveSync
BlockModernAuthAutodiscover
BlockModernAuthImap
BlockModernAuthMapi
BlockModernAuthOfflineAddressBook
BlockModernAuthPop
BlockModernAuthRpc
BlockModernAuthWebServices

Après l’installation de CU13 ou version ultérieure, les paramètres 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 si vous utilisez déjà HMA, vous n’avez pas besoin de modifier les stratégies d’authentification préexistantes.

Aucune nouvelle stratégie d’authentification requise pour Exchange Hybride

Les configurations Exchange hybrides existantes doivent utiliser l’authentification moderne hybride (HMA). Les installations hybrides utilisant HMA peuvent laisser les valeurs des BlockModernAuth* paramètres à pour continuer à 0 utiliser HMA. Les étapes décrites pour configurer l’authentification moderne avec ADFS s’appliquent uniquement aux organisations qui n’utilisent pas Exchange Hybrid et qui sont purement locales.

Configurer Services ADFS (ADFS)

Vous devez installer et configurer ADFS dans l’environnement pour permettre aux clients Exchange d’utiliser l’authentification Forms (OAuth) pour se connecter à Exchange Server. Reportez-vous à la Liste de contrôle : Configuration d’un serveur de fédération pour faciliter la configuration de votre service ADFS.

La fonctionnalité ADFS peut être installée en exécutant la commande suivante à partir d’une fenêtre PowerShell avec élévation de privilèges sur le nouveau serveur qui devient le serveur ADFS :

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

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) :

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.
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. Ce processus inclut la signature des métadonnées de fédération publiées et les demandes de résolution d’artefacts. Vous pouvez avoir plusieurs certificats de signature de jeton configurés dans le composant logiciel enfichable Gestion ADFS 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 ADFS 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)	Ce certificat est le 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 décrites dans la documentation Déployer un serveur ADFS et Configurer et tester le serveur ADFS . Vérifiez que l’URL des métadonnées de fédération est accessible dans un navigateur web à partir du serveur Exchange et d’au moins un ordinateur client.

L’URL utilise la syntaxe suivante : https://<FederationServiceName>/federationmetadata/2007-06/federationmetadata.xml

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

Configurer la méthode d’authentification dans ADFS

Pour utiliser l’authentification moderne dans Outlook sur Windows, vous devez configurer .Primary Authentication Methods Nous vous recommandons de choisir Forms Authentication à la fois Extranet pour et Intranet. Cette configuration peut être effectuée en exécutant les commandes suivantes à partir d’une fenêtre PowerShell sur le serveur ADFS :

Set-AdfsGlobalAuthenticationPolicy -PrimaryIntranetAuthenticationProvider FormsAuthentication
Set-AdfsGlobalAuthenticationPolicy -PrimaryExtranetAuthenticationProvider FormsAuthentication

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

Choisissez une durée de vie de Sign-On unique (SSO) appropriée afin que les utilisateurs finaux ne soient pas obligés de se réauthentifier fréquemment. Pour valider la configuration de durée de vie de l’authentification unique actuelle, ouvrez une nouvelle fenêtre PowerShell sur le serveur ADFS et exécutez la commande suivante :

Get-AdfsProperties | Format-List SsoLifetime, PersistentSsoLifetimeMins, KmsiLifetimeMins, DeviceUsageWindowInDays, KmsiEnabled, PersistentSsoEnabled, BrowserSsoEnabled

Utilisez l’applet de commande Set-AdfsProperties pour configurer les valeurs appropriées pour SsoLifetime, PersistentSsoLifetimeMins, KmsiLifetimeMinset DeviceUsageWindowInDays. Ces paramètres doivent être ajustés pour activer l’authentification unique et définir son expiration. Selon le mode d’authentification unique, tel que Keep Me Signed In (KMSI) ou Device registration, vous devrez peut-être également activer KsmiEnabled et PersistentSsoEnabled. Pour plus d’informations sur l’authentification unique ADFS, consultez la documentation relative aux paramètres d’Authentification unique AD FS 2016.

Configurer l’inscription des appareils dans ADFS

Il est recommandé de permettre à la Device Registration fonctionnalité dans ADFS de bénéficier d’une expérience d’authentification unique améliorée. Pour activer Device Registration, suivez les étapes décrites dans la documentation Configurer un serveur de fédération avec le service d’inscription d’appareil .

Ensuite, effectuez toutes les étapes de configuration Device Registration Service Discovery et , Device Registration Discovery Server SSL certificatecomme décrit dans la documentation Configuration de l’inscription d’appareil .

Pour utiliser l’inscription de l’appareil, les utilisateurs finaux doivent joindre leur appareil à un espace de travail. Pour plus d’informations, consultez les documentations suivantes :

Vérifiez que l’inscription de l’appareil est configurée et que l’authentification de l’appareil est activée en vérifiant .Device Registration Overview 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.

Configurer KSMI dans ADFS

Si vous préférez ne pas utiliser Device Registration ou si vous ne pouvez pas le faire, vous pouvez activer la fonctionnalité à la Keep Me Signed In place. ADFS crée ensuite un cookie persistant immédiatement après l’authentification de l’utilisateur, ce qui élimine le besoin de réauthentification dans les sessions suivantes, à condition que le cookie reste valide.

La durée d’expiration du jeton d’actualisation est égale à la durée de vie du cookie d’authentification unique persistante pour Keep me signed in. La durée de vie des cookies d’authentification unique persistante est d’un jour par défaut, avec un maximum de sept jours. Sinon, la durée de vie du jeton d’actualisation est égale à la durée de vie des cookies d’authentification unique de session (8 heures par défaut). Pour plus d’informations sur KSMI, consultez la documentation relative aux paramètres de l’authentification unique AD FS .

KMSI est désactivé par défaut et peut être activé en définissant la propriété KmsiEnabled ADFS sur True. Veillez à exécuter les étapes suivantes à partir d’une fenêtre PowerShell sur votre serveur ADFS :

Set-AdfsProperties -EnableKmsi $true

Avec KMSI désactivé, la période d’authentification unique par défaut est 8 hours. La période d’authentification unique peut être configurée à l’aide de la propriété SsoLifetime. La propriété étant mesurée en minutes, sa valeur par défaut est 480:

Set-AdfsProperties -SsoLifetime <LifetimeInMinutes>

Avec KMSI activé, la période d’authentification unique par défaut est 24 hours. La période d’authentification unique avec KMSI activé peut être configurée à l’aide de la propriété KmsiLifetimeMins. La propriété étant mesurée en minutes, sa valeur par défaut est 1440:

Set-AdfsProperties -KmsiLifetimeMins <LifetimeInMinutes>

Créer le groupe d’applications Outlook ADFS

S’il s’agit de votre première configuration de l’authentification moderne ADFS dans Exchange en local, suivez les étapes décrites dans cette section du guide. Si vous disposez d’une configuration d’authentification moderne ADFS qui a été configurée avant la prise en charge des clients autres que Microsoft Outlook for Windows, reportez-vous aux étapes décrites dans la section Mettre à jour le groupe d’applications Outlook ADFS existant de cette documentation. Les commandes PowerShell suivantes doivent être exécutées à partir d’une fenêtre PowerShell sur votre serveur ADFS. Si vous n’envisagez pas d’utiliser des applications iOS et macOS, telles que l’application Apple Mail native, vous pouvez ignorer la création de l’application cliente native ADFS pour iOS et macOS. Toutefois, nous vous recommandons de les créer par souci d’exhaustivité.

Tout d’abord, nous allons créer le ADFS Application Group:

New-AdfsApplicationGroup -Name "Outlook" -ApplicationGroupIdentifier "Outlook" -Disabled:$false

Ensuite, nous créons trois autres Scopes - EAS.AccessAsUser.All, EWS.AccessAsUser.All et :offline_access

Add-AdfsScopeDescription -Name "EAS.AccessAsUser.All" -Description "EAS scope"
Add-AdfsScopeDescription -Name "EWS.AccessAsUser.All" -Description "EWS scope"
Add-AdfsScopeDescription -Name "offline_access" -Description "Offline Access"

À présent, nous créons deux Native Client Applications - Outlook - Native application et iOS and macOS - Native mail application:

Add-AdfsNativeClientApplication -Name "Outlook - Native application" -ApplicationGroupIdentifier "Outlook" -Identifier "d3590ed6-52b3-4102-aeff-aad2292ab01c" -RedirectUri @("ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c","msauth.com.microsoft.Outlook://auth","urn:ietf:wg:oauth:2.0:oob")
Add-AdfsNativeClientApplication -Name "iOS and macOS - Native mail application" -ApplicationGroupIdentifier "Outlook" -Identifier "f8d98a96-0999-43f5-8af3-69971c7bb423" -RedirectUri @("com.apple.mobilemail://oauth-redirect","com.apple.preferences.internetaccounts://oauth-redirect/","com.apple.Preferences://oauth-redirect/")

À l’étape suivante, nous créons Web Api Applications. Nous créons une application par URI qui est utilisée dans votre environnement Exchange Server. Si vous utilisez, par exemple, autodiscover.contoso.com et mail.contoso.com, vous devez créer deux Web Api Applications. Veillez à remplacer les URI dans l’exemple suivant par les URI que vous utilisez dans votre configuration. Il est important de s’assurer que tous les URI côté client sont couverts. Incluez la fin / et assurez-vous que les URI commencent par https://:

# Replace the URIs with your URIs
$exchangeServerServiceFqdns = @("https://autodiscover.contoso.com/","https://mail.contoso.com/")

$issuanceTransformRules = @"
@RuleName = "ActiveDirectoryUserSID"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]
 => issue(claim = c);

@RuleName = "ActiveDirectoryUPN"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
 => issue(claim = c);

@RuleName = "AppIDACR"
 => issue(Type = "appidacr", Value = "2");

@RuleName = "SCP"
 => issue(Type = "scp", Value = "user_impersonation");

@RuleName = "SCPEAS"
 => issue(Type = "scp", Value = "EAS.AccessAsUser.All");

@RuleName = "SCPEWS"
 => issue(Type = "scp", Value = "EWS.AccessAsUser.All");

@RuleName = "offlineaccess"
 => issue(Type = "scp", Value = "offline_access");
"@
foreach ($fqdn in $exchangeServerServiceFqdns) {
    Add-AdfsWebApiApplication -Name "Outlook - Web API ($((New-Guid).ToString("N")))" -ApplicationGroupIdentifier "Outlook" -Identifier $fqdn -IssuanceTransformRules $issuanceTransformRules -AccessControlPolicyName "Permit Everyone"
}

Dans la dernière étape, nous ajoutons les autorisations client pour tous les Native Client Applications dans le existant Web Api Applications:

$clientRoleIdentifier = @("f8d98a96-0999-43f5-8af3-69971c7bb423","d3590ed6-52b3-4102-aeff-aad2292ab01c")
(Get-AdfsWebApiApplication -ApplicationGroupIdentifier "Outlook") | ForEach-Object {
    [string]$serverRoleIdentifier = $_.Identifier
    foreach ($id in $clientRoleIdentifier) {
        Grant-AdfsApplicationPermission -ClientRoleIdentifier $id -ServerRoleIdentifier $serverRoleIdentifier -ScopeNames "winhello_cert","email","profile","vpn_cert","logon_cert","user_impersonation","allatclaims","offline_access","EAS.AccessAsUser.All","EWS.AccessAsUser.All","openid","aza"
    }
}

Mettre à jour le groupe d’applications Outlook ADFS existant

Importante

Ignorez les étapes décrites dans cette section si vous n’avez pas de groupe d’applications Outlook ADFS, qui a été configuré avant l’introduction de la prise en charge des clients autres que Microsoft Outlook for Windows celui-ci.

Si vous disposez d’une configuration de groupe d’applications Outlook ADFS, qui a été configurée avant l’introduction de la prise en charge des clients autres que Microsoft Outlook for Windows , suivez les étapes ci-dessous pour activer la prise en charge d’autres plateformes. Les commandes PowerShell suivantes doivent être exécutées à partir d’une fenêtre PowerShell sur votre serveur ADFS.

Tout d’abord, nous créons trois autres Scopes - EAS.AccessAsUser.All, EWS.AccessAsUser.All et :offline_access

Add-AdfsScopeDescription -Name "EAS.AccessAsUser.All" -Description "EAS scope"
Add-AdfsScopeDescription -Name "EWS.AccessAsUser.All" -Description "EWS scope"
Add-AdfsScopeDescription -Name "offline_access" -Description "Offline Access"

À présent, nous créons un nouveau Native Client Applications - iOS and macOS - Native mail application:

Add-AdfsNativeClientApplication -Name "iOS and macOS - Native mail application" -ApplicationGroupIdentifier "Outlook" -Identifier "f8d98a96-0999-43f5-8af3-69971c7bb423" -RedirectUri @("com.apple.mobilemail://oauth-redirect","com.apple.preferences.internetaccounts://oauth-redirect/","com.apple.Preferences://oauth-redirect/")

Nous mettons à jour le existant Native Client Application - Outlook - Native application. Veillez à remplacer par TargetName le nom cible que vous utilisez dans la configuration existante :

Set-AdfsNativeClientApplication -TargetName "Outlook - Native application" -RedirectUri @("ms-appx-web://Microsoft.AAD.BrokerPlugin/d3590ed6-52b3-4102-aeff-aad2292ab01c","msauth.com.microsoft.Outlook://auth","urn:ietf:wg:oauth:2.0:oob")

À l’étape suivante, nous devons en créer un Web Api Application pour chaque Identifier (URI) qui est utilisé dans votre environnement Exchange Server et qui existe dans votre configuration d’authentification moderne ADFS actuelle :

$duplicateFqdnHashSet = New-Object System.Collections.Generic.HashSet[string]
$issuanceTransformRules = @"
@RuleName = "ActiveDirectoryUserSID"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"]
 => issue(claim = c);

@RuleName = "ActiveDirectoryUPN"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
 => issue(claim = c);

@RuleName = "AppIDACR"
 => issue(Type = "appidacr", Value = "2");

@RuleName = "SCP"
 => issue(Type = "scp", Value = "user_impersonation");

@RuleName = "SCPEAS"
 => issue(Type = "scp", Value = "EAS.AccessAsUser.All");

@RuleName = "SCPEWS"
 => issue(Type = "scp", Value = "EWS.AccessAsUser.All");

@RuleName = "offlineaccess"
 => issue(Type = "scp", Value = "offline_access");
"@
(Get-AdfsWebApiApplication -ApplicationGroupIdentifier "Outlook") | ForEach-Object {
    if ($_.Identifier.Count -gt 1) {
        Write-Host "[+] More than one identifier was found in Web Api Application: $($_.Name)" -ForegroundColor Yellow
        $_.Identifier | Select-Object -Skip 1 | ForEach-Object {
            Write-Host "[+] Identifier $_ must be added to a new Web Api Application and will now be removed from the existing one" -ForegroundColor Yellow
            [void]$duplicateFqdnHashSet.Add($_)
        }

        Set-AdfsWebApiApplication -TargetName $_.Name -Identifier ($_.Identifier)[0] -IssuanceTransformRules $issuanceTransformRules -AccessControlPolicyName "Permit Everyone"
    }
}

foreach($identifier in $duplicateFqdnHashSet) {
    Write-Host "[+] Creating a new Web Api Application for: $identifier" -ForegroundColor Yellow
    Add-AdfsWebApiApplication -Name "Outlook - Web API ($((New-Guid).ToString("N")))" -ApplicationGroupIdentifier "Outlook" -Identifier $identifier -IssuanceTransformRules $issuanceTransformRules -AccessControlPolicyName "Permit Everyone"
    Write-Host "[+] Done!`r`n" -ForegroundColor Green
}

Dans la dernière étape, nous ajoutons les autorisations client pour tous les Native Client Applications dans le existant Web Api Applications:

$clientRoleIdentifier = @("f8d98a96-0999-43f5-8af3-69971c7bb423","d3590ed6-52b3-4102-aeff-aad2292ab01c")
$requiredScopes = @("winhello_cert","email","profile","vpn_cert","logon_cert","user_impersonation","allatclaims","offline_access","EAS.AccessAsUser.All","EWS.AccessAsUser.All","openid","aza")

(Get-AdfsWebApiApplication -ApplicationGroupIdentifier "Outlook") | ForEach-Object {
    [string]$serverRoleIdentifier = $_.Identifier
    Write-Host "[+] Processing Server Role: $serverRoleIdentifier" -ForegroundColor Yellow
    foreach ($id in $clientRoleIdentifier) {
        Write-Host "[+] Processing Client Role: $id" -ForegroundColor Yellow
        $permissionEntry = Get-AdfsApplicationPermission | Where-Object { $_.ClientRoleIdentifier -eq $id -and $_.ServerRoleIdentifier -eq $serverRoleIdentifier }
        if ($null -eq $permissionEntry) {
            Write-Host "[+] No Application Permission found for Client Role: $id - Server Role: $serverRoleIdentifier" -ForegroundColor Yellow
            Grant-AdfsApplicationPermission -ClientRoleIdentifier $id -ServerRoleIdentifier $serverRoleIdentifier -ScopeNames $requiredScopes
        } else {
            Write-Host "[+] Application Permission found - validating Scopes" -ForegroundColor Yellow
            $missingScopesList = New-Object System.Collections.Generic.List[string]
            $requiredScopes | ForEach-Object {
                if ($_ -in $permissionEntry.ScopeNames) {
                    Write-Host "[+] Scope: $_ is already set!" -ForegroundColor Green
                } else {
                    Write-Host "[+] Scope: $_ is missing and must be added" -ForegroundColor Yellow
                    $missingScopesList.Add($_)
                }
            }

            if ($missingScopesList.Count -ge 1) {
                Write-Host "[+] The following Scopes will be added: $([string]::Join(", ", $missingScopesList))" -ForegroundColor Yellow
                Set-AdfsApplicationPermission -TargetClientRoleIdentifier $id -TargetServerRoleIdentifier $serverRoleIdentifier -AddScope $missingScopesList
                Write-Host "[+] Done!`r`n" -ForegroundColor Green
            } else {
                Write-Host "[+] There is nothing to do!`r`n" -ForegroundColor Green
            }
        }
    }
}

Supprimer un groupe d’applications Outlook ADFS existant

Attention

En suivant les étapes de cette section, vous supprimez la configuration existante du groupe d’applications Outlook ADFS.

Si vous disposez d’une configuration de groupe d’applications Outlook ADFS existante et que vous souhaitez la supprimer, suivez les étapes ci-dessous pour supprimer la configuration existante. Toutes les commandes PowerShell suivantes doivent être exécutées à partir d’une fenêtre PowerShell sur votre serveur ADFS.

Tout d’abord, nous allons supprimer :ADFS Application Group

Remove-AdfsApplicationGroup -TargetApplicationGroupIdentifier "Outlook"

En dernière étape, nous supprimons les éléments personnalisés Scopes qui ont été ajoutés :

Remove-AdfsScopeDescription -TargetName "EAS.AccessAsUser.All"
Remove-AdfsScopeDescription -TargetName "EWS.AccessAsUser.All"
Remove-AdfsScopeDescription -TargetName "offline_access"

(Facultatif) Configurer Proxy d'application web peut être configuré 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 la configuration effectuée, 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.

(Facultatif) Configurer l’authentification multifacteur pour l’accès client

Reportez-vous aux liens suivants pour configurer ADFS avec un fournisseur MFA de votre choix.
- Configurer des fournisseurs d’authentification tiers comme authentification principale dans AD FS 2019
- Configurer Azure MFA en tant que fournisseur d’authentification avec AD FS
Configurez Access Control stratégie nécessitant l’authentification multifacteur.
- stratégies de Access Control dans Windows Server 2016 AD FS

Créer des stratégies d’authentification 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 via ADFS. Dans ce scénario, nous vous recommandons d’activer l’authentification moderne pour les utilisateurs avec des clients pris en charge et de la bloquer pour les utilisateurs sans.

Pour activer l’authentification moderne pour un ensemble spécifique d’utilisateurs et la bloquer pour les utilisateurs restants, vous devez créer au moins deux stratégies d’authentification.

Importante

Les nouvelles stratégies d’authentification sont disponibles dès que Active Directory est préparé à l’aide du support Exchange 2019 CU13 ou version ultérieure.

Stratégie organization pour bloquer l’authentification moderne par défaut
Une stratégie secondaire pour autoriser de manière sélective l’authentification moderne pour des utilisateurs spécifiques

Les commandes PowerShell suivantes doivent être exécutées à partir d’une fenêtre EMS (Exchange Management Shell) sur votre serveur Exchange.

Créer une stratégie de niveau organization pour bloquer l’authentification moderne par défaut

Une fois l’authentification moderne activée, tous les clients Outlook tentent d’utiliser des jetons OAuth. Toutefois, certains clients qui ne sont pas compatibles avec l’authentification moderne ADFS peuvent uniquement récupérer des jetons OAuth à partir de Microsoft Entra ID. Par conséquent, ces clients ne peuvent pas se connecter si l’authentification moderne est activée.

Pour éviter ce scénario, vous pouvez implémenter une stratégie organization pour désactiver l’authentification moderne. Dans l’exemple, nous créons une stratégie d’authentification nommé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"

Créer une 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. Affectez cette stratégie à tous les utilisateurs disposant de clients Outlook pris en charge pour permettre à leurs clients d’utiliser l’authentification moderne.

Dans l’exemple, 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

Vérifiez si OAuth est activé sur les répertoires virtuels suivants. S’il n’est pas activé, activez-le OAuth pour tous ces répertoires virtuels :
```
Get-MapiVirtualDirectory | Format-List Server, *auth*
Get-WebServicesVirtualDirectory | Format-List Server, *auth*
Get-OabVirtualDirectory | Format-List Server, *auth*
Get-AutodiscoverVirtualDirectory | Format-List Server, *auth*
Get-ActiveSyncVirtualDirectory | Format-List Server, *auth*
```
La sortie s’affiche comme suit. Le principal détail sur lequel se concentrer est OAuth, comme mentionné précédemment :
```
Get-MapiVirtualDirectory | Format-List Server, *auth*

Server                        : EX1
IISAuthenticationMethods      : {Ntlm, OAuth, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
```
S’il OAuth manque à un serveur ou à l’un des cinq répertoires virtuels, vous devez l’ajouter à l’aide des commandes appropriées avant de continuer : Set-MapiVirtualDirectory, Set-WebServicesVirtualDirectory, Set-OabVirtualDirectory, Set-AutodiscoverVirtualDirectory et Set-ActiveSyncVirtualDirectory.
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.
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 . Lorsque vous publiez l’en-tête Modern Auth, Exchange Server publie l’URL d’authentification DefaultAuthorizationEndpointdu . C’est ainsi que les clients savent quel point de terminaison utiliser pour l’authentification.
Nous devons exécuter cette commande pour activer l’authentification moderne au niveau organization :
```
Set-OrganizationConfig -OAuth2ClientProfileEnabled $true
```
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"
```

Client-Side configuration de l’authentification moderne

Nous vous recommandons de tester l’authentification moderne avec peu d’utilisateurs avant de déployer 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. Vérifiez que votre client prend en charge l’authentification moderne ADFS. Pour plus d’informations sur les clients pris en charge, consultez la section Conditions préalables du client .

Microsoft Windows

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

Créez les clés de Registre suivantes pour faire de votre domaine ADFS un domaine approuvé. Veillez à ajouter les deux clés avec et sans à / la fin du domaine ADFS :
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://your-ADFS-domain/
- HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains\https://your-ADFS-domain
Vous pouvez utiliser PowerShell pour créer les clés de Registre ou les déployer à l’aide d’un stratégie de groupe. Exécutez les commandes suivantes à partir d’une fenêtre PowerShell sur chaque ordinateur client. Remplacez par your-ADFS-domain votre domaine ADFS.
```
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains" -Force
(Get-Item HKLM:).OpenSubKey("SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains", $true).CreateSubKey("https://your-ADFS-domain/")
(Get-Item HKLM:).OpenSubKey("SOFTWARE\Policies\Microsoft\AAD\AuthTrustedDomains", $true).CreateSubKey("https://your-ADFS-domain")
```
Pour activer l’authentification moderne ADFS dans Microsoft Outlook for Windows , ajoutez la EnableExchangeOnPremModernAuthREG_DWORD valeur sous HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity\.

Vous pouvez utiliser PowerShell pour créer la valeur de Registre ou la déployer via un stratégie de groupe. Exécutez la commande suivante à partir d’une fenêtre PowerShell sur chaque ordinateur client.
```
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Office\16.0\Common\Identity\" -Name "EnableExchangeOnPremModernAuth" -Value 1 -Type DWord
```

Apple macOS

Pour activer l’authentification moderne pour Microsoft Outlook sur les versions prises en charge d’Apple macOS, vous devez modifier les préférences de l’application Microsoft Outlook.

Ouvrez une fenêtre Terminal et exécutez la commande suivante, en host1 remplaçant par le nom de domaine complet de votre serveur ADFS. Veillez à ne pas inclure le protocole ou à ajouter des barres obliques à la fin du nom de domaine complet. Par exemple, si votre serveur ADFS est accessible via https://fs.contoso.com/, utilisez fs.contoso.com. Si vous avez plusieurs espaces de noms ADFS, ajoutez-les séparés par un espace.

defaults write com.microsoft.Outlook ADFSAuthorizedURLs -array host1

Pour les appareils gérés, les administrateurs peuvent utiliser une solution mobile Gestion des appareils (MDM) pour gérer et envoyer (push) de manière centralisée une liste de noms de domaine complets ADFS aux appareils clients. Le tableau suivant décrit les paramètres de configuration requis pour contrôler cette fonctionnalité via GPM :

Paramètres	Values
Application ciblée	`Outlook Mac`
Clé de configuration	`trustedauthorities`
Type de valeur	`String`
Valeur de configuration	`<ADFS FQDNs>`

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

Les utilisateurs activés pour l’authentification moderne qui utilisent plusieurs clients (par exemple, Outlook on Windows et ) rencontrent Outlook Mobiledes comportements différents sur chaque client. Dans le résumé suivant, nous décrivons les comportements du client lorsque l’authentification moderne est activée, en supposant Block Modern Auth que est appliqué en tant que au DefaultAuthenticationPolicy niveau organization.

Client	Comportement
Outlook pour Windows (classique)	Utilise l’authentification moderne par défaut.
Outlook pour Windows (nouveau)	Tente d’utiliser l’authentification moderne, mais échoue.
Outlook pour Mac	Utilise l’authentification moderne si elle est activée sur le client.
Outlook iOS	Revient à l’authentification de base.
Outlook Android	Revient à l’authentification de base.
Application de messagerie iOS	Utilise l’authentification moderne.
Application de messagerie macOS	Utilise l’authentification moderne.
Application Gmail	Revient à l’authentification de base.
OWA/ECP	N’utilise pas de stratégie d’authentification. Selon la façon dont il est configuré, il 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

Vous utilisez peut-être ou non l’authentification basée sur les revendications ADFS pour Outlook sur le web. Les étapes mentionnées 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 utilisé l’activation de l’authentification moderne pour Exchange Server

Si vous utilisez l’authentification moderne avec ADFS et que vous décidez ultérieurement de configurer Exchange Hybrid, vous devez passer à l’authentification moderne hybride. Des étapes de migration détaillées seront incluses dans une prochaine version 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.

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}

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 est constaté 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.

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 :

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

Phasez une variable contenant le chemin de sortie souhaité de votre nouvelle demande de certificat :
```
$requestFile = "C:\temp\CertRequest.req"
```
Créez 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.
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.
Étape d’une variable contenant le chemin d’accès complet de la demande terminée :
```
$certFile = "C:\temp\ExchangeCert.p7b"
```

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

Variable d’étape pour le mot de passe afin de protéger le certificat terminé :
```
$pw = Read-Host "Enter password" -AsSecureString
```

Exportez le certificat Binary dans une variable :

$binCert = Export-ExchangeCertificate <Thumbprint> -BinaryEncoded

Variable de phase pour le chemin de sortie souhaité du certificat terminé :
```
$certificate = "\\$env:computername\c$\temp\CompletedExchangeCert.pfx"
```
Exportez la demande terminée pour l’importer sur d’autres serveurs :
```
[System.IO.File]::WriteAllBytes($certificate, $binCert.FileData)
```
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 précédent en fonction de la configuration de vos certificats précédents.
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.
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.
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 précédent 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.

Phasez une variable contenant le mot de passe du certificat :
```
$pw = Read-Host "Enter password" -AsSecureString
```
Étape d’une variable contenant le chemin d’accès complet du certificat :
```
$certificate = "\\E2k19-1\c$\temp\CompletedExchangeCert.pfx"
```

Importez le certificat dans le magasin personnel de LocalMachine :

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

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.

Partager via