I'm guessing that your workflow / product / code requires Kerberos (in the absence of a good open source NTLM story), and you're trying to figure out how to get SPNEGO wrapped kerberos tokens all of the time?
Its also extremely difficult to *always* get kerberos authentication (wrapped or unwrapped). For example, if the target HTTP server is in another forest, then chances are the client will end up using NTLM due to SPN location issues. Also, some IE policies will not even allow a kerberos or NTLM authentication over the HTTP transport to various zones. My reading of the RFC is that it is truly "informational," describing how clients and servers use SPNEGO + HTTP, but not specifying every possible HTTP auth scheme. Chances are the answer you got about raw NTLM being "OK" was passed through various layers of Microsoft from Larry Zhu, the author of the RFC itself, and based on not on "correctness" but rather on the behavior of millions of deployed clients and servers. Even if you could get MS to change the behavior to your interpretation of the RFC, its not going to help much until every machine out there is updated. Todd On Mar 18, 2008, at 8:14 AM, Michael B Allen wrote: > On 3/18/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> On Mar 18, 12:59 am, "Michael B Allen" <[EMAIL PROTECTED]> wrote: >>> 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. >> >> >> Yep ... that's pretty much how I understand things. In our case we >> are >> only returning "WWW-Authenticate: Negotiate". >> >> >>> Otherwise, you need to explain the point of failure in more detail. >> >> >> The IE client is responding to "WWW-Authenticate: Negotiate" with >> a raw NTLM instead of SPNEGO. > > Well I just looked at some of my captures and I can see that raw > NTLMSSP tokens can be sent in response to "WWW-Authenticate: > Negotiate". And I now recall that raw Kerberos tokens can be used as > well. > >>> If you're not sure then provide an HTTP client / server call >>> sequence >> >> >> We're sure ... it's all been check / doubled checked using pack >> sniffers, > > Well I'm glad you're sure but I'm not clear on what the point of > failure is so if you want my input you'll have to explain the exact > exchange. If you're seeing an XP client send a raw NTLM token in > response to sending it "WWW-Authenticate: Negotiate" then I refer you > to my original response. > >> etc. Microsoft has also confirmed it and looked at their code. They >> say that it's intentional to return a raw NTLM instead of SPNEGO >> regardless of the availability of Kerberos in some situations when >> responding to "WWW-Authenticate: Negotiate". >> >>> the point of failure. >> >> The real problem is that Microsoft admits that this is intentionally >> and claims that it is RFC4559 compliant. I'm having great difficulty >> in getting them to understand that RFC4559 * requires * that SPNEGO >> be used. I'm open to suggestions. > >> From glancing at RFC 4559 it indeed does not seem to include any > mention that raw NTLM and Kerberos tokens are accepted. But I learned > a long time ago that RFCs are not the law. What you see on the wire is > the law. > > 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 > ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
