Securing an Exchange Online mailbox after an employee is fired

In my last post I covered the process that you can use to secure an on-premises Exchange mailbox after an employee is fired from the organization. The situation is different when the mailbox is in the cloud because some of the same conditions and levers do not exist for administrators inside Office 365. Thus, a slightly different approach is necessary.

Remember that the on-premises directory is usually the master in a hybrid organization, so if you're in that situation, the steps outlined for securing on-premises mailboxes will probably suit your needs.

In an on-premises environment mailboxes can be retained in fully working order for as long as they are required. The same is true for Office 365, but you probably don't want to pay the monthly fee for a mailbox that isn't going to be used and is only being kept in case some of its contents are required in the future. Therefore, when someone leaves and their mailbox needs to be preserved, we need to secure access to the mailbox to stop any interference with its contents and then move the mailbox into a suitable status for long-term preservation.

The first step is to change the password for the user account:

Set-MsolUserPassword –UserPrincipalName [email protected] –NewPassword "Testing123" –ForceChangePassword $False

Next, we put the mailbox on litigation hold to ensure that no information can be removed from the mailbox. This code writes the current date and user name into the retention comment as a note to let administrators know who put the hold on the mailbox. In cases when you suspect that the terminated employee might attempt to remove data as soon as they hear any indication that they might be leaving, you can preserve data by putting the mailbox on hold in advance. It is reasonable to assume that HR will not want Exchange administrators to have advance knowledge of the fate of their co-workers. This issue can be addressed by creating an RBAC role that allows HR to place a mailbox on hold as they need.

Set-Mailbox –Identity 'Rob Young' –LitigationHoldEnabled $True –RetentionComment ("Employee Terminated on " + (Get-Date) + " by " [System.Security.Principal.WindowsIdentity]::GetCurrent().Name))

To prevent the user using a mobile device that they still have and is configured to access the mailbox, we issue a remote wipe for all ActiveSync devices registered with the mailbox. This ensures that any attempt to access the mailbox that might use cached credentials will fail.

Get-MobileDevice –Mailbox 'Rob Young' | Clear-MobileDevice

Two choices exist as to how to preserve the mailbox. It can be converted into a shared mailbox or it can be made into an inactive mailbox.

The Remove-MsOlUser cmdlet is run to remove an Office 365 user account. In this case, the RemoveFromRecycleBin switch tells Office 365 that the account should be removed immediately and not retained for 30 days.

Remove-MsolUser –userPrincipalName '[email protected]' -RemoveFromRecycleBin

The mailbox can remain in the inactive state for a sustained period. It can be recovered or restored from the inactive state if required and information held in the mailbox remains available for eDiscovery searches. If you want to export information from a mailbox to a PST (for long-term preservation or to provide to a third-party investigator) you can do this by running a Compliance Search in the Compliance Center, specifying just this mailbox as the source.

When you convert a user mailbox to a shared mailbox, the mailbox retains all of the assigned email addresses and can continue to receive email sent to the mailbox. Obviously someone will need to process messages that arrive into the mailbox to let the senders know that the intended recipient no longer works at the company. Alternatively, you can change the assigned email addresses so that any new messages sent to the mailbox are bounced.

Any inbound messages sent to an inactive mailbox will be bounced automatically because the addresses previously assigned to the mailbox are removed from the directory when the user account is deleted and are no longer valid. You can let people who attempt to contact the now-departed employee receive the normal non-delivery notification or you can attempt to provide a better experience by telling them why the person they attempted to contact is no longer available.

Exchange Online doesn't have a way to inform correspondents that a mailbox is now inactive, but we can do this by creating a shared mailbox to hold the email addresses previously assigned to inactive mailboxes or the old addresses of user mailboxes that have been converted to shared mailboxes. In effect, you use the shared mailbox (which doesn't need an Office 365 license) to redirect inbound messages so that the senders will receive some custom information about the person who used to own the now-defunct email addresses. A shared mailbox can easily hold 40 or more email addresses and you can use several mailboxes if needed to accommodate more than this number.

The shared mailbox will act as a black hole if you just add the email addresses to it. Exchange will deliver inbound messages but unless anyone opens the shared mailbox to process and respond to the email, the sender will never know that their intended correspondent has moved on. We therefore need an automatic bounce mechanism, which is easily provided by the combination of a distribution group and a transport rule. Here's how:

New-TransportRule "Block Email to Disabled Mailboxes" -SentToMemberOf "Disabled Mailboxes" -RejectMessageReasonText "Unfortunately the person with whom you attempted to communicate is no longer with our company." -Enabled $True

Once enabled, the rule will reject any message sent to one of the SMTP addresses held by the shared mailboxes in the distribution group. It's a simple but effective way to provide a better user experience.

The steps required to disable and preserve an employee's account in a hybrid deployment are different. Remember that in this scenario, the on-premises Active Directory is the master and all changes to accounts and mailboxes are made on-premises and then synchronized to Office 365, which usually creates a delay before a guaranteed block can be placed on an account. The steps described in the post about preserving a mailbox for a departing on-premises employee will be helpful in creating your checklist for preserving hybrid mailboxes.

Finally, remember that an ex-employee might have accumulated information elsewhere in Office 365 that needs to be identified and secured. They might own some public folders or SharePoint sites and might have used OneDrive for Business to hold files. Some good advice on that topic can be found in this Microsoft support article.

All of this proves that securing information after someone departs is a task best understood and practiced before the need arises as otherwise a high risk exists that something important wil be overlooked.

Follow Tony @12Knocksinna