Aug 10, 2009 at 8:06 AM
Edited Feb 26, 2010 at 5:53 PM
If you use SPnego with Kerberos, there is only one round between the navigator and tomcat. Alice sends a ticket and an authenticator, Tomcat sends back an authenticator. But with NTLM, there are two rounds. The server sends a nonce and Alice must send
a response with this nonce.
It is important to know that.
If you use IE, not Firefox, and you have been authenticated on the Uri http://myserver.test.net/application/first/second/index.jsp, IE suppose that the Uris under second must probably be also authenticated. A query with the verb POST will change the
server. So, for security, with the verb POST (not GET), IE sends a header Authorization Negotiate.
If IE use Kerberos, it knows that it can send the content of the query with the header Authorization. The server will respond to the query and send the authenticator simultaneously.
But, with NTLM, IE knows that the server do not read the content if it authenticates Alice. So, it sends a header Content-size equal to 0. The version 100809 has no problem with this behavior.
Jul 18, 2013 at 12:21 PM
Edited Jul 18, 2013 at 2:32 PM
We are using tomcatspnego and we are very pleased with it, except the IE POST problem. We are using a version that was realesed after 100809 (it is 211121010).
Sometimes we are seeing empty POST messages, and as we read in some forums, we are sending back UNAUTHORIZED error code like this:
HttpServletResponse httpResponse = (HttpServletResponse) servletResponse;
Type1Message type1 = new Type1Message(src);
/* respond with a type 2 message */
Type2Message type2 = new Type2Message(type1, new byte, null);
String reply = Base64.encodeBytes(type2.toByteArray());
String responseWWWAuthenticate = ntlmTitle + " " + reply;
But it does not work either, IE displays an error page. The only resolution that worked for us is to set DisableNTLMPreAuth on the client machines:
but it is quite embarassing.
Could you help to resolve the issue on the server side? Microsoft's server side resolution is to disable Kernel Mode Authentication in IIS, but that I really do not understand because I thought this problem is related to NTLM, and Kernel Mode Authentication
is Kerberos. How comes that?!
Can you confirm that his problem comes up only if NTLM is used? Then we can force Kerberos by setting up all of the requirements, and the problem should be eliminated?
If nothing else works, and you could provide a fix or any workaround on the server side, my company would be very thankful and they would Donate / pay for it.
I realized that disabling "Kernel Mode Authentication" actually disables NTLM and Kerberos too, so no question why that is a "good" workaround :)