On 3/17/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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/ ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
