AD FS 故障排除 – Microsoft Entra ID

项目
02/13/2024
适用于:

✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

随着云的发展，许多公司已开始将 Microsoft Entra ID 用于其各种应用和服务。与 Microsoft Entra ID 联合已成为许多组织的标准做法。本文档将介绍排查此联合出现的问题的某些方面。常规故障排除文档中的几个主题仍涉及与 Azure 的联合，因此本文档将仅重点介绍 Microsoft Entra ID 和 AD FS 交互的细节。

重定向到 AD FS

当你登录到 Office 365 等应用程序时，就会发生重定向，你会被“重定向”到 AD FS 服务器要登录的组织。

Redirection screen to AD FS

需要检查的首要事项

如果未发生重定向，需要检查以下事项

确保 Microsoft Entra 租户已启用联合身份验证，方法是登录到 Azure 门户并在 Microsoft Entra Connect 下进行检查。
单击 Azure 门户中联合身份验证旁边的域，确保自定义域得到验证。
最后，要检查 DNS，并确保 AD FS 服务器或 WAP 服务器正在从 Internet 进行解析。验证此问题是否已解决，以及你是否能够导航到它。
还可以使用 PowerShell cmdlet Get-MgDomain 获取此信息。

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

从 Azure 重定向时，可能会遇到“未知身份验证方法”错误，指出 AuthnContext 在 AD FS 或 STS 级别不受支持。

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

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

对于 WS 联合身份验证，使用 WAUTH 查询字符串强制使用首选身份验证方法。
对于 SAML2.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 管理单元中的“服务”和“身份验证方法”。

在“主要身份验证”部分，单击“编辑”。

在“编辑身份验证方法”窗口的“主要”选项卡上，可以将设置配置为身份验证策略的一部分。

Edit Authentication Methods window

AD FS 颁发的令牌

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

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

AD FS 在令牌中发出的声明应与 Microsoft Entra ID 中用户的相应属性相匹配。
Microsoft Entra ID 的令牌应包含以下必需的声明：
- WSFED：
  - UPN：此声明的值应与 Microsoft Entra ID 中用户的 UPN 相匹配。
  - ImmutableID：此声明的值应与 Microsoft Entra ID 中用户的 sourceAnchor 或 ImmutableID 相匹配。

若要获取 Microsoft Entra ID 中的用户属性值，请运行以下命令行：Get-AzureADUser –UserPrincipalName <UPN>

Screenshot of the PowerShell window showing the results of the Get-AzureADUser command.

SAML 2.0：
- IDPEmail：此声明的值应与 Microsoft Entra ID 中用户的用户主体名称相匹配。
- 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 的信赖方信任上配置的安全哈希算法设置为 SHA1

后续步骤

AD FS 疑难解答

通过