In one of my previous articles, we spoke about Outlook on the Web (OWA) for daily use. In this article, we will chat about setting timeouts on Outlook on the Web so that just like bank websites that timeout after a few minutes, the same will happen with OWA in your organization. While security IT personnel will praise you for this, end-users will not be applauding you as they become frustrated because they have to log in again and again after five or 10 minutes when the session becomes inactive.
Before we jump into how to configure this in Exchange 2010, let’s first understand the limits that are set by default within Exchange. In Exchange 2010, you have the options that have limits that can be configured, they are:
LogonPagePublicPrivateSelectionEnabled
Public and private timeouts defaults for Outlook on the Web
The public option is disabled by default in Exchange 2010. If you look at the option for private, the default timeout is eight hours. Eight hours is just too long and will need to be changed. Imagine that you are sitting at a coffee shop connected to the public WiFi, and your session remains open for this long. It gives an attacker plenty of time to sniff the traffic and grab your details. If you connect to a 3G or 4G connection through a VPN, your traffic will be more secure than connecting to the coffee shop’s WiFi, but you still need to have the Outlook timeouts in place.
There are actually three options that you need to set for this to take effect on your Exchange Server 2010 or higher. From an elevated command prompt on the Exchange 2016 Server, run the following two commands:
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\MSExchange OWA" -Name PrivateTimeout -Value 15 -Type DWORD
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\MSExchange OWA" -Name PublicTimeout -Value 15 -Type DWORD
In both settings, I have set the default value to 15 minutes. You can change this to what your organization requires. The next option you need to set is the following:
ActivityBasedAuthenticationTimeoutInterval
This value can be set to 15 minutes to match what you have set for OWA on both private and public timeouts. For Microsoft 365/Exchange Online, the setting is pretty much the same, and it is an organization-wide setting and not individual user settings. The command to use for that is:
Set-OrganizationConfig -ActivityBasedAuthenticationTimeoutInterval 00:15:00
With Exchange Online, you need to ensure the setting for the above is also enabled. If we head over to Exchange 2019, you also have org-wide settings that can be configured. If we run the command below, we can check the default value, which is six hours on Exchange 2019. The command is formatted with only the Activity info:
Get-OrganizationConfig | FL activity*
You can set the Outlook timeouts to whatever the organization’s security requirements are. In this example, we chose to set it to five minutes, and this was achieved using the following command:
Set-OrganizationConfig -ActivityBasedAuthenticationTimeoutInterval 00:05:00
Active Directory replication
If you are aware, everything you set in Exchange 2016/2019 or legacy requires Active Directory replication to take place. For those new to these technologies, Exchange and Active Directory work hand in hand. Anything you set on Exchange is not instantly set and does take time. If you wonder why you can see the settings in Exchange but you do not see anything happen in Outlook on the Web, it is because of this. In a lab environment, the settings will almost be instantly replicated or set because you only have one or two domain controllers in a small environment.
The key here is to educate your end-users on security and awareness of why you are applying this setting. Once they understand, you may still get pushback from some end-users, but at least they will know why you are doing this. If you are running coexistence in your environment, Exchange 2010 and Exchange 2016, or Exchange 2010 and Exchange 2013, you need to ensure you configure the settings on both sets of Exchange Servers.
You can also take this a step further. Let’s say you have an F5 load balancer in place that handles the OWA/Outlook on the Web Traffic. You can create multiple traffic groups where one will expire the session after 15 minutes but the other will have a persistent connection for, say, one hour. You will then split your Exchange Servers in the different pools, so let’s say 4 goes to Pool 1, which will log off the session in 10 minutes and 4x servers go to Pool 2, and this persistence is maintained for one hour. Again, this is dependent on the business requirements.
Consider your end-users
I have seen some companies want the lowest idle session timeout so they ensure nothing can be breached but just remember, you will frustrate end-users if you set things too low. I would suggest that you have a test pool on your load balancer and test it out with some users. Get feedback from them so you can give the business a more accurate explanation about which timeouts work better.
On a final note, remember the security of the company and the security of the end-users is key. As mentioned, if they are educated well enough, they will understand the limits set and be more vigilant when it comes to these things, and the ones that do take note will advise the others to follow. It has a ripple effect.
Featured image: Shutterstock
