topic Re: authentication issues with https in Web Security

authentication issues with https

mulhollandm — Sun, 10 Nov 2013 11:17:51 GMT

folks

i have a couple of WSA670s behind a big ip load balancer and this week, after a feature key update, i'm getting occasional problems with authentication when accessing https sites

i'm running in transparent mode but with the big ip configured as an explicit proxy in the user's browser

i using 7.7.0-608

when users attempt to access a https site the page isn't always served, sometimes is does, sometime it doesn't

if i check the the accesslog i see a TCP 407/DENIED

if i then go to open a new tab and another https site, ie google, i can get access and if i go back to the tab that didn't work and refresh it now works

the accesslogs shows the traffic as authenticated

i can't allow any unauthenticated traffic

can anyone give me any help or point me in the right direction?

thanks to anyone replying

greatly appreciated

Re: authentication issues with https

Vance Kwan — Mon, 11 Nov 2013 06:35:37 GMT

How does the F5 load balancer determine which WSA to send traffic to?

When the request leaves the F5, what is the Source IP address?

What surrogate type are you using? (IP Address/Session Cookie/Persistent Cookie).

You may want to take a packet capture at the WSA while the issue is occuring to make sure that it is indeed authenticating to the WSA that wants to authenticate the user.

-Vance

Re: authentication issues with https

mulhollandm — Mon, 11 Nov 2013 08:28:30 GMT

vance

many thanks for your reply

the f5 is configured with a pool of proxy servers (ironports) and uses irules to forward internet traffic to one set of proxies and intranet traffic to another set of proxies

the source address of the traffic leaving the f5s is the expected f5 ip address but x-forwarding is configured and i can see the client address in my accecsslogs

we are using ip address as the surrogate

i can see the traffic hitting the correct wsa on the f5 through a source ip based persistence policy on the f5 and in the accesslogs of the wsa, if i tail on my other wsas there is no traffic from my source ip

all http traffic works fine, the problem only happens with occasional https traffic

thanks again

i'm considering enabling the https proxy and just traffic without decrypting it but i'm not sure if this is relevant to my issue

authentication issues with https

VeNoMouSNZ — Mon, 11 Nov 2013 22:07:58 GMT

I too am seeing TCP_DENIED/407 on SSL's... I have No Surrogate enabled due to we have alot of XenApp servers , maybe this is wrong.... mulhollandm do you have No Surrogate on your identity policies?

authentication issues with https

mulhollandm — Mon, 11 Nov 2013 23:13:57 GMT

jodi

we're using ip address as surrogate

authentication issues with https

Vance Kwan — Wed, 13 Nov 2013 03:02:09 GMT

I see some potential problems with your setup.

If the request is leaving the F5 with its own IP address as the Source, and when your user authenticates, the WSA will associate that user with the F5's IP address. Authentication does not take the XFF header into consideration. If you have not run into problems with this, chances are that you are not using any surrogates (see the option to Apply Same Surrogate Type For Explicit Forward Requests).

If all you saw is a 407 when it does not work, this pretty much narrows it down to an authentication problem I suppose.

Can you post the actual Access Log entries when the issue occurs?

authentication issues with https

mulhollandm — Fri, 15 Nov 2013 23:04:33 GMT

vance

apologies for the delay, here's a sample log entry

both of these are from the same log

not working

1383782289.013 149 10.63.132.227 TCP_DENIED/407 0 CONNECT tunnel://www.eventtouch.eu:443/

- NONE/- - OTHER-NONE-All_Authenticated_Users-NONE-NONE-NONE-NONE

<-,-,-,"-",-,-,-,-,"-",-,-,-,"-",-,-,"-","-",-,-,-,-,"-","-","-","-","-","-",0.00,0,-,"

-","-" > - "10.63.132.227"

working

1383782479.285 547 10.63.132.227 TCP_CLIENT_REFRESH_MISS/200 3814 CONNECT

tunnel://www.eventtouch.eu:443/ "**********\1028009@**********" DIRECT/www.eventtouch.eu

application/octet-stream

DEFAULT_CASE_12-Default_DOWNLOAD_Internet_Access_Policy-All_Authenticated_Users-NONE-NONE-

NONE-DefaultGroup

thanks again

authentication issues with https

Vance Kwan — Sun, 17 Nov 2013 08:31:25 GMT

Based on the logs, it appears when it is not working, it needs authentication. When it is working, authentication was not needed.

Do you think it is possible that when you open a new tab, you are hitting a home page that authenticates the user correctly? Then when going back to the previous tab, you refresh, which no longer requires authentication since you did on the last tab?

-Vance

authentication issues with https

mulhollandm — Sun, 17 Nov 2013 09:00:12 GMT

vance

thanks again for replyingto my posts, its greatly appreciated

you're right in that the new tab opens to an intranet home page that authenticates the user - this works most of the time but not all

is there a resolution to this

i can't have an authentication bypass for https as it against policy

i don't have the https proxy enabled - would this help?

authentication issues with https

Vance Kwan — Sun, 17 Nov 2013 09:09:32 GMT

Some sites just do not work with authentication and there is no way around it for now with your setup.

Right now, it sounds like that particular destination has trouble authenticating. Are you able to bypass that site from authentication?

authentication issues with https

mulhollandm — Sun, 17 Nov 2013 09:57:08 GMT

vance

we're replacing currently replacing our existing bluecoats with ironports and this issue only happens with the ironports

the bluecoats go to the same sites and there are no issues

both systems use ntlm

if its not possible we may have to bypass but that adds extra overhead to manage

would using the context agent on ad server make an difference or using the httpsproxy?

thanks again for your help

Re: authentication issues with https

Vance Kwan — Mon, 18 Nov 2013 05:12:35 GMT

I don't think the Context Directory Agent will work for you since the request leaves your F5 load balancer with its own IP address. The CDA will only work for you if the WSA receives the request with the true client IP.

Without comparing the packet capture with the capture from a Blue Coat, I wouldn't be able to explain why one works and the other one does not.

The CDA works by building a user to IP mapping as the users sign on to the domain..

Re: authentication issues with https

mulhollandm — Mon, 18 Nov 2013 20:45:17 GMT

vance

again, many thanks for your patience

i might log a tac call for this as i can't allow anything to bypass authentication

i ran a packet capture on a client which had authentication issues and i can see the proxy sending back an authentication required message but nothing happens after that

there's no ntlm challenge or anything

i'll see what tac have to say

thanks again