WS1000 - site blocked but allowed

Hi, We were having a problem with Outlook; it was coming up with a proxy authentication request box which would not go away even when the correct credentials were used. Outlook would not open some user's calendar & would not open shared mailboxes. The blocked message appeared in the WS1000 logs at the same time.

We have added the site to proxy bypass in Internet Explorer and that solves the problems, but it's not ideal. Some satellite sites do not have internet access except via the proxy.

Thanks,

Ed

Hi, We were having a problem with Outlook; it was coming up with a proxy authentication request box which would not go away even when the correct credentials were used. Outlook would not open some user's calendar & would not open shared mailboxes. The blocked message appeared in the WS1000 logs at the same time.

We have added the site to proxy bypass in Internet Explorer and that solves the problems, but it's not ideal. Some satellite sites do not have internet access except via the proxy.

Thanks,

Ed

Hi Ed,

As I mentioned before the best and recommend solution is to omit the traffic. 

as a full explication is not thread friendly .. the autodiscover client expects essentially a yes/no response.  when you start adding things like SSH certs, other internet codes, like a 307 or similar.. authentication and all of the "other" things in a typical network.   It becomes a major pita. 

the other issue is, its a "service" so if ms changes anything anyone of these "fixes" may or may not be affected.  As I mentioned I strongly suggest omitting the traffic. \

that been said here are the ways you can "make" it work

#1 ensure the workstation has the appliances ssl certificate installed (any ssl error will cause issues) its a client, it cant hit yes to accept a self signed cert. so it must be pushed out as per https scanning.

#2 under authentication profiles.. 

step 1: create a profile based on IP ranges, enter in your ip ranges ie: 10.0.0.0/8

step 2: under authentication tab.. create a new bypass profile, under sites.. enter your autodiscover.mydomain.com  check off.. bypass authentication. 

#3 you could create a local site list entry for autodiscover.mydomain.com set it as globally allowed.. (or change the category to custom) and allow specific groups / users to access the custom category.

#4 black hole the dns request as mentioned before, causing the request to fail.. the autodiscover client will time out properly and default to the network look up

#5 In your case if you have a mixed onsite/off site environment, configured via proxy.. consider creating / hosting a proxy .pac file. something like this..

function FindProxyForURL(url, host)
{
// variable strings to return
var proxy_yes = "PROXY 192.168.1.1:8080";
var proxy_no = "DIRECT";

if (shExpMatch(url, "www.mycompanywebsite.com*")) { return proxy_no; }
if (shExpMatch(url, "www.myotherwebsite.com*")) { return proxy_no; }
if (shExpMatch(url, "www.my3rdlocalsite.com*")) { return proxy_no; }
if (shExpMatch(url, "http://192.168.1.100*")) { return proxy_no; }
// Proxy if PC is on local LAN
if (isInNet(myIpAddress(), "192.168.1.0", "255.255.255.0"))
return "PROXY 192.168.1.1:8080";
else
return "DIRECT";
}

replace one of the entries with your autodiscover address so that any request is sent "direct" .. host it and push it out 

The recommended solution is bypassing the appliance altogether.. In your case as you mentioned using a mixed proxy environment.. the BEST solution is #5 the proxy .pac file.  It solves not only this issue, but gives your the ability to correct any other proxy issues and or specifically tailor an internal or external workstation, machine or other infrastructure. 

The SWA is a true proxy.. it will always return an answer for every request it makes (unlike a UTM/xg that contains a firewall ie: a response could be dropped hence causing the service to fail normally). .. when ever a response (like a ssl cert, or authentication or any other response is returned to the auto discover service.. the service its self does not understand what to do.  This is the same with things like fax machines, photocopiers and another infrastructure that will fail closed.

This is why I highly recommend omitting the proxy from this service.  Yes you "can" make it work.. but its not recommended..  the only traffic that should ever go through a swa is:

#1 traffic that requires policy and or authentication for users to prevent unauthorized internet use and police/track sites.

#2 Only traffic sent via one of the 4 approved browsers. (no pdf/stamp/photocopiers.. or services/applications)  

All internal requests should be explicitly omitted. (something like this is generally apart of your .pac file)

if (isInNet(dnsResolve(host), "192.168.0.0/16", "255.255.0.0"))
return "DIRECT";

etc

Unfortunately support cant write a .pac file for you, but here are the resources I use, if your really stuck we do offer professional services, just get in touch with your account manager.

findproxyforurl.com/.../
community.sophos.com/.../38784
community.sophos.com/.../38787
community.sophos.com/.../38783
community.sophos.com/.../38788