As many others, we were out to find an alternative solution to proxying Outlook Anywhere. We already successfully setup Apache to support OWA, but management was putting pressure on us to support Outlook Anywhere as well. That requires the ability to proxy RPC over HTTP; something Apache currently will not do due to the fact that Microsoft's Implementation does not conform to the HTTP protocol standards.
Enter Squid. The Squid Proxy does have the ability to proxy RPC over HTTP. They have a howto on their website describing how to configure Squid to make it work. We followed their instructions towards our initial configuration. For the most part it worked, but discovered some problems along the way.
Our environment consists of a heterogeneous computer base. Most use Windows, others use Mac OSX or Linux. With regards to the Squid Proxy configuration, one configuration worked for the Windows users, while the other configuration only worked for Mac OSX users. The former seemed to worke for the OSX Outlook client but consistently gave a "disconnected from server" error. To fix that we had to add client_persistent_connections off towards the top of the configuration file.
# Publish the RPCoHTTP service via SSL client_persistent_connections off http_port 80 accel ....Our second problem was one where Squid would only process attachments smaller than 2 megabytes (mb). Our server was built using Redhat Enterprise Linux 6.4 running Squid3-3.3.3. During out testing we used tcpdump to peek at the traffic between the Squid proxy and the Exchange server. Tcpdump revealed the Exchange server setting the Window Size to zero (0) after ~2MB of data had been sent from the Squid server.
Our first thought was that this was a protocol issue brought upon by Squid. So we Installed a previous version of Squid (Squid3-3.2.9) on another server to test. Those tests were successful, so we installed version 3.2.9 on our to-be production server and it failed. The difference was that our test server was running RHEL 5.5 with OpenSSL 0.9.8e version while our future production server was running RHEL 6.4 with OpenSSL 1.0.0. Given that the amount of data sent was always the same, We concluded that this may a SSL certificate rekey issue. On a hunch we forced SSL to version 3 on the cache peer configuration line which fixed the problem by adding sslversion=3.
cache_peer %EXCHANGE_SERVER_FQDN% parent 443 0 no-query originserver login=PASS connection-auth=on ssl sslflags=DONT_VERIFY_PEER sslcafile=/etc/squid/ca01.crt sslversion=3 name=exchangeServer
The third issue was the use of free/busy calendar status in Outlook Anywhere. Free/busy, along with some other features, requires autodiscover to be configured and operating properly. Squid needs to be configured to forward autodiscover requests to the exchange server. This is rather simple. Just add your autodiscover FQDN to the ACL of permtted domains.
acl MS-OWA dstdomain webmail.domainname.com autodiscover.domainname.com
In the end there were only three changes that had to be made. But the trial and error was rather tedious. Along with the required changes we made a few other superficial modifications such as port 80 redirect, and squid manager access for stats collection. The final configuration looks as follows...
# Publish the RPCoHTTP service via SSL client_persistent_connections off http_port 80 accel https_port %SQUID_IP_ADDR%:443 accel cert=/etc/squid/your_ssl.crt defaultsite=webmail.domainname.com cache_peer %EXCHANGE_SERVER_FQDN% parent 443 0 no-query originserver login=PASS connection-auth=on ssl sslflags=DONT_VERIFY_PEER sslcafile=/etc/squid/ca01.crt sslversion=3 name=exchangeServer #acl manager proto cache_object (OPTIONAL) #for squidclient access acl localhost src 127.0.0.1/32 http_access allow manager localhost http_access deny manager # ACL to allow your FQDNs acl MS-OWA dstdomain webmail.domainname.com autodiscover.domainname.com # Redirect port 80 requests to port 443 acl port80 myport 80 http_access deny port80 MS-OWA deny_info https://webmail.domainname.com/%R MS-OWA cache_peer_access exchangeServer allow MS-OWA cache_peer_access exchangeServer deny all never_direct allow MS-OWA cache deny all # Lock down access to just the Exchange Server! http_access allow MS-OWA http_access deny all miss_access allow MS-OWA miss_access deny all
Last, but not least... Make sure to increase the available file handles for the squid user by editing /etc/security/limits.conf and adding the following and restarting Squid.
# SQUID squid soft nofile 32768 squid hard nofile 32768
I hope this article was helpful!
Hi kiphat
ReplyDeleteThanks for sharing this article.
Everything is working in my environment.
Just if it comes to NTML authentication for autodiscovery the password prompt keeps coming up and up again.
How did you build your squid server and which version of squid are you using? I am on Cent OS 6.5 with latest updates and installed it via "yum install squid"
Thanks for your help!
Wow Grim. Sorry I didn't catch this sooner. I hope everything worked out well in the end.
DeleteWe built our own from the source RPM tailored for squid version 3.2.9. The stock version from CentOS/RedHat most definitely did not work at the time. I do vaguely recall issues regarding NTLM authentication, but those issues were resolved in the end.
Great information, Thanks
ReplyDeleteThis post helped me resolve the issue with our OSX users but now that same issue is back after the OSX users upgraded to 10.11.3. I have verified that the client_persistent_connections is set to off in the config but I cannot get iMail or iCal to Sync with Exchange through Squid from outside the network. When the computer is inside and can communicate with Exchange directly everything works. Does anyone else have this experience? Were you able to resolve it?
ReplyDeleteThanks