Active Directory 联合身份验证服务的新增功能

  • 项目

Windows Server 2019 的 Active Directory 联合身份验证服务的新增功能

本文介绍对 Active Directory 联合身份验证服务 (AD FS) 所做的新更改。

受保护的登录

以下几点简要概述了针对 Active Directory 联合身份验证服务 (AD FS) 2019 中提供的受保护登录的更新：

  • 外部身份验证提供程序作为主要身份验证手段。 客户现在可以将第三方身份验证产品用作首要因素，而不需将会暴露的密码用作首要因素。 在外部身份验证提供程序可以证明两个因素的情况下，其可以声明 MFA。
  • 密码身份验证作为额外身份验证。 客户有一个完全受支持的内置选项，可在将无密码选项用作首要因素后，仅将密码用作额外因素。 与 AD FS 2016 相比，此选项改善了客户体验（在 AD FS 2016 中，客户必须按原样下载受支持的 GitHub 适配器）。
  • 可插入风险评估模块。 客户现在可以生成自己的插件模块，以在预身份验证阶段阻止特定类型的请求。 通过此功能，客户可以更轻松地使用云智能（如身份保护）来阻止风险用户的登录或风险事务。 有关详细信息，请参阅使用 AD FS 2019 风险评估模型生成插件。
  • ESL 改进。 通过添加以下功能，对 2016 中的 ESL 快速修复工程 (QFE) 进行了改进：
    • 自 AD FS 2012R2 起，支持客户处于审核模式并同时受“经典”Extranet 锁定功能保护。 目前，2016 客户在审核模式下不受任何保护。
    • 为熟悉位置启用独立锁定阈值。 通过此功能，使用公共服务帐户运行的多个应用实例可以在最小的影响下滚动密码。

其他安全改进

AD FS 2019 中提供了以下安全改进：

  • 使用智能卡登录的远程 PowerShell。 客户现在可以使用智能卡通过 PowerShell 远程连接到 AD FS，并使用它来管理所有 PowerShell 功能，包括多节点 cmdlet。
  • HTTP 标头自定义。 客户现在可以自定义在 AD FS 响应期间发出的 HTTP 标头，包括以下标头：
    • HSTS：此标头表明 AD FS 终结点只能在 HTTPS 终结点上使用，以使兼容浏览器强制执行。
    • x-frame-options：使 AD FS 管理员可允许特定信赖方为 AD FS 交互式登录页面嵌入 iFrame。 请谨慎使用此标头并且只能在 HTTPS 主机上使用。
    • 未来的标头：还可以配置其他未来的标头。

有关详细信息，请参阅使用 AD FS 2019 自定义 HTTP 安全响应标头。

身份验证/策略功能

AD FS 2019 中包含以下身份验证/策略功能：

  • 为每个 RP 的其他身份验证指定身份验证方法。 客户现在可以使用声明规则来决定要为其额外身份验证调用的其他身份验证提供程序。 此功能适用于两个用例：
    • 客户从一个其他身份验证提供程序转换到另一个。 这样，当他们将用户加入到较新的身份验证提供程序时，他们可以使用组来控制调用哪个额外身份验证提供程序。
    • 对于某些应用程序，客户需要使用特定的额外身份验证提供程序（例如证书）。
  • 将基于传输层安全性 (TLS) 的设备身份验证仅限于需要它的应用程序。 客户现在可以将基于客户端 TLS 的设备身份验证仅限于执行基于设备的条件访问的应用程序。 对于不需要基于 TLS 的设备身份验证的应用程序，此选项可以阻止任何不必要的设备身份验证提示（或者在客户端应用程序无法处理时失败）。
  • 多重身份验证 (MFA) 新鲜度支持。 AD FS 现在支持根据第二因素凭据的新鲜度重新执行第二因素凭据的功能。 通过此功能，客户可以使用两个因素执行初始事务，仅定期提示输入第二因素。 此功能适用于可以在请求中提供额外参数并且在 AD FS 中不属于可配置设置的应用程序。 如果配置了“在 X 天内记住我的 MFA”且“supportsMFA”标志在 Azure AD 联合域信任设置上设置为 true，则 Azure AD 支持此参数。

单一登录改进

AD FS 2019 中进行了以下单一登录 SSO 改进：

  • 使用居中主题的分页 UX。 AD FS 现在已移动到分页的 UX 流，使 AD FS 能够进行验证并提供更流畅的登录体验。 AD FS 现在使用居中 UI（而不是屏幕右侧）。 你可能需要较新的徽标和背景图像以使其符合此体验。 此更改也反映了 Azure AD 中提供的功能。
  • Bug 修复：执行主刷新令牌 (PRT) 身份验证时 Win10 设备的持久 SSO 状态。此更改解决了在对 Windows 10 设备使用 PRT 身份验证时 MFA 状态不持久的问题。 此问题导致的结果是，最终用户会频繁收到输入第二因素凭据 (MFA) 的提示。 通过客户端 TLS 和 PRT 机制成功执行设备身份验证时，此修复还可使体验保持一致。

对生成新式业务线应用的支持

AD FS 2019 中添加了对生成新式业务线 LOB 应用的以下支持：

  • OAuth 设备流/配置文件。 AD FS 现在支持 OAuth 设备流配置文件，以在没有 UI 外围应用支持丰富登录体验的设备上登录。 通过此功能，用户可以在不同的设备上完成登录体验。 Azure Stack 中的 Azure CLI 体验需要此功能，且其可以在其他情况下使用。
  • 删除了“Resource”参数。 AD FS 现在删除了指定一个符合当前 OAuth 规范的资源参数的要求。 除请求的权限外，客户现在可以提供信赖方信任标识符作为范围参数。
  • AD FS 响应中的跨源资源共享 (CORS) 标头。 客户现在可以生成单页应用程序，其允许客户端 JavaScript 库通过从 AD FS 上的 OpenID Connect (OIDC) 发现文档中查询签名密钥来验证 id_token 的签名。
  • 代码交换证明密钥 (PKCE) 支持。 AD FS 添加了 PKCE 支持，以在 OAuth 内提供安全的身份验证代码流。 此功能会为此流添加一个额外的安全层，以防止代码劫持并从其他客户端重播。
  • Bug 修复：发送 x5t 和儿童声明。 此更改修复了一个小 bug。 AD FS 现在额外发送“儿童”声明，以表示用于验证签名的密钥 ID 提示。 以前 AD FS 仅发送“x5t”声明。

可支持性改进

以下可支持性改进现在属于 AD FS 2019：

  • 向 AD FS 管理员发送错误详细信息。 允许管理员配置最终用户以发送与最终用户身份验证失败相关的调试日志，并将其存储为压缩文件以方便使用。 管理员还可以配置简单邮件传输协议 (SMTP) 连接，以将压缩文件自动邮寄到分类电子邮件帐户，或根据电子邮件自动创建票证。

部署更新

AD FS 2019 中现已包含以下部署更新：

  • 场行为级别 2019。 与 AD FS 2016 相同，需要新的场行为级别版本才能启用本文稍后所述的新功能。 此更新允许进行以下升级：
    • 从 Windows Server 2012 R2 上的 AD FS 升级到 Windows Server 2016 上的 AD FS。
    • 从 Windows Server 2016 上的 AD FS 升级到 Windows Server 2019 上的 AD FS。

SAML 更新

AD FS 2019 中包含以下安全断言标记语言 (SAML) 更新：

  • Bug 修复：修复聚合联合身份验证中的 bug。 围绕聚合联合身份验证支持进行了大量 bug 修复（例如 InCommon）。 以下内容已得到修复：
    • 改善了聚合联合身份验证元数据文档中大量实体的缩放。以前，缩放会失败并显示“ADMIN0017”错误。
    • 通过 Get-AdfsRelyingPartyTrustsGroup PowerShell cmdlet 使用“ScopeGroupID”参数进行查询。
    • 处理有关重复 entityID 的错误条件。

范围参数中的 Azure AD 样式资源规范

之前，AD FS 要求所需的资源和范围在任何身份验证请求中都位于单独参数中。 例如，以下 OAuth 请求可能类似于你通常发送的请求：

https://fs.contoso.com/adfs/oauth2/authorize?response_type=code&client_id=claimsxrayclient&resource=urn:microsoft:adfs:claimsxray&scope=oauth&redirect_uri=https://adfshelp.microsoft.com/
ClaimsXray/TokenResponse&prompt=login

借助 Server 2019 上的 AD FS，你现在可以传递嵌入在 scope 参数中的资源值。 此更改与可以对 Azure AD 进行身份验证的方式一致。

现在可以将 scope 参数组织成一个用空格分隔的列表，其中每个条目的结构都作为资源/范围。

注意

身份验证请求中只能指定一个资源。 如果请求中包含多个资源，则 AD FS 将返回错误，且身份验证将失败。

适用于 OAuth 的代码交换证明密钥 (PKCE) 支持

使用授权代码授予的 OAuth 公共客户端容易受到授权代码拦截攻击。 RFC 7636 中详细介绍了这种攻击。 要缓解这种攻击，Server 2019 中的 AD FS 支持适用于 OAuth 授权代码授予流的代码交换证明密钥 (PKCE)。

为使用 PKCE 支持，此规范将向 OAuth 2.0 授权和访问令牌请求添加更多参数。

Diagram of the PKCE relationship between the client and AD FS 2019.

答： 客户端创建并记录名为“code_verifier”的机密，并导出转换后的版本“t(code_verifier)”（称为“code_challenge”）。 该机密与“t_m”转换方法一起在 OAuth 2.0 授权请求中发送。

B. 授权终结点照常响应，但记录“t(code_verifier)”和转换方法。

C. 然后，客户端照常在访问令牌请求中发送授权代码，但包含在 (A) 生成的“code_verifier”机密。

D. AD FS 转换“code_verifier”，并将其与 (B) 中的“t(code_verifier)”进行比较。 如果它们不相等，则拒绝访问。

如何在 2019 版中选择额外身份验证提供程序

AD FS 已支持基于声明规则策略触发额外身份验证。 可以在特定的 RP 或全局级别设置这些策略。 可使用 cmdlet Set-AdfsRelyingPartyTrust (AD FS) | Microsoft Docs 通过传递 AdditionalAuthenticationRules 或 AdditionalAuthenticationRulesFile 参数为特定 RP 设置额外身份验证策略。 若要全局设置该策略，管理员可以使用 cmdlet Set-AdfsAdditionalAuthenticationRule (AD FS) | Microsoft Docs。

例如，如果请求来自 Extranet，从 2012 R2 版开始，管理员可以编写以下规则来提示进行额外身份验证。

Set-AdfsAdditionalAuthenticationRule -AdditionalAuthenticationRules 'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", value = "https://schemas.microsoft.com/claims/multipleauthn" );'

在 2019 版中，客户现在可以使用声明规则来决定要为额外身份验证调用的其他身份验证提供程序。 此功能适用于两种方案：

客户从一个其他身份验证提供程序转换到另一个。 这样，当他们将用户加入到较新的身份验证提供程序时，他们可以使用组来控制调用哪个额外身份验证提供程序。

客户需要为某些应用程序提供特定的额外身份验证提供程序（例如证书），而为其他应用程序提供不同的方法（Azure AD 多重身份验证）。

可通过从其他身份验证策略发出 https://schemas.microsoft.com/claims/authnmethodsproviders 声明来实现此配置。 此声明的值应为身份验证提供程序的名称。

在 2019 版中，客户现在可以修改以前的声明规则，以根据其具体情况选择身份验证提供程序。

从一个身份验证提供程序转换到另一个身份验证提供程序：可以修改上述规则，以便为组 SID S-1-5-21-608905689-872870963-3921916988-12345 中的用户选择 Azure AD 多重身份验证。 例如，可以将此修改用于按企业管理的组，该组跟踪已注册 Azure AD 多重身份验证的用户。 此修改也适用于管理员想要使用证书身份验证的其余用户。

'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "https://schemas.microsoft.com/claims/multipleauthn" ); 

 c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value == "S-1-5-21-608905689-872870963-3921916988-12345"] => issue(Type = "`https://schemas.microsoft.com/claims/authnmethodsproviders`", Value = "AzureMfaAuthentication"); 

not exists([Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value=="S-1-5-21-608905689-872870963-3921916988-12345"]) => issue(Type = "`https://schemas.microsoft.com/claims/authnmethodsproviders`", Value = "CertificateAuthentication");’

此示例演示如何为两个不同的应用程序设置两个不同的身份验证提供程序：

将应用程序 A 设置为使用 Azure AD 多重身份验证作为额外身份验证提供程序：

Set-AdfsRelyingPartyTrust -TargetName AppA -AdditionalAuthenticationRules 'c:[type == "https://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "https://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "https://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "AzureMfaAuthentication");'

将应用程序 B 设置为使用证书作为额外身份验证提供程序：

Set-AdfsRelyingPartyTrust -TargetName AppB -AdditionalAuthenticationRules 'c:[type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn" ); 

c:[] => issue(Type = "http://schemas.microsoft.com/claims/authnmethodsproviders", Value = "CertificateAuthentication");'

管理员还可以制定规则以允许多个额外身份验证提供程序。 在这种情况下，AD FS 显示已颁发的身份验证方法提供程序，用户可以选择其中任何一个。 若要允许多个额外身份验证提供程序，则应发出多个声明 https://schemas.microsoft.com/claims/authnmethodsproviders。

如果声明评估未返回任何身份验证提供程序，AD FS 会回退以显示管理员在 AD FS 上配置的所有额外身份验证提供程序。 然后，用户需要选择适当的身份验证提供程序。

若要获取允许的所有其他身份验证提供程序，管理员可以使用 cmdlet (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider。 https://schemas.microsoft.com/claims/authnmethodsproviders 声明的值应为上述 cmdlet 返回的提供程序名称之一。

如果 RP 使用 AD FS Windows Server 2016 中的访问控制策略 | Microsoft Docs，则不支持触发特定的额外身份验证提供程序。将应用程序移出访问控制策略时，AD FS 会将访问控制策略中的相应策略复制到 AdditionalAuthenticationRule 和 IssuanceAuthorizationRule。 因此，如果管理员想要使用特定的身份验证提供程序，请不要使用访问控制策略，而是修改 AdditionalAuthenticationRule 来触发特定的身份验证提供程序。

常见问题解答

如何解决 AD FS 管理事件日志错误“收到的 Oauth 请求无效。 禁止客户端 'NAME' 访问作用域为 'ugs' 的资源。”？

请按照以下步骤修正该问题：

  1. 启动 AD FS 管理控制台。 转到“服务”>“作用域说明”。
  2. 在“作用域说明”上选择更多选项，然后选择“添加作用域说明”。
  3. 在“名称”下输入“ugs”，然后选择“应用”>“确定”。
  4. 以管理员身份启动 PowerShell。
  5. 运行命令 Get-AdfsApplicationPermission。 查找具有 ClientRoleIdentifier 的 ScopeNames :{openid, aza}。 记下 ObjectIdentifier。
  6. 运行命令 Set-AdfsApplicationPermission -TargetIdentifier <ObjectIdentifier from step 5> -AddScope 'ugs'。
  7. 重启 AD FS 服务。
  8. 在客户端上，重启客户端。 系统应提示配置 Windows Hello 企业版 (WHFB)。
  9. 如果未弹出配置窗口，则需要收集跟踪日志并进一步进行故障排除。

是否可以像在 Azure AD 中完成请求那样将资源值作为作用域值的一部分进行传递？

借助 Server 2019 上的 AD FS，你现在可以传递嵌入在 scope 参数中的资源值。 现在可以将 scope 参数组织成一个用空格分隔的列表，其中每个条目的结构都作为资源/范围。 例如： <create a valid sample request>

AD FS 是否支持 PKCE 扩展？

Server 2019 中的 AD FS 支持适用于 OAuth 授权代码授予流的代码交换证明密钥 (PKCE)。

Windows Server 2016 的 Active Directory 联合身份验证服务的新增功能

要查找有关 AD FS 早期版本的信息，请参阅以下文章：Windows Server 2012 或 2012 R2 中的 AD FS 和 AD FS 2.0。

AD FS 跨多种应用程序（包括 Office 365、基于云的 SaaS 应用程序以及企业网络上的应用程序）提供访问控制和单一登录。

  • 对于 IT 组织，它使你能够基于同一组凭据和策略在任何计算机上为新式和旧版应用程序提供登录和访问控制。
  • 对于用户，它使用相同且熟悉的帐户凭据提供无缝登录。
  • 对于开发人员，它提供了一种简单的方法来对其身份位于组织目录中的用户进行身份验证，以便开发人员可以将精力集中于其应用程序，而不是身份验证或身份上。

消除 Extranet 中的密码

AD FS 2016 启用了三个无需密码即可登录的新选项，使组织能够避免网络危害（网络钓鱼、密码泄露或被盗）所带来的风险。

使用 Azure Active Directory 多重身份验证登录

AD FS 2016 基于 Windows Server 2012 R2 中 AD FS 的多重身份验证 (MFA) 功能生成。 现在，只需使用 Azure AD 多重身份验证代码即可允许登录，而无需先输入用户名和密码。

  • 使用 Azure AD 多重身份验证作为主要身份验证方法，系统会提示用户通过 Azure Authenticator 应用输入其用户名和 OTP 代码。
  • 使用 Azure AD 多重身份验证作为辅助或额外身份验证方法时，用户提供主要身份验证凭据。 他们可以使用 Windows 集成身份验证，通过用户名和密码、智能卡或用户或设备证书登录。 然后，他们会看到提示输入文本、语音或基于 OTP 的 Azure AD 多重身份验证登录。
  • 借助新的内置 Azure AD 多重身份验证适配器，使用 AD FS 进行 Azure AD 多重身份验证的设置和配置从未如此简单。
  • 组织可以利用 Azure AD 多重身份验证，而无需本地 Azure AD 多重身份验证服务器。
  • 可为 Intranet 或 Extranet 配置 Azure AD 多重身份验证，或将其作为任何访问控制策略的一部分进行配置。

有关使用 AD FS 进行 Azure AD 多重身份验证的详细信息，请参阅配置 AD FS 2016 和 Azure AD 多重身份验证。

符合设备的无密码访问

AD FS 2016 基于以前的设备注册功能生成，可基于设备符合性状态启用登录和访问控制。 用户可以使用设备凭据登录，在设备属性发生变化时会重新评估符合性，这样你就可以始终确保策略得到实施。 此功能可以实现以下策略：

  • 仅允许从托管和/或符合的设备进行访问。
  • 仅允许从托管和/或符合的设备进行 Extranet 访问。
  • 对于未托管或不符合的计算机，需要多重身份验证。

AD FS 在混合方案中提供条件访问策略的本地组件。 向 Azure AD 注册设备以对云资源进行条件访问时，该设备标识也可用于 AD FS 策略。

Diagram of a hybrid solution and the relationships between users and on-premises active directory.

有关在云中使用基于设备的条件访问的详细信息，请参阅 Azure Active Directory 条件访问。

有关将基于设备的条件访问与 AD FS 结合使用的详细信息，请参阅：

通过 Windows Hello 企业版登录

注意

目前，基于浏览器的单一登录 (SSO) 与 Windows Hello 企业版不支持 Google Chrome 和基于 Chromium 构建的新 Microsoft Edge 开源项目浏览器。 请使用 Internet Explorer 或较早版本的 Microsoft Edge。

Windows 10 设备引入了 Windows Hello 和 Windows Hello 企业版，将用户密码替换为受用户手势（PIN、指纹等生物识别手势或面部识别）保护的强设备绑定用户凭据。 AD FS 2016 支持这些新增 Windows 10 功能，使用户无需提供密码即可从 Intranet 或 Extranet 登录到 AD FS 应用程序。

有关在组织中使用 Windows Hello 企业版的详细信息，请参阅在组织中启用 Windows Hello 企业版。

保护对应用程序的访问

以下更改会影响对 AD FS 中应用程序的安全访问。

新式身份验证

AD FS 2016 支持最新的新式协议，可为 Windows 10 以及最新的 iOS 和 Android 设备和应用提供更好的用户体验。

有关详细信息，请参阅适用于开发人员的 AD FS 方案。

无需了解声明规则语言即可配置访问控制策略

以前，AD FS 管理员必须使用 AD FS 声明规则语言配置策略，这使得配置和维护策略变得困难。 借助访问控制策略，管理员可以使用内置模板来应用常见的策略，例如

  • 仅允许 Intranet 访问。
  • 允许所有人，并要求来自 Extranet 的人员进行 MFA。
  • 允许所有人，并要求来自特定组的人员进行 MFA。

使用向导驱动过程可以轻松地自定义模板，以便添加异常或额外策略规则，并可将模板应用到一个或多个应用程序，以实现一致的策略执行。

有关详细信息，请参阅 AD FS 中的访问控制策略。

启用使用非 AD LDAP 目录进行登录

许多组织将 Active Directory 和第三方目录结合在一起。 通过添加 AD FS 对存储在符合轻型目录访问协议 (LDAP) v3 的目录中的用户进行身份验证的支持，AD FS 现在可用于：

  • 符合 LDAP v3 的第三方目录中的用户。
  • 未配置 Active Directory 双向信任的 Active Directory 林中的用户。
  • Active Directory 轻型目录服务 (AD LDS) 中的用户。

有关详细信息，请参阅 Configure AD FS to authenticate users stored in LDAP directories。

更好的登录体验

以下更改改进了 AD FS 的登录体验。

自定义 AD FS 应用程序的登录体验

以前，Windows Server 2012 R2 中的 AD FS 为所有信赖方应用程序提供一种通用的登录体验，并能够为每个应用程序自定义基于文本的内容的子集。 通过 Windows Server 2016，你不仅可为每个应用程序自定义消息，还可以自定义图像、徽标和 Web 主题。 此外，你还可以创建新的自定义 Web 主题，并为每个依赖方应用这些主题。

有关详细信息，请参阅 AD FS 用户登录自定义。

可管理性和操作增强

下一节介绍了 Windows Server 2016 中的 Active Directory 联合身份验证服务引入的改进操作方案。

简化的审核，以便更轻松地进行行政管理

在适用于 Windows Server 2012 R2 的 AD FS 中，为单个请求生成了大量审核事件，且有关登录或令牌颁发活动的相关信息或是不存在，或是跨多个审核事件分布。 由于其冗长特性，AD FS 审核事件默认处于关闭状态。 随着 AD FS 2016 的发布，审核变得更加精简且不那么冗长。

有关详细信息，请参阅 Windows Server 2016 中 AD FS 的审核增强功能。

改进了与 SAML 2.0 的互操作性，以参与联合身份验证

AD FS 2016 包含更多 SAML 协议支持，包括支持基于包含多个实体的元数据导入信任。 此更改使你可以将 AD FS 配置为参与联合身份验证，例如 InCommon 联合身份验证和其他符合 eGov 2.0 标准的实现。

有关详细信息，请参阅 SAML 2.0 的改进互操作性。

Microsoft 365 联合身份验证用户的简化密码管理

你可以将 Active Directory 联合身份验证服务 (AD FS) 配置为向受 AD FS 保护的信赖方信任（应用程序）发送密码过期声明。 如何使用这些声明取决于应用程序。 例如，使用 Office 365 作为你的信赖方时，会将更新实施到 Exchange 和 Outlook，以通知联合身份验证用户其密码即将过期。

有关详细信息，请参阅配置 AD FS 以发送密码过期声明。

从 Windows Server 2012 R2 中的 AD FS 迁移到 Windows Server 2016 中的 AD FS 更简单

以前，迁移到新版 AD FS 需要从旧的场导出配置，并将其导入到全新的并行场。

现在，从 Windows Server 2012 R2 上的 AD FS 迁移到 Windows Server 2016 上的 AD FS 已变得更加简单。 将新的 Windows Server 2016 服务器添加到 Windows Server 2012 R2 场，该场将按 Windows Server 2012 R2 场行为级别执行操作。 服务器现在的外观和行为就像 Windows Server 2012 R2 场一样。

然后，将新的 Windows Server 2016 服务器添加到场，验证该功能并从负载均衡器中删除旧服务器。 所有场节点都运行 Windows Server 2016 后，便可以将场行为级别升级到 2016，并开始使用新功能。

有关详细信息，请参阅升级到 Windows Server 2016 中的 AD FS。