Question

我在Intranet应用程序中遇到单个用户的问题。客户端是WPF应用程序，它与ASP.Net Web API Web服务进行通信。

客户端使用

发送HTTPS GET和POST请求

HttpClientHandler handler = new HttpClientHandler()
{
  AutomaticDecompression = DecompressionMethods.Deflate | DecompressionMethods.GZip,
  UseDefaultCredentials = true,
  PreAuthenticate = true
};

在IIS上，使用NTLM和协商提供程序启用Windows身份验证。

该系统适用于所有用户，除了获得401.1但仅来自POST请求的用户。

我目前正试图弄清楚这个用户有什么不同。我注意到的唯一一种是不同类型的授权标题。

从here（以及许多其他资源）我读到：

如果标题以“T”开头（例如：HTTP：Authorization = Negotiate TlRMTVNTU ...），那么您正在使用NTLM。 如果它以“Y”开头（例如：授权：协商YIILjgYGKwYB ...）那么您就成功使用了Kerberos。

我可以看到似乎使用Kerberos的工作请求的标头：

Authorization: Negotiate YIIT4QYGKwYBBQUCoIIT1TCC...

从无法POST的用户发送的标题看起来像

Authorization: Negotiate oYICOTCCAjWgAwoBAaKCAhg...

以o开头。 这是NTLM还是Kerberos？ POST请求的身份验证失败，但GET成功了！

Answer 1

为什么不使用Wireshark呢？

Wireshark将检查所有流量。我将从ASN.1分解为可显示的树结构。您将看到您的案例中使用了什么机制。此外，您还会看到所有Kerberos流量，例如您的TGS-REQ。

Answer 2

鉴于“协商”的存在，两个请求似乎都是使用Spnego协商机制的尝试。尽管Spnego通常与Kerberos结合使用，但不要混淆两者。

授权：正在协商...。

...是Spnego NegTokenResp（Microsoft文档中的NegTokenTarg）。

这可能包含Kerberos令牌，NTLM或Spnego协议（或所使用的特定Spnego实现）支持的任何其他可协商子机制。因此，这可能是Kerberos，NTLM或其他。

“ oY”解码为十六进制字节“ a1”，“ oQ”解码为“ oZ”，因此任何一个都可能表示NegTokenResp。

授权：协商YI。...

...是Kerberos令牌（可以具有Kerberos或Spnego OID）。

它可以“直接”发送，也可以包装在Spnego令牌中（例如上面的NegTokenResp）。

Windows身份验证 - Kerberos或NTLM（协商oYICO ...）

2 个答案: