Today I had to set up a Treo 650 to access a user’s Exchange mailbox over the web. I did not imagine it would be as difficult as it turned out to be.
At this site we run a Linux router/firewall that handles all traffic coming into, and leaving the network. We use Apache’s mod_proxy to proxy web connections from the internet to IIS servers on the private network. Having had more than a couple 36+ hour days cleaning up viruses due to exploited IIS servers, I feel much more comfortable having Apache handle the web requests.
One of the “Gotcha’s” to using mod_proxy is that you have to disable “Integrated Windows Authentication” on any sites you proxy with Apache. Apache doesn’t understand the headers involved. No big deal, because these requests are typically coming from the internet over SSL.
I started the setup at about 12:00 noon today. The first thing I did was add the following bits of code to the Apache configuration file to Proxy the ActiveSync connections:
#ActiveSync
ProxyPass /Microsoft-Server-ActiveSync https://webmail.example.com/Microsoft-Server-ActiveSync
ProxyPassReverse /Microsoft-Server-ActiveSync https://webmail.example.com/Microsoft-Server-ActiveSync
I then put the appropriate settings into the Treo, and tested connectivity. This is where things started to piss me off.
The software on the Treo has terrible, non-intuitive error codes. The documentation is even worse. This is what I discovered (over about 4 hours of trying to get it to work):
- For the ProxyPass directives to work, you can not use Integrated Windows Authentication on the IIS site.
- For the Treo VersaMail app to use Exchange ActiveSync it must use kerberos authentication, which requires enabling Integrated Windows Authentication.
- Palm’s software engineers don’t really give a shit whether the error message you get is in any way helpful, just as long as you understand it’s not working.
So the thing that sucks about this is that we run “stuff” on the gateway which requires us to use Apache on Linux. It provides remote access for employees through a web interface, and dynamically modifies iptables firewall rules when folks need access.
This was my fix, which I think is as good of a fix as is possible.
- Exported the IIS web site that handled OWA, OMA, and ActiveSync to a file.
- Created a new web site from the exported file.
- Changed the TCP ports for HTTP and HTTPS to obscure, high ports.
- Modified the document root on the IIS site, as all the magic happens in Virtual Directories.
- Requested/Installed a new SSL certificate from an internal enterprise CA with a common name matching the internet FQDN.
- Enabled “Integrated Windows Authentication” on the “Exchange” virtual directory in this new web site.
- Forwarded the obscure, high SSL port from the firewall into the Exchange server.
Now the Treo works… just had to set the obscure high port in the advanced settings on the Treo. I didn’t want to go down the forwarded port road, because it seems like a compromise in security. All too often I see people bypass security measures in order to get things to work, and I hate it. This seems like a small compromise I’ll have to settle for.
Got a better solution? Let me know.
-Chris
