Introduction to Working with Store Permissions in Exchange 2000 and 2003

This guide explains the process by which both Microsoft® Exchange Server 2003 and Microsoft Exchange 2000 Server use permissions to control access to objects in the Exchange store (public folder databases and mailbox databases).

What Will You Learn from This Guide?

This guide provides detailed answers to the following questions:

• When I open a folder or a message, what does Exchange check to determine whether I have access? Where does this information come from?

• How do Exchange store permissions differ from permissions in the Microsoft Active Directory® directory service and the Microsoft Windows® 2000 or Microsoft® Windows Server 2003 file system?

• How many sets of permissions does Exchange use, and what is the function of each?

• Of these sets of permissions, which ones are related to one another and how does Exchange convert information from one form to another?

• Why does Exchange provide several different user interfaces for viewing permissions, and why is each different?

• Which interface should I use to set a particular type of permission? Which interfaces should I never use?

• If I want to change permissions, which settings should I leave alone for Exchange to function smoothly?

Who Should Read This Guide?

This guide is intended for advanced Exchange administrators. This guide provides a high-level explanation of the process by which Exchange controls access to objects in the Exchange store.

What Terminology Is Used in This Guide?

To understand this guide, make sure you are familiar with the following terms taken from the Distributed Systems Guide volume of the Window 2000 Resource Kit.

• access control entry (ACE)
  An entry in an access control list (ACL) containing the security ID (SID) for a user or group and an access mask that specifies which operations by the user or group are allowed, denied, or audited.

• access control list (ACL)
  A list of security protections that apply to an entire object, a set of the object's properties, or an individual property of an object. There are two types of access control lists: discretionary and system.

• access token
  A data structure containing security information that identifies a user to the security subsystem on a computer running Windows 2000 or Windows NT. Access tokens contain a user's security ID, the security IDs for groups that the user belongs to, and a list of the user's privileges on the local computer.

• discretionary access control list (DACL)
  The part of an object's security descriptor that grants or denies specific users and groups permission to access the object. Only the owner of an object can change permissions granted or denied in a DACL; thus access to the object is at the owner's discretion.

• permission
  A rule associated with an object to regulate which users can gain access to the object and in what manner. Permissions are granted or denied by the object's owner.

• security descriptor
  A data structure that contains security information associated with a protected object. Security descriptors include information about who owns the object, who may access it and in what way, and what types of access will be audited.

• security ID (SID)
  A data structure of variable length that uniquely identifies user, group, service, and computer accounts within an enterprise. Every account is issued a SID when the account is first created. Access control mechanisms in Windows 2000 identify security principals by SID rather than by name.

• security principal
  An account-holder, such as a user, computer, or service. Each security principal within a Windows 2000 domain is identified by a unique security ID (SID). When a security principal logs on to a computer running Windows 2000, the Local Security Authority (LSA) authenticates the security principal's account name and password. If the logon is successful, the system creates an access token. Every process executed on behalf of this security principal will have a copy of its access token.

• system access control list (SACL)
  The part of an object's security descriptor that specifies which events are to be audited per user or group. Examples of auditing events are file access, logon attempts, and system shutdowns.

For more information about Microsoft Windows 2000 security concepts, see "Access Control" in Chapter 12 of the Distributed Systems Guide volume of the Microsoft Windows 2000 Resource Kit.

Background

Because of the way Exchange data can be distributed around an Exchange deployment, and as a result of efforts to maintain backward compatibility with previous versions of Exchange, access control in Exchange Server 2003 is not straightforward.

The Effects of Distributed Data

Using the architecture of Exchange Server 2003, you can place multiple mailbox databases and public folder databases on different servers. Exchange 2003 also stores some information about users in Active Directory (instead of using its own directory, the way that Exchange 5.5 did). For example, see the sample deployment of Exchange 2003 in the following figure. This deployment includes a domain controller, one mailbox server, and two public folder servers. The figure indicates what data is stored on each of the servers. Controlling access to Exchange user information, mailboxes, folders, and messages often involves controlling access to data on several different servers.

Example Exchange 2003 deployment showing the distribution of data across several servers

The Effects of Backward Compatibility

Exchange 2003 uses the Windows 2000 security model. All objects (whether in the Windows file system or in Active Directory) have access control lists (ACLs), and in these ACLs, users and groups from Active Directory serve as security principals. Exchange extends this model to the Exchange store: each object in the Exchange store uses ACLs in which the security principals are users and groups from Active Directory. This is a change from Exchange 5.5, in which Exchange used its own Lightweight Directory Access Protocol (LDAP) directory for the security principals used by Exchange objects.

The ACLs on objects in the Exchange store use Windows 2000 permissions to control access (with a few additional permissions that are specific to Exchange). This is another change from Exchange 5.5, in which the ACLs used Messaging Application Programming Interface (MAPI) permissions. However, Exchange 2003 substitutes MAPI permissions for Windows 2000 permissions in the following circumstances:

• When communicating with MAPI-based client applications, such as Outlook.

• When replicating data to Exchange 5.5 servers in a deployment that contains coexisting servers that run Exchange 5.5 and servers that run Exchange 2003.

Exchange handles all conversions between Windows 2000 permissions and MAPI permissions automatically. However, as an administrator, be aware that when you use Exchange System Manager to set permissions, you may need to work with either Windows 2000 permissions or MAPI permissions, depending on the type of object that you are securing.

This guide includes more information about how this access control process works, including information about the modifications that Exchange makes to the Windows 2000 security model to apply that model to objects in the Exchange store. This guide also describes when and how Exchange converts Windows 2000 permissions to MAPI permissions (and MAPI permissions back to Windows 2000 permissions).