通过

在本地 Exchange 中启用新式身份验证

适用于：no-img-162016 yes-img-192019 yes-img-se订阅版

概述

从 Exchange Server 2019 CU13 开始，Exchange Server支持OAuth 2.0使用 ADFS 作为安全令牌服务 (STS) 的纯本地环境 (也称为 Modern Authentication) 。 本文档提供启用此功能的先决条件和步骤。

2019 Exchange Server 中的新式身份验证不应与混合新式身份验证 (HMA) 混淆，后者使用 Microsoft Entra ID 进行新式身份验证。 事实上，建议使用 HMA 为 Exchange 混合配置中的所有本地和云用户启用新式身份验证。 此新功能允许对没有Microsoft Entra ID或不在 Exchange 混合配置中的组织使用新式身份验证。

新式身份验证如何工作，此功能是否适用于我？

使用新式身份验证，用户可以使用 ADFS 向 Exchange 进行身份验证。 为用户启用新式身份验证后，其 Outlook 客户端将重定向到 ADFS。 然后，用户可以通过提供凭据或执行多重身份验证进行身份验证。 ADFS 对用户进行身份验证后，会生成访问令牌。 Exchange Server验证这些访问令牌，以提供对用户邮箱的客户端访问权限。

下图演示了Exchange Server、ADFS 和 Outlook 之间的协调，以使用新式身份验证对用户进行身份验证。

显示 Exchange Server 2019 新式身份验证握手工作流的关系图。 在上图中，3a步骤 、 4a5a 和 6a 是在为最终用户启用新式身份验证时发生的。 4b为用户禁用新式身份验证时，将发生步骤 3b。

请参阅下表，评估此功能是否适用。

Exchange 配置 此功能是否适用？ 备注
仅具有 2019 Exchange Server 的本地 Exchange 组织 是 不适用
包含 2019 Exchange Server、2016 Exchange Server 和 2013 Exchange Server 混合的本地 Exchange 组织 否 Exchange Server 2013 不受支持。
混合使用 2019 Exchange Server 和 2016 Exchange Server 的本地 Exchange 组织 是 仅 Exchange 2019 服务器可用作 Front-End (客户端访问) 服务器。
使用 HMA 的 Exchange 混合组织 否 使用 Microsoft Entra ID 的 HMA 是首选解决方案。 请参阅有关使用新身份验证策略的指南。
不使用 HMA 的 Exchange 混合组织 否 将 HMA 与 Microsoft Entra ID 配合使用。

在 Exchange 中启用新式身份验证的先决条件

Exchange Server 2019 CU13 或更高版本

若要使用新式身份验证，用于客户端连接的所有服务器都必须安装 Exchange Server 2019 CU13。

ADFS 2019 或更高版本

若要在本地 Exchange 环境中启用新式身份验证，需要在 Windows Server 2019 或更高版本上Active Directory 联合身份验证服务 (ADFS) 。 不支持在Exchange Server上安装和配置 ADFS 角色。 有关详细信息，请参阅 规划 AD FS 部署拓扑。

你还可能需要在 Windows Server 2019 或更高版本上 (Web 应用程序代理 Server) ，以启用从公司网络外部的客户端访问。 有关详细信息，请阅读 (可选) 为 Extranet 访问配置 Web 应用程序代理部分。

客户端先决条件

若要利用新式身份验证，用户需要通过 ADFS 与新式身份验证兼容的客户端应用程序，例如 Outlook 或其他本机作系统客户端。

Windows 版 Outlook

以下版本的 Microsoft Outlook for Windows中提供了对通过 ADFS 的新式身份验证的支持。 Microsoft Outlook Windows 客户端（从内部版本号 16.0.17628.10000开始）使用最新的 MSAL library 身份验证。 为确保使用最新的身份验证堆栈，建议安装最新版本：

Microsoft 365 应用版中的 Outlook：

频道 支持 版本 生成 (或更高版本)
预览体验成员频道 是 2304 16327.20200
当前频道 是 2304 16327.20214
月度企业频道 是 2304 16327.20324
半年企业频道（预览） 是 2402 17328.20184
半年度企业频道 是 2402 17328.20452

Outlook for Windows (批量许可证 & 零售) ：

版本 支持 版本 生成 (或更高版本)
Outlook 2016 (任何版本) 否 不适用 不适用
Outlook 2019 (任何版本) 否 不适用 不适用
Outlook 2021 (零售) 是 2304 16327.20214
Outlook 2021 (卷) 否 不适用 不适用
Outlook 2024 (零售) 是 2410 18129.20158
Outlook 2024 (卷) 是 2408 17932.20162

可以按照此处提到的步骤检查 Office 的内部版本号。

Mac 版 Outlook

从内部版本号 16.95.4 (25040241)开始，通过 Outlook for Mac (Microsoft 365) Microsoft 365 提供通过 ADFS 的新式身份验证支持。 请注意，独立版本（如 Outlook 2024 for Mac）目前不支持通过 ADFS 进行的新式身份验证。

Windows OS

Windows 客户端必须是 Windows 11 22H2 or later 并且必须安装 2023 年 3 月 14 日更新 。

可以查看Windows 更新历史记录来验证是否已KB5023706安装。

显示运行 Windows 11 22H2 的计算机的更新历史记录的屏幕截图。

Apple 平台

通过 ADFS 的新式身份验证支持在 Apple Mail 从 和 iOS 17.6.1开始macOS Sequoia的应用中Outlook for Mac (Microsoft 365)macOS Sequoia可用。

使用 ADFS 新式身份验证的协议

下表概述了可以通过利用 ADFS 新式身份验证令牌访问的协议。 我们一直在努力将 ADFS 新式身份验证支持添加到更多Exchange Server协议。

协议 支持 ADFS 新式身份验证
MAPI over HTTP (MAPI/HTTP) 是
Outlook Anywhere (RPC/HTTP) 否
Exchange Active Sync (EAS) 是
Exchange Web 服务 (EWS) 是
Outlook 网页版 (OWA) 是 (基于声明的身份验证)
Exchange 管理员 Center (ECP) 是 (基于声明的身份验证)
脱机通讯簿 (OAB) 是
IMAP 否
流行 否

使用 ADFS 作为 STS 在 Exchange Server 中配置新式身份验证的步骤

本部分详细介绍了如何在 Exchange Server 2019 CU13 中实现新式身份验证。

在所有 FE 服务器上安装 Exchange 2019 CU13， (至少)

用于客户端连接的所有服务器都必须升级到 Exchange 2019 CU13。 此方法可确保与 Exchange 2019 的初始客户端连接使用 OAuth，与 Exchange Server 2016 的代理连接使用 Kerberos。

Exchange 2019 CU13 添加了对新身份验证策略的支持，以在用户级别允许或阻止新式身份验证。 阻止新式身份验证用于确保不支持新式身份验证的客户端仍然可以连接。

若要将多个新的身份验证策略参数添加到Exchange Server，需要使用安装程序运行/PrepareAD。

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

安装 CU13 或更高版本后，任何预先存在的身份验证策略 (包括默认身份验证策略) 禁用参数。 这意味着，如果已在使用 HMA，则无需更改预先存在的身份验证策略。

Exchange 混合不需要新的身份验证策略

现有 Exchange 混合配置 应使用 混合新式身份验证 (HMA) 。 使用 HMA 的 BlockModernAuth* 混合安装可以将参数的值保留为 以 0 继续使用 HMA。 为使用 ADFS 设置新式身份验证而概述的步骤仅适用于未使用 Exchange Hybrid 且纯粹在本地的组织。

设置 Active Directory 联合身份验证服务 (ADFS)

需要在环境中安装和配置 ADFS，以允许 Exchange 客户端使用Forms身份验证 (OAuth) 连接到Exchange Server。 请参阅 清单：设置联合服务器 以帮助配置 ADFS。

可以通过在成为 ADFS 服务器的新服务器上从提升的 PowerShell 窗口中运行以下命令来安装 ADFS 功能：

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

Exchange Server组织中的 ADFS 配置的证书要求

ADFS 需要两种基本类型的证书 (请参阅 本文 ，了解) 的详细信息：

  1. 服务通信安全套接字层 (SSL) 证书，用于 ADFS 服务器、客户端、Exchange 服务器和可选的 Web 应用程序代理服务器之间的加密 Web 服务流量。 建议使用内部或商业证书颁发机构颁发的证书 (CA) ，因为所有客户端都需要信任此证书。
  2. 用于 ADFS 服务器、Active Directory 域控制器和 Exchange 服务器之间的加密通信和身份验证的令牌签名证书。 可以通过从 CA 请求令牌签名证书或创建自签名证书来获取令牌签名证书。

有关在 Windows 中创建和导入 SSL 证书的详细信息，请参阅 服务器证书。

下面是我们在此方案中使用的证书的摘要：

证书 (使用者、使用者可选名称或通配符证书匹配) 中的公用名 (CN) 类型 在服务器上是必需的 Comments
adfs.contoso.com
enterpriseregistration.contoso.com		 由 CA 颁发 ADFS 服务器，
Web 应用程序代理 服务器 (可选) 		联合服务器使用 SSL 证书来保护与客户端和联合服务器代理进行 SSL 通信的 Web 服务流量。

由于 SSL 证书必须受客户端计算机信任，我们建议您使用由受信任的 CA 签名的证书。 您选择的所有证书都必须拥有相应的私钥。
ADFS 令牌签名 - adfs.contoso.com 自签名或 CA 颁发 ADFS 服务器，
Web 应用程序代理 服务器 (可选) 		令牌签名证书是 X509 证书。 联合服务器使用关联的公钥/私钥对对它们生成的所有安全令牌进行数字签名。 此过程包括对已发布的联合元数据和项目解析请求进行签名。

可以在 ADFS 管理管理单元中配置多个令牌签名证书，以便在一个证书即将过期时允许证书滚动更新。 默认情况下，列表中的所有证书都会发布，但 ADFS 仅使用主令牌签名证书对令牌进行实际签名。 您选择的所有证书都必须拥有相应的私钥。

可以通过从企业 CA 或公共 CA 请求令牌签名证书，或通过创建自签名证书来获取令牌签名证书。
mail.contoso.com
autodiscover.contoso.com		 由 CA 颁发 Exchange 服务器，
Web 应用程序代理 服务器 (可选) 		此证书是用于加密与Outlook 网页版 (和其他 Exchange 服务) 的外部客户端连接的典型证书。 有关详细信息，请参阅 Exchange 服务的证书要求。

部署和配置 ADFS 服务器

使用 Windows Server 2019 或更高版本部署 ADFS 服务器。 按照 部署 ADFS 服务器 和 配置和测试 ADFS 服务器 文档中的步骤进行作。 确保可以从 Exchange 服务器和至少一台客户端计算机在 Web 浏览器中访问联合元数据 URL。

URL 使用以下语法： https://<FederationServiceName>/federationmetadata/2007-06/federationmetadata.xml

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

在 ADFS 中配置身份验证方法

若要在 Outlook on Windows 中使用新式身份验证，需要配置 Primary Authentication Methods。 建议同时Extranet选择 Forms Authentication 和 Intranet。 可以通过在 ADFS 服务器上的 PowerShell 窗口中运行以下命令来完成此配置：

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

选择适当的 SSO 生存期

选择适当的单 Sign-On (SSO) 生存期，以便最终用户无需频繁重新进行身份验证。 若要验证当前的 SSO 生存期配置，请在 ADFS 服务器上打开新的 PowerShell 窗口，并执行以下命令：

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

使用 Set-AdfsProperties cmdlet 为 SsoLifetime、 PersistentSsoLifetimeMins、 KmsiLifetimeMins和 DeviceUsageWindowInDays配置适当的值。 应调整这些设置以启用 SSO 并定义其到期时间。 根据 SSO 模式（如 Keep Me Signed In (KMSI) 或 Device registration），可能还需要启用 KsmiEnabled 和 PersistentSsoEnabled。 有关 ADFS SSO 的更多详细信息，请参阅 AD FS 2016 单一登录 设置文档。

在 ADFS 中配置设备注册

建议在 ADFS 中启用该功能， Device Registration 以便从改进的 SSO 体验中受益。 若要启用 Device Registration，请按照 使用设备注册服务配置联合服务器 文档中概述的步骤进行作。

接下来，完成配置 Device Registration Service Discovery 和 Device Registration Discovery Server SSL certificate的所有步骤，如 配置设备注册 文档中所述。

若要使用设备注册，最终用户必须将设备加入工作区。 可以在以下文档中找到更多详细信息：

通过检查 Device Registration Overview来验证是否已配置设备注册，并启用设备身份验证。 建议执行此步骤以减少用户的身份验证提示数，并有助于在 ADFS 中强制实施访问控制策略。

在 ADFS 中配置 KSMI

如果不想使用 Device Registration 或无法使用此功能，可以改为启用该功能 Keep Me Signed In 。 然后，ADFS 会在用户身份验证后立即创建持久性 Cookie，无需在后续会话中重新进行身份验证，前提是 Cookie 保持有效。

刷新令牌的过期时间等于 的持久性 SSO Cookie 的 Keep me signed in生存期。 默认情况下，持久性 SSO Cookie 生存期为一天，最长为 7 天。 否则，默认情况下，刷新令牌生存期等于会话 SSO Cookie 生存期 (8 小时) 。 有关 KSMI 的详细信息，请参阅 AD FS 单一登录设置 文档。

KMSI 默认处于禁用状态，可以通过将 ADFS 属性 KmsiEnabled 设置为 True来启用。 请确保在 ADFS 服务器上的 PowerShell 窗口中运行以下命令：

Set-AdfsProperties -EnableKmsi $true

禁用 KMSI 后，默认单一登录周期为 8 hours。 可以使用 属性 SsoLifetime配置单一登录周期。 属性以分钟为单位，因此其默认值为 480：

Set-AdfsProperties -SsoLifetime <LifetimeInMinutes>

启用 KMSI 后，默认单一登录期为 24 hours。 可以使用 属性 KmsiLifetimeMins配置启用了 KMSI 的单一登录期。 属性以分钟为单位，因此其默认值为 1440：

Set-AdfsProperties -KmsiLifetimeMins <LifetimeInMinutes>

创建 ADFS Outlook 应用程序组

如果这是你第一次在本地 Exchange 中配置 ADFS 新式身份验证，请按照本指南本部分中的步骤进行作。 如果现有的 ADFS 新式身份验证配置是在支持客户端（而不是 Microsoft Outlook for Windows）之前设置的，请参阅本文档更新 现有 ADFS Outlook 应用程序组 部分中的步骤。 必须在 ADFS 服务器上的 PowerShell 窗口中执行以下 PowerShell 命令。 如果不打算使用 iOS 和 macOS 应用程序（例如本机 Apple Mail 应用），可以跳过创建适用于 iOS 和 macOS 的 ADFS 本机客户端应用程序。 但是，为了完整性，我们建议创建它们。

首先，我们将创建 ADFS Application Group：

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

接下来，再创建三Scopes - EAS.AccessAsUser.All个 和 offline_accessEWS.AccessAsUser.All ：

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"

现在，我们将创建两个 Native Client Applications - Outlook - Native application 和 ：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/")

下一步，我们将创建 Web Api Applications。 我们为每个在Exchange Server环境中使用的 URI 创建一个应用程序。 如果使用 （例如 ） autodiscover.contoso.com 和 mail.contoso.com，则必须创建两个 Web Api Applications。 请确保将以下示例中的 URI 替换为在设置中使用的 URI。 请务必确保涵盖所有面向客户端的 URI。 包括尾随 / ，并确保 URI 以 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"
}

最后一步是添加现有 Web Api Applications中所有 的Native Client 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"
    }
}

更新现有的 ADFS Outlook 应用程序组

重要

如果没有现有的 ADFS Outlook 应用程序组，该组是在引入对客户端 Microsoft Outlook for Windows 的支持之前配置的，请跳过本部分中的步骤。

如果现有的 ADFS Outlook 应用程序组配置是在引入其他客户端 Microsoft Outlook for Windows 支持之前设置的，请按照此处的步骤启用对其他平台的支持。 必须在 ADFS 服务器上的 PowerShell 窗口中执行以下 PowerShell 命令。

首先，我们将创建三个额外的 Scopes - EAS.AccessAsUser.All和 EWS.AccessAsUser.Alloffline_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"

现在，我们正在创建新的 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/")

更新现有的 Native Client Application - Outlook - Native application。 请确保将 替换为 TargetName 在现有配置中使用的目标名称：

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

下一步，我们必须为每个 Identifier (URI 创建一个Web Api Application，) 用于Exchange Server环境中，并且存在于当前 ADFS 新式身份验证配置中：

$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
}

最后一步是添加现有 Web Api Applications中所有 的Native Client 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
            }
        }
    }
}

删除现有的 ADFS Outlook 应用程序组

警告

按照本部分中的步骤，将删除现有的 ADFS Outlook 应用程序组配置。

如果你有现有的 ADFS Outlook 应用程序组配置，并且想要删除它，请按照此处的步骤删除现有配置。 必须在 ADFS 服务器上的 PowerShell 窗口中执行以下所有 PowerShell 命令。

首先，我们将删除 ADFS Application Group：

Remove-AdfsApplicationGroup -TargetApplicationGroupIdentifier "Outlook"

最后一步，我们将删除已添加的自定义 Scopes ：

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

(可选) 可以为 Extranet 访问配置 Web 应用程序代理

Web 应用程序代理 是 Windows Server 中远程访问服务器角色的一部分。 它提供反向代理功能，允许用户从企业网络外部访问 Web 应用程序。 Web 应用程序代理使用 ADFS 对 Web 应用程序的访问进行预身份验证，并充当 ADFS 代理。

如果计划使用 Web 应用程序代理，请使用安装和配置 Web 应用程序代理 服务器中提到的步骤对其进行配置。 配置后，可以发布Autodiscover.contoso.com或/，并使用mail.contoso.com发布使用 OAuth2 的应用程序中所述的步骤。

(可选) 为客户端访问配置 MFA

  1. 请参阅以下链接，使用所选的 MFA 提供程序配置 ADFS。

  2. 配置需要 MFA 的访问控制策略。

为最终用户创建身份验证策略

组织中的所有用户可能都有支持通过 ADFS 进行新式身份验证的电子邮件客户端。 在此方案中，我们建议为具有支持的客户端的用户启用新式身份验证，并为没有客户端的用户阻止新式身份验证。

若要为一组特定用户启用新式身份验证并为其余用户阻止新式身份验证，至少需要创建两个身份验证策略。

重要

一旦使用 Exchange 2019 CU13 或更高版本媒体 准备 Active Directory ，新的身份验证策略就可用。

  • 默认阻止新式身份验证的组织范围策略
  • 用于选择性地允许特定用户进行新式身份验证的辅助策略

必须从 Exchange 服务器上的 EXCHANGE 命令行管理程序 (EMS) 窗口中执行以下 PowerShell 命令。

创建组织级策略以默认阻止新式身份验证

启用新式身份验证后，所有 Outlook 客户端都会尝试使用 OAuth 令牌。 但是，某些与 ADFS 新式身份验证不兼容的客户端只能从Microsoft Entra ID检索 OAuth 令牌。 因此，如果启用了新式身份验证，这些客户端将无法连接。

若要防止出现这种情况，可以实施组织范围的策略来禁用新式身份验证。 在此示例中，我们将创建一个名为 Block Modern Auth的新身份验证策略。

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

可以使用以下命令在组织级别设置此策略。

Set-OrganizationConfig -DefaultAuthenticationPolicy "Block Modern Auth"

创建用户级身份验证策略以启用新式身份验证

接下来，创建另一个启用新式身份验证的身份验证策略。 将此策略分配给具有支持的 Outlook 客户端的所有用户，以允许其客户端使用新式身份验证。

在此示例中，我们使用以下命令创建名为 Allow Modern Auth 的新身份验证：

New-AuthenticationPolicy "Allow Modern Auth"

配置Exchange Server以使用 ADFS OAuth 令牌

  1. 验证是否 OAuth 在以下虚拟目录上启用了 。 如果未启用，请为所有这些虚拟目录启用 OAuth 它：

    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*

    输出如下所示。 要关注的主要详细信息是 OAuth，如前所述：

    Get-MapiVirtualDirectory | Format-List Server, *auth*

Server                        : EX1
IISAuthenticationMethods      : {Ntlm, OAuth, Negotiate}
InternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}
ExternalAuthenticationMethods : {Ntlm, OAuth, Negotiate}

    如果 OAuth 任何服务器或五个虚拟目录中的任何一个都缺少，则需要使用相关命令添加它，然后再继续作： Set-MapiVirtualDirectory、 Set-WebServicesVirtualDirectory、 Set-OabVirtualDirectory、 Set-AutodiscoverVirtualDirectory 和 Set-ActiveSyncVirtualDirectory。

  2. 运行以下命令：

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

    在 ADFS 的 Exchange Server 中创建新的身份验证服务器对象时，需要使用此命令。 身份验证服务器对象是受信任颁发者的列表。 仅接受来自这些颁发者的 OAuth 令牌。

  3. 运行以下命令：

    Set-AuthServer -Identity MyADFSServer -IsDefaultAuthorizationEndpoint $true

    将刚刚添加的身份验证服务器设置为 DefaultAuthorizationEndpoint。 播发新式身份验证标头时，Exchange Server播发 的DefaultAuthorizationEndpoint身份验证 URL。 这是客户端知道使用哪个终结点进行身份验证的方式。

  4. 我们需要运行此命令以在组织级别启用新式身份验证：

    Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

  5. 通过分配 Allow Modern Auth 身份验证策略，为具有支持的客户端的用户启用新式身份验证：

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

Client-Side 新式身份验证配置

我们建议在部署到所有用户之前，先用少量用户测试新式身份验证。 一旦一组试点用户可以使用新式身份验证，就可以部署更多用户。 验证客户端是否支持 ADFS 新式身份验证。有关支持的客户端的更多详细信息，请参阅 客户端先决条件 部分。

Microsoft Windows

在 Outlook 中启用新式身份验证并将 ADFS 域添加为受信任域：

  1. 创建以下注册表项，使 ADFS 域成为受信任的域。 请确保在 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

    可以使用 PowerShell 创建注册表项，或借助组策略进行部署。 在每台客户端计算机上的 PowerShell 窗口中运行以下命令。 将 替换为 your-ADFS-domain 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")

  2. 若要在 中 Microsoft Outlook for Windows 启用 ADFS 新式身份验证，请在 EnableExchangeOnPremModernAuthREG_DWORD 下 HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity\添加 值。

    可以使用 PowerShell 创建注册表值，或通过组策略部署它。 在每台客户端计算机上的 PowerShell 窗口中运行以下命令。

    Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Office\16.0\Common\Identity\" -Name "EnableExchangeOnPremModernAuth" -Value 1 -Type DWord

Apple macOS

若要在受支持的 Apple macOS 版本上为 Microsoft Outlook 启用新式身份验证，需要修改 Microsoft Outlook 应用程序的首选项。

打开终端窗口并运行以下命令，将 host1 替换为 ADFS 服务器的 FQDN。 确保不包含协议或在 FQDN 末尾添加任何斜杠。 例如，如果可以通过 访问 https://fs.contoso.com/ADFS 服务器，请使用 fs.contoso.com。 如果有多个 ADFS 命名空间，请添加用空格分隔的命名空间。

defaults write com.microsoft.Outlook ADFSAuthorizedURLs -array host1

对于托管设备，管理员可以使用移动设备管理 (MDM) 解决方案集中管理 ADFS FQDN 列表并将其推送到客户端设备。 下表概述了通过 MDM 控制此功能所需的配置设置：

设置 值
目标应用 Outlook Mac
配置密钥 trustedauthorities
值类型 String
配置值 <ADFS FQDNs>

验证新式身份验证流

正确配置后，用户在连接到 Exchange 服务器时会遇到 ADFS 登录提示。

启用新式身份验证时对其他客户端的影响

例如，启用了新式身份验证的用户使用多个客户端 (， Outlook on Windows) Outlook Mobile 在每个客户端上体验不同的行为。 在以下摘要中，我们描述了启用新式身份验证时的客户端行为，假设 Block Modern Auth 在组织级别应用为 DefaultAuthenticationPolicy 。

Client 行为
Outlook for Windows (经典) 默认情况下，使用新式身份验证。
Outlook for Windows (新建) 尝试使用新式身份验证，但失败。
Outlook for Mac 如果在客户端上启用了新式身份验证，则使用新式身份验证。
Outlook iOS 回退到基本身份验证。
Outlook Android 回退到基本身份验证。
iOS 邮件应用 使用新式身份验证。
macOS 邮件应用 使用新式身份验证。
Gmail 应用 回退到基本身份验证。
OWA/ECP 不使用身份验证策略。
根据配置方式，它使用新式身份验证或基本身份验证。
Windows 邮件应用 不会回退到基本身份验证。
Thunderbird 客户端 不会回退到基本身份验证。
PowerShell 使用基本身份验证。

为其他客户端启用新式身份验证时对 OWA/ECP 的影响

你可能正在使用基于 ADFS 声明的身份验证，也可能不使用Outlook 网页版。 为其他客户端启用 OAuth 需要上述步骤，并且不会影响 OWA/ECP 的配置方式。

将基于 AD FS 声明的身份验证与 Outlook 网页版

更改身份验证策略后的等待时间

更改身份验证策略以允许新式身份验证或阻止旧身份验证后：

  • 等待 30 分钟，让前端服务器读取新策略

    或

  • 在所有前端服务器上执行 IIS 重置。

使用为 Exchange Server 启用新式身份验证后迁移到混合新式身份验证

如果将新式身份验证与 ADFS 配合使用，并且后来决定配置 Exchange 混合，则应过渡到混合新式身份验证。本文档的未来版本中将包含详细的迁移步骤。

续订证书

评估当前证书配置

当涉及到与Exchange Server的客户端连接时，应评估的证书是绑定到前端 IIS 站点的证书。 对于 ADFS 服务器，请确保中 Get-AdfsCertificate 返回的所有证书都是最新的， 这是理想之选。

  1. 若要标识Exchange Server上的相关证书，请在 Exchange 命令行管理程序中执行以下作：

    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. 若要查看 ADFS 服务器上的活动证书，请在 PowerShell 中执行以下作：

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

更新Exchange Server上的证书

如果发现需要更新 Exchange 证书以建立客户端连接，则必须颁发新证书并将其导入 Exchange Server。 之后，至少应为 IIS 启用证书。 根据配置评估是否应为新证书启用其他服务。

基于 Exchange 命令行管理程序中的现有证书在所有服务器上创建、完成、启用和导入新证书的示例：

  1. 基于现有证书在 Exchange 命令行管理程序中生成新的证书请求：

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

  2. 暂存包含新证书请求的所需输出路径的变量：

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

  3. 创建证书请求文件：

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

    注意

    证书请求的文件夹路径必须已存在。

  4. 与证书颁发机构 (CA) 共享请求文件。 获取已完成证书所需的步骤因 CA 而异。

    注意

    .p7b 是已完成请求的首选格式。

  5. 暂存包含已完成请求的完整路径的变量：

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

  6. 将请求导入到最初生成请求的服务器：

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

  7. 用于保护已完成证书的密码的阶段变量：

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

  8. 将证书二进制文件导出到变量中：

    $binCert = Export-ExchangeCertificate <Thumbprint> -BinaryEncoded

  9. 已完成证书的所需输出路径的阶段变量：

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

  10. 导出要在其他服务器上导入的已完成请求：

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

  11. 启用应绑定到证书的服务：

    Enable-ExchangeCertificate <Thumbprint> -Services IIS

    注意

    可能需要根据以前的证书配置向前面的示例添加更多服务。

  12. 通过使用主机文件将客户端定向到所有客户端命名空间的服务器，验证证书是否按预期工作。

  13. 在所有其他 Exchange 服务器上导入 Exchange 证书：

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

    注意

    导入到其他 Exchange 服务器时， -PrivateKeyExportable 包括 参数是可选的。

  14. 在所有其他 Exchange 服务器上为所需的 Exchange 服务启用 Exchange 证书：

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

    注意

    可能需要根据以前的证书配置向前面的示例添加更多服务。

更新 ADFS 上的证书

根据需要在 ADFS 上更新的证书类型，确定是否需要遵循下面所述的步骤。

Service-Communications 证书

此示例提供导入格式的证书.pfx所需的 PowerShell，例如按照Exchange Server证书步骤生成的证书。 确保已登录主 ADFS 服务器。

  1. 暂存包含证书密码的变量：

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

  2. 暂存包含证书的完整路径的变量：

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

  3. 将证书导入到 LocalMachine 的个人存储中：

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

  4. 更新 Service-Communications 证书：

    Set-AdfsSslCertificate -Thumbprint <Thumbprint>

Token-Signing 和 Token-Decryption 证书

按照 获取和配置 AD FS 的 TS 和 TD 证书 文档中概述的步骤进行作。

注意

对 Outlook 网页版 使用基于 ADFS 声明的身份验证中的 Token-Signing 的默认自签名证书要求在 Exchange 服务器上安装证书。