问题
I have problems with a single user in an intranet application. The client side is a WPF application which communicates with a ASP.Net Web API Web Service.
The client sends HTTPS GET and POST requests using
HttpClientHandler handler = new HttpClientHandler()
{
AutomaticDecompression = DecompressionMethods.Deflate | DecompressionMethods.GZip,
UseDefaultCredentials = true,
PreAuthenticate = true
};
On IIS Windows authentication is enabled with NTLM and Negotiate providers.
The system works for all users except one that gets 401.1 but only from POST requests.
I'm currenty trying to figure out what's different with this user. The only thing I noticed is a different kind of authorization header.
From here (and many other resources) I read:
If the header starts with a "T" (example: HTTP: Authorization = Negotiate TlRMTVNTU...) then you're using NTLM. If it starts with a "Y" (example: Authorization: Negotiate YIILjgYGKwYB...) then you're successfully using Kerberos.
I can see headers for working requests that seems to use Kerberos:
Authorization: Negotiate YIIT4QYGKwYBBQUCoIIT1TCC...
The header which is sent from the user which fails to POST looks like
Authorization: Negotiate oYICOTCCAjWgAwoBAaKCAhg...
It starts with o. So is this NTLM or Kerberos? The authentication fails for POST request, but succeeds on GET!
回答1:
Given the presence of "Negotiate " both requests seem to be attempts to use the Spnego Negotiation Mechanism. While Spnego is often used in conjunction with Kerberos, the two should not be confused.
Authorization: Negotiate oY....
...is a Spnego NegTokenResp (NegTokenTarg in Microsoft documents).
This may contain a Kerberos Token, NTLM, or any other negotiatable sub-mechanism supported by the Spnego Protocol (or by the specific Spnego implementation used). So this may be Kerberos, NTLM, or something else again.
"oY" decodes to HexByte "a1", as do "oQ" to "oZ", so any of these could indicate a NegTokenResp.
Authorization: Negotiate YI....
...is a Kerberos token (which may have a Kerberos or a Spnego OID).
It can either be sent "direct", or wrapped in a Spnego Token (e.g. the NegTokenResp above).
回答2:
Why don't you use Wireshark for that?
Wireshark will inspect all traffic. I will break down the ticket from ASN.1 to a displayable tree structure. You'll see what mechanism is used in your case. Additionally, you'll see all the Kerberos traffic, e.g., your TGS-REQ.
来源：https://stackoverflow.com/questions/24454777/windows-authentication-kerberos-or-ntlm-negotiate-oyico