Access Control and Permissions | Secure Messaging with MicrosoftВ® Exchange Server 2003 (Pro-Other)

Most Windows objects, including files, folders, disk volumes , user accounts, blocks of memory, and physical devices, can have permissions associated with them. The Windows SRM, which runs as part of the Windows kernel, is responsible for deciding whether to grant access to a particular resource. Whenever the user s process, or any child process it starts, requests access to an object, it passes a copy of its token. The SRM uses the SIDs in the token to check the DACL for the requested object. Each ACE in a DACL contains a SID for the account or group that s the object of the ACE. By checking the SIDs you have against the SIDs listed in the DACL, the SRM can determine what access you should have.

Note	Some objects cannot have permissions associated with them, and any object that can have permissions might have an empty set of permissions such that no one has access to the object. This isn t very useful, though, because it prevents anyone from modifying or using the object.

The rules that Windows uses for access determination are simple:

First, the SRM looks for deny ACEs containing any of the SIDs in the user s token. If any exist, access is denied . It doesn t matter how many allow ACEs there are; a single deny ACE overrides them all. This is desirable because it allows you to quickly deny access to particular users or groups, and it guarantees that denials are always evaluated, and acted on, first. A deny ACE is not at all the same as the absence of an allow ACE for the same user. Deny entries actively prohibit access, whereas the lack of an allow ACE fails to grant it. It might be easier to remember this behavior if you think of a common security maxim : everything not explicitly allowed is forbidden.
If no deny ACE is found, all applicable permissions on the object are collated into a single list. Because Windows allows objects to inherit permissions from parent objects, this calculation might involve permissions for many other objects.
The system calculates the effective permission by finding the least restrictive permission that applies to the request. For example, let s say Jonathan s account is in the Engineers and Security Engineers groups. Jonathan wants access to the XboxGameDev folder, which has Engineers:Read and Security Engineers:Modify ACEs. Jonathan gets Modify rights because that s the least restrictive permission in the set of permissions.

This basic process works the same way for access to any SRM-protected object, including files and folders, mailboxes, and administrative groups. Whenever a user attempts to open , modify, or remove an Exchange object, his or her permissions are checked by the SRM before anything else happens.

It s interesting to consider the role that auditing plays in this process, too. In general, we would like the audit log to report go/no-go decisions before resource access is granted; in fact, that s exactly what happens. If you enable object access auditing (discussed in more detail in Chapter 18, Security Monitoring and Intrusion Detection ), access attempts are logged. If you have chosen to log successful access requests, the event log entry will be generated after the ACL is verified but before the caller actually gets access to the resource it s asked for.

How Exchange Modifies the Access Control Process

Exchange modifies the standard Windows DACL evaluation process in a few small but significant ways. First of all, it s important to understand that there are two separate but similar formats for DACLs. The first format is the one we ve been talking about all along: the Windows DACL format specifies a standardized order for ACEs that appear in the DACL. Windows NT, Windows 2000, Windows XP, Windows Server 2003, and Active Directory all use (and create) these canonical DACLs . Exchange, on the other hand, uses a separate format, known as the Exchange canonical ACL format.

The reason for this divergence is that in prior versions of Exchange, the Exchange directory maintained its own set of client permissions, and these permissions were structured in a way that made sense for MAPI clients. To preserve compatibility with MAPI, Exchange Server 2003 requires that objects that are accessible from MAPI clients have the ACL in a format that allows translation of the ACEs into their equivalent MAPI permissions. This requirement applies to mailboxes, their enclosed folders and messages, public folders in the MAPI top-level hierarchy (TLH), and their contents; it doesn t apply to public folders that are hosted in other TLHs.

The specific format of the MAPI-style DACL isn t important to us; what is important is that some administrative tools create correctly structured DACLs for Exchange, and some don t. In particular, trying to set public folder permissions using Windows Explorer is a recipe for heartache, because Explorer only creates Windows-style DACLs, and public folder management depends on the Exchange canonical format. That s one of the major reasons why the M pseudo-drive that we all know and love from Exchange 2000 isn t present by default in Exchange Server 2003 ”people kept using it to screw up their public folder permissions. However, you can easily set public folder permissions with Microsoft Outlook or Exchange System Manager, both of which understand the Exchange canonical format.

Before Exchange asks Windows to make an access control decision, it performs three sets of preliminary checks. The first two are easy to understand:

It checks the type of user. If the user is the owner of the requested mailbox, access is granted. Likewise, if the user holds Exchange Full Administrator privileges and is using an administrative application (in this case, Exchange System Manager), that user will be granted access. Holders of the Exchange View Only Administrator permission have read access to all Exchange objects, so if the user is requesting read permission, no additional checks are required.
If the user is requesting access to a public folder (or an object contained therein), Exchange checks to see whether the user is running an administrative application or a client application. (It knows because administrative applications have to use a separate virtual root on the Exchange server.) Requests for administrative access are evaluated against the Admin SD, whereas requests for normal access are evaluated using the standard object SD.

The third check takes a bit more explaining. Users can store documents in public folders just by dragging them to the public folder from their desktop, not to mention by using Microsoft Office or other Web Distributed Authoring and Versioning (WebDAV)-aware applications to explicitly save them there. These documents aren t attached to public folder posts; instead, they re free-floating, which led the Exchange development team to call them freedocs . Freedocs are useful, but they make it possible for a malicious user to cause all sorts of trouble by saving a freedoc with malicious content in it, then distributing links to the freedoc. To combat this, Exchange performs an additional test if the user is requesting access to a freedoc: if the request is coming through Microsoft Outlook Web Access, the user will get a 403: Forbidden error, but access is allowed through Office applications. (You can disable this default Outlook Web Access freedoc block; see Chapter 14, Outlook Web Access Security, for details.)

Understanding Exchange-Specific Permissions

Fortunately, because the permission calculation process works the same way for Exchange as it does for Windows, you assign permissions on mail- related objects using the same general user interface you use for setting permissions to do anything else. Exchange-specific permissions are not automatically granted to accounts in most cases; however, the Domain Admins and Enterprise Admins security groups do get permission on many objects at installation time. (Chapter 7, Installing Exchange with Security in Mind, describes the security effects of installation in more detail.) After you ve installed Exchange, you ll have to use Exchange System Manager to give other accounts whatever permissions you want them to have.

Note

In Exchange 5.5, Exchange permissions were completely divorced from Windows NT permissions. This led to various kinds of troublesome behavior, including accidentally giving system administrators elevated Exchange privileges and vice versa. If you re migrating from Exchange 5.5, you ll need to be aware of this difference.

Exchange Server 2003 doesn t maintain its own set of permissions in a separate directory; it compensates for this by extending the Windows permission schema to add a number of new permissions that you can grant or deny. You can use Exchange permissions to fine-tune what users can do once they ve successfully connected to the Exchange server itself; their Windows credentials control whether they can connect at all. This integration is useful both for controlling what end users can do (for instance, allowing some users, but not others, to create and manage public folders) and for allowing different levels of administrative privilege to different classes of users. For example, you might entrust one group of administrators with the responsibility of creating mailboxes, but not the ability to delete them.

The permissions themselves fall into several categories. Each category has some permissions (like Read or Read Permissions) that are fairly generic; however, some specific objects have very specific permissions.

Mailbox permissions are granted to one or more accounts or groups, which can then use them to log onto the mailbox and use it.
Public folder permissions govern what users can do to public folders; you can control read, write, and modify access to user mailboxes, distribution lists, and other public folders.
Directory permissions control read and write access to Active Directory; these permissions control who can add and remove accounts, change directory permissions, and so forth.
Exchange permissions is the catch-all term for permissions that apply to various Exchange objects. For example, there are specific permissions for administering the information store, mounting and dismounting databases, and changing permissions on subordinate objects.

Exchange permissions are hierarchical; objects inherit permissions from their parent containers. In practice, this means that normally you ll apply permissions to container objects like the administrative groups, although in some cases you might want to apply individual permissions on low-level objects. Table 3-1 lists common Exchange permissions, indicating what they do and where they re normally applied. In most cases, the permissions can only be used from within the Exchange System Manager and Active Directory Users And Computers administrative tools. However, Outlook clients can take advantage of some permitted operations at the client level.

Table 3-1: Common Exchange Permissions
Permission	What Holders Can Do	Applied to
Add Public Folder to admin group	Add an existing public folder to an existing administrative group.	Administrative groups
Administer information store	View and modify properties of the information store and its subordinate objects.	Information store
Associated external account	Allows an account in a trusted domain to be associated with the mailbox and allowed access. Because the mailbox is the account in Exchange Server 2003, this provides the parallel to the linkage between an Exchange 5.5 mailbox and its corresponding Windows NT account.	Mailboxes
Change permission	Change the permissions on an object, including adding or removing.	Mailboxes
Create named properties in information store	Create new properties in the store, including those associated with messages, public folder posts, and information store objects.	Folders
Create public folder	Create new public folders beneath existing public folders in any hierarchy they have access to.	Folder hierarchies
Create top-level public folder	Create new top-level public folders at the top level of any hierarchy they have access to.	Organization
Delete mailbox storage	Delete mailboxes from the information store.	Mailboxes
Full mailbox access	Grants full control for the holder on the specified mailbox; the holder can do literally anything with the mailbox (but not necessarily the directory).	Mailboxes
Full store access	Open or modify any property of the information store; mount and dismount databases.	Mailbox store; storage group
Mail-enable public folder	Enable a public folder to receive mail at its associated SMTP address.	Public folders
Modify public folder ACL	Change the contents of the ACL (for example, add or remove accounts and groups) for a public folder.	Public folders
Modify public folder admin ACL	Change the permission settings that govern who can administer or grant permissions on a public folder.	Public folders
Modify public folder deleted item retention	Change the deleted item retention settings for an existing folder.	Public folders
Modify public folder expiration	Change the expiration settings for an existing folder.	Public folders
Modify public folder quotas	Add, remove, or change storage limits for a folder.	Public folders
Modify public folder replica list	Modify the list of public folder replicas on a particular server; must be set on the public folder store and admin group where replica is to be added.	Public folders, public databases
Open mail send queue	Open the queue of outbound mail to inspect or modify it. Normally granted only to Exchange Servers group.	Information store
Read all metabase properties	Read properties pertaining to Internet protocol handling from the Internet Information Services (IIS) “owned sections of the metabase. Normally granted only to services.	IIS metabase
Read permissions	Read permissions and ACL entries from the selected mailbox.	Mailboxes
Receive as	Receive mail addressed to another user. When this permission is granted along with the Send as permission, the holder effectively has full control over the mailbox.	Mailbox stores, mailboxes
Remove public folder from admin group	Remove a public folder from an administrative group.	Administrative group
Send as	When a user holds this permission, he or she can send messages with another user s return address. For example, the CEO of a company can grant his executive secretary Send as permission so that he can send mail that appears with the CEO s address. Users always have this permission on their own mailboxes.	Mailboxes
Take ownership	When a user holds this permission, he or she can actually take ownership of a mailbox by substituting his or her SID in place of the current owner s SID. This leaves an audit trail in the system s security event log.	Mailboxes
View information store status	View health, status, and performance information about instances of the information store.	Information store

Explorer and Exchange Permissions

Exchange 2000 Server included the Exchange Installable File System (ExIFS) driver; ExIFS exposes Exchange store data so that it looks like a large file system. If you ve ever noticed the presence of the M drive on an Exchange server, you re seeing ExIFS in action. Because ExIFS makes Exchange data visible within Windows Explorer, you might think that you can manipulate those items from within Explorer; in fact, you can copy and open messages, move items between folders, and so forth. This is generally harmless, as long as you don t try to back up or virus-scan files on the M drive.

However, if you use the Explorer interface to change permissions on an Exchange message, folder, or mailbox, you ll be sorry: Explorer doesn t understand the Exchange-specific permissions and often writes a DACL that leaves out some of the previously present Exchange permissions or that isn t in the correct canonical Exchange format. The most visible symptom of this problem is the inability to open public folders; you can generally fix these problems using Exchange System Manager to reapply the desired permissions. Exchange Server 2003 turns off the M drive by default. If you have Exchange 2000 servers in your organization, you might prefer to force ExIFS not to display the M drive at all; that way no one can change the permissions in the first place (see Microsoft Knowledge Base article 305145 if you re interested in doing this).

Permissions and Roles

In Exchange, a role represents a group of permissions you want to grant as a unit. (Outlook has its own set of roles, which I discuss further in Chapter 13, Securing Outlook. ) Although you can assign individual permissions to user accounts, roles speed up the process and reduce the likelihood that you ll accidentally give someone permissions you don t want them to have or forget to give them a right they need.

Note	Roles are very similar to the familiar Windows combined permissions, like NTFS Full Control. They both allow you to group several permissions together so that you can grant or deny them as a unit instead of separately.

Exchange Server 2003 uses the Exchange Administration Delegation Wizard to ease the process of delegating some types of access using roles. You can use the wizard by right-clicking various Exchange objects (including the organization object and administrative group objects, if present) in Exchange System Manager, then selecting Delegate Control, which actually starts the wizard (see Figure 3-1).

Figure 3-1: The Exchange Administration Delegation Wizard is boring but useful.

There are three predefined roles that you can assign through the wizard:

The Exchange View Only Administrator role lets you see all configuration settings applied to Exchange objects, but you can t change any of them. This permission is not automatically propagated down to subcontainers when you apply it; this is by design, so that you can grant someone view-only access to an object without giving that person view permission on subobjects.
Accounts that hold the Exchange Administrator role can change any Exchange configuration setting on or below the delegated object, but they cannot change permissions on Exchange objects. This prevents an Exchange Administrator holder from usurping a greater role by adding elevated permissions to his or her account. You ll typically use this role to allow a group to administer Exchange without granting themselves, or anyone else, a different access level.

The Exchange Full Administrator role allows its holders to modify any configuration setting or permission, without limitation, on the delegated object and its children. The account you originally use to install Exchange Server 2003 will have this role, which is why you shouldn t use the Administrator account when you install Exchange (more on that later).

Tip	The Exchange View-Only Administrator is a great learning tool, because it lets you give people access to poke about and learn without giving them the ability to accidentally cause any damage.

Note that some of these roles (notably Exchange Full Administrator) are supersets of other roles. This can make it hard to calculate the effective set of permissions when you have accounts with permissions on multiple administrative groups. Table 3-2 (reprinted here from the Microsoft Exchange 2000 Internals: Permissions Guide white paper) lists the permissions you grant in each row, and the effective permissions the grantee receives in each column. Items marked as Yes have the effective permission indicated; items marked with an asterisk have that permission only in their local administrative group.

Table 3-2: Effective Permissions Granted to Exchange Objects Might Differ from What You Explicitly Grant
	AG: View	AG: Admin	AG: Full Admin	ORG: View	ORG: Admin	ORG: Full Admin
AG: Exchange View Only Administrator	Yes*
AG: Exchange Administrator	Yes*	Yes*
AG: Exchange Full Administrator	Yes*	Yes*	Yes*
ORG: Exchange View Only Administrator	Yes			Yes
ORG: Exchange Administrator	Yes	Yes		Yes	Yes
ORG: Exchange Full Administrator	Yes	Yes	Yes	Yes	Yes	Yes

If you want to delegate control over lower level objects (for example, individual servers or administrative groups), you must do so manually by setting permissions on the objects themselves using the ADSIEdit snap-in. However, be forewarned: as soon as you change a DACL below the original object it was applied to, the original DACL is replaced with one that just says Custom. For example, let s say you grant Exchange Full Administrator permission to the ExAdmins group on a storage group, then use ADSIEdit to modify the permissions on a mailbox database, your original Exchange Full Administrator DACL goes away. The permissions are still there, but they re no longer marked as a role ”you have to manually inspect the permissions bundled into Custom to figure out exactly what it means.

Permissions and Mailboxes

In most cases, users must be able to log on to a Windows domain before they can access Exchange resources. You can allow anonymous Network News Transfer Protocol (NNTP), Internet Message Access Protocol 4 (IMAP4), and Lightweight Directory Access Protocol (LDAP) traffic; however, by default the NNTP and IMAP4 protocols require authentication, too (and because they re turned off by default in Exchange Server 2003, they won t be available to authenticated or anonymous users unless you enable them). The account used to log on controls which resources the user can access, in both Windows and Exchange.

Each private mailbox on an Exchange server is owned by one Windows account; one Windows account can own zero or one mailbox. That s because the mailbox itself is now an attribute of the user account, instead of being a separate object as it was in Exchange 5.5. Another change has to do with the relationship between Exchange organizations and Active Directory domains. In Exchange 5.5, it was common to use multiple domains with trust relationships to build an Exchange organization that spanned multiple Windows NT domains. In Exchange 2000 and later, the Exchange organization already spans all the domains in your Active Directory forest. That s why you can only have one Exchange organization per Active Directory forest.

There are two ways to get permission to open a user s mailbox. First, you can present credentials from that user s account by logging on with it. This is the most commonly used method, as this is what happens when Alice logs on to her own account and opens her own mailbox.

Second, you can open a mailbox or folder if you re logged on with an account that has permissions to the mailbox. Note that this doesn t include administrators! By default, the local Administrator account and the Domain Admins and Enterprise Admins groups have a deny ACL set for the Full Mailbox Access permission, meaning that administrators are explicitly restricted from reading users mail unless you manually change that permission on the parent store and server of the mailbox. Users often need to grant someone else access to selected parts of their mailbox. This process, known as delegation, is controlled through Outlook. When you delegate access to another user, that user gains permission to open specified folders in your mailbox. For example, if Bob grants Charlie access to his Calendar folder, Charlie can use Outlook s File Open Other User s Folder command to open Bob s Calendar. Because this is an Outlook feature, you ll learn how to control this in Chapter 13.

Permissions and Public Folders

Some special considerations arise when using public folders in an organization that contains both Exchange 5.5 and Exchange 2000 or Exchange Server 2003 servers (I ll lump the two together for purposes of this sidebar). The two versions of Exchange have different permission sets ”Exchange 2000 and later have some permissions that its predecessor lacks. In addition, it s possible for problems to occur because the DACL for a public folder with replicas on both Exchange 5.5 and Exchange 2000 servers might contain SIDs for users that don t exist in Active Directory. The most common cause for this is deleting a user account from the Exchange 5.5 directory but leaving the user s ACE in place on the folder DACL. Exchange 5.5 public folders store their DACLs in a separate table in the directory, whereas in Exchange 2000 the DACL is stored directly on the folder, just like a file system folder.

The basic requirements for peaceful coexistence of public folders in mixed- mode organizations are simple. First, any user or group who has mailboxes on an Exchange 5.5 server must have a corresponding account in Active Directory. Second, remember that there is a relatively complicated conversion process that s supposed to map the Exchange 5.5 folder DACL to the correct Active Directory equivalent. This process works in two directions:

When Exchange Server 2003 replicates access control data to an Exchange 5.5 server, it converts each SID in the DACL to an Exchange 5.5-style distinguished name (DN). The Windows 2000 permissions are converted to MAPI permissions, and the MAPI permissions are stored in the ptagACLData property and replicated, along with the Windows NT and Admin SDs.
When Exchange 2000 receives access control data from an Exchange 5.5 server, it throws away the Windows NT and Admin SDs. This protects your Exchange 2000 item-level permissions from damage, but it also keeps you from making effectual permission changes on a replicated object from within Exchange 5.5. It then converts the DNs back to SIDs, converts the permissions in ptagACLData to Windows 2000 format, and puts the converted permissions into the Windows NT-style SD.

Sometimes this process fails, in which case public folder permissions seem to disappear. The conversion process is detailed in Microsoft Knowledge Base article 326266; the article also provides a number of methods for preventing the problem from happening in the first place.

If you want to see the permissions on a particular public folder, use Exchange System Manager. Right-click the folder of interest, then choose the Properties command and click the Permissions tab. Click Client Permissions. What you see at this point will depend on whether you re examining a public folder in the MAPI TLH or in an application TLH: folders homed in the MAPI TLH will (quite naturally) show the Outlook-style MAPI permissions dialog box, whereas application TLH public folders show the Windows 2000-style dialog box. If you want to see the Windows Server 2003 equivalent permission on a MAPI TLH public folder, then hold down the Ctrl key when you click Client Permissions, and you ll get a Windows Server 2003-style permissions dialog box that happens to be empty ”click Advanced to see the actual ACEs in the DACL.