AD FS 故障排除：Microsoft Entra ID

2025-05-02
适用于: ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

随着云的增长，许多公司开始将 Microsoft Entra ID 用于其各种应用和服务。与 Microsoft Entra ID 联合现在是许多组织的标准做法。本文介绍如何对该联合体中出现的问题进行故障排除的某些方面。常规故障排除文章中的几个主题仍与 Azure 联合，因此本文介绍了与 Microsoft Entra ID 和 Active Directory 联合身份验证服务（AD FS）交互的具体内容。

重定向到 AD FS

登录应用程序（如 Office 365）后，您会被重定向到所在组织的 AD FS 服务器以完成登录。

显示“重定向”窗格的屏幕截图。

要检查的第一件事

如果未发生重定向，则需要检查一些事项。

确保已为联合身份验证启用 Microsoft Entra 租户。登录到 Azure 门户，并在 “Microsoft Entra Connect”下进行检查。
确保已验证自定义域。在 Azure 门户中选择联盟旁边的域。
检查域名系统 (DNS) 并确保 AD FS 服务器或 Web 应用程序代理服务器正在从 Internet 解析。验证它们是否已解决，以及是否可以转到它们。

还可以使用 PowerShell cmdlet Get-MgDomain 获取此信息。

收到“未知身份验证方法”错误

从 Azure 重定向时，可能会遇到“未知身份验证方法”错误， AuthnContext 指出 AD FS 或安全令牌服务（STS）级别不支持此方法。

使用一个强制身份验证方法的参数导致 Microsoft Entra ID 重定向到 AD FS 或 STS 时，这种情况最为常见。

若要强制执行身份验证方法，请使用以下方法之一：

对于 WS-Federation，使用 WAUTH 查询字符串强制首选身份验证方法。
对于 SAML 2.0，请使用以下代码：
```
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
```
如果强制身份验证方法发送的值不正确，或者 AD FS 或 STS 上不支持该身份验证方法，则会在进行身份验证之前收到错误消息。

所需的身份验证方法	WAUTH URI
用户名和密码身份验证	`urn:oasis:names:tc:SAML:1.0:am:password`
安全套接字层（SSL）客户端身份验证	`urn:ietf:rfc:2246`
Windows 集成身份验证	`urn:federation:authentication:windows`

下表列出了支持的 SAML 身份验证上下文类：

身份验证方法	身份验证上下文类 URI
用户名和密码	`urn:oasis:names:tc:SAML:2.0:ac:classes:Password`
密码保护传输	`urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport`
传输层安全性 (TLS) 客户端	`urn:oasis:names:tc:SAML:2.0:ac:classes:TLSClient`
X.509 证书	`urn:oasis:names:tc:SAML:2.0:ac:classes:X509`
Windows 集成身份验证	`urn:federation:authentication:windows`
Kerberos	`urn:oasis:names:tc:SAML:2.0:ac:classes:Kerberos`

若要确保在 AD FS 级别支持身份验证方法，请检查以下事项。

AD FS 2.0

在 /adfs/ls/web.config下 ，确保存在身份验证类型的条目。

<microsoft.identityServer.web>
<localAuthenticationTypes>
<add name="Forms" page="FormsSignIn.aspx" />
<add name="Integrated" page="auth/integrated/" />
<add name="TlsClient" page="auth/sslclient/" />
<add name="Basic" page="auth/basic/" />
</localAuthenticationTypes>

AD FS 2012 R2

在“AD FS 管理”下，选择 AD FS 管理单元中的“身份验证策略”。
在 “主身份验证 ”部分的 “全局设置”旁边，选择“ 编辑”。还可以右键单击 “身份验证策略 ”，然后选择“ 编辑全局主身份验证”。或在 “动作” 窗格中，选择 “编辑全局主身份验证”。
在 “编辑全局身份验证策略 ”窗格的“ 主 ”选项卡上，可以将设置配置为全局身份验证策略的一部分。例如，对于主要身份验证，请在 Extranet 和 Intranet 下选择可用的身份验证方法。

确保选中所需身份验证方法的复选框。

AD FS 2016

在 AD FS 管理下，选择 AD FS 管理单元中的服务>身份验证方法。
在 “主身份验证 ”部分中，选择“ 编辑”。
在 “编辑身份验证方法 ”窗格的“ 主要 ”选项卡上，可以将设置配置为身份验证策略的一部分。

AD FS 颁发的令牌

本部分讨论 AD FS 颁发的令牌。

Microsoft Entra ID 在令牌颁发后引发错误

AD FS 颁发令牌后，Microsoft Entra ID 可能会引发错误。在这种情况下，检查以下问题：

令牌中 AD FS 问题的声明应与 Microsoft Entra ID 中用户相应的属性相匹配。
Microsoft Entra ID 的令牌应包含以下必需的声明：
- WSFED：
  - UPN：此声明的值应与Microsoft Entra ID 中的用户主体名称（UPN）匹配。
  - ImmutableID：此声明的值应与 Microsoft Entra ID 中用户的 sourceAnchor 或 ImmutableID 属性匹配。
  若要获取 User Microsoft Entra ID 中的属性值，请运行以下命令行： Get-AzureADUser –UserPrincipalName <UPN>
- SAML 2.0：
  - IDPEmail：此声明的值应与Microsoft Entra ID 中的用户的 UPN 匹配。
  - NAMEID：此声明的值应与 Microsoft Entra ID 中用户的sourceAnchor或ImmutableID属性匹配。

有关详细信息，请参阅使用 SAML 2.0 标识提供者实现单一登录。

AD FS 与 Microsoft Entra ID 之间的令牌签名证书不匹配

AD FS 使用令牌签名证书对发送给用户或应用程序的令牌进行签名。 AD FS 与 Microsoft Entra ID 之间的信任是基于此令牌签名证书的联合信任。

如果 AD FS 端的令牌签名证书因自动证书滚动更新或某些干预而更改，则必须在联合域的Microsoft Entra ID 端更新新证书的详细信息。当 AD FS 上的主令牌签名证书不同于 Microsoft Entra ID 时，Microsoft Entra ID 不信任 AD FS 颁发的令牌。因此，不允许联合用户登录。

若要解决此问题，请按照 Office 365 和 Microsoft Entra ID 续订联合证书中的步骤作。

要检查的其他常见事项

如果 AD FS 和 Microsoft Entra 交互出现问题，请检查：

Windows 凭据管理器中过时或缓存的凭据。
在 Office 365 的信赖方信任上配置的安全哈希算法（SHA）设置为 SHA1。

AD FS 故障排除

通过