SPNEGO NTLM / Kerberos over HTTP (aka RFC4559) confusion

[Michael B Allen]

On 3/17/08, john at feith.com <john at feith.com> wrote:
> 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?

Hi John,

The problem is that the client will not or cannot initiate Kerberos.
There could be many reasons for this:

1) The client cannot obtain a Kerberos ticket for the desired service.
There can be many reasons for this too:

1a) If a MS client is not "joined" to a domain it cannot participate
in Kebreros authentication and thus the client has no choice but to
fall-back to using NTLM.

1b) A temporary network failure has prevented the client from
acquiring the necessary ticket and thus the client has no choice but
to fall-back to using NTLM.

1c) The XP credential cache bug [1] is preventing the client from
renewing tickets causing the client to fall-back to NTLM.

2) The browser must be configured to trust the target server. In IE
you must add the target server or it's domain under Tools > Internet
Options > Security > IntrAnet Zone.

3) In some browsers automatic authentication must be enabled. For
example, in IE you must turn on Tools > Internet Options > Advanced >
Enabled Integrated Windows Authentication.

4) The user entered and saved credentials into a Network Password
Dialog which preempts the client to initiate NTLM rather than
Kerberos.

5) There is a problem with the service principal name on the service
account preventing the client from initiating Kerbeors authentication
and thus the client has no choice but to fall-back to using NTLM.

I recommend using wfetch.exe (available on MS's website) to narrow
down where the problem is. You can also look at our product manual at
http://www.ioplex.com/support.html. In particular see "Issue 3" and
"Issue 5" in the "Possible Issues" section. That document details all
of the conditions described here and much more. Even though our code
is completely different from what you're using the condition is the
same (described as the "GSS_S_BAD_MECH" error in our document).

Mike

PS: Also note that the HTTP service account must be set to permit
delegation. Otherwise, even if you get the client to do Kerberos you
won't get the delegated ticket necessary to impersonate the user when
initiating auth with the next tier.

[1] http://support.microsoft.com/kb/885887
    http://support.microsoft.com/kb/906524/en-us

-- 
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/