当我配置 Kerberos 委派时，我对 IIS 10 中的 Windows 身份验证的理解存在差距。
对于访问 Web 服务器（IIS，启用了 Windows 身份验证）且无需担心委派场景或自定义 SPN 的客户端，我对 Kerberos 身份验证的解释如下：
客户端向 KDC 请求 TGT（和会话密钥）。
收到 TGT 后，客户端使用它向 TGS 请求与 Web 服务器主机名匹配的 SPN 的服务票证。(HTTP/name.company.com)。
客户端基础 64 对服务票据进行编码，并将其作为 WWW 身份验证标头插入到发送到 Web 服务器进行身份验证的请求中。Web 服务器可以对其进行解密以验证客户端的身份。
这些服务器故障帖子（MSSQLSvc 服务主体名称、Kerberos 和 NTLM） 和这个 （为什么在 IIS 中使用 Kerberos 而不是 NTLM？) 似乎意味着如果 TGS 在步骤 2 中未找到 SPN，则客户端将回退到使用 NTLM 协议而不是 kerberos 来向 IIS Web 服务器进行身份验证。
我的问题：
我似乎对在我描述的这个场景中是使用 Kerberos 进行身份验证还是使用 NTLM 感到困惑 - 我一直认为 IIS 开箱即用地使用 kerberos 进行 Windows 身份验证。
来自步骤 2 的服务票证 - 我认为服务票证仍会被发回，尽管它不包含 SPN？
答案1
如果 IIS 配置为协商身份验证，它将首先尝试 Kerberos，前提是客户端发送 Kerberos 令牌。IIS 服务器对初始请求（通常为 401）的响应将包含标头“WWW-Authenticate: Negotiate”，又名“向我发送 Kerberos 令牌”。
如果 Kerberos 身份验证失败，则 IIS 可以配置为回退到 NTLM，前提是客户端发送 NTLM 令牌。（数据的第一个字符是字符“T”）。
回退到 NTLM 是一个相互的概念，可以在客户端和服务器上启用、禁用和配置，并且适用于与 Windows 主机通信时使用的大多数协议和技术，例如 SMB 和 RPC。
协商的语义可能很微妙且依赖于实现。例如，Kestrel 在解码后的 WWW-Authenticate 标头响应负载前加上NTLM或前缀HTTP，这表示 Kerberos。
请注意，回退仅适用于访问 IIS 服务器本地的资源。对于模拟用户访问其他资源（如数据库或 Web 服务）的应用程序，必须使用 Kerberos。这通常是更常见的情况，IIS 服务器只是一个应用服务器，它负责处理访问另一个远程资源的请求。
在此上下文中，“失败”并不一定意味着任何失败。特定失败可能有特定的异常处理程序。此功能旨在解决的典型“失败”是令牌大小限制。Windows Active Directory 用户可能是许多组的成员，这些组包含在 Windows Kerberos 实现上的令牌的特权属性证书 (PAC) 中，该证书作为响应的 WWW-Authenticate 标头插入。如果它大于 IIS 允许的大小，它将失败。NTLM 令牌要小得多，通常小于 1kb，并且 NTLM 可以正常工作。
解决此问题的最佳方法可能是使用 Fiddler/Wireshark 并检查数据包头。
https://www.crowdstrike.com/cybersecurity-101/ntlm-windows-new-technology-lan-manager/
https://specopssoft.com/blog/configuring-chrome-and-firefox-for-windows-integrated-authentication/
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Authorization