Subject: RE: Is anyone successfully running OWA2K behind Apache/mod_ssl?

From: "David Marshall" <[email-masked]>
Date: Thu, 7 Nov 2002 06:57:36 -0800

Jason,

I had this running on RedHat 7.2. Apache 1.3.22/Mod_SSL

Here are the steps...
1. Obtain Apache Mod mod_proxy_add_forward.c
   Modify the code to set the header "font-end-https: on".

   add the following

   /* turn on front-end-https header, so OWA will put HTTPS into urls */ 
   ap_table_set(r->headers_in, "front-end-https","on");

   Compile and install mod_proxy_add_forward.c. 
   I used command "apxs -i -c mod_proxy_add_forward.c" 
  
2. Add a line to your httpd.conf file: 
   "LoadModule proxy_add_forward_module /usr/lib/apache/1.3/mod_proxy_add_forward.so" 
    replacing /usr/lib/apache/1.3 with the path that apxs installs the module.

3. Add the following directives to the virtual host section of your apache
   configuration files, replacing FQDN with the fully qualified domain name you
   want to use, NOT the address of the exchange server:
    ProxyPass /exchange/ http://FQDN/exchange/
    ProxyPass /public/ http://FQDN/public/
    ProxyPass /exchweb/ http://FQDN/exchweb/

4. Make sure that external dns resolves the FQDN to the Apache proxy server

5. Modify your /etc/hosts on the Apache proxy server
   Add the FQDN to resolve to the ip address of the OWA server 

6. On the Server where OWA is installed, Turn off Windows Integrated Authentication
   run Internet Services Manager 
   ( "Programs"->"Administrative Tools"->"Internet Services Manager" )

   Expand to your OWA website and Right-click the OWA site and select 
   "Properties", on the resulting Dialog, select the "Directory Security" 
   Tab, Then Edit the "Anonymous access and authentication control", 
   remove "Windows Integrated Authentication" and turn on "Basic Authentication"

   note: you must repeat this step every time you restart IIS or reboot this machine.

I must tell that although the solution "worked", we did not put this solution into production. 

The biggest drawbacks to this solution were.
a. Every time you reboot/restart IIS on the System where OWA is installed, 
   your security settings will be reset adding "Windows Integrated Authentication" 
   back to the virtual directories. 

   We have found no way to resolve this.

b. We had to add a virtual host for every OWA site on Apache that we needed to host.
   In my environment we have 3 exchange servers and 2 routing groups. 
   This meant that as we changed our Exchange Topology, that we would have
   to re-work the Apache front-end proxy.

c. Users cannot use the password change option.

After reading the Microsoft Exchange Front-End/Backend documents http://www.microsoft.com/downloads/release.asp?releaseid=43997 , We decided to evaluate running a Front-End OWA server under SSL with HTTP disabled on a separate system from the other Exchange Servers. In the final analysis, we decided that this was the right answer for us.

David Marshall

-----Original Message-----
From: Jason Haar [mailto:[email-masked]]
Sent: Thursday, November 07, 2002 12:04 AM
To: [email-masked]
Subject: Is anyone successfully runnin OWA2K behind Apache/mod_ssl?

We're using Apache/mod_ssl to provide a reverse-proxy to some backend Web
servers, and want to add OWA2K to the list (that's Outlook Web Access for
Microsoft Exchange 2000).

It works fine with OWA from Exchange 5.5 - which was basically just HTML
plus some javascript - but OWA2K (under IE5+) uses all sorts of whizzy M$
stuff, and doesn't work!

If you access OWA2K with a non-IE browser (e.g. Mozilla), OWA2K reverts to
the older format and works fine - it just doesn't work well from IE (ironic
isn't it :-)

It's pretty flakey. IE5.0 works pretty well, IE5.5 works 20% of the time and
IE6 just dies. It goes without saying that all these browsers work fine when
talking directly to the OWA2K server: it's only via the RP that they fail.

I've done packet sniffs and compares and can't see anything out of the
ordinary. I think it's an OWA issue, or an IE security-context issue, but
can't say for sure.

Anyone else got any stories about this?

Thanks

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl)                   www.modssl.org
User Support Mailing List                      [email-masked]
Automated List Manager                            [email-masked]

---

From: Jason Haar <[email-masked]>
Date: Fri, 8 Nov 2002 13:30:56 +1300

>    back to the virtual directories. 

Strange. We've already done that and it does last through reboots.

>    to re-work the Apache front-end proxy.

Ah. That sounds like you're doing this to backend servers - not an OWA
frontend server - sorry for not mentioning that - we're using frontend
servers - specifically to get around the issues of having multiple Exchange
servers.

> After reading the Microsoft Exchange Front-End/Backend documents
> http://www.microsoft.com/downloads/release.asp?releaseid=43997 , We decided
> to evaluate running a Front-End OWA server under SSL with HTTP disabled on a
> separate system from the other Exchange Servers. In the final analysis, we
> decided that this was the right answer for us.

That's alright. I finally think I've figure it out! The problem was that our
Apache reverse-proxy was called "proxy.domain", whereas our OWA2K was called
"owa.domain". Whenever a client asked for
"https://proxy.domain/exchange/..." that would pass through to owa.domain
with a Host: header of "proxy.domain" (as you would expect). However there
is a bug in either OWA or IE5+ that causes OWA2K to generate corrupt XML if
the IIS server doesn't recognise the Host: header as being itself.

So all we did was tell IIS that "proxy.domain" was a valid alias for itself,
and magically OWA2K started working via the reverse-proxy :-)

I feel like I've achieved something this week :-)

-- 
Cheers

Jason Haar