Outlook Web App is enabled by default on an Exchange 2010 client access server, but that doesn’t mean it’s going to work optimally. You’ll need to reconfigure OWA after installing the CAS role to get the application running smoothly and securely.
When you install the client access server role, Exchange requires SSL encryption for OWA. That SSL encryption is linked to a self-signed certificate, which temporarily secures HTTP communications with the CAS.
Unlike a traditional SSL certificate, a self-signed certificate doesn’t provide proof of the CAS’s identity. Furthermore, client computers don’t trust self-signed certificates, and they shouldn’t. Consequently, users will receive certificate errors when they try to access OWA (Figure 1).
To resolve this, you need to acquire an X.509 certificate from a trusted certificate authority (CA). You can either use a commercial CA or you can generate the certificate in-house. I recommend using a well-known commercial CA. Windows trusts most well-known CAs by default.
The certificate must be assigned a name that matches your client access server’s fully qualified domain name (FQDN). If your internal domain name is different from your external domain name, then the certificate should use the FQDN that accessed the CAS from outside the Exchange environment. The certificate’s Subject Alternate Name should contain the FQDN that the certificate authority uses for internal network communications.
After obtaining the correct certificate, go to your CAS and open the Exchange Management Console. Next, select the Server Configuration container to view a list of Exchange servers on your network. Select the server on which you want to apply the certificate; the details pane at the bottom of the screen displays existing certificates.
Figure 2 shows the self-signed certificate that has been assigned to the client access server. The screen also shows the Actions pane, which contains a link labeled New Exchange Certificate. Clicking this link launches the New Exchange Certificate Wizard. Follow the wizard’s prompts to import your new certificate.
Choosing your authentication method
Outlook Web App is a Web application that resides on top of Internet Information Server. IIS supports several different authentication methods, some of which can be used with OWA. However, which authentication method is available varies depending on the roles that the server is hosting.
Client access servers support Integrated Windows Authentication (IWA) and Digest Authentication. However, if the server is only hosting the CAS role, then your choice of authentication methods is limited to either basic or forms-based authentication.
Which authentication method you use depends on your enterprise’s requirements. If your primary need is universal compatibility, I recommend using basic authentication because it’s a simple method that works with almost any browser. Basic authentication transmits passwords using clear text, so it’s not very secure unless you use it in conjunction with SSL encryption. Basic authentication can also be risky if a user accesses OWA from a public kiosk that could potentially cache that user’s credentials.
Digest Authentication transfers a mathematical hash -- not the user’s actual password -- to the server. This method is more secure than basic authentication, but it’s not flawless. The potential for caching a user’s credentials is still a concern. Additionally, Digest Authentication can only be used with Exchange 2010 virtual directories.
IWA is a single sign-on technology that checks to see if the user is already logged into the local network. If so, then he can log into OWA without having to enter credentials. IWA can only be used with Exchange 2010 virtual directories, unless you’ve installed a mailbox server role. With IWA, the authentication process is encrypted but everything else is transmitted using clear text -- unless SSL is used. One final caveat is that IWA only operates with Internet Explorer.
Configuring OWA authentication
To configure the authentication method, open the Exchange Management Console and navigate to Server Configuration -> Client Access (Figure 3). Next, select the server that’s running OWA and select the Outlook Web App tab, as shown in Figure 3.
In the work pane, click the Properties link and choose the authentication tab from the sheet. Finally, select the authentication method that you want to use and click OK.
Creating legacy host names
If you’re running a mixed Exchange environment in which an Exchange 2010 client access server will coexist with an Exchange 2007 CAS, you have to create a legacy host name for the Exchange 2007 CAS. This means that all inbound OWA traffic will pass through the Exchange 2010 CAS while the legacy host name dynamically reroutes Exchange 2007 mailbox traffic to the Exchange 2007 CAS.
To create a legacy host name, you need to create a DNS host (A) record that adds the word legacy to the beginning of your domain name. For example, if your domain name is Contoso.com, the legacy host name would be legacy.contoso.com.
Point this DNS record to the IP address associated with your Exchange 2007 CAS. (This also works for Exchange 2003 front-end servers.) Then point the DNS record for your regular host name (Contoso.com) to your Exchange 2010 CAS. Depending on how your network is configured, you may also need to create a publishing rule for the legacy host name on your firewall.
ABOUT THE AUTHOR
Brien M. Posey, MCSE, is a seven-time Microsoft MVP for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. For more information visit www.brienposey.com.