Implementing Outlook Web Access with Exchange Server 2003

Following the implementation of Exchange Server in a company it is often desirable connect to users mailboxes using Web Access. Especially with the new release of Exchange Server it is quite interesting to use OWA because you have nearly all the functionality as Microsoft Office Outlook 2003. Within this article we provide a detailed step-by-step guide for implementing Outlook Web Access. Priority will be given to security issues at every stage of the implementation.

 

General Information

With Exchange Server 2003 you can use Standard Edition or Enterprise Edition of Exchange Server to provide Web Access with a Frontend Server. That is quite different in comparison to Exchange 2000 Server where you had to use Enterprise Edition to provide it. But before thinking of implementing a Frontend Server you should first consider your network infrastructure. Do you have a DMZ (also known as perimeter network)? What kind of firewall(s) do you have? Are you using an ISA Server 2000 or any other application layer firewall? Especially using ISA Server 2000 you have some tricky functions providing a good way to securely configure OWA Access over the ISA Server.

Preparing Exchange Server 2003 for OWA
Your Exchange Server 2003 generally behaves as Backend Server and every user has HTTP as an allowed protocol. So you do not have to configure anything on your Backend Servers unless you want to prevent some of your users from accessing their mailbox using OWA. This can be done quite easily via Active Directory Users and Computers in the user properties.

Figure 1:  Enabling OWA for a user

The next step is installing and configuring your Frontend Server. The easiest way to do this is to install it as a second Exchange Server in your organization. After that we should enable it to act as a Frontend Server. This can be generally done in the properties of your Exchange Server in Exchange System Manager.

Figure 2: Configuring a Frontend Server

If we choose this configuration the server changes from using the DAVEx process (to act as Backend Server) to the ExProx process (acting as Frontend Server). The next step is to reboot the server to make the changes take effect.
Then we should go through the following steps to make the Frontend Server a genuine Frontend by disabling all unnessecary services. On your Frontend Server you must have the following services running, every other service may be stopped without any trouble.

• HTTP-Service
• SMTP-Service
• Exchange System Attendant
• Exchange Routing Engine

You really do not need to run the Exchange Information Store, because there should not be any public folders or mailboxes on your Frontend Server. The best practice is to dismount and delete all databases on your server and then disable the Exchange Information Store Service.
After you have successfully placed this server in the perimeter network (also known as DMZ) we now have to configure the appropriate ports on the firewall(s) to make our server run.
On the intranet firewall (which connects the DMZ and the internal network) we have to open the following ports:

• For Exchange Communication:
  • Port 80 for HTTP
  • Port 691 for Link State Algorithm routing protocol
• For Active Directory communication:
  • Port 389 for LDAP (TCP and UDP)
  • Port 3268 for Global Catalog Server LDAP (TCP)
  • Port 88 for Kerberos Authentication (TCP and UDP)

Note: You should now configure the DSAccess service for perimeter networks on your Frontend Server. At first you should disable the check for available disk space at netlogon by using RPC. This can be done by changing the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess
Registry Value: DisableNetlogonCheck
Value Type: REG_DWORD
Value Data: 1

In addition to this you should prevent DSAccess from pinging domain controllers. This can be done by creating the following key on your Frontend Server:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDSAccess
Registry Value: LdapKeepAliveSecs
Value Type: REG_DWORD
Value Data: 0

Then you should configure your Exchange Frontend Server to connect to the DC and GC you want by editing the server properties in Exchange System Manager.

• For DNS communication:
  • Port 53 for DNS (TCP and UDP)
• For RPC communication:
  • Port 135 – RPC endpoint mapper (TCP)
  • Ports 1024 and higher for RPC services

Note: You can limit RPCs across the firewall by editing the registry of all your DCs. You should now change the registry setting of the following key:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters Registry Value: TCP/IP PortValue Type: REG_DWORDValue Data: (available port)

If you are using IPSec between Frontend- and Backend Servers you have to open:

• Port 500 for IKE (UDP)
• Port 51 for Authentication Header (AH)
• Port 50 for Encapsulation Protocol (ESP)

If you want to provide high availability for your Frontend Server you could do this by configuring the Network Load Balancing Service (NBL) to act as a virtual cluster. NLB will then make sure that users connect to a running Frontend Server. Then every user connecting to OWA will connect to the virtual cluster and will then be redirected to one of your Frontend Server nodes.

Implementing Security for Outlook Web Access

If you have successfully implemented your Exchange Front-End Server constellation for providing Outlook Web Access for your users, you may be concerned about security matters. HTTP connectivity is not very secure and authentication information is always on the net as clear text. In addition to this, Outlook Web Access authentication is generally session based. This means if you do not logoff and close your browser you remain logged in. Especially in public web access areas where users are unable to close the browser window it becomes quite easy for other users to read and send emails in the name of a company user.
Providing a secure HTTPS connection with an SSL server certificate is quite easy to implement. The most interesting decision is whether to use a web server certificate from an internal certificate authority or to buy one from a well-known trust center like Verisign or anyone else. This certificate must then be installed on your OWA server.

Figure 3: Installing a Web Server Certificate on an OWA Box

Now you can choose between a secure channel and a non-secure one. If you would like to require 128-bit encryption, just check the appropriate box and it runs. But do not forget that some countries have laws that only allow 40-bit encryption (e.g. France).
With a new feature in Exchange Server 2003 you can make your OWA connections more secure. This feature is called “Form-based Authentication” which means you can configure a cookie timed-out session connection. This can be quite easily implemented as shown in the following picture below.

Figure 4: Enabling Form-based Authentication

After enabling this feature you have a default setting of 10 minutes as the timeout value for a client session. Then you must re-logon to get a new cookie and new OWA access.
Note:  You can change the default timeout by changing the following registry setting:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWeb\OWA
Registry Value: PublicClientTimeout
Value Type: REG_DWORD
Value Data: (possible setting decimal)
and
Registry Value: TrustedClientTimeout
Value Type: REG_DWORD
Value Data: (possible setting decimal)

On both registry values the possible settings will vary from 1 – 4320 (minutes). After changing these settings you have to restart your W3SVC service.
With the setting of compression you have the possibility of speeding up your connections, if you can make sure that your OWA clients are aware of the following requirements:

• Windows 2000 or later
• Internet Explorer 6.0 with the cumulative of November 2002 or Netscape Navigator 6.0 or higher