On 3/17/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Mar 17, 9:12 pm, "Michael B Allen" <[EMAIL PROTECTED]> wrote: > > The problem is that the client will not or cannot initiate Kerberos. > > > Nice try, however no. The client has no problems using Kerberos. > There are credentials in the cache for user. There's no problem > fetching credentials for the webserver. The problem has specifically > been traced by Microsoft to a bit of code in the Negotiate SSPI > which causes a raw NTLM to be returned instead of a SPNEGO > in some situations even though Kerberos is available / working.
If the HTTP server returns "WWW-Authenticate: NTLM" then the client must use NTLMSSP tokens. If it returns "WWW-Authenticate: Negotiate" then the tokens must be SPNEGO. If it returns both, then the client can pick. Otherwise, you need to explain the point of failure in more detail. Is it gss_accept_sec_context that is returning a token you didn't expect, or InitializeSecurityContext, or what? If you're not sure then provide an HTTP client / server call sequence w/ headers that illustrates the point of failure. Mike -- Michael B Allen PHP Active Directory SPNEGO SSO http://www.ioplex.com/ ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
