Some of your users might be able to get away with using just Outlook Web Access, the great tool that mimics Outlook's interface in a Web browser, in lieu of the traditional Outlook client.
However, there are concerns about Outlook Web Access in regards to security. How might one go about protecting it? Outlook Web Access can use HTTPS—the encrypted, authenticated, and tunneled version of the HTTP protocol—but it lacks any intrusion detection features. More problematically, all versions of Outlook Web Access except 2003 do not include a session timeout feature, so users remain logged into their Outlook Web Access session until they click Logout. Picture the chief financial officer of your company checking his e-mail through Outlook Web Access at an Internet kiosk at the airport. He simply closes the browser when he is finished, but a clever information spy can then reopen the browser after he has walked away, revisit the previous site, and gain access to a very sensitive and important e-mail account. That is certainly a very bad situation, and it has happened before.
To make Outlook Web Access secure, there are four things that you, as an administrator, must configure a firewall to do:
Inspect all Secure Sockets Layer (SSL) traffic at the application layer to make sure the traffic is what it claims to be. This prevents a significant portion of today's attacks.
Maintain wire privacy, as sensitive information is very often transmitted through e-mail.
Enforce the HTTP and HTML standards to make sure that nefarious code doesn't sneak through via weaknesses in these protocols and standards.
Block Uniform Resource Locator (URL)—based attacks by enforcing only known URLs. This protects you against attacks that request unusual actions, have a large number of characters, or are encoded using an alternate character set.
All in all, when you have this quadruple-layered security scenario protecting Outlook Web Access, you can feel reasonably confident that data trusted to its mechanisms is secure.
ISA Server protects your Outlook Web Access front-end server or servers. The ISA server in effect becomes the bastion host, terminating all connections with its Web Proxy feature, decrypting HTTPS to inspect the content of the packets transmitted through the machine, enforcing known-URL access with URLScan, and ultimately reencrypting everything for transmission to the Outlook Web Access server, living safely behind the ISA Server front-line machine.
To provide your clients access to Exchange Server through a Web interface, follow these instructions:
To create a secure Web site, you'll need a certificate, either from an internal certification authority (CA), or from a trusted third party, like VeriSign or Thawte. You'll then need to export it, along with its private key, for importation on the ISA server.
If you have an Enterprise CA set up within your environment, you can request a certificate from it by following these steps:
On your Exchange server, from the Start, Administrative Tools folder, open the Internet Information Services (IIS) Manager.
Navigate to the Web site containing your Exchange Server installation, right-click that site, and select Properties.
Click the Directory Security tab, and then click Server Certificate.
On the Welcome To The Web Server Certificate page, click Next.
On the Server Certificate page, click Create A New Certificate, and then click Next.
On the Delayed Or Immediate request page, select Send The Request Immediately To An Online Certification Authority, and then click Next.
On the Name And Security Settings page, click Next.
On the Organization Information page, enter the name of your company and an organizational unit, if you desire, and then click Next.
On the Your Site's Common Name page, in the Common Name field, type in the public fully qualified domain name (FQDN) of your Exchange server (for example, exchange.contoso.com).
On the Geographic Information page, select your Country/Region, type in your state's full name (for example, Kentucky), and your city name.
Do not use state abbreviations, like KY, on the Geographic Information page, or your certificate will fail.
On the SSL Port page, leave the default of 443 or type the SSL port you will use, and then click Next.
On the Choose A Certification Authority page, select your CA, and then click Next.
On the Completing The Web Server Certificate Wizard page, click Finish, and then click OK.
See www.verisign.com or www.thawte.com for more information about purchasing trusted third-party certificates.
In Internet Information Services (IIS) Manager, expand the Web site for your Exchange server, and right-click the Exchange virtual directory beneath it, and then select Properties.
Click the Directory Security tab, and then in the Secure Communications area, click Edit.
In the Secure Communications dialog box, select the Require Secure Channel (SSL) check box, and then click OK. Click OK to close the Exchange Properties dialog box.
|Best Practices|| |
Selecting the Require 128-Bit Encryption check box provides a more secure configuration for Outlook Web Access.
Repeat steps 14 to 16 for the ExchWeb and Public virtual directories.
Click View Certificate.
In the Certificate dialog box, click the Details tab, and then click Copy To File.
On the Welcome To The Certificate Export Wizard page, click Next.
On the Export Private Key page, ensure that Yes, Export The Private Key is selected, and then click Next.
On the Export File Format page, select the Include All Certificates In The Certification Path If Possible check box, and clear the Enable Strong Protection check box. Click Next.
On the Password page, type a strong password. You will need to remember this password to import the certificate on the ISA Server computer. Click Next.
On the File To Export page, type the path and name of the file (for example, c:\ExchCert.pfx), and then click Next.
|Best Practices|| |
Ensure that your certificate is saved to a secure location, and is removed after you import it to the ISA Server computer.
On the Completing The Certificate Export Wizard page, click Finish.
Click OK, and then close the Internet Information Services (IIS) Manager console.
Open the ISA Server Management Console and expand your ISA server or array.
Right-click the Firewall Policy node, and from the New menu, select Mail Server Publishing Rule.
The New Mail Server Publishing Rule Wizard appears. Type a name for the rule, and then click Next.
On the Select Access Type page, select Web Client Access, and then click Next to continue.
On the Select Services page, select Outlook Web Access, and then click Next.
If you have e-mail that contains foreign characters, select the Enable High Bit Characters Used By Non-English Character Sets check box. For example, if you are using a German-language computer and open Outlook Web Access, you cannot create new e-mails. Why? Because Outlook Web Access saves new opened e-mails in the folder called Drafts—in German the folder is called Entwürfe—and the save will fail if you don't select the Enable High Bit Characters check box.
On the Bridging Mode page, select Secure Connection To Clients And Mail Server, and then click Next to continue.
Recall that by using bridging, you can force secure communications for all transmissions between the client and the ISA server and the mail server and the ISA server, which is our recommended configuration. Choosing other configurations is an option, but not preferred.
On the Specify The Web Mail Server page, enter the name of the Outlook Web Access site you're securing into the Web Mail Server box, and then click Next.
If you're using SSL bridging, use a host name here or else provide name resolution using a HOSTS file entry for the Mail Server on the ISA server itself.
On the Public Name Details page, determine the names that the public will use to connect to this server—the ISA server will accept only names designated here. In the Accept Requests For drop-down list box, select This Domain Name (Type Below) and type the registered DNS name of the Outlook Web Access site in the Public Name text box. Click Next.
Your clients will use the Public Name value to connect to Outlook Web Access remotely.
On the Select Web Listener page, click New (or choose an already created listener and skip to Step 13).
On the Welcome To The New Web Listener Wizard page, enter a name for this listener, and then click Next.
The IP Addresses page appears. Select the External option. Click Address.
In the External Network Listener IP Selection box, select the Specified IP Addresses on the ISA Server computer in the selected network option, and then, in the Available IP Addresses list, select the external address on which you want to listen for connection requests. Click OK, and then click Next.
You can include other networks if you will use Outlook Web Access from them.
On the Port Specification page, select Enable HTTP and Enable SSL. Click Select, then select the certificate you imported to the ISA server from the Exchange server earlier. Click Next, and then click Finish.
On the Select Web Listener page, click Edit, and then click the Preferences tab. Click Authentication.
Select Basic Authentication, and clear the check boxes for the other authentication methods. Click OK twice. Finally, click Next on the IP Addresses page.
On the User Sets page, select the user sets you want to allow access to, and then click Next.
On the Completing The New Mail Server Publishing Rule Wizard page, click Finish.
Double-click the rule you just created, click the Users tab, and then select the Forward Basic Authentication Credentials (Basic Delegation) check box, and click OK.
Click Apply to commit the changes, and then click OK.
ISA Server 2004 also provides another benefit: preauthentication of connections. ISA Server actually hosts the forms that a user is used to seeing, such as the login screen. This screen queries the user for his or her credentials, and once the user enters them into the form, ISA Server verifies them against Active Directory directory service. Note that RADIUS is also supported, so even ISA servers that do not trust or are not members of a domain can do this preauthentication. ISA Server then takes the result of that verification and embeds the credentials into the actual HTTP headers of the packets that it forwards to the front-end Outlook Web Access server, so the user doesn't receive a second prompt. In effect, the ISA server is vetting your users with an actual Outlook Web Access form, ensuring that they are who they say they are, and actually authenticating them at the perimeter of your network before the packets ever hit the Outlook Web Access server. Figure 16-1 shows this process in detail.
Figure 16-1: Forms-based authentication with ISA Server 2004 and Outlook Web Access.
To configure forms-based authentication, protecting your Exchange server from any nonauthenticated requests, follow these instructions:
In the ISA Server Management console tree, click Firewall Policy.
In the Tasks pane, click the Toolbox tab, expand Network Objects, expand Web Listeners, right-click the Web listener you are using and then select Properties.
If you do not have a Web listener, see Chapter 7, "Configuring Toolbox Elements."
In the Web Listener Properties dialog box (where Web Listener is the name of your Web listener), click the Preferences tab, and then click Authentication.
In the Authentication dialog box, clear the Basic Method check box. Click OK when you receive a warning.
Select the OWA Forms-Based check box, and then click Configure.
In the Idle Session Timeout area, type in the amount of time you want Outlook Web Access to wait before requiring authentication again.
|Best Practices|| |
For public machines, you might want to choose a very low number, between 2 and 5 minutes.
Select whether you want to block any e-mail attachments.
Select Log Off OWA When The User Leaves OWA Site, unless there are good reasons for not doing so.
Click OK to close the OWA Forms-Based Authentication dialog box, OK to close the Authentication dialog box, and then OK once more to close the Web Listener Properties dialog box.
Remember that you cannot use forms-based authentication and another form of authentication on the same listener, just as you can only have one listener per Internet Protocol (IP) address. Therefore, to publish Outlook Web Access with forms-based authentication and something like Active-Server-Sync, you need more than one external IP address.
Click Apply to commit the changes, and then click OK.
You can perform almost the same steps as those to publish Outlook Web Access to publish Outlook Mobile Access or ActiveSync. You need a unique certificate and Web listener (and therefore a unique IP address) for each method published.