Intermittent auth failures with IE7 using Negotiate

Sep 28, 2011 at 9:44 AM

Hi,

I'm using WAFFLE 1.4 with the Spring Security Negotiate Filter. We're running within JBoss AS 6.0. I've been through the process of creating a SPN and configuring IE for IWA and all seems well on our local test network.

We've moved the application to our staging area and are intermittently getting authentication popups in IE7 (and windows audit log auth failures in the event viewer).

Here is the log of a failed login:

2011-09-28 16:10:51,680 INFO  waffle.spring.NegotiateSecurityFilter  - POST /somelongurl, contentlength: 0
2011-09-28 16:10:51,680 INFO  waffle.servlet.spi.NegotiateSecurityFilterProvider  - security package: Negotiate, connection id: 10.223.15.11:1415
2011-09-28 16:10:51,680 INFO  waffle.servlet.spi.NegotiateSecurityFilterProvider  - token buffer: 40 byte(s)
2011-09-28 16:10:51,696 INFO  waffle.servlet.spi.NegotiateSecurityFilterProvider  - continue token: TlRMTVNTUAACAAAACgAKADgAAAAFgomizNC0QVVdNhoAAAAAAAAAAMAAwABCAAAABgBxFwAAAA9GAE8AQwBJAFMAAgAKAEYATwBDAEkAUwABABgAUwBZAFMALQBEAEEAQwAtAFMAUgBWADEABAAgAGYAbwBjAGkAcwAuAG4AcwB3AC4AZwBvAHYALgBhAHUAAwA6AFMAWQBTAC0ARABBAEMALQBTAFIAVgAxAC4AZgBvAGMAaQBzAC4AbgBzAHcALgBnAG8AdgAuAGEAdQAFACAAZgBvAGMAaQBzAC4AbgBzbf1ALgBnAG8AdgAuAGEAdQAHAAgAqKzIX6V9zAEAAAAA
2011-09-28 16:10:51,696 INFO  waffle.servlet.spi.NegotiateSecurityFilterProvider  - continue required: true
2011-09-28 16:10:51,790 INFO  waffle.spring.NegotiateSecurityFilter  - POST /focis-hmi-1.0.10/focis.client.gwtui.Focis/focis.client.gwtui.client.services.alerts.AlertsService, contentlength: 188
2011-09-28 16:10:51,790 INFO  waffle.servlet.spi.NegotiateSecurityFilterProvider  - security package: Negotiate, connection id: 10.223.15.11:1422
2011-09-28 16:10:51,790 INFO  waffle.servlet.spi.NegotiateSecurityFilterProvider  - token buffer: 178 byte(s)
2011-09-28 16:10:51,790 WARN  waffle.spring.NegotiateSecurityFilter  - error logging in user: The token supplied to the function is invalid

Looking at the log it appears the IE has dropped and recreated the TCP connection in the middle of authenticating and this is causing a failure.

The interesting thing is that on our local test network (which is rock solid) there are no "continue required: true" logs. Every time it is simply "continue required: false" and the user is logged in successfully. Do you have any idea what the difference in setup could be that would cause this?

Cheers,
Alex

Oct 3, 2011 at 12:37 AM

This has been solved. Negotiate was falling back to NTLM instead of Kerberos because the people configuring the network has set multiple SPNs for the same service. After tracking down and removing the extra SPNs Kerberos is working again and we no longer have the intermittent failures.

One thing I do wonder about is why Internet Explorer fails after a while with NTLM (due to the TCP connection being recreated). Is there a missing header that perhaps IIS sets that forces Internet Explorer to be a little bit smarter?

Coordinator
Oct 5, 2011 at 1:11 PM

NTLM is per connection, but it should just renegotiate without any issues. I would say something else is going on there.

Coordinator
Oct 5, 2011 at 1:12 PM

Btw, it would be amazing if you posted how to configure JBoss with Waffle (or maybe even a doc patch? :)).

Oct 6, 2011 at 4:34 AM

We're only using JBoss as the web container - the Spring Security Negotiate Filter is used in it's standard configuration.

Looking at http://waffle.codeplex.com/discussions/244329?ProjectName=waffle it seems there is a problem when the TCP connection is dropped in the middle of the negotiation. Looking at the Tomcat docs (as JBoss uses Tomcat for it's web container) gives the following configuration item:

maxKeepAliveRequests

The maximum number of HTTP requests which can be pipelined until the connection is closed by the server. Setting this attribute to 1 will disable HTTP/1.0 keep-alive, as well as HTTP/1.1 keep-alive and pipelining. Setting this to -1 will allow an unlimited amount of pipelined or keep-alive HTTP requests. If not specified, this attribute is set to 100.

I'm just guessing at the moment but I'm thinking that the TCP connection is hitting the 100 keep-alives (our web app periodically requests information from the server) and is being dropped. At this point I guess a browser would detect this and re-negotiate - I wouldn't be suprised if IE7 fails to do this. Again, just a guess but it might help someone stumbling across this. I'll look into a bit more if I have time and provide an update.