Directory Objects Access Control

Microsoft Exchange Server Directory objects are protected with Windows NT security descriptors. A security descriptor may contain a discretionary access control list (DACL) where user accounts are listed with assigned access masks. An access mask is a collection of individual access rights. The following rights are used with Microsoft Exchange server:
 
 
Right
Binary Value
Description
Add Child $00000001 Allows to add child objects.
Modify User Attributes $00000002 Allows to modify user-level attributes of an object.
Modify Admin Attributes $00000004 Allows to modify admin-level attributes of an object.
Send As $00000008 Allows to use this object e-mail address to send mail.
Mailbox Owner $00000010 Allows to read and delete messages sent to the object.
Logon Rights $00000020 User can logon to Exchange server.
Replication $00000040 Allows to perform directory replication.
Modify Permissions $00000080 User can modify permissions for an object.
Search $00000100 Right to search.
Delete $00010000 Right to delete the object.
 
All these rights except for the Delete right are specific to Microsoft Exchange server. The Delete right is a standard Windows NT access right.
 

Roles

Roles are named collections of individual access rights. It is often necessary to enable a set of rights in order to do something useful. Roles provide easy to remember names for such collections. Here is the list of Microsoft Exchange server roles with a description for each:
 
 
Role
Access Mask
Description
View Only Admin. $00000020 This role has only Logon Rights access. Allows for logon access to Exchange server.
User $0000001A Combines Mailbox Owner, Send As and Modify User Attributes rights. 
Admin. $00010027 Combines Delete, Logon, Add Child, Modify User Attributes and Modify Admin Attributes rights.
Permissions Admin. $000100A7 Same as Admin. with an addition of Modify Permissions right.
Service Account Admin. $000100FF Contains all rights except for the Search.
 
A directory object may be associated with a security descriptor. This security descriptor is in self-relative format, which means that its pointer members are not real pointers, but offsets from the beginning of the structure. Thus, a security descriptor in self-relative form contains everything in one contiguous memory block, contrary to absolute format, where several blocks are individually allocated and the security descriptor has real pointers to these blocks. You may easily copy a self-relative security descriptor, because everything is in one place. You may also observe its binary contents when you start you Exchange Administrator in raw mode, select an object, open its Raw Properties dialog and examine the NT-Security-Descriptor attribute. Exchange Administrator provides a built-in editor to edit its contents. Also, this contents is modifiable via the Permissions tab dialog for the object. When permissions are modified, the NT-Security-Descriptor attribute is changed accordingly.

Although a Windows NT security descriptor is a generic binary structure, that contains many members such as owner security identifier, system access control list (generates audits), discretionary access control list (DACL), and others, in context of Exchange server programming we are dealing mostly with DACL. Also, we have a simplified DACL here, because Exchange Administrator manipulates with only ACCESS_ALLOWED_ACEs. A generic DACL may accept 2 types of entries: ACCESS_DENIED_ACE and ACCESS_ALLOWED_ACE. Also, they should be ordered so that ACCESS_DENIED_ACEs are first in the DACL followed by ACCESS_ALLOWED_ACEs.

Thus, the task of protecting a Directory object is really about inserting an appropriate DACL in its NT-Security-Descriptor attribute. DACL contains entries (ACCESS_ALLOWED_ACEs) and each entry lists a user security identifier with an access mask assigned. For example, Exchange server site object may have Domain Users account listed with Logon Rights ($00000020). This allows any user who is a member of Domain Users to logon to Exchange Server.

You can access NT-Security-Descriptor contents with either MAPI or DAPI calls. Further sections show code examples of how you can retrieve and modify security descriptor contents with DAPI. A drawback of DAPI usage is that the DAPIStart call is miserable in performance. In production code you should either cache a DAPI Session at start up or use MAPI.