Modifying Store Permissions in Exchange 2000 and 2003
Two primary applications provide access to Microsoft® Exchange security descriptor information:
Microsoft Outlook®, through which users can set permissions on mailbox folders and can create new public folders
Exchange System Manager, through which administrators can set permissions on public folders and public folder trees
Note
Exchange System Manager also provides access to the security descriptors of mailbox and public folder databases. However, Exchange uses standard Windows 2000 security descriptors for the databases, without any special format requirements.
Important
You can also use the ADSI Edit MMC console to view security descriptors on Exchange-related objects in the Active Directory® directory service. However, if you use ADSI Edit to change the permissions that are stored in these security descriptors, ADSI Edit saves them using the Windows 2000 ACL format instead of the Exchange Canonical ACL format. To ensure that permissions remain in the format that Exchange expects, use Outlook or Exchange System Manager whenever possible to edit permissions.
For information about working with permissions programmatically, see the "Security" topic in the "Key Tasks" section of the Microsoft Exchange Software Development Kit (SDK). You can download the Exchange SDK or view it online from the Exchange developer center.
Controlling Client Access to Mailboxes
The security descriptor for the mailbox object resides both in the Exchange store and in the user object in Active Directory. In the user object, the mailbox security descriptor is stored using a special attribute. This attribute keeps the mailbox security descriptor separate from the security descriptor of the user object, which is a normal Windows security descriptor.
When you create a new mailbox-enabled user, the mailbox inherits a security descriptor from the mailbox database. This security descriptor is stored in Active Directory. The Exchange store does not actually create the mailbox until the first time the user opens the mailbox, at which time Exchange creates the security descriptor in the store. The default folders in the new mailbox inherit security descriptors from the mailbox.
Users can modify the permissions on folders or messages in their mailboxes using Outlook. For detailed instructions, see How to View Permissions for a Mailbox Folder.
Controlling Client Access to Public Folders
As with mailboxes, security descriptor information for public folders resides both in the Exchange store and in Active Directory. However, the way Exchange manages security descriptors for public folders is much more complex.
The following table lists the different locations in which Exchange places public folder information.
Locations of security information for public folders
| Data | Location | Security information |
|---|---|---|
Public folder objects (one object for each folder, including the top folder in the hierarchy) |
Exchange store (public folder databases) |
Security descriptors (ntsecuritydescriptor and Admindescriptor for each folder object) |
Folder hierarchy objects (one object for each hierarchy, used for hierarchy-wide attributes such as hierarchy type) |
Active Directory (Configuration container) |
Security descriptors (ntsecuritydescriptor and Admindescriptor for each hierarchy object) Additional security attributes (These attributes, although not used as security descriptors by Active Directory, hold information that is needed to create default security descriptors for new top-level folder objects in the store.) |
Public folder proxy objects (one object for each mail-enabled public folder, used to hold mail attributes for public folders) |
Active Directory (Domain container) |
Security descriptors (ntsecuritydescriptor and Admindescriptor for each proxy object) |
When you create a new top-level public folder (in an existing hierarchy), Exchange creates the security descriptor for the folder by combining the security descriptor of the folder hierarchy object with stored permissions information.
As an Exchange administrator, you are already familiar with the view that Exchange System Manager provides of objects in the Exchange store. This is the interface that you normally use when you are modifying permissions on objects in the store. For detailed instructions, see How to View Permissions That Control Client Access to a Public Folder.
The default Public Folders tree and application public folder trees in Exchange System Manager
.gif "411b2e79-7731-4114-bc46-e7ff790bc8b7")
After clicking Client permissions, you will be presented with one of two different dialog boxes, depending on the type of public folder hierarchy with which you are working. If you are working with a folder in the default Public Folders hierarchy, you will see a dialog box that contains MAPI permissions and roles, as shown in the following figure.
Client Permissions dialog box for a public folder in the default Public Folders hierarchy
.gif "d095e2ac-8b32-4b05-9453-d007f8072ea8")
If you are working with a folder in an application public folder hierarchy, you will see a dialog box that contains Windows 2000 permissions, users, and groups, as shown in the following figure.
Client Permissions dialog box for a public folder in an application public folder hierarchy.
.gif "9c19d56c-1cb2-4b91-bff4-73500aea42e6")
You can also use Exchange System Manager to view the Windows 2000 version of the permissions on a folder in the default Public Folders hierarchy. For detailed instructions, see How to View the Windows 2000 Version of MAPI Permissions.
Warning
Although you can view the Windows 2000 version of the default Public Folders hierarchy permissions, do not attempt to edit the permissions in this view. The Windows user interface that is used to display the permissions will format the ACL in such a way that Exchange will no longer be able to convert the permissions to their MAPI form. If this happens, you will no longer be able to use Outlook or the regular Exchange System Manager dialog boxes to edit the permissions.
Special Considerations for Messages
When a user opens a message, the message inherits message ACEs dynamically from the folder security descriptor. If the folder security descriptor changes, all new messages that are opened within the folder will inherit the security descriptor change immediately. Messages that are already open will retain their original security descriptors until the messages are saved.
Exchange stores the security descriptor on an attachment (or embedded message) in the database, but does not use it. Instead, the Exchange store uses the security descriptor of the outermost message for all attached messages. The store retains the security on attachments to allow a client to send a message to another user for debugging purposes. In addition, if a user copies the attached message to a top-level folder, its security descriptor will immediately become effective.
Controlling Administrative Access to Mailboxes and Public Folders
In general, the administrative security descriptor follows the Windows 2000 rules for format and inheritance.
Note
Database-level administrative tasks, such as moving users or connecting and disconnecting mailbox stores or public folder stores, are controlled by the individual database security descriptor, which is a normal Windows 2000 security descriptor.
Mailboxes
Exchange System Manager does not provide administrative access to user mailboxes. Use Active Directory Users and Computers to perform administrative tasks on the Exchange-related attributes of user objects.
Public Folders
Administrative permissions for public folders are stored both in the Exchange store (in the admindescriptor property of each object) and in Active Directory. These permissions are Active Directory permissions; no MAPI conversion is involved.
Whether you are modifying administrative permissions on a public folder in the default hierarchy or on a public folder in an application hierarchy, you will use a common user interface (UI)—the Windows UI—and a common set of permissions, as shown in the following figures.
Administrative rights dialog box for a public folder in the default Public Folders hierarchy
.gif "4f696b75-b69f-4449-b82b-05c352b95511")
Administrative rights dialog box for a public folder in an application public folder hierarchy
.gif "9def3306-691c-4af5-9adc-fee7401d0e30")
To store properties that govern all folders in a hierarchy, each public folder hierarchy has a "folder hierarchy" object in Active Directory. This object stores properties such as the distinguished name of the Exchange store in which the hierarchy resides, and the hierarchy type (MAPI or application) for the hierarchy.
Important
The security descriptor of the folder hierarchy object includes permissions such as Create public folder that may override permissions that are set on individual public folders in the hierarchy.
Exchange System Manager provides access to some of this information by displaying a tree object for each public folder hierarchy. You can also use ADSI Edit to view the folder hierarchy objects in Active Directory, as shown in the following figure.
Public folder tree objects in Active Directory
.gif "b0715730-d2f2-4e9d-b0d3-f9e802de9cab")
When you create a new top-level folder within a hierarchy, the Exchange store copies the administrative security descriptor from the folder hierarchy object in Active Directory and uses that as the parent administrative security descriptor. For all other folders, the store copies the administrative security descriptor from the parent folder and uses that as the parent administrative security descriptor.
Note
When Exchange checks the administrative security descriptor, it first updates the inherited ACEs in the security descriptor. Exchange retrieves the current administrative security descriptor of the hierarchy object, and uses that information to replace the inherited information in the administrative security descriptor that is being checked. ACEs that have been set explicitly for the folder in question are not affected.
Note
If your deployment includes both Exchange 2003 and Exchange 5.5 servers, and the folder in question is homed on an Exchange 5.5 server, that folder will not have an administrative security descriptor. In this case, if the folder is not marked as secured to a site, or if site of the folder is the same as the current site, the store uses the regular security descriptor on the folder hierarchy object in Active Directory for the administrative security descriptor.
Special Controls for Mail-Enabled Public Folders
Mail-enabled public folders use special Active Directory objects to store their mailbox attributes, such as automatically-generated proxy addresses. Each mail-enabled folder has one such object, and the object's name is the same as the folder name. The following figure shows the location of these objects in Active Directory, as viewed with ADSI Edit.
Public folder proxy objects in Active Directory
.gif "051786c0-8a21-4274-a57a-1ccf87d484bc")
As with public folder tree objects, the permissions on public folder proxy objects are the same whether the public folder is a member of a MAPI tree or an application tree. The user interface is the standard Windows UI.
For detailed instructions, see How to View Permissions That Control Access to Mail-Enabled Folder Attributes.
For more information about mail-enabled public folders, see the Exchange Server 2003 Help or the Exchange Server 2003 Administration Guide.