Unauthorized remote access to mail resources by recently-terminated employees.
The key points from the linked article are discussed below. The main thing to note is that in Exchange environments, no hacks are needed for an employee to retain access to mail resources in the immediate hours following termination of employment. Fortunately, there are measures you can implement to prevent this from happening...
Let me set the scene for you. You are a Microsoft Exchange administrator and your organization deployed Outlook Web Access (OWA) and Outlook Anywhere to support remote employees. The company prides itself on a strong IT team that has all the bases covered with respect to email security, but one afternoon the proverbial ‘stuff’ hits the fan.
A disgruntled employee (someone familiar with the company's proprietary information) was terminated earlier in the day, yet he was able to access his email account even though you disabled it in Active Directory (AD) so the account was inaccessible on the domain. The spiteful ex-employee subsequently sent out damaging messages to the entire organization AND to your company’s direct competitors. You are somewhat confused because you confirmed that a local log in to his account on the domain was no longer possible. As upper management relates this tale of woe to you, you get that sinking feeling in the pit of your stomach and in the back of your mind, you start thinking about the last time you updated your résumé…
So what happened? Why was it possible for the employee to still access his mail account externally through OWA and send/receive mail? More importantly, what can you do to prevent this in the future?
The disgruntled employee in this scenario did nothing out of the ordinary to access the system, nor did he need any special technical skills. The first time a user logs on to an Exchange mailbox/OWA using a Web browser, an IIS user token is created. If the Log on Locally right is subsequently revoked, the mailbox will remain accessible for at least 15 minutes. The frustrating thing is that this problem is not new. The loophole is due to a set of sparsely-documented default settings in Exchange that were implemented by Microsoft to improve IIS performance.
To answer the question of why access was still possible, let’s look at what happens to a user’s access when an account is disabled in Active Directory:
- On the internal network, access to everything is disabled immediately.
- External to the network, things are different. Access is denied to everything except OWA and ActiveSync.
There is a clear reason why 15 minutes is the default cache setting. Whenever a user logs in to OWA, ASP packets flood the server during authentication. If this is set to happen too often (e.g., every five minutes), your help desk will receive a high volume of calls from users reporting slow Exchange performance and frequent disconnects. An IIS token cache value of five minutes doesn’t mean that remote users connecting through OWA will need to log back in every five minutes, but it does mean that their credentials will be resent every 5 minutes by the cached token session to obtain a new token. Changing this value has the potential to cause general Network congestion, especially in larger organizations. Trying to address this problem through registry changes is possible but only recommended if the process is clearly understood and documented; if the need to reverse such changes arises, it may be difficult, particularly if the infrastructure holds multiple Exchange servers.
The next important point in this scenario is that all fifteen minute periods are not equal. The fifteen minute flush value is theoretical, i.e. it is fifteen minutes under ideal conditions. What are these ideal conditions? Ideal means that users connecting through OWA are using the latest, fully-patched iteration of Internet Explorer or a Windows mobile phone. If other (i.e., non-Microsoft) browsers or mobile operating systems are used, it may still be possible for disabled accounts to connect to the network for many hours, even though the default fifteen-minute flush value is set. If an OWA session is active when credentials are disabled or changed, this is another point of weakness that influences how long an OWA account will remain accessible to send and receive mail.
To confound the issue, it makes no difference how many times a user’s password is changed in AD while a token is active. The original password and any others that you set for that user can be used to log the user in remotely through OWA during the token’s active period. The reason is because if a user is still logged on when the registry key is updated for the token, that user’s current Time-to-Live (TTL) token for that password stays the same and corresponds to the one used before changes were made to the registry key. The change becomes active only after the user closes all instances of the browser, logs in again, and changes the password. It is only then that the new password will have the TTL of the specified registry key.
What you can do to make sure that a disabled account is actually disabled to keep this from happening to your organization? Here are a few changes to the Exchange configuration that you can make that will help:
1. Remove the NT AUTHORITY\SELF from the full permissions settings: use the Exchange management console (Exchange 2007 and 2010) to remove the NT AUTHORITY\SELF from the full permissions settings for the user whose account you wish to disable. This setting is found under the Recipient Configuration container > Mailbox. Select the user and from the Actions pane on the right hand side, click Manage Full Access Permissions. The setting can be modified from the new window that is generated. If the user already has a session open, the fifteen minute time period will still apply. In the unlikely case that the employee is re-employed by your organization before their mailbox is removed and the mailbox needs reactivation, the NT AUTHORITY\SELF user will need to be added back to the full mailbox rights or the mailbox will not be accessible. Since NT AUTHORITY\SELF is not a true user in terms of AD, and the management console looks in AD to add users, this user back must be re-added via the Exchange management shell with the following command:
Add-MailboxPermission –Identity “*user*” –User “NT AUTHORITY\SELF” –Accessright Fullaccess
If on Exchange 2003 (or earlier), the mailbox must be re-created.
For Exchange 2013, I did not find any clear instructions, but the process is somewhat different. I tested the solution described below in-house and successfully prevented a message from being sent from a disabled account that still had an active OWA session running. Please verify this in your environment as your mileage may vary:
Start by accessing the Exchange admin Center (EAC) and in the Recipients container, locate the Exchange account to be disabled. The first step is to change the permissions on the Exchange account. Open the account`s properties and select the mailbox delegation container (left hand side). Scroll to the bottom of the page and in the Full Access permission options, remove both Exchange Servers and Exchange Trusted Subsystem:
Disable the account in AD, if you have not already done so.
The next step is to move the mailbox to another database (refer to the screenshot below):
- Still in the Recipients container, highlight the Exchange account to be disabled and locate the Move Mailbox option in the left pane of the EAC.
- Click To another database. Name the job in the New migration batch name field, and select the appropriate radio button (primary and/or archive mailbox).
- Proceed with the Mailbox move.
Once the move is in progress, the job can be followed on the migration page of the EAC:
As the move progresses and the changes are synchronising, it will no longer be possible for mail to be sent via OWA from the disabled Exchange account. Attempts to send mail will generate the following message:
2. Disable Mailbox Features: disable all features on the user’s Exchange mailbox from the mailbox properties. From the Mailbox Features tab set the status of OWA, Exchange Active Sync, Unified Messaging, MAPI, POP3, IMAP4, and Archive to Disabled. If on Exchange 2003, configure this in the mailbox features tab in AD).
This can also be achieved using the command shell or through a script running against the terminated account:
Set-CASMailbox –Identity “User_ID” –OWAEnabled:$false –ActivesyncEnabled:$false –MAPIEnabled:$flase –POPEnabled:$false –IMAPEnabled:false
As usual, conditions apply: if the user has an open session from outside the network to their OWA account or ActiveSync, the fifteen minute rule applies before the account becomes disabled (and as explained above, this can take considerably longer). If no sessions are active, the mailbox features will be disabled immediately.
3. Change the Default Interval for IIS User Tokens: as discussed earlier, changing the flush interval has the potential to negatively affect network traffic and should be properly researched before proceeding. The issues that can arise may not be immediate and may even appear months later. Please refer to this Microsoft article for more information on changing the interval.
4. Restart the IIS service on all Exchange CAS servers: this is the easiest measure to implement, but is potentially the most disruptive to user access if done during peak business hours. Resetting IIS will clear the token cache and therefore force new tokens to be issued from all connected users. Given the potential security risk of allowing a disgruntled ex-employee to maintain access to their mail account for even a short time after termination of employment, the disruptive nature of this measure and the inconvenience that follows is justified.
Since there is no way to know which CAS server holds the token of interest and tokens are replicated to each CAS server, bounce the IIS service on all of them (applies to Exchange 2003 through 2013). Do this by opening a command prompt on each server and issuing the following command which will try to stop and restart the IIS service:
IISRESET /no force
Should the command fail or return an error indicating that the service could not be stopped, issue the following command to force the restart:
The impact of this command on users, depending on the environment, can be as minor as getting the Disconnected from Exchange server message in the lower right side of the Outlook client, or it may the generation of the logon box requesting credentials (which can lead to a lot of helpdesk calls).
These are some of the actions that can be applied to secure the mail system. This is an ongoing problem that many Exchange and system administrator face on a regular basis. There are undoubtedly many other creative ways of approaching the issue. Have you experienced this problem in your organization and how did you overcome it? What other solutions did you implement to avoid this type of security breach?