The Public vs. Private Dilemma in OWA

If you are an IT or security professional working with Microsoft Exchange, I have a question for you: would you ever let a user at your company plan out the security protocols that the entire organization must follow? Probably not, so why leave these sensitive security decisions in the hands of users when they access their corporate mail via Outlook Web App (OWA)? If there are no additional security measures in place around OWA, then users are in fact the ones to choose!

Forms-Based Authentication and Cookies

If you have forms-based authentication (FBA) enabled for Exchange 2010 or Exchange 2007 (or even Exchange 2003), many of the security controls configured are dependent on whether your users select either “This is a public or shared computer” or “This is a private computer” when they sign in. With Exchange 2013, this option is actually hidden by default, and your users are instead logged in as “private-computer” users.

Exchange 2010 Outlook Web App FBA Page
When using FBA authentication, a cookie is stored in the browser cache with the user’s encrypted session information. This cookie is used to determine the idle time allowed for the OWA session before the session is automatically terminated. For public computers, the default time-out value set is between 15 and 22 minutes; for private computers, the default session time-out value is between 8 and 12 hours. This timeout is used to ensure that users that fail to log out of their active OWA sessions will eventually have their sessions ended. The caveat is that user’s OWA sessions remain authenticated and accessible until the cookie timeout expires.

In addition to session time out limits, the public vs. private option that users select determines the type of file and data access granted to them. Options like access to windows file shares, SharePoint documents, WebReady document viewing, or direct file access are all dependent on which option your users select when they sign in. Setting more restrictive options for public access and more lenient for private access gives a false sense of security, as it is the users that are actually choosing which to follow when they sign on, rather than having the system apply the correct policies.

Exchange 2013 OWA Authentication

By default, the OWA 2013 sign on page no longer provides users with the public computer vs. private computer option when they log in. Instead, users simply enter their user name and password and are ready to start working. Simple. Easy. However, you can still configure the 2013 FBA page to show users the public vs. private options; see the references section at the end of this article for steps to do so.

The default cookie timeouts in Exchange 2013 are still 15 minutes for public computers and 8 hours for private computers. However, the issue with Exchange 2013 is that the default security settings for OWA sessions are based on the “Private computer access” settings. This means that users’ OWA sessions, and their privileged access to data, are now available for between 8 and 12 hours.

Exchange 2013 Outlook Web App FBA Page

Security Implications and Next Steps

According to a Microsoft TechNet article, “although automatic time-out greatly reduces the risk of unauthorized access, it doesn't completely eliminate the possibility that an unauthorized user might access an Exchange mailbox if a session is left running on a public computer” and “make sure that you warn users to take precautions to avoid risks, such as by telling them to sign out from Outlook Web App and close the Web browser after they've finished using Outlook Web App.”

The assumption that if you educate your users in hopes that they will understand and act accordingly is very problematic. If you had to work on a lengthy email for a customer, and found that your session kept ending, forcing you to log back on every 15 minutes unless you signed in with the “private computer” option, would you ever choose the public option again? With email accounts rich in sensitive information, the implications of a vulnerable session range from loss of competitive data to breach of compliance and privacy laws.

There are many reasons why users may fail to log out of an active OWA session, and education is not the appropriate strategy to prevent this. To rely on users as the sole gatekeeper to your corporate networks and data is a very poor security strategy. Fortunately, there are a number of options available to mitigate or even prevent these security risks from occurring.

Among them are Messageware’s suite of security solutions for OWA, which provide role and criteria-based security relating to session, navigation, and document access control. The security provided with Messageware is set at the server-level and therefore independent from the decisions users make when signing on to OWA. It ensures that the IT security group, not the users, dictate what policies are set and enforced within an organization.

Keeping Microsoft Exchange Secure

Complete our OWA Security Audit to see if you are protected from, or vulnerable to, the scenarios just discussed.

Read more about:
Messageware TimeGuard – Session Security for Outlook Web App
Messageware NavGuard – Navigation Security for Outlook Web App
Messageware AttachView – Attachment Security for Outlook Web App

 

References

Microsoft TechNet, Understanding Authentication for Outlook Web App: http://technet.microsoft.com/en-us/library/bb430796%28v=exchg.141%29.aspx

Microsoft TechNet, Configure Public and Private Computer File Access: http://technet.microsoft.com/en-us/library/bb124232(v=exchg.141).aspx

Configuring Public vs. Private Logon Parameter in Exchange 2013:

By running the Set-OwaVirtualDirectory cmdlet, you can enable or disable security and user features for OWA for Exchange 2013. The LogonPagePublicPrivateSelectionEnabled parameter specifies whether the Outlook Web App logon page includes the public computer or private computer option. By default, this parameter is set to False for Exchange 2013, which means that users do not see this option when signing in to OWA.

To change this parameter, run the following cmdlets:

Set-OwaVirtualDirectory “CAS1\owa (Default Web Site)” -LogonPagePublicPrivateSelectionEnabled $True IISreset /noforce

For more information on the different parameter settings available for Exchange 2013, view the Microsoft TechNet article, Set-OwaVirtualDirectory: http://technet.microsoft.com/en-us/library/bb123515%28v=exchg.150%29.aspx

For more information on configuring timeout values in Exchange 2013, view the following article from MSExchange.org http://www.msexchange.org/kbase/ExchangeServerTips/ExchangeServer2013/OutlookOWA/how-configure-public-and-private-computer-settings-owa-2013.html

April 4, 2014 | Topics: Blog, OWA Security

Recent Posts

A World Leader in Microsoft Exchange Security

Join 30,000+ people that receive news, Messageware's security advice and tips