The Public vs. Private Dilemma in OWA

Summary: This article discusses the security implications of letting users choose whether their OWA session is public or private. It points out that the default settings in Exchange 2013 are more lenient than previous versions, and recommends using Messageware’s security solutions to mitigate the risks.

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!

RELATED:
Watch a video on High Volume Attacks attacks on Exchange Server

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.

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.

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.

Is your Outlook Web (OWA) Secure?

In just 10 minutes, our OWA Security Audit for On-Premises Exchange will help you identify potential risks associated with your Outlook Web deployment.

This audit will:
Provide insight into the effectiveness of your security policies;
Identify Attachment Security and Data Loss vulnerabilities;
Uncover risks of Unauthorized Access to Outlook Web user sessions;
Highlight the impact these exposures can have on your organization.

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 “CAS1owa (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