Recipe5.23.Granting Users or Groups Permission to Access Other Mailboxes

Recipe 5.23. Granting Users or Groups Permission to Access Other Mailboxes

Problem

You have a mailbox and need to allow either an additional user or a group of users to access information within it. This mailbox could either be a normal user mailbox or a resource mailbox, used to book a resource such as a conference room, audio/video equipment, or a company car.

Solution

Using a graphical user interface

Log on to any machine in your domain that has the Exchange management tools installed.
Open the ADUC snap-in (Users and Computers.msc).
Browse to the container that holds the target user account.
Ensure that the Advanced View is selected on the View menu.
Right-click the user account whose mailbox you want others to be able to access and click Properties.
Select the Exchange Advanced tab and click Mailbox Rights.
Click Add and select the users and groups you wish to have permissions to the mailbox. Click OK.
In the Allow column of the Permissions list, make sure Full mailbox access is checked. Click OK.
Click OK.

Discussion

The link between an AD user object and the actual mailbox in the Exchange message store is contained in two places: the security descriptor property on the actual mailbox database and the msExchMailboxSecurityDescriptor property in AD. The msExchMailboxSecurityDescriptor property is added to the AD user object by the Exchange schema updates; it holds a partial copy of the security descriptor on the actual mailbox. Modifying the AD property directly will not change the descriptor on the mailbox; changes to the mailbox security descriptor are mirrored back to the msExchMailboxSecurityDescriptor property. Because of this, granting access to other users programmatically can only be done through CDOEXM.

MS KB 310866 describes the steps necessary to modify a mailbox security descriptor using CDOEXM; in order to use it, the server must be at least Exchange 2000 Service Pack 2 or later. In addition, the relevant information store must be started and the mailbox store mounted. CDOEXM provides the IExchangeMailbox interface, which in turn exposes the MailboxRights property. This property then allows you to manage the security descriptor using the standard IADsSecurityDescriptor ADSI interface.

This technique requires a thorough understanding of security descriptors, access control lists (ACLs), and access control entries (ACEs); manipulating the IADsSecurityDescriptor interface uses the same principles underlying the NTFS file system permissions. This is a topic of sufficient complexity that it is outside the scope of a recipe.

There are two caveats to remember:

Permissions that have been inherited from the mailbox store are not directly exposed in the msExchMailboxSecurityDescriptor property. They can only be viewed or modified through the IExchangeMailbox interface.
Mailboxes that have not yet been created, either through user logon or through having received a message for the recipient, do not have a mailbox database; the msExchMailboxSecurityDescriptor property has only a limited set of rights.

Many experienced Exchange 5.5 administrators find the relationship between user accounts and mailboxes to be one of the biggest differences in Exchange 2000 and Exchange Server 2003, as it affects the way that resource accounts are handled.

Under Exchange 5.5, user accounts (the Windows NT domain SAM) and Exchange information (ExchangeDS) were two separate directories. Under this model, it was easy for the Exchange directory to store the proper associations to relate multiple mailboxes back to one Windows NT domain user account. The user to mailbox relationship was one to many; any need for a many-to-one relationship was taken care of through the appropriate mailbox ACLs.

With the advent of AD, this association changed. The attributes that keep track of the user/mailbox association are now part of the user object, turning it into a one-to-one relationship. Resource objects in the AD-aware Exchange world have their own corresponding account object, usually disabled; management permissions are then granted to the appropriate user accounts via the security descriptor. Since the actual mailbox database (and associated security descriptor) is not created until the message store must actually deliver a message or enumerate the contents of the database, the initial permissions are not granted until the mailbox is initialized. This complicates scripted provisioning of accounts that must be accessible by multiple users.