Authentication behind F5 LineRate issue.

Hello Elio,

 

How many Real Servers do you have configured in the Virtual Server you are testing? If there are multiple, one thing that comes to mind for the issue you are experiencing is persistence. If persistence is not enabled, you may be successfully authenticating to one server, and then your next request is routed to a different server which has not yet been authenticated.

 

You can read more about the Persistence options available for your Virtual Server on LineRate here: https://docs.lineratesystems.com/087Release_2.6.1/200CLI_Reference_Guide/Configure_Commands/Virtual_Server_Mode_Commandspersist

 

To look into what Real Server your requests are getting sent to and how persistence might be enabled, take a look at the results of some of the following commands:

 

• show real-server < rs_name > (To view request counts handled by a given RS)
• show virtual-server < vs_name > statistics detailed (To show overall requests coming into the Virtual Server, and other persistence data if that is enabled)

-Andrew

 

It is possible you are running in to an issue with NTLM authentication over HTTP (see http://www.innovation.ch/personal/ronald/ntlm.html for a good write-up on the subject). If this is the case, and your authentication mechanism is using NTLM over HTTP (which the default for some Microsoft web technologies) then you may have some challenges avoiding the re-authentication steps whenever the real-server connection is closed. As Andrew mentioned, persistence is necessary to make NTLM over HTTP work correctly, but preventing the connection from closing on the real-server side is the key to avoiding constant re-connection attempts. So double-check what the "WWW-Authenticate" header in the initial response looks like (using Chrome developer tools or similar) and if it is indeed of type NTLM then we can discuss how one might work around this with LineRate. Cheers, -johnny

Hi Johnny, Thanks for your input. I was able to confirm the two methods used by the app servers ( IIS ) where our application is running are set to Negotiate and NTLM in that order. I have disabled persistence for troubleshooting, what should be the next step to try?- Thanks in advance. Elio Diaz

A good next step would be to take a packet capture on the client side and see 1) what types of headers are coming back (particularly WWW-Authenticate) from the server and 2) how far into the negotiation process you get (ie. what are the packets you get in your conversation) to determine where things are failing. It may be worthwhile, too, to compare the conversation with LineRate in the middle to the one directly taking to the server successfully. This research should help you figure out what needs to be tweaked to get everything to work. Here's a good MSDN article on what you might want to look for when Negotiate is the primary means of auth: http://blogs.msdn.com/b/benjaminperkins/archive/2011/09/14/iis-integrated-windows-authentication-with-negotiate.aspx

Hello Andrew, Unfortunately, our trial license for F5 Linerate has expired and we cannot conduct further troubleshooting. Is there any chance we can extend the trial? We want to fully test this solution and make sure it works in our environment before purchasing any licenses. Thanks, Elio Diaz - StateTrust.