Looking for something else?
With previous versions of Exchange, administrators had a decision to make when it came to deploying Outlook Web Access (OWA), the Web-based client for Exchange. Although the ability to access e-mail remotely was appealing, the functionality that was provided was far below what was offered in the full Outlook client, and there were serious security concerns about deploying a Web-based client for Exchange.
With the introduction of a newly updated version of OWA that is on a rough parity with the full Outlook 2003 client, mail administrators will want to take a second look at deploying this Web-based client for Exchange.
Because OWA is installed and configured by default with Exchange 2003, administrators now have a robust Web client for Exchange that is easy to deploy and use. Although the updated OWA provides a host of new features for Exchange users, some of the same security concerns have persisted from previous versions.
If you are thinking about deploying OWA, the configuration and use of Secure Sockets Layer (SSL) encryption should be at the top of your security checklist. This security measure was also available for Exchange 2000 and its implementation of OWA. However, if you chose not to deploy OWA within your organization, you probably haven't run across it as an administrator.
As a user, you have probably been to numerous Web sites or e-commerce sites that were secured using SSL, where the padlock appears in the bottom-right corner of your browser or the address is prefixed by HTTPS:// (instead of HTTP://), indicating that the Web site or store is secure.
Because OWA is installed by default with Exchange 2003, you will want to configure SSL to provide a secure interface to OWA and secure communications between front-end servers that connect to the other servers in your Exchange topology. This section looks at some of the steps required to use SSL in your Exchange implementation.
First, you need to have a Server Certificate to enable SSL. A Server Certificate is a virtual document that is available from a Certification Authority (CA). You can use a commercial CA, such as Thawte or VeriSign, or you can use an internal CA that your company maintains. This CA collects information from you, including details about your organization, and issues a certificate that serves as verification that you are who you say you are. This same certificate makes it possible to create a secure connection between two computers, using encryption keys to ensure that the information being sent across the wire is confidential and hasn't been tampered with.
To obtain a certificate, it's easiest to request one from a commercial CA. You could create your own certificate, but most browsers are already programmed to trust certificates that are issued by commercial CAs, eliminating those annoying pop-up messages every time you want to access a Web site.
Luckily, the process of requesting a server certificate from a CA has been streamlined through the use of a wizard. This wizard collects information about your organization and submits it to the CA. To obtain a server certificate, follow these steps:
1. On the server, open the Internet Services Manager from the Administrative Tools group.
2. Locate the EXCHWEB Web site beneath the Default Web Site node. Then right-click on the Web site and select its properties.
3. Click on the Directory Services tab and click the button marked Server Certificate to open the Server Certificate Wizard. Then click Next to open the dialog box shown in Figure 8.1.
4. Select the option Create a New Certificate and click Next to proceed to the next step of the wizard.
5. Select the option Prepare Request Now But Send Later and click Next to proceed.
6. Using the dialog box shown in Figure 8.2, enter a name for your certificate, as well as 1024 for the bit length. Click Next to proceed.
7. Enter the name of your organization and organizational unit. The organization name should be your legal trading name (that is, "Orion Mining, LLC"), and the organizational unit should be something that describes your particular area within that organization (that is, "Mining Operations.")
8. Enter the DNS name for your server. This should be the name of the front-end server that you are using for Exchange OWA that is exposed to the Internet.
9. Enter your geographical information, including your country, state, city, and so on. Then click Next to proceed.
10. Finally, enter a filename and location for your certificate request.
If you are using ISA Server with Exchange in a firewall/DMZ setup, this should be the name of the ISA server. Check your ISA Server documentation for how to request and implement a server certificate on this platform. For more information on implementing ISA server, including different deployment scenarios you can use with Exchange 2003, visit http://www.microsoft.com/isa.
After you have created this request, you can send it on to a CA (http://www.verisign.com, http://www.thawte.com, and so on), who will then check your credentials and, upon the payment of a fee, issue you a server certificate. (The timeframe for this could be anywhere from the same day to a few weeks' time.) With your certificate in hand, it is time to do a little more configuration work to make Exchange secure.
To use your Server Certificate to secure Exchange, follow these steps:
1. On the server, open the Certificate Manager from the Administrative Tools program group.
2. Install and configure your Server Certificate using the instructions that your Certificate Authority provides.
3. Open the Internet Services Manager from Administrative Tools and select the Web server you want to secure.
4. Click on the Directory Services tab and click the button marked Edit under Secure Communications. Then select the option Require Secure Channel (SSL).
INDIVIDUAL WEB SITES
You could also use this same process to secure specific virtual folders within your Web site. However, Exchange provides several different access methods (OWA, Outlook Mobile Access [OMA], and so on) that are exposed through IIS, so it is best to secure the entire Web site using SSL.
Now whenever users want to access OWA or other Exchange client applications that are exposed through IIS, they will use the HTTPS:// prefix, which provides a secure SSL connection.
Get more "8 Exchange 2003 security tips in 8 minutes." Return to the main page.
About the authors:
David McAmis is an enterprise architect and partner in a consulting firm in Sydney, Australia. David has written a number of books and more than 100 articles that have appeared in magazines and journals.
Don Jones, MCSE, CTT+, is an independent consultant and founding partner of BrainCore.Net. Don is the author of more than a dozen books and the creator and series editor of Sams Publishing's Delta Guide series. He is also a contributing editor and columnist for Microsoft® Certified Professional Magazine, the Microsoft technology columnist for CertCities.com, and a speaker at technology conferences.