Details of the Exchange Access Control Process

 

As discussed in Accessing Exchange Objects, Microsoft® Exchange uses a two-step process to control access to items in the Exchange store:

  • Preliminary checks   These checks streamline the access control process. Certain types of users always have full access to items in the Exchange store (with the exception of administrative tasks in public folders), so further checks are unnecessary, and the user is granted access to the requested item. In addition, if subsequent access checks are required (for example, a qualified user is requesting administrative access to a public folder), the preliminary checks determine which set of permissions to use for subsequent access checks.

  • Object-level access control   Each object in the Exchange store (mailbox, folder, or message) has a set of security descriptors. Each security descriptor is an attribute that contains information about which users have access to the object, and what type of access each user has. Additional controls are used to control access to special objects such as public folder trees (as opposed to individual public folders) and the extra properties of mail-enabled public folders.

Performing Preliminary Checks

Exchange uses a set of preliminary checks to determine what kind of check (if any) to use for the object-level access control check.

Note

This section describes two preliminary checks. Exchange performs another preliminary check to determine whether the user is requesting access to an attribute of a folder or message. However, a full discussion of the mechanisms that Exchange uses to implement access control on individual attributes is beyond the scope of this book.

Determining the Type of User

When a user attempts to access an object in the Exchange store, before reviewing the access control settings at the folder or message level, Exchange first checks to determine whether the user is one of the following user types:

  • Mailbox owner (for mailboxes only)   The mailbox owner has full access to the mailbox and all folders and messages in that mailbox. No further checks are performed.

  • Exchange Full Administrator   When using an administrative application, a Full Administrator has full access to all objects in the Exchange store, and no further checks are performed (with the exception of requests to perform administrative tasks on public folders—see "Determining the Type of Client Application" later in this topic).

  • Exchange View-Only Administrator   When using an administrative application, a View-Only Administrator has read access to all objects in the Exchange store, and no further checks are performed before granting the user this level of access. For more information about administrative applications, see "Determining the Type of Client Application."

Determining the Type of Client Application

When a user requests access to a public folder or a message in a public folder, Exchange checks whether the user matches one of the user types that is described in the preceding section. Exchange also checks what type of application the user is running. Exchange performs these checks to determine whether subsequent access checks should use the security information that controls regular client access or the security information that controls administrative client access. Exchange stores the two types of security information separately (as described in "Anatomy of Object-Level Access Control" later in this topic).

Note

If the user who is requesting access to a public folder or a message in a public folder is running an administrative application, but does not match one of the user types described in the preceding section (for example, an end user who is not the owner of the requested object), Exchange will ignore the user's request for administrative access, and will treat the user as if he or she is using a regular client application.

As discussed in Accessing Exchange Objects, Exchange treats an action that is performed in a client application, such as Microsoft Outlook®, as a client action (one that requires regular client access) even if the user might consider the action to be "administrative." For example, when a user is changing the permissions on a public folder, if the user uses Outlook to change the permissions, Exchange treats the action as a client action (one that requires regular client access). However, if the user uses Exchange System Manager (an administrative application) to change permissions on the public folder, Exchange treats the action as administrative (one that requires administrative client access). This distinction between a client action and an administrative one provides protection against an accidental lockout. No Outlook user (even the folder owner) can modify the permissions that control access by Exchange System Manager and thereby prevent an administrator from using Exchange System Manager to access the public folder.

  • If you are developing custom applications, Exchange needs to be able to identify them as either administrative applications or end user applications. For more information, see the topics "Using the Administrative Virtual Root" in "Exchange Store URLs" and Exchange Management Security" in "CDO for Exchange Management" in the Microsoft Exchange Software Development Kit (SDK) (for either Exchange 2000 Server or Exchange Server 2003). You can download the Exchange SDK or view it online from the Exchange Server MSDN Web site.

  • For additional information about how to establish the ownership of an object, see the topics "Access Control" and "Security" in the Exchange SDK.

Anatomy of Object-Level Access Control

To understand the way Exchange handles access control, it is necessary to examine the basics of access control as implemented in the Microsoft® Windows 2000 security model (as extended and modified by Exchange).

If you are developing custom applications, Exchange needs to be able to identify them as either administrative applications or end user applications. For more information, see the topic on Properties by Namespace in the Exchange SDK.

For information about working with security descriptors on folders and messages, see "Application Security Module Reference" in "Reference" in the Exchange SDK.

Security Descriptors

Each object (mailbox, folder, or message) in the Exchange store has two security descriptors:

  • Windows NT security descriptor   Every object in a Windows 2000 system has a Microsoft Windows NT® security descriptor. This security descriptor, described in the Exchange SDK as the ntsecuritydescriptor field (also as the ptagNTSD property), applies to most operations that users perform on the object (such as reading or editing messages).

  • Admin security descriptor   Every Exchange Server 2003 object has an Admin security descriptor. This security descriptor, described in the Exchange SDK as the admindescriptor field (also as the ptagAdminNTSD property), applies to administrative actions (such as creating or deleting public folders).

Both types of security descriptors contain the same information that is relevant to Exchange:

  • Control information (information about the security descriptor, such as whether it was created explicitly or by a "defaulting" mechanism)

  • Owner of the object

  • Primary group to which the object owner belongs

  • Discretionary Access Control List (DACL)

  • System Access Control List (SACL)

    Note

    Security descriptors can contain additional information, but Exchange 2003 does not use that information.

For a full description of the elements of a security descriptor in Windows 2000, see Chapter 12, "Access Control," in the Distributed Systems Guide volume of the Microsoft Windows 2000 Resource Kit.

ACLs and ACEs

In the Exchange store, as in Windows 2000, both of the access control lists (ACLs) that are used in security descriptors—discretionary access control lists (DACLs) and system access control lists (SACLs)—consist primarily of lists of access control entries (ACEs). ACEs in the SACL pertain to auditing and alert functions, whereas ACEs in the DACL control which users can perform tasks on the secured object, and what tasks each user can perform. The ACEs in the DACL are of primary interest in this book.

Each ACE contains the following information (this list is simplified for the purposes of this book):

  • ACE type (either Grant Access or Deny Access)

  • Security ID (SID) of the user or group that is granted or denied access

  • Specific permissions to be granted or denied (in the form of a hexadecimal access mask)

  • Flags, which specify further information about how to process the ACE. The possible flag values are the following:

    • OBJECT_INHERIT_ACE The ACE should be inherited to objects within this container.

    • CONTAINER_INHERIT_ACE   The ACE should be inherited to containers that are created below this container.

    • NO_PROPAGATE_INHERIT_ACE   The ACE will only be propagated to the immediate children of this container, but not to containers that are created below the immediate children.

    • INHERIT_ONLY_ACE   The ACE is not effective on this object, but is instead effective only on objects that are created below this object.

    • **INHERITED_ACE   **The ACE was inherited from a parent object.

The flags OBJECT_INHERIT_ACE, CONTAINER_INHERIT_ACE, and INHERIT_ONLY_ACE are of particular importance to the way that Exchange manages security. Exchange uses these flags to identify whether an ACE applies to folders or to messages, as follows:

  • Folder ACEs carry the CONTAINER_INHERIT_ACE flag.

  • Message ACEs carry the OBJECT_INHERIT_ACE and INHERIT_ONLY_ACE flags.

ACE Sequences in the ACL

Some of the Windows NT security descriptors that are used on objects in the Exchange store use a different sequence of ACEs in the DACL than the sequence that is used by standard Windows NT security descriptors ("standard" Windows NT security descriptors are used by objects in the Active Directory® directory service and the Windows 2000 file system).

For Application public folder hierarchies, Exchange supports the standard Windows 2000 rules for ordering ACEs.

However, MAPI-based clients such as Outlook use a MAPI-based ACL format instead of the Windows 2000 format. To support these clients, Exchange uses a special set of rules for the security descriptors of mailboxes and for folders in the default Public Folders hierarchy (also known as the MAPI hierarchy). As a result of the special format, Windows evaluates whether a user has access in a manner that mimics the access control behavior of Exchange 5.5 (which depended on MAPI-based permissions). This format is known as the Exchange Canonical ACL format (also called the Exchange Canonical security descriptor format).

The following rules control the sequence of ACEs in an Exchange Canonical ACL:

  • Each ACL contains both ACEs that apply to folders and ACEs that apply to messages within those folders. Folder and message ACEs can be intermixed in the ACL.

  • For each Grant ACE, there must be a corresponding Deny ACE for the same security principal (unless no rights are granted or denied). The Grant ACE must precede the Deny ACE.

  • All of the ACEs for users must precede all of the ACEs for groups (corresponding to Exchange 5.5 distribution lists). ACEs for the groups Everyone and Anonymous must occur last in the sequence.

  • All Grant ACEs for distribution groups must precede the corresponding Deny ACEs for these groups.

The following table shows an example of the sequence of ACEs in an Exchange Canonical ACL.

Example of the sequence of information in an Exchange Canonical ACL

ACE type Security principal

Grant

User <A>

Deny

User <A>

Grant

User <B>

Deny

User <B>

Grant

Distribution group <C>

Grant

Distribution group <D>

Deny

Distribution group <C>

Deny

Distribution group <D>

Grant

Everyone

With the ACL in this format, Exchange can translate the security descriptor information into the MAPI permissions that are expected by MAPI clients such as Outlook.

When a user sets permissions on a mailbox in Outlook, or when you set permissions on a mailbox or a MAPI public folder in Exchange System Manager, the user interface lists MAPI permissions and roles that are consistent with those used by Exchange 5.5. The following figure shows the dialog box you see in Exchange System Manager. If you are using Outlook, this information appears on the Permissions tab of the folder's Properties dialog box.

Client Permissions dialog box for a public folder in the default Public Folders hierarchy

d095e2ac-8b32-4b05-9453-d007f8072ea8

Because application public folders are intended for access by HTTP or Network News Transfer Protocol (NNTP) clients (for example, Outlook Web Access), they do not use this conversion to MAPI permissions. As shown in the following figure, the permissions that are listed are normal Windows 2000 permissions. For more information about application public folders (also called general-purpose public folders) see the Exchange Server 2003 Administration Guide.

Client Permissions dialog box for a public folder in an application public folder hierarchy

9c19d56c-1cb2-4b91-bff4-73500aea42e6

Note

Use only the Permissions dialog box provided by Outlook and the Client Permissions dialog box provided by Exchange System Manager to modify MAPI permissions. When you use the Outlook or Exchange System Manager user interface to edit MAPI permissions, Exchange reverses the translation to store the modified security descriptor and maintains the Exchange Canonical ACL format. However, if you edit permissions using the Windows file system user interface (for example, by using the M:\ drive supplied by the Installable File System in Exchange 2000 Server), the security descriptor will be stored using the normal Windows ACL format. This means that the ACEs will be in a different sequence, and Exchange will no longer be able to translate the security descriptor into MAPI permissions. For more information about this issue, see the Microsoft Knowledge Base article 270905, "Unable to Set Client Permissions on Public Folders Through Exchange System Manager."

Default ACLs for Messages

As stated previously, each folder security descriptor contains ACEs that apply only to messages. Known collectively as the default message ACL, these ACEs provide security for messages in the folder that do not have their own security descriptor information.

When a user opens such 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 immediately inherit the security descriptor change. Messages that are already open will retain their original security descriptors until the messages are saved.

Exchange records 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 become effective immediately.

Special Considerations for Coexisting Exchange 2003 and Exchange 5.5 Servers

If your deployment includes both Exchange 2003 and Exchange 5.5 servers, you have an additional level of complexity to deal with when managing permissions, especially public folder permissions. For a more detailed explanation of how Exchange passes access control information between Exchange 2003 and Exchange 5.5 servers, see Public Folder Permissions in a Mixed Mode Microsoft Exchange Organization. The important points that relate to managing public folder permissions are the following:

  • Before any data can be replicated between Exchange 2003 and Exchange 5.5 servers, any users or groups with mailboxes on the Exchange 5.5 servers must have accounts in Active Directory.

    • If the user or group has only an Active Directory account (not a Windows NT 4.0 account), then the Active Directory account is an "enabled" account.

    • If the user or group has a Windows NT 4.0 account, then the Active Directory account is a "disabled" account. This account, created using the Active Directory Migration Tool, is a placeholder that associates an Active Directory SID with the existing Windows NT 4.0 account.

      Important

      If you plan to maintain user accounts in Windows NT 4.0 for a period of time and then fully migrate those accounts to Active Directory, you will need to create disabled accounts that have a SID history. The Active Directory Migration Tool can migrate the Windows NT 4.0 SID into the sidHistory attribute of the new disabled account in Active Directory. If you enable the accounts at a later date, Exchange can use the SID history information to determine where newly enabled accounts have replaced Windows NT 4.0 accounts in ACEs. For more information about this process, see the Knowledge Base Article 316047, "XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts."

    Exchange 5.5 uses MAPI-based permissions, identifies users and groups by their distinguished names in the Exchange Directory, and uses a property called ptagACLData to store access control information. When Exchange 2003 replicates access control information to an Exchange 5.5 server, it does the following:

    1. Converts the Active Directory security identifiers (SIDs) of users and groups to Exchange Directory distinguished names.

    2. Converts the Windows 2000 permissions to MAPI permissions.

    3. Stores the converted access control information in ptagACLData.

    4. Replicates ptagNTSD, ptagAdminNTSD, and ptagACLData to the Exchange 5.5 server.

    When an Exchange 2003 server receives data replicated by an Exchange 5.5 server, it does the following:

    1. Discards the incoming values of ptagNTSD and ptagAdminNTSD. This step protects against any changes that may have been made to these properties while they were under the control of Exchange 5.5.

    2. Extracts the user and group distinguished names from ptagACLData and converts them to Active Directory SIDs.

    3. Extracts the permissions from ptagACLData and converts them to Windows 2000 permissions.

    4. Stores the converted access control information in ptagNTSD. The original value of ptagAdminNTSD remains unaffected.

    5. Discards the value of ptagACLData, unless a problem occurred during the conversion in Step b or Step c. If a conversion problem occurs, Exchange 2003 keeps the ptagACLData value.

  • Exchange 5.5 applies permissions to folders. You cannot assign permissions to individual messages (item-level permissions) explicitly, as you can with Exchange 2003. If you are replicating folders and their contents from Exchange 5.5 to Exchange 2003, do not attempt to set explicit permissions on messages. Exchange 2003 manages permissions so that the messages are secure, but if you attempt to change the message permissions in this situation, the changes will be lost in the next replication cycle.