Forum Discussion

Mike_S_59924's avatar
Mike_S_59924
Icon for Nimbostratus rankNimbostratus
Mar 08, 2012

Occational IIS authentication Problems on LTM hosted SSL sites

First I apologize for the length of this post and it's possible misplacement in this group. None of the Devcentral groups was quite right. Also I apologize for Cross Posting.

 

 

We have an IIS application that has been installed for dozens of clients that is load blanced on two or more servers. This issue has only cropped up twice and it is a mystery why it's an issue on some but not all. There is a lot of heat to fix it.

 

 

We are on LTM version 10.2

 

 

We have two types of users (regular and admin) and both sites run under the same URL. The regular site can be load balanced freely (and needs to be for our larger clients) but the admin site must persist to the same server due to application limitations that can't be easily fixed.

 

 

We have a pool w/ all the servers and an irule that looks for /admin in the uri and if so, sends it to just server1. We have to host the SSL on the LTM to do the irule. We have tried both port 80 http: to the server and port 443 to the server w/ the serverssl profile and have the issue w/ both configurations.

 

 

We have a call center that screen pops to the /admin site when they get calls from users. For internal users like the call center, they single sign-on (SSO) to the application based on their windows login. For the two sites in question, the SSO sometimes fails and prompts the users w/ windows authentication. If you hit cancel and refresh you sometimes get in. Annoying for regular users but crippling for the Call Center Reps.

 

 

We have tried multiple versions of Internet explorer from 6 to 9 w/ no substantive differences.

 

 

After killing most of the day the first time this issue came up, we discovered that removing the SSL from the LTM fixed the issue. We lost the ability to do the fancy load balancing and went to active/passive using priority groups at the pool level. As it was a relatively small client and a one time situation, we just kind of forgot about it and left well enough alone.

 

 

It has now popped up on a new client that is larger. We tried a combination of things and thought we had it licked but it has come back again, albeit w/ less frequency. Here are the things we tried that initially seemed to work in combination (not sure which of the steps was the most effective).

 

 

We changed the IIS settings to use only NTLM for authentication instead of Kerberos (Server metabase change)

 

 

We implemented the ntlm connection pool on the Virtual Servers

 

 

We implemented preserve chunking on the http profile

 

 

we applied the default oneconnect profile

 

 

The only other non-standard settings is we have the SSL 3 big buffer option on in the SSL profile. This is our standard since it fixed a strange bug years ago on version 9 but couuld probably be removed.

 

 

All other SSL profile options are default other than the necessary chaining cert. Thanks in advance for any insight you can provide.

7 Replies

  • Hi Mike,

     

     

    I think this would be complicated to try to give an educated guess on. You could open a case with F5 Support to get help diagnosing the issue. They'll be able to inspect your full configs and problem statement.

     

     

    Aaron
  • Hi Aaron,

     

     

    That's plan B. I have had very poor experiences w/ complicated issues w/ support and very good experiences with Dev Central. Hopefully something breaks soon. We had to open up a second URL to the site to get around this issue for now and that is definitely not a long term viable solution.
  • Hopefully you'll have a better experience this time. If you're not happy with how it goes, you can contact your account management team or post the case number here.

     

     

    Aaron
  • I will agree with Mike.... F5 support is really weak to resolve the cases particularly related to anything that they don't know or like something that they have not experienced before, they simply try to take their hands out of the case.

     

     

    Mike just a small suggestion, if possible try the things out on ver. 11.0 and see it may be behaving much better. Are you using insert cookie persistence?
  • Ok,

     

     

    Support suggested putting a 255.255.255.255 source mask on the oneconnect profile. I couldn't get any failures to occur before I made the change or after so I don't yet know if this helps but the whole SSO handshake seems snappier now. As the problem is very intermittent, we probably won't be sure of the fix for a few days.

     

     

    Techgeeeg,

     

     

    Not sure what our upgrade schedule is as we are usually pretty cautious here. We are not using cookie peristance. We are fully load-balancing the traffic (no persistance) unless /admin is in the URI, and if it is, sending the traffic to just one particular server as there is one portion of the application that does not load balance properly.
  • Well over a wekk has gone by and there have been no more problem supported. We're callng this one fixed. Big kudos to F5 support.
  • That's good news. Any chance you could share the case number ?

     

    Thanks,

     

     

    Christian