On Mar 18, 3:15 pm, "Michael B Allen" <[EMAIL PROTECTED]> wrote: > I would hope that they do NOT change the existing behavior. I consider > accepting "raw" NTLM and Kerberos tokens to be a feature.
I have no problems with them * accepting * "raw" NTLM and Kerberos tokens. I am merely talking about them * sending * "raw" tokens when RFC4559 calls for SPNEGO. > Note that accepting raw tokens is not terribly hard considering SPNEGO > is largely a wrapper for the raw tokens. Agreed and if I was getting a raw Kerberos token I'd probably just deal. However handling a NTLM token in place of a Kerberos token is a little more complicated. In our situation the Microsoft SSPI has decided that since there are NTLM credentials available due to an interactive logon to the same machine that happens to run our application it's going to send the NTLM credentials instead of using the Kerberos credentials which are also available. This is due to special case code in the SSPI which prefers NTLM over Kerberos in this situation. Now if they actually implemented SPNEGO as required by the RFC we would be able to respond with accept_incomplete and request that the Kerberos token be used. -- John [EMAIL PROTECTED] ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
