Tip

Three ways to tighten OWA 2010 security

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

    Requires Free Membership to View

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>

Figure 1. Change the type from "radio" to "hidden."

In this line of code, change the type from radio to hidden (Figure 1). After doing so, save your changes.

Figure 2. The modification removes the private computer option.

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.

URL redirection

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.

Figure 3. You can redirect HTTP requests to the HTTPS OWA site.

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:

  • Aspnet_client
  • Autodiscover
  • Ecp
  • EWS
  • Microsoft-Server-ActiveSync
  • OAB
  • PowerShell
  • Rpc

Final thoughts

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.

This was first published in January 2013

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.