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

  • 项目

Windows Server 2019 的 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 (PSH) - 客户现在可以使用智能卡通过 PSH 远程连接到 AD FS，并使用它来管理所有 PSH 功能，包括多节点 PSH 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 支持此参数。

登录 SSO 改进

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 标头 - 客户现在可以生成单页应用程序，其允许客户端 JS 库通过从 AD FS 上的 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 相同，需要新场行为级别版本才能启用上述新功能。 这允许进行以下升级：
    • 2012 R2-> 2019
    • 2016 -> 2019

SAML 更新

AD FS 2019 中包含以下 SAML 更新：

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

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

之前，AD FS 要求所需的资源和范围在任何身份验证请求中都位于单独参数中。 例如，典型的 OAuth 请求如下所示：7 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 授权和访问令牌请求添加其他参数。

Proofkey

A. 客户端创建并记录名为“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 版中，客户现在可以使用声明规则来决定要为附加身份验证调用的附加身份验证提供程序。 这对于以下两种情况很有用：

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

客户需要为某些应用程序提供特定的附加身份验证提供程序（例如证书），而为其他应用程序提供不同的方法 (AzureMFA)。

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

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

从一个附加身份验证提供程序转移到另一个身份验证提供程序：我们将修改上述规则，为 SID S-1-5-21-608905689-872870963-3921916988-12345 组（例如，由跟踪已注册 AzureMFA 的用户的企业管理的组）中的用户选择 AzureMFA，而对于其余用户，管理员需要使用证书身份验证。

'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 MFA 作为附加身份验证提供程序：

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- 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 来触发特定的附加身份验证提供程序。

FAQ

注意

可能会在 AD FS 管理事件日志中遇到此错误：收到的 Oauth 请求无效。 禁止客户端 'NAME' 访问作用域为 'ugs' 的资源。 若要修正此错误，请执行以下操作：

  1. 启动 AD FS 管理控制台。 浏览到“服务 > 范围说明”
  2. 右键单击“作用域说明”，选择“添加作用域说明”
  3. 在名称下键入“ugs”，然后单击“应用”>“确定”
  4. 以管理员身份启动 PowerShell
  5. 执行“Get-AdfsApplicationPermission”命令。 查找 ScopeNames :{openid, aza}，其中包含 ClientRoleIdentifier。 记下 ObjectIdentifier。
  6. 执行“Set-AdfsApplicationPermission -TargetIdentifier <步骤 5 中的 ObjectIdentifier> -AddScope 'ugs'”命令
  7. 重启 AD FS 服务。
  8. 在客户端上执行以下操作：重启客户端。 系统会提示用户预配 WHFB。
  9. 如果未弹出预配窗口，则需收集 NGC 跟踪日志并进行进一步的故障排除。

Q. 是否可以像在 Azure AD 中完成请求那样将资源值作为作用域值的一部分进行传递？
答：借助 Server 2019 上的 AD FS，你现在可以传递嵌入到 scope 参数中的资源值。 现在可以将 scope 参数组织成一个用空格分隔的列表，其中每个条目的结构都作为资源/范围。 例如 <创建有效的示例请求>

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

Active Directory 联合身份验证服务跨多种应用程序（包括 Office 365、基于云的 SaaS 应用程序以及企业网络上的应用程序）提供访问控制和单一登录。

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

本文介绍 Windows Server 2016 (AD FS 2016) 中 AD FS 的新增功能。

消除 Extranet 中的密码

AD FS 2016 支持三个新的无密码登录选项，使组织能够避免因网络钓鱼、密码泄露或被盗而遭受网络危害的风险。

使用 Azure 多重身份验证登录

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

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

有关 Azure MFA 与 AD FS 的详细信息，请参阅：

符合设备的无密码访问

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

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

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

新增功能

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

有关将基于设备的条件访问与 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 企业版，请参阅：

安全访问应用程序

新式身份验证

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) 中的用户

有关详细信息，请参阅配置 AD FS 以对存储在 LDAP 目录中的用户进行身份验证。

更好的登录体验

自定义 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 审核事件默认处于关闭状态。 随着 AD FS 2016 的发布，审核变得更加精简且不那么冗长。

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

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

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

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

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

你可以将 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。