Exchange 2010 - Security - Auditing administrator access to mailboxes ~ NEW TECH

Introduction

From time to time, on the Technet Exchange forums, someone will ask a question about Exchange administrators accessing another user's mailbox. They may suspect that an administrator is reading other staff member's email or management may simply have requested that IT take measures to prevent this proactively.

Some respond that you have to trust your administrators and if you cannot, fire them and hire administrators that you can trust.

Some propose a more technical - and more complex - solution with S/MIME or IRM/RMS. The key point here is that since these solutions are based on certificates and public/private key pairs, the administrators that manage Exchange and the certificate administrators should not be the same. If this is the case, users can encrypt their email with S/MIME and since the Exchange administrators do not have the appropriate key, they could not open and read the email of other employees.

In this post, I'm going to take a look at another approach based on monitoring...

access to mailboxes and...
modifications to access rights on mailboxes.

The objective is not to block administrator access to mailboxes but to log any attempts to access these mailboxes.

This approach is really only feasible in an organization with more than one administrator on staff. The person (or team) responsible for monitoring the logs would be different from the person that manages Exchange.

Default permissions on mailboxes (administrator access)

By default, administrators do not have access to anyone's mailbox. In fact, if we except the system itself, only the user has access to their mailbox. This is represented by the entry "SELF".

Right-click on the mailbox in question and select "Manage Full Access Permission".

However, the resulting entry in the "Manage Full Access" interface is the product of a rather complex interaction among permissions that is better illustrated in the output of the Get-MailboxPermission cmdlet (please feel free to skip to the summary that follows, below):

*************************

Get-MailboxPermission ana.hayes@mynet.lan | fl User,AccessRights,IsInherited,Deny

User : NT AUTHORITY\SELF
AccessRights : {FullAccess, ReadPermission}
IsInherited : False
Deny : False

User : MYNET\Domain Admins
AccessRights : {FullAccess}
IsInherited : True
Deny : True

User : MYNET\Enterprise Admins
AccessRights : {FullAccess}
IsInherited : True
Deny : True

User : MYNET\Organization Management
AccessRights : {FullAccess}
IsInherited : True
Deny : True

User : MYNET\Exchange Organization Administrators
AccessRights : {FullAccess}
IsInherited : True
Deny : True

User : MYNET\admin
AccessRights : {FullAccess}
IsInherited : True
Deny : True

User : MYNET\Exchange Servers
AccessRights : {FullAccess}
IsInherited : True
Deny : False

User : MYNET\Organization Management
AccessRights : {ReadPermission}
IsInherited : True
Deny : False

User : MYNET\Public Folder Management
AccessRights : {ReadPermission}
IsInherited : True
Deny : False

User : MYNET\Exchange Public Folder Administrators
AccessRights : {ReadPermission}
IsInherited : True
Deny : False

User : NT AUTHORITY\SYSTEM
AccessRights : {FullAccess}
IsInherited : True
Deny : False

User : NT AUTHORITY\NETWORK SERVICE
AccessRights : {ReadPermission}
IsInherited : True
Deny : False

User : MYNET\Exchange Servers
AccessRights : {ReadPermission}
IsInherited : True
Deny : False

User : MYNET\Delegated Setup
AccessRights : {ReadPermission}
IsInherited : True
Deny : False

User : MYNET\Exchange View-Only Administrators
AccessRights : {ReadPermission}
IsInherited : True
Deny : False

User : MYNET\Organization Management
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited : True
Deny : False

User : MYNET\Exchange Organization Administrators
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited : True
Deny : False

User : MYNET\Exchange Trusted Subsystem
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited : True
Deny : False

User : MYNET\admin
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited : True
Deny : False

User : MYNET\Enterprise Admins
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited : True
Deny : False

User : MYNET\Domain Admins
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited : True
Deny : False

******************************

Let's attempt to summarize.

In Exchange 2010 at least, READ access to the user's mailbox is specifically denied to common administrative groups. This means that even if they belong to a group that may have READ access otherwise, they are still denied READ access because of this single "Deny" permission.

For example:

User : MYNET\admin
AccessRights : {FullAccess}
IsInherited : True
Deny : True

On the other hand, Exchange administrators most certainly can change permissions on the mailbox.

We cannot see this in the GUI but the Get-MailboxPermission cmdlet shows all these details:

User : MYNET\admin
AccessRights : {FullAccess, DeleteItem, ReadPermission, ChangePermission, ChangeOwner}
IsInherited : True
Deny : False

"ChangePermission" is not denied here. Full Access is not either but it is elsewhere. A single "Deny" permission will suffice to block access.

Let's test this!

When we need to access another person's mailbox in Outlook, we follow this path (after opening Outlook - Outlook 2010 in this example):

Yes, the administrator is able to add the mailbox to Outlook... but cannot open it. If I try, this is what happens:

Now let's have the administrator grant himself "Full Access" to Ana Hayes' mailbox:

Here is the EMS - PowerShell equivalent:

Add-MailboxPermission 'CN=Ana.Hayes,OU=ExchangeUsers,DC=mynet,DC=lan' -User 'MYNET\admin' -AccessRights 'FullAccess'

This changes the output of the Get-MailboxPermission cmdlet. Now the "Deny" for the READ permission is no longer "True":

*************************

Get-MailboxPermission ana.hayes@mynet.lan | fl User,AccessRights,IsInherited,Deny

User : NT AUTHORITY\SELF
AccessRights : {FullAccess, ReadPermission}
IsInherited : False
Deny : False

User : MYNET\admin
AccessRights : {FullAccess}
IsInherited : False
Deny : False

************************

Now the admin can open the the mailbox of Ana Hayes and read her email!

In this case, the content is not very interesting but if it were, the administrator could read it.

Note: the admin CANNOT open the email message marked with the padlock which has been encrypted with S/MIME:

However, the administrator has left traces! Granted, we would have to know where to look to find those traces.

So... where do we look?

There are at least two places we can find this information:

The Powershell equivalent of the actions performed in the EMC is logged in the MSEXchange Management section of the Event Viewer.
We can perform a search for "non-owner mailbox access" in the Audit section of the Exchange Control Panel (ECP).

Actions added to the MSEXchange Management log

On the mail server, we have to open the Event Viewer and go to the MSEXchange Management section:

At that point, we are looking for a "needle in a haystack". The Event ID is 1 but the Event ID for the execution of other Powershell cmdlets is also 1. This is how the entry appears:

We can see that even though the EMC (GUI) was used to grant the administrator access to the mailbox, the underlying PowerShell cmdlet was logged in the Event Viewer.

Of course, the administrator could clear the MSExchange Management log.

But such an event would be logged in the System Log:

But what if the admin clears the System Log? That too would be logged:

Otherwise, the loss of these entries would be noticed if anyone else is monitoring the logs. That is the key point. If there is only one administrator, there's probably no one else looking at the logs anyway.

We've demonstrated that an adminstrator cannot grant himself access to someone else's mailbox without the event being recorded in the Event Viewer logs. However, we have also seen that even if a second person is monitoring these logs, it is not easy to find evidence of such actions even when the evidence is there.

Is there a better way?

Yes.

We can use the ECP Audit option "Search for Mailbox Access by Non-Owners".

Search for Mailbox Access by Non-Owners

Once we have logged into the ECP (I'll assume that if you are managing an Exchange 2010 server, you know how to do this), we must go to the following location:

Mail | Options: Manage My Organization | Roles and Auditing | Auditing (tab)

Select the option "Run a non-owner mailbox access report":

At first, this option does not seem very convincing. I know I've accessed Ana Hayes' mailbox as administrator yet no results appear:

Note: the "Search" button, not shown in the screenshot above, is off to the right.

In fact, as we can see below, mailbox auditing is not enabled by default so we have to enable it manually:

****************

[PS] C:Get-Mailbox ana.hayes@mynet.lan | fl *auditenabled*

AuditEnabled : False

[PS] C:\>Set-Mailbox ana.hayes@mynet.lan -AuditEnabled $true
[PS] C:\>
[PS] C:\>Get-Mailbox ana.hayes@mynet.lan | fl *auditenabled*

AuditEnabled : True

*****************

The problem is that it does not function even after that...

"There are no items to show in this view".

I selected "All non-owners".

I've been clicking all over the place in Ana Hayes' mailbox. There is obvious access but nothing is being logged...

Here is what's happening.

Not all actions are logged. In fact, simple access is not logged for "Delegates".
Administrators that have been granted (or that have granted themselves) "Full Access" are considered "Delegates".

The following commands show what actions, by default, are logged, after logging is enabled:

*********************

[PS] C:\>(Get-Mailbox ana.hayes@mynet.lan).auditadmin

Update
Move
MoveToDeletedItems
SoftDelete
HardDelete
FolderBind
SendAs
SendOnBehalf
Create

[PS] C:\>(Get-Mailbox ana.hayes@mynet.lan).auditdelegate

Update
SoftDelete
HardDelete
SendAs

*********************

In particular, the action "MessageBind" which consists of viewing or opening a message is not logged by default for anyone - even when auditing is enabled. Strangely enough, it appears that we cannot add the action "MessageBind" for delegate auditing. I did try:

********************

[PS] C:\>Set-Mailbox ana.hayes@mynet.lan -auditDelegate update,softdelete, harddelete,sendas,create,folderbind,messagebind

Invalid audit operation specified. Supported audit operations for Delegate are None, Create, FolderBind, SendAs, SendOnBehalf, SoftDelete, HardDelete, Update, Move, and MoveToDeletedItems.
+ CategoryInfo: NotSpecified: (Microsoft.Excha...asks.SetMailbox:SetMailbox) [], RecipientTaskException
+ FullyQualifiedErrorId : DB4194A

********************

After all is said and done, since the administrator is considered a "delegate" here, we cannot audit the reading of an email by an administrator!

Given the default settings, results could only be obtained if I created a new folder and moved a message to this folder. Besides the creation of the folder, this resulted in a "soft-delete" of the message which was logged:

Let's see if we can at least audit folder access?

I add the action FolderBind to the list of audited actions with the following results:

******************

[PS] C:\>Set-Mailbox ana.hayes@mynet.lan -auditDelegate update,softdelete, harddelete,sendas,create,folderbind

[PS] C:\>

[PS] C:\>(Get-Mailbox ana.hayes@mynet.lan).auditdelegate

Update
SoftDelete
HardDelete
FolderBind
SendAs
Create

******************

However, I seem to obtain no more results than before (two hours earlier).

In fact, the logging process seems to require a minute or two.

If I wait a moment (several minutes) the "Open Folder" actions are indeed logged:

The methods above allow monitoring of administrator access to mailboxes in Exchange 2010. They do require some configuration effort.

Exchange 2007 did not provide any of the options presented above, but rather another method that required the logging level for the MSExchangeIS service to be increased to "medium". For more information, please consult the references below, in particular the article by Neil Hobsen.

References:

Auditing Mailbox Access (Exchange 2010) - by Nuno Mota

These articles apply to Office 365 but the content seems to apply to Exchange 2010 as well:

Use Auditing Reports in Exchange Online

Run a Non-Owner Mailbox Access Report

Run a non-owner mailbox access report in Auditing

Auditing mailbox access in Exchange 2007

Exchange Team Blog - Service Pack 2 Highlight: Mailbox Access Auditing

Exchange 2007 Mailbox Access Auditing - by Neil Hobsen

Thank you for reading the article about Exchange 2010 - Security - Auditing administrator access to mailboxes on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.

Exchange 2010 - Security - Auditing administrator access to mailboxes

New articles :