Avoid this OWA configuration gotcha

by Derrick Brasslett | May 06, 2005 7:00:00 AM

Tags: SSL/TLS, Authentication/Encryption, Microsoft Office, Network security, SECURITY, Derrick Brasslett, SSL, Microsoft Outlook Web Access, HTTP, server, front-end server, Microsoft Outlook, E-mail Administration Tips Newsletter

4 comment(s)

Takeaway: If you desire a front-end / back-end topology with OWA, make sure that your configuration is set up properly. Here's a minor problem to be aware of and how to avoid it.

Delivered each Monday, TechRepublic's free E-mail Administration NetNote provides tips, articles, and other resources to help you manage your Exchange server and other e-mail systems. Automatically sign up today!

Outlook Web Access (OWA) is included in Exchange 2003 Server's default installation. Once OWA is installed, it's easy to configure the server to use security certificates and Secure Sockets Layer (SSL). Setting up a front-end server is fairly straightforward, as well. However, configuring a front-end has a minor gotcha that isn't immediately apparent when you're following the Microsoft topology guide.

It's a common security practice to select the Require Secure Channel (SSL) option when configuring OWA. This prevents users from inadvertently sending their username and password in clear-text. However, you must not make SSL a requirement on your back-end server, because the front-end server communicates with the back-end server only via HTTP. If your back-end is set up to require SSL, this will prevent proper communication with the front-end, and your users will see an error message similar to the following after they log in:

HTTP 403 (Forbidden)

You are not authorized to view this page

Since the front-end must use HTTP to communicate with the back-end, if you desire a front-end / back-end topology with OWA, change the back-end's directory security so that it doesn't require SSL. You can enforce the SSL requirement by placing the back-end behind a firewall and allowing HTTP traffic only from the front-end server, while allowing HTTPS from everywhere else.

4 comment(s)