While Exchange Server 2010 includes solid security out-of-the-box, further strengthening Outlook Web App is never...
a bad idea. After all, OWA is exposed to the Internet as a Web application and, like any other Internet-facing Web app, is prone to attacks. Here are a few tweaks you can make to bolster OWA 2010 security.
Eliminate the OWA private computer option
When users log into OWA 2010, they have the option to select whether they are accessing OWA 2010 from a public computer or a private computer; many users skip this step. If users do not explicitly choose public or private, OWA assumes they are logging on from a public computer, and therefore uses a more secure profile.
One way to improve OWA 2010 security is to eliminate the private computer access option entirely. This forces users into the more secure profile. The easiest way to do so is to modify the logon.aspx file.
Note: Make sure you create a backup of this file before modifying it.
The logon.aspx file is located in the c:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\Auth folder. To modify it, open the file in Notepad, then locate the following line of code:
<td><input id="rdoPrvt" type="radio" name="trusted" value="4" class="rdo" onclick="clkSec()"></td>
In this line of code, change the type from radio to hidden (Figure 1). After doing so, save your changes.
Next, open a command prompt window and enter the IISRESET command. This resets both Internet Information Services (IIS) and OWA. The logon.aspx file will use your modified code after the reset. As you can see in Figure 2, users can no longer select the This is a Private Computer option.
Another public/private computer option
In some cases it may actually be better to tighten the private computer security settings rather than abandon them altogether. One way to do so is to change the automatic logout setting. Idle OWA sessions are disconnected after 12 hours of inactivity by default. You can modify this setting to make the time-out period much shorter.
You can only adjust the time-out period if you've set up OWA to use forms-based authentication. Also, modifying the time-out period involves editing the server's registry. Remember, making registry modifications is dangerous because you can destroy Windows and/or Exchange if you make a mistake. Be certain to make a full system backup before attempting to adjust the OWA time-out period.
To configure the time-out period, open the Registry Editor and navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchange OWA. Create a new DWORD value, and name it PrivateTimeout.
Note: You can also create a value named PublicTimeout if you want to adjust the time-out period for the Public Computer profile.
Set a decimal value ranging from one to 43,200. This value reflects the amount of time -- in minutes -- before inactive OWA users are logged out.
Another way to enhance OWA 2010 security is to force users to use HTTPS rather than an unencrypted HTTP session. To do so, you must configure IIS to redirect requests to the SSL-encrypted OWA URL. Again, be sure to make a backup; it's very easy to make an error during this procedure.
The first thing to do is ensure that the HTTP Redirect module is installed through Server Manager. After doing so, open the IIS Manager and navigate to Sites -> Default Web Site -> OWA. Select the OWA virtual directory, then double-click the HTTP Redirect icon.
Now select the Redirect Requests to This Destination check box and enter your secure OWA URL. Select the Only Redirect Requests to Content in This Directory (Not Subdirectories) check box (Figure 3).
Many Exchange administrators like to apply HTTP redirection at the Default Web Site level. This ensures that any HTTP requests are redirected to OWA. While this technique does work, there are a number of virtual directories you must exclude in order to keep the client access server functional.
Make sure to disable HTTP redirection for the following virtual directories:
As you can see, there are several different techniques you can implement to harden OWA 2010 security. Remember, though, none of these techniques are a substitute for basic security practices like strong user passwords and staying up-to-date with the latest patches.
About the author
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a chief information officer at a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the nation's largest insurance companies and for the Department of Defense at Fort Knox.