Windows 7 NTLM Pre-Auth Problem with SPNEGO

I'm using SPNEGO to authenticate via KERBEROS with our Active Directory. This works great with Windows XP but when we upgraded to Windows 7, we could no longer log-in to our applications. We found that Microsoft is adding an NTLM pre-auth which is messing up our sign-in. We added a registry key to disable this pre-auth under IE8 and all works well. Microsoft supplied the registry entry to disable the pre-auth but said they don't recommend keeping it that way. We don't want to add this registry key to every user if it can be helped. Has anyone else run into this issue? Thanks

Here's what Microsoft had to say:

"Hello:

Per our discussion, the following question is to be answered:

Questions :

Microsoft suggested we disable the NTLMPreAuth in registry, we would like know to the impact of disabling the DisableNTLMPreAuth ?

What will be issues, if the DisableNTLMPreAuth is set to 1 ?
DisableNTLMPreAuth is a change in the way internet explorer handles authentication with a web server in the http authentication header. It should not have any effect on Kerberos authentication to a web site nor authentication in Windows as a whole. The following is information on DisableNTLMPreAuth:

More details about the DisableNTLMPreAuth.
NTLM Pre-Authentication is used for when NTLM authentication is required for a
website. Once the client has been authenticated for a connection, no further
challenges are made until a new connection is opened. However, there are times
when this "convenience" can cause some problems. For example, KB 231453 talks
about Posting data on an ASP page. When IE is POSTing data and NTLM authentication
is required, the initial POST is sent because the client is expecting to be
challenged - this was set up for performace reasons. However, since the connection
has already been authenticated, the server responds with a 200 instead of a 401 and
the data is NOT posted to the server. Disabling the Pre-Authentication forces the
challenge, so the client and server behavior is in sync.

When NTLM Pre-Authentication is used by IE, the above negotiation will still occur for the first request but in subsequent connections to the same web server for that instance of Iexplore.exe IE will include in the initial request the NTLM hash, effectively “pre authenticating” before it is challenged”. Disabling NTLMPreAuth will not expose a vulnerability, it simply prevents IE from ever performing the NTLM pre-auth, effectively forcing IE to the behavior of the initial connection for all new ports.

Now, in your environment we do not see pre-auth occurring so there is 0 net change. All your requests on new ports will still go through the negotiation. The net change of disabling NTLM pre auth for you is the change in timing in the wininet code that prevents the failure, or prompt, you were seeing.


Internet Explorer 5.0 has added a feature called NTLM pre-authorization. When an Internet Explorer 5.0 browser connects to an IIS 4.0 Web site that uses NTLM security, Internet Explorer 5.0 negotiates security. If an NTLM challenge is received, these credentials are used for any subsequent request for that Web site. In this case, when an Internet Explorer 5.0 browser connects, it receives an NTLM challenge, but when a sub folder on the same Web site does not use NTLM, no challenge is received by Internet Explorer 5.0, which causes the browser to not send the POST data to the server



The registry key should be a viable solution but if you are looking for an alternative solution then this would need to be worked out between internet explorer and Tomcat as Tomcat would need to indicate why it’s rejecting the authentication header. "