Exchange Server's Perplexing Permissions

Understanding Exchange Server's complex array of permission levels is crucial to managing the Exchange organization effectively. You need to know about Exchange roles and rights and how Exchange permissions flow via the Organization, Site, and Configuration containers. You also need to know how to fine-tune permissions for mailboxes and distribution lists (DLs).

Exchange Roles and Their Rights
Exchange Server permissions consist of a group of rights collected into roles that define the type of access a Windows NT account has to an Exchange Server container and its objects. Table 1 lists the seven default Exchange roles and their associated rights; Table 2 describes the activities the rights permit.

The Service Account Admin has rights over all objects. In most installations, you don't want to log on with the Service Account Admin role because this role has more rights than you need to perform routine tasks. However, you need the Service Account Admin role to troubleshoot your server with the Mdbvu32 utility. (Tony Redmond discusses the Mdbvu32 utility in "What to Do When Your IMS Fails," February 1999.)

Permissions Admin and Admin are the same, except the Permissions Admin has the additional right to use the Permissions tab of a property sheet to modify permissions. NT administrators who have the Admin role are often surprised when they can't modify permissions on an Exchange object because in NT, the Administrator role gives you complete control over the OS. In Exchange, however, the Permissions Admin role has more rights than the Admin role. To maintain a high security level, Microsoft recommends giving the Permissions Admin role to as few individuals as possible and the Admin role to most administrators.

The View Only Admin role has the right to log on to the Microsoft Exchange Administrator program. By default, Exchange displays this role only at the Site container. If you want to use the View Only Admin role on any other container, you must force Exchange to display the rights window in all objects. To do so, go to Tools, Options in Exchange Administrator, and from the Permissions tab, check Show Permissions page for all objects and Display rights for roles on Permissions page, as Screen 1 shows. If you follow these steps, you can use this role on any container by clearing every check box in the Rights window for an NT account.

You assign predefined roles and rights on the Permissions tab of an Exchange object in the Administrator program. For example, in the Configuration container you see in Screen 2, the NT local group Administrators has the Permissions Admin role, and the NT user account EXService has the Service Account Admin role.

Permission Flow
After you install Exchange Server, you must define who has permission to modify your Exchange hierarchy. You usually define permissions at three levels: Organization, Site, and Configuration. Each of these containers has a Permissions tab associated with its property sheet; Screen 2 shows the Configuration Properties sheet.

The highest level of the hierarchy is the Organization, which is the messaging enterprise on top of the NT domains and consists of one or more Sites. In Screen 3, the Organization is WidgetsRus. Contrary to what you might expect, the roles assigned to the Organization don't flow down to any underlying subfolders. Therefore, Address Book Views (ABVs), Folders (both public folders and system folders), and the Global Address List (GAL) aren't part of the Organization context.

Below the Organization object is the Site container, which is a collection of one or more servers that share a common Site name. Screen 3 shows two Sites in the WidgetsRus Organization: USA and EUROPE. Strangely enough, the permissions you assign at the Site level can flow in either direction, up or down. If you assign roles at the Site level, permissions flow up to the Address Book Views and Folders containers and flow down to the Recipients container. I don't know any other BackOffice application that demonstrates this peculiar behavior.

Users with the appropriate roles at the Site container can open the Exchange Administrator program and modify recipients' attributes in the Recipients container. This capability creates some interesting scenarios. For example, if you want each Site to be autonomous from every other Site within the Organization, you can assign the proper role (e.g., Admin) to the specific NT group that manages that Site. Then, all users who manage Exchange can open the Exchange Administrator program, but they can manipulate the Recipients container only within their Site. This arrangement prohibits single-seat administration but allows some independence between Sites.

You use the Configuration container to set parameters for all objects within that container. As Screen 3 shows, roles set at this object flow down to its subcontainers. Hence, everything in the right pane inherits permissions set at the Configuration object. For example, if I disabled POP3 support from the Protocols container's property sheet, all servers under the Configuration hierarchy would disable this protocol, unless I override this function by configuring the POP3 protocol at the server.

Permissions flow downward in a least restrictive manner. If you give someone Admin rights on the Configuration container and View Only Admin rights on the Connections container, that person will effectively have Admin rights on the Connections container because you can't restrict permissions at a lower level. You must restrict permissions at the parent level and then loosen them on the specific container level.

Configuring Exchange Permissions
When you understand how permissions flow, you can apply them in a real-world environment. Here are two examples of how to give the proper NT user or groups the ability to control Exchange objects.

When the NT administrator and Exchange administrator are different people. In a certain large company, suppose separate departments administer NT and Exchange Server. Because creating new recipients (e.g., mailboxes) is straightforward, you can assign this task to the NT administrators by granting the Exchange role of Admin to their NT group account at the Site container.

When the NT administrator invokes User Manager for Domains to create a new NT user account on the master domain, Exchange Server can automatically create a new mailbox for that account in the Recipients container on the Exchange server. This automation, which permissions make possible, frees the Exchange administrator to focus on more complex messaging concerns, such as managing connectors and configuring servers.

To make NT prompt the NT administrator to create a new Exchange Server mailbox when the administrator creates a new NT user account, use User Manager for Domains to go to Exchange, Options and check the appropriate check boxes, as Screen 4 shows.

Conversely, when an Exchange administrator creates a new mailbox, he or she can tie an existing NT account to that mailbox or create a new NT account. To create or add a mailbox, use User Manager for Domains to add the Exchange administrator's NT account into the Account Operators local group. That way, the Exchange administrators can create or delete NT user accounts when they create or delete individual mailboxes.

When you want to grant Exchange responsibilities for a particular container. Suppose you decide to make a few people responsible for administering the Monitors container in the Configuration container. (Monitors proactively ensure that Exchange servers are performing properly. For more information about using monitors, see "Using Exchange Server Link and Server Monitors," May 1999.) However, you don't want these people to have the ability to add, delete, or modify any other Exchange objects under the Configuration container.

To assign the appropriate role, go to the Permissions tab of the Configuration container's property sheet, and add the NT group with View Only Admin role. Because the Roles menu in the Configuration container doesn't include the View Only Admin option, you assign the role by clearing all the check boxes in the Rights window. As you see in Screen 5, the NT group Monitor LG has only limited permissions at the Configuration container (i.e., the ability to view the Configuration objects), but the Monitor group has Admin privileges at the Monitors container only. Thus, this group has the ability to add, modify, or delete monitors, but it can't alter any other objects with the Configuration container.

To complete setting up permissions for the monitoring responsibility, you need to give members of the NT monitors group the right to log on to the Exchange Administrator program by assigning them the View Only Admin role on the Permissions tab of the Site container properties sheet.

As you see, setting up permissions can be tedious. In the latter example, you had to assign rights to three different containers (Site, Configuration, and Monitors) to give the proper permissions level to an NT group.

Permissions on Recipients
Assigning permissions to recipients also works differently from what you might expect. The core concept is that whenever you place permissions on mailboxes, mailboxes always take precedence over DLs. For example, if you want to prevent a mailbox from receiving messages from a specific mailbox, open the Exchange Administrator program and go to that recipient mailbox's property sheet. On the Delivery Restrictions tab, you can define what mailboxes and DLs you want the recipient to accept or reject messages from. If you accept mail from the Sales DL and reject mail from Juli X. Nimitz, that mailbox will reject Juli's messages, even if she's a member of the Sales DL.

You can apply permissions on a public folder from the Exchange Administrator program by drilling down to Organization, Folders, Public Folders and then selecting the property sheet of the folder you want to restrict. On the General tab, click Client permissions. (A public folder owner can access this page from the Outlook client by right-clicking the public folder, selecting Properties, and then going to the Permissions tab.) As Screen 6 shows, client permissions have roles such as Author, Owner, and Reviewer. Each role has a different set of permissions. In Screen 6, if Juli X. Nimitz were a member of both the Sales DL and the Mkt DL, Juli's permissions to this public folder would still be only Reviewer because her mailbox takes precedence over the DL's role. If Juli's mailbox weren't on the list, she would have the accumulated permissions of Custom and Nonediting Author because of her membership in the Sales and Mkt DLs. If you don't assign roles to any mailboxes or DLs, the system-generated Default name with a role of Author defines the permissions for all recipients.

At any time, the client can discern who the public folder contact is and the permissions the client has to a particular folder by right-clicking the folder, selecting Properties, and looking on the Summary tab.

Assign with Care
Exchange Server permissions aren't intuitive, and they're often inconsistent with NT permissions. For instance, in NT, share permissions for user and group accounts always accumulate; in Exchange Server, mailbox permissions take precedence over DLs. Share permissions in NT always flow down. In Exchange, permissions set at the Organization container don't flow down at all and permissions set at the Site container can flow both up and down. When you know how permissions work in Exchange, you can properly assign users to the Exchange objects they need to control and keep nonauthorized personnel out.