Recipe 5.23. Granting Users or Groups Permission to Access Other MailboxesProblemYou 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. SolutionUsing a graphical user interface
DiscussionThe 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:
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. See AlsoRecipes Recipe 5.1 and Recipe 5.2 for creating mailbox-enabled accounts, MS KB 275636 (Creating Exchange Mailbox-Enabled and Mail-Enabled Objects in Active Directory), MS KB 327079 (How to programmatically create a mailbox for an existing user in the Active Directory by using CDOEXM), MS KB 304935 (How to set Exchange 2000 mailbox rights at the time of mailbox creation), MS KB 310866 (How to Set Exchange 2000 Mailbox Rights on a Mailbox That Exists in the Information Store), and Chapter 23 ("Permissions and Auditing") of Active Directory, Second Edition (O'Reilly) |