Preauthentication for Negotiate

[jzarling]

I'm wondering why the SocketsHttpHandler does not support preauthentication for the Negotiate protocol. I do not have deeper knowledge about the Kerberos implementation and therefore have no idea of how extensive it would be to support this feature.

I base my statement of it being unsupported on the comment in the AuthenticationHelper.cs:

...
// If preauth is enabled and this isn't proxy auth, try to get a basic credential from the
// preauth credentials cache, and if successful, set an auth header for it onto the request.
// Currently we only support preauth for Basic.
bool performedBasicPreauth = false;
if(preAuthenticate)
{ ...

Information about our setup:

• The client application is running on Linux
• The client application is joined to the domain via a keytab-file
• The client application can succesfully authenticate

So, everything is working, but certain gateway policies prohibits us from calling consecutive unauthenticated calls, which is why the preauthentication is needed. It also seems to be an uneccesary use of network capacity and server resources to perform the challenge on every HTTP-call, but there might be something I'm missing.

[davidsh]

So, everything is working, but certain gateway policies prohibits us from calling consecutive unauthenticated calls, which is why the preauthentication is needed. It also seems to be an unnecessary use of network capacity and server resources to perform the challenge on every HTTP-call, but there might be something I'm missing.

Preauthentication for Negotiate/Kerberos/NTLM schemes isn't strictly needed. Those schemes require connection affinity. Once a request on a connection has done the multi-legged challenge/response of these schemes, the connection is authenticated. Additional HTTP requests to that endpoint using the same connection will not be challenged for additional authentication despite not having any 'Authorization:' headers on those additional requests.

[jzarling]

Okay, I will investigate further on my part then and close the issue since it does not seem to have anything to do with the behavior of the HttpClientHandler. Thank you for the enlightenment.