具有多个主机绑定的 IIS 上的 Windows 身份验证类型问题

Question

在 IIS 上使用 Duende SSO 部署单点登录 (SSO) 应用程序时，我遇到了 Windows 身份验证问题。该应用程序使用具有以下主题备用名称的 SSL 证书进行保护：

• 我的机器
• 我的机器.home

在 IIS 中，我为 SSO 配置了以下绑定：

• https://mymachine.home:5007
• https://mymachine:5007

问题： 当我向 https://mymachine.home:5007 发送身份验证请求时，方法 GetWindowsPrincipal() 返回“”（空字符串）的authenticationType，这会导致身份验证失败。

但是，当我将请求发送到 https://mymachine:5007 时，该方法返回authenticationType =“Negotiate”，并且身份验证过程使用 NTLM 按预期工作。

这是 GetWindowsPrincipal() 方法的代码：

Copy code
private WindowsPrincipal? GetWindowsPrincipal()
{
    NativeMethods.HttpGetAuthenticationInformation(_requestNativeHandle, out var authenticationType, out var token);

    if (token != IntPtr.Zero && authenticationType != null)
    {
        if ((authenticationType.Equals(NtlmString, StringComparison.OrdinalIgnoreCase)
            || authenticationType.Equals(NegotiateString, StringComparison.OrdinalIgnoreCase)
            || authenticationType.Equals(BasicString, StringComparison.OrdinalIgnoreCase)))
        {
            return new WindowsPrincipal(new WindowsIdentity(token, authenticationType));
        }
    }
    return null;
}

问题： 为什么在使用 https://mymachine.home:5007 绑定时，authenticationType 返回空字符串？如何解决此问题以确保身份验证适用于这两种绑定？

我已确保 SSL 证书配置正确，并且包含 mymachine 和 mymachine.home 作为主题备用名称。是否需要特定的 IIS 设置或其他配置来处理这种情况？

Answer 1

我找到了部署在 IIS 上时在 Duende IdentityServer SSO 中遇到的 NTLM 身份验证问题的解决方案。

问题回顾：

我遇到了一个问题，即通过 FQDN (

https://mymachine.home:5007

) 访问 SSO 应用程序时，

GetWindowsPrincipal()

方法返回空的 authenticationType。但是，当通过简单的主机名 (https://mymachine:5007) 访问时，它工作正常，返回

authenticationType

=“协商”并使用 NTLM 成功进行身份验证。

解决方案：

经过一番研究，我发现该问题与称为环回检查的 Windows 安全功能有关，该功能旨在防止在使用 FQDN 或 CNAME 别名本地访问服务器时对 NTLM 凭据进行反射攻击。

当我使用 FQDN 访问服务器时，环回检查阻止了 NTLM 身份验证请求，这就是

authenticationType

为空的原因。

为了解决此问题，我应用了以下解决方案：

修复步骤：

修改Windows注册表：

为了允许对 FQDN (mymachine.home) 进行 NTLM 身份验证，我将 FQDN 添加到 Windows 注册表中的

BackConnectionHostNames

列表中。

我是这样做的：

在“运行”对话框 (Win + R) 中键入 regedit 打开注册表编辑器。 导航至：

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

右键单击 MSV1_0，选择新建 > 多字符串值，并将其命名为

BackConnectionHostNames

。 双击

BackConnectionHostNames

并添加以下条目：

• 我的机器.home
• 我的机器

单击“确定”并关闭注册表编辑器。 重新启动服务器：

更改注册表后，我重新启动服务器以应用新设置。

说明：

当使用 FQDN (mymachine.home) 访问服务器时，环回检查会阻止 NTLM 身份验证，因为它将此类请求视为潜在的安全风险。通过将 FQDN 添加到

BackConnectionHostNames

，我能够绕过此限制，允许 NTLM 身份验证按预期进行。

现在，

GetWindowsPrincipal()

方法可以正确地将

authenticationType

识别为 mymachine.home 和 mymachine 的“协商”，解决了身份验证问题。

结论：

如果其他人在使用 FQDN 时遇到 NTLM 身份验证失败的类似问题，此解决方案应该有助于解决该问题。将 FQDN 添加到

BackConnectionHostNames

注册表项可确保环回检查不会阻止合法的 NTLM 身份验证请求。