Exchange Best Practices: Administrator Access to User Mailboxes

In many organizations there is a clear corporate policy that work email accounts belong to the company, not to the employee, and that the company has the right to monitor and inspect employee email at any time. I personally don’t like those policies, because they are often worded in a way that removes any expectation of privacy or confidentiality, even for work related emails. That’s just not something that sits well with me. Accessing an employees email is something that should be done only under specific circumstances, and by appropriate people, such as a HR or legal investigation.

Unfortunately, some email admins interpret such policies as allowing them to access user mailboxes any time they like, under the guise of “support”. The ability for an administrator to access another person’s mailbox does not require very high admin privileges, and in a culture of “we can access mailboxes when we want to” with no control or oversight, it opens up the possibility of some pretty dangerous situations. Over the years I’ve seen multiple cases of stalking, harassment, and other illegal activities that have resulted in job losses, criminal charges, and significant liability for the company. All because admins accessed other people’s mailboxes whenever they like, with no regulation or auditing.

Obviously none of that is good, and blanket access to mailboxes should never be considered an acceptable situation. The best practice that I recommend is to not have blanket, persistent access to the mailboxes in your organization. So what’s the solution? It comes in several parts.

Policy

Your corporate IT policy is likely not the issue here. Companies do need the right to monitor and inspect employee email, and that needs to be communicated in their IT policy. The issue is more likely with your IT department policies, which a surprising number of companies seem to forget about. I’ve sat through countless induction sessions around ethics, harassment, financial security, and other risk areas for the business, but only a small number that had any IT-specific policies in place around use of administrative privileges (other than your standard change control stuff).

So first things first, if you have no IT policies governing how your team uses admin rights, and how they access other users’ data in mailboxes (or elsewhere), then now is the time to start drafting them.

Configuration

One of those horrible practices that has carried over from the bad old days of systems administration is configuring blanket access for admins to all of the mailboxes in Exchange. It was usually meant as a time-saving solution, so that mailboxes could be quickly accessed when needed. Other times it was due to laziness – access is granted for a specific reason, but never removed again. Often this was coupled with the use of admin accounts as day to day user accounts for IT staff, which is a separate issue.

It’s the type of practice that leads to questions like this one about unexpected permissions appearing on mailboxes. If you’ve got ACLs set on databases that give you access to all of that database’s mailboxes, or a step in your new user provisioning that adds the permissions when the mailbox is created, then that is something I recommend you stop doing.

If you’re not sure what your current situation is with permissions on mailboxes throughout your organization, there’s scripts like this one that can help you with that.

Auditing

Exchange provides you with two types of auditing that allow you to capture who is accessing other people’s mailboxes:

• Admin audit logging will track when IT admins grant themselves permissions to someone else’s mailbox, and whether they’ve removed the permissions at the end of the support case. Any such actions should be traceable to a support ticket and/or an approval process for accessing the mailbox.
• Mailbox audit logging, if enabled (which it isn’t by default) and configured correctly, will track any actions a person takes once they have access to a mailbox. Mailbox audit logging is useful for proving what a person did, as well as what they *didn’t* do while they had access to a mailbox. When an accusation is made against an administrator for accessing or deleting something, having audit logs that show that they didn’t access it, or that someone else deleted it, helps resolve the dispute.

Reporting

Auditing is useful, but audit logs don’t hang around forever (unless you’re extracting the data and archiving it yourself). So it’s important to regularly audit what your admins are doing. This can be a random sample, or a targeted review of high-impact actions (e.g. Add-MailboxPermission is potentially more sensitive than Set-Mailbox). Importantly, your staff should be aware that the auditing is being performed. Knowing that your actions are auditable and are being reported on is a wonderful reminder for IT staff to stick to the policies and procedures that are in place.

Summary

If you’ve got no regulation of auditing of IT staff access to user mailboxes today, it’s time you put new measures in place. Email just happens to be a good place to start with this. The same approach can be applied more broadly across your environment, managing how your admin staff access end user data of all types.