Keywords: outlook web access, OWA, front-end-https, proxy, libproxy.so, protect OWA, front-end-proxy, header, SSL, front, end, mod_proxy, apache, 2000, 2003, NT, windows
[I have successfully implemented this solution with SSL-aware Apache 2.0.46 on Debian Sarge and Redhat Enterprise Linux 3.1. This "HOWTO" does not cover setting up an OWA or SSL-aware Apache server. That's up to you. Sorry.]
Outlook Web Access 2000 and 2003 (OWA) runs on Microsoft's Internet Information Service (IIS). IIS is considered by many to be the swiss cheese of web servers (and I agree with this... sort of). I would never consider putting an IIS box on a publicly accessible network simply because it's just too much work to secure.
The point of having an OWA server is moot if one is not willing to allow access to it from the world. So, we need to somehow make the OWA service publicly accessible while not actually making the box itself publicly accessible (hopefully that makes sense. ;-). The answer? Proxy incoming requests with something a little more secure - namely Apache. Apache comes with a nice proxy module called mod_proxy. It does everything we need.
Remote users want to access OWA. They type https://webmail.somedomain.com into their browser. Their workstation/laptop then asks their DNS for the IP address of webmail.somedomain.com. The DNS replies with the IP address of the APACHE PROXY. The browser then connects to the proxy and sends its request. The APACHE PROXY then connects to the the internal OWA SERVER and requests the objects on behalf of the remote user. Simple enough.
Be aware that in this example, the Apache "proxy" is on a locked down service network. Nothing gets in or out of this net unless it is required. For the Apache "proxy", connection requests destined for port 443 (https) are allowed through the firewall from the world. Connection requests from the Apache "proxy" are allowed through to destination port 443 on the internal OWA server. That's it. If the Apache "proxy" generates any traffic other than that, alarms go off (i.e. WARNING! WARNING! You may be 0wn3d!). I highly recommend this configuration for all pubicly accessible services.
Now, to make this bit of magic work, we need to do several things.
1. Configure Apache to use the mod_proxy modules.
Ensure Apache's configuration file (httpd.conf) includes the following lines.
LoadModule proxy_module <path to modules dir>/mod_proxy.so LoadModule proxy_http_module <path to modules dir>/mod_proxy_http.so LoadModule proxy_connect_module <path to modules dir>/mod_proxy_connect.so
NOTE: If mod_proxy is not part of your distribution's Apache package or you did not compile Apache with the mod_proxy option turned on, httpd may not start (it'll probably only complain).
2. Add a RequestHeader and these ProxyPass configuration directives to your Apache config file. You may place them in the main section of the config or in a VirtualHost section. It all depends how you have your server configured. I've done it in both and either will work.
RequestHeader set Front-End-Https "On"
ProxyPass /exchange http://webmail.somedomain.com/exchange/
ProxyPassReverse /exchange http://webmail.somedomain.com/exchange/
ProxyPass /exchweb http://webmail.somedomain.com/exchweb/
ProxyPassReverse /exchweb http://webmail.somedomain.com/exchweb/
ProxyPass /public http://webmail.somedomain.com/public/
ProxyPassReverse /public http://webmail.somedomain.com/public/
ProxyPass /iisadmpwd http://webmail.somedomain.com/iisadmpwd/
ProxyPassReverse /iisadmpwd http://webmail.somedomain.com/iisadmpwd/
CacheDisable *
3. And finally add an entry to the Apache server's /etc/hosts file.
You may notice the ProxyPass directives redirect several directories to webmail.somedomain.com. But how can we redirect to webmail.somedomain.com if the Apache server is webmail.somedomain.com? We need to add an entry to the /etc/hosts file pointing webmail.somedomain.com to the internal OWA IP address.
192.168.0.100 webmail.somedomain.com
Be sure your server is configured to look in your hosts file before consulting the DNS. Check your /etc/host.conf file to make sure. It should read like this.
order hosts, bind multi on
Now start Apache. Watch your logs for any errors. Make sure the appropriate access is configured through your firewall (world --> proxy dst tcp 443 and proxy --> internal OWA server dst tcp 443). Also remember to watch the logs on your internal OWA server.
Some things to watch include
If you try implementing this and have problems or (sorry -- I'm bombarded with questions) have something you think I should add (or modify) to these instructions, feel free to contact me at mikeg@3cx.org.
|
When I implemented this, I ran into a nasty bug. Exchange, for some strange reason, looks up each email using the subject line (as opposed to say... THE FRIGGIN UNIQUE IDENTIFIER!). That means the email subject is part of the URL. If a percent symbol (%) is in the subject line of the requested email, Apache will complain that it cannot find the URL. This has to do with the way mod_proxy does encoding/decoding of URI escape sequences. By using the following mod_rewrite rules and a simple bash script, one can easily work around this problem. Insert this right before your "front-end" Proxy* directives in httpd.conf.
# Using mod_rewrite to fix a problem when percent symbols are in
# the subject line of the OWA email (the email subject is used # in the web query - WTF?). The entire URI is passed to a small # bash script I wrote that replaces all occurrences of the % symbol # with the URI escape sequence (%25). That seems to make everything # happy. RewriteEngine On RewriteMap damnpercent prg:/usr/local/bin/percent_rewrite RewriteCond $1 ^/exchange/.*\%.*$ RewriteRule (/exchange/.*) ${damnpercent:$1} [P] The simple bash script uses sed to work its magic. You'll notice I am also sending the original and changed URL to a log file in /tmp. This helps with troubleshooting and can be shut off when you're confidant everything is working. (This could easily be rewritten in any language.)
#!/bin/bash
LOGFILE=/tmp/percent_rewrite.log cat /dev/null > $LOGFILE while read URL do NEWURL=$(echo "$URL" | sed -e "s/%/%25/g") echo "Changing $URL to $NEWURL" >> $LOGFILE echo $NEWURL done Keep in mind that this script only works if you implemented my solution exactly as I have. A man from Germany tried a modified solution, but could never get the percent rewrite to function properly. He used the ProxyPreserveHost directive, which I do not. By using this directive, you can dispense with the /etc/hosts hack and use the real OWA hostname in the ProxyPass directives (but not the ProxyPassReverse directives). I tried this and it works wonderfully... except for the percent symbol problem. I never could get the rewrite to work with the ProxyPreserveHost setup. I suspect this is due to my lack of understanding of the inner workings of both Apache's proxy subsystem and mod_rewrite. |
|
Outlook RPC over HTTP with Apache 2.0 Simon Blackstein returned and added an excellent comment about Outlook RPC over HTTP via Apache 2.0 proxying to this post (http://3cx.org/item/35). He says he still has a few minor issues, but I believe he'll work them out. Hopefully he'll report back here with any "fixes". Here is his comment in full (with a few minor changes only to assist my HTMLization). Simon wrote: OK, so I'm still having a few funny issues with this config, as opposed to opening 80/443 directly to Exchange *shudder*. BTW, this is very similar to proxying OWA really. A couple of other things involved. Like most people probably checking out this article, I only have a single Win2k3/Exch SP1 back-end server and an Apache reverse-proxy.
Again, sometimes you do get some funny pauses happening, especially if you're on a shady connection. If anyone can find any way to make this more stable - I've been looking at the disable-cache thing potentially solving that - let me know. Rgds, Simon Blackstein
Tue 26 Jul 12:47:48 JST 2005
|
© 2002-2007 Michael Gauthier
Bother the webmaster at webmaster@3cx.org.
![[QUIT SLASHDOT TODAY]](/misc/quit-slashdot.gif){kind=small}