SPNEGO NTLM / Kerberos over HTTP (aka RFC4559) confusion

john@feith.com john at feith.com
Mon Mar 17 19:31:03 EDT 2008


Feel free to point me to the right group if I'm in the wrong place,
I wasn't quite sure of the best group for a HTTP protocol question.

We have a web application which needs to log into a backend data
service as the user who accessed our application.  Now the standards
compliant way to accomplish this would seem to be to return a 401
WWW-Authenticate: Negotiate which should result in the browser using
SPNEGO to send the server a list of the supported authentication
mechanisms along with the optimistic mechanism token (as per RFC4559
and RFC4178).  As long as one of the listed mechanisms is Kerberos
we should be able to use SPNEGO to get the Kerberos token which will
allow us to log into our data service.

This appears to work for the most part (tested with Firefox and IE),
however in some cases our server receives a NTLM token instead of a
SPNEGO in response to the 401.  This problem occurs with both Firefox
and IE.  A packet trace shows Negotiate was the only WWW-Authenticate
header we supplied when we responded.  The configuration is correct
and Kerberos credentials are available.  Microsoft has looked into
the issue and has stated that the Microsoft SSPI correctly implements
RFC4559.  Specifically they've stated that in some cases the SSPI will
return a NTLM token instead of a SPNEGO token causing the browser to
return Authorization: Negotiate with a non-SPNEGO token and that this
behavior complies with RFC4559.

Now my understanding of RFC4559 is that SPNEGO must always be used by
the client when responding.  The NTLM is allowed to be * inside * of
the
SPNEGO.

Anyone care to clear up the confusion, or suggest how to go about
resolving
the issue?

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email:
john at feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495
|                         |
-------------------------------------------------------------------------



More information about the Kerberos mailing list