Let’s talk about mailbox permissions. People often get a little confused between store-level mailbox permissions and Active Directory-level mailbox permissions. They are similar but not the same. For clarity it may help for us to look at them all.
Note: this post is written specifically against Exchange Server 2007. For Exchange Server 2010, storage groups disappear – mailbox stores acquire storage group attributes, they are promoted to equal status (you could see this coming, as a number of features in Exchange Server 2007 only worked when you had a single mailbox store per storage group). So, the contents of this post apply equally to Exchange Server 2010 – just where-ever you see “storage group”, replace that with “mailbox store”.
Mailbox permissions include: FullAccess, SendAs, ExternalAccount, DeleteItem, ReadPermission, ChangePermission, and ChangeOwner. This list does not include “Send on Behalf”. That’s because a user can set “Send on Behalf” for another user by defining the other user as a delegate and that’s handled separately from mailbox permissions.
Relevant Active Directory permissions include: FullControl, SendAs, ReceiveAs, Delete, and ViewInfoStoreStatus. Three of these (SendAs, ReceiveAs, and ViewInfoStoreStatus) are so-called “extended rights”, which means they are handled somewhat differently than standard access rights.
The AD permission ViewInfoStoreStatus allows a specific user or group to do just that – view the status of an information store. It doesn’t map to anything at the mailbox level. I don’t believe that it is used in Exchange 2007 and above. It had applicability in the Exchange 2000 and Exchange 2003 timeframe when administration of Exchange was handled at the “Administrative Group” level, and ViewInfoStoreStatus was assigned to an administrative group for the administrators of that administrative group (and set to inherit down through all the servers and stores in that group).
The AD permission FullControl includes Delete, SendAs, and ReceiveAs at the AD level. At the mailbox level this maps to FullAccess and SendAs.
The AD permission ReceiveAs maps to FullAccess at the mailbox level. Note that this does not include SendAs or ExternalAccount permissions. There is no way (even though some Microsoft documentation states otherwise) to provide read-only access to a mailbox via permissions.
The AD permission SendAs maps to SendAs at the mailbox level. Note that while it is possible to set Send-As on the mailbox itself, without having it set in AD, you will not be able actually Send-As using Outlook – it depends on Send-As being set within AD.
The AD permission Delete maps to DeleteItem at the mailbox level.
The store permission FullAccess includes all mailbox permissions except SendAs and ExternalAccount.
Setting the AD permission does not cause the mailbox permission(s) to be set (AD has no direct knowledge of Exchange). One must presume that the information store service is smart enough to check both. I have no idea of the official precedence map of AD permissions vs. store permissions. However, behavior indicates that AD permissions are evaluated first, and if they produce a “pass” then the store permissions are evaluated to get the final result (similar to the “share” vs. “NTFS” precedence rules).
The AD permissions can be set on a storage group or a mailbox store, and apply to all mailboxes in that storage group or mailbox store (if set for inheritance). There is no mechanism to do that within the mailbox store itself (that is, there is no cmdlet for Add-MailboxDatabasePermission or Add-StorageGroupPermission, nor do I believe that a store has a concept of a security hierarchy above the mailbox level). Also, while you can set SendAs at the storage group or mailbox store level, this just means that you can impersonate the storage group or mailbox store – it does not mean that you can Send-As for all accounts in that storage group or mailbox store. That permission must be set on a per-mailbox basis.
There is a good whitepaper for understanding store and AD permissions written against Exchange 2000 and Exchange 2003. It is still at microsoft.com/downloads : Working with Store Permissions in Microsoft Exchange 2000 Server and Exchange Server 2003. However, it is a little dated and there are a couple of errors in the document. The basics are still good, but Exchange 2007 reintroduced the idea of setting actual permissions on the mailbox (in 2000 and 2003, you could set mailbox permissions only before the mailbox was created, everything else was set against the AD user object). Exclusive of the impact of Role Based Access Control (commonly referred to as RBAC), I believe that Exchange Server 2010 continues to follow the Exchange Server 2007 rules.
While we have not discussed them here, note that the store-level permissions available to mailboxes are the same permissions available to public folders (excepting only ExternalAccount). And, with the exception of SendAs and ExternalAccount, these are the same permissions available to subfolders within a mailbox and a public folder.
Implementation note:
From a technical perspective, the AD attributes actually represent Access Control Entries set within the nTSecurityDescriptor object assigned to a user object within Active Directory.
For more information on Access Control Lists, Access Control Entries, and the nTSecurityDescriptor object, see Displaying Security on Active Directory, Exchange, and Registry Objects and Windows Permissions – Access Control Lists.
Until next time…
If there are things you would like to see written about, please let me know!
P.S. Thanks to Ross Smith, IV of Microsoft for clarifying a couple of points contained in this article.
Follow me on twitter: @EssentialExch