Sdílet prostřednictvím


Understanding Permissions Coexistence with Exchange 2007

 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

The permissions model in Microsoft Exchange Server 2010 is improved from the models used in earlier versions of Exchange. Exchange 2010 includes Role Based Access Control (RBAC) permissions that replace the Active Directory access control entry (ACE)-based authorization model used in Microsoft Exchange Server 2007. RBAC is the authorization mechanism used for most of the management of Exchange 2010. This mechanism includes the following management areas:

  • Exchange Management Shell

  • Exchange Control Panel

  • Exchange Management Console (EMC)

  • Exchange Web Services

  • MAPI on the middle-tier component

For more information about how to plan coexistence between Exchange 2010 and earlier versions of Exchange, see Understanding Upgrade to Exchange 2010.

Looking for management tasks related to permissions? Check out Managing Permissions.

Exchange 2010 Permissions

The Exchange 2010 RBAC permissions model consists of management role groups assigned one of several management roles. Management roles contain permissions that enable administrators to perform tasks in the Exchange organization. Administrators are added as members of the role groups and are granted all the permissions that the roles provide. The following table provides an example of the role groups, some of the roles assigned to role groups, and a description of the kind of user who might be a member of the role group.

Examples of role groups and roles in Exchange 2010

Management role group Management roles Members of this role group

Organization Management

The following roles are some of the roles assigned to this role group:

  • Address Lists

  • Exchange Servers

  • Journaling

  • Mail Recipients

  • Public Folders

Users who manage the entire Exchange 2010 organization should be members of this role group. With some exceptions, members of this role group can manage nearly any aspect of the Exchange 2010 organization.

By default, the user account used to prepare Active Directory for Exchange 2010 is a member of this role group.

For more information about this role group and for a complete list of roles assigned to this role group, see Organization Management.

View Only Organization Management

The following roles are assigned to this role group:

  • Monitoring

  • View-Only Configuration

  • View-Only Recipients

Users who view the configuration of the entire Exchange 2010 organization should be members of this role group. These users must be able to view server configuration and recipient information, and perform monitoring functions without the ability to change organization or recipient configuration.

For more information about this role group, see View-Only Organization Management.

Recipient Management

The following roles are assigned to this role group:

  • Distribution Groups

  • Mail Enabled Public Folders

  • Mail Recipient Creation

  • Mail Recipients

  • Message Tracking

  • Migration

  • Move Mailboxes

  • Recipient Policies

Users who manage recipients such as mailboxes, contacts, and distribution groups in the Exchange 2010 organization should be members of this role group. These users can create recipients, modify or delete existing recipients, or move mailboxes.

For more information about this role group and for a complete list of roles assigned to this role group, see Recipient Management.

Server Management

The following roles are some of the roles assigned to this role group:

  • Databases

  • Exchange Connectors

  • Exchange Servers

  • Receive Connectors

  • Transport Queues

Users who manage Exchange server configuration such as Receive connectors, certificates, databases, and virtual directories should be members of this role group. These users can modify Exchange server configuration, create databases, and restart and manipulate transport queues.

For more information about this role group and for a complete list of roles assigned to this role group, see Server Management.

Discovery Management

The following roles are assigned to this role group:

  • Legal Hold

  • Mailbox Search

Users who perform searches of mailboxes to support legal proceedings or to configure legal holds should be members of this role group.

This is an example of a role group that might contain non-Exchange administrators, such as personnel in the legal department. Legal personnel can perform their tasks without intervention from Exchange administrators.

For more information about this role group and for a complete list of roles assigned to this role group, see Discovery Management.

This table shows that Exchange 2010 provides a granular level of control over the permissions that you grant to your administrators. You can choose among 11 role groups in Exchange 2010. For a complete list of role groups and the permissions that they provide, see Built-in Role Groups.

Because Exchange 2010 provides many role groups and because further customization is possible by creating role groups that have different role combinations, the manipulation of access control lists (ACLs) on Active Directory objects is no longer necessary and has no effect. ACLs are no longer used to apply permissions to individual administrators or groups in Exchange 2010. All tasks, such as an administrator creating a mailbox or a user accessing a mailbox, are managed by RBAC. RBAC authorizes the task, and then Exchange performs the task on behalf of the user if allowed. Exchange performs the task in the Exchange Trusted Subsystem universal security group (USG). With some exceptions, all the ACLs on objects in Active Directory that Exchange 2010 has to access are granted to the Exchange Trusted Subsystem USG. This is a fundamental change from how permissions are handled in Exchange 2007.

The permissions granted to a user in Active Directory are separate from the permissions granted to the user by RBAC when that user is using the Exchange 2010 management tools.

For more information about RBAC, see Understanding Role Based Access Control.

Exchange 2007 Permissions

The Exchange 2007 administrative model leverages Active Directory forests to define security boundaries. There is no isolation of security permissions within a particular forest. Forest owners and enterprise administrators can always gain access to all resources in any domain. In Exchange 2007, you may have to grant enterprise administrator rights and top-level domain administrator rights on a temporary basis only.

Exchange 2007 provides the following predefined administrator roles:

  • Exchange Organization Administrator role   This role grants permissions to control all aspects of the Exchange 2007 organization. Additionally, an administrator who has this role can grant permissions to other Exchange administrators. This role is granted to the account that you use to install Exchange 2007.

  • Exchange View-Only Administrator role   This role grants permissions to view Exchange configuration. However, an administrator who has this role can't modify objects in the Exchange 2007 organization.

  • Exchange Recipient Administrator role   This role grants permissions to manage e-mail recipients. An administrator who has this role can modify Exchange-related items for users, groups, contacts, and distribution groups.

  • Exchange Server Administrator role   This role grants permissions to manage a specific server. However, this role doesn't grant permissions to perform actions that have a global impact on the Exchange 2007 organization.

  • Exchange Public Folder Administrator role   This role was added in Exchange 2007 Service Pack 1**.** This role grants permissions to manage public folders in the Exchange 2007 organization.

This permissions model uses USGs for all roles except for the Exchange Server Administrator role. When you run the Exchange 2007 Setup /PrepareAD command, the Setup program creates the USGs in the root domain and gives a forest-wide scope to the USGs. The USGs are assigned ACLs to manage Exchange objects throughout Active Directory.

In Exchange 2007, you can separate administrators by assigning them various roles. The permissions are assigned directly either to the user or to the USG of which the user is a member. Any actions performed by the user are performed in the context of that user's Active Directory account. The following table lists the Exchange 2007 administrator roles together with their Exchange-related permissions.

Exchange 2007 administrator roles

Administrator role Members Member of Exchange permissions

Exchange Organization Administrator

The Administrator account or the account used to install the first Exchange 2007 server

Exchange Recipient Administrator

Administrators local group of <server name>

Full control of the Microsoft Exchange container in Active Directory

Exchange View-Only Administrator

Exchange Recipient Administrators

Exchange Server Administrators (<server name>)

Exchange Recipient Administrators

Exchange Server Administrators

Read access to the Microsoft Exchange container in Active Directory

Read access to all the Windows domains that have Exchange recipients

Exchange Recipient Administrator

Exchange Organization Administrators

Exchange View-Only Administrators

Full control of Exchange properties on Active Directory user objects

Exchange Server Administrator

Exchange Organization Administrators

Exchange View-Only Administrators

Administrators local group of <server name>

Full control of Exchange <server name>

Exchange Server

Each Exchange 2007 computer account

Exchange View-Only Administrators

Special

Exchange Public Folder Administrator

Exchange Organization Administrators

Exchange View-Only Administrators

Full control to manage all public folders (granted the Create top level public folder extended right)

If you need to make more granular permission assignments, you can modify the ACLs on individual Exchange 2007 objects, such as address lists or databases. You must add the user or security group of which the user is a member directly to the ACL. Then, the actions are performed in the context of the particular user.

For more information about how to manage permissions in Exchange 2007, see Configuring Permissions in Exchange Server 2007.

Exchange 2010 and Exchange 2007 Coexistence Permissions

Because the permissions models for Exchange 2010 and for Exchange 2007 differ, Exchange 2010 permission assignments are separate from Exchange 2007 permission assignments. This is true even if both versions of Exchange are installed in the same forest. Without additional configuration, Exchange 2010 administrators don't have the required permissions to manage Exchange 2007-based servers, and Exchange 2007 administrators don't have the required permissions to manage Exchange 2010-based servers. You should consider the following questions:

  • Do you want to grant Exchange 2010 administrators access to manage Exchange 2007 servers?

  • Do you want to grant Exchange 2007 administrators access to manage Exchange 2010 servers?

  • Do you want to customize Exchange 2010 permissions so that they match any customizations that have been made to Exchange 2007 ACLs?

Granting Exchange 2010 Permissions to Exchange 2007 Administrators

If you want Exchange 2007 administrators to administer Exchange 2010 servers, the Exchange 2007 administrators must be added as members of one or more Exchange 2010 role groups. You can add either users or USGs to role groups. The permissions granted to the role groups are then applied to the users or the USGs that you add as members.

Important

If you use domain local or global Active Directory security groups, you must change them to USGs if you want to add them as members of an Exchange 2010 role group. Exchange 2010 supports only USGs.

The following table describes the mapping between Exchange 2007 administrator roles and Exchange 2010 role groups.

Exchange 2007 administrator roles and Exchange 2010 role groups

Exchange 2007 administrator role Exchange 2010 role group

Exchange Organization Administrator

Organization Management

Exchange Recipient Administrator

Recipient Management

Exchange Server Administrator

Server Management

Exchange View-Only Administrator

View Only Organization Management

Exchange Server

No equivalent role group in Exchange 2010

(For more information about how to create custom role groups, see Create a Role Group.)

Exchange Public Folder Administrator

Public Folder Management

If all your Exchange 2007 administrators are members of one of the Exchange 2007 administrative roles, you can add the members of each of the administrative groups to their equivalent Exchange 2010 role group. For example, if you want to give all Exchange 2007 organization administrators full access to Exchange 2010 objects, add the Exchange Organization Administrators USG to the Organization Management role group.

For more information about how to add users and USGs to role groups, see Add Members to a Role Group.

If you modify ACLs on Exchange 2007 objects to grant more granular permissions to Exchange 2007 administrators, and if you want to assign similar permissions to Exchange 2010 servers to those administrators, follow these steps:

  1. Review the ACL customizations that have been made to the Exchange 2007 objects, and locate the administrators who have been granted permissions to each object.

  2. Categorize each Exchange 2007 object. For example, determine whether the object is a database, server, or recipient object.

  3. Map the objects to the corresponding Exchange 2010 role group. For a list of built-in role groups, see Built-in Role Groups.

  4. Add the USGs or users for each kind of object to the corresponding Exchange 2010 role groups. For more information about how to add users and USGs to role groups, see Add Members to a Role Group.

After you complete these steps, the Exchange 2007 administrators will be members of the specific role group that's mapped to the appropriate Exchange 2010 objects. The Exchange 2007 administrators can use the Exchange 2010 management tools to manage the Exchange 2010 servers and recipients.

Important

In general, Exchange 2007 servers and recipients must be managed by using Exchange 2007 management tools, and Exchange 2010 servers and recipients must be managed by using Exchange 2010 management tools.

If the built-in role groups don't provide the specific set of permissions that you want to grant to some administrators, you can create custom role groups. When you create a custom role group, you can select which roles to add to it. You can define the specific features you want members of the role group to manage. For example, if you want administrators to manage only distribution groups, you can create a custom role group, and then select only the Distribution Groups role. After you do this, members of that custom role group can manage only distribution groups. For more information about how to create custom role groups, see Create a Role Group.

If you assign selective permissions to certain Exchange 2007 objects (for example, you allow administrators to administer only specific databases), and if you want to apply the same configuration to your Exchange 2010 servers, see "Re-Creating Exchange 2007 ACL Customization Using Management Scopes in Exchange 2010" later in this topic.

Granting Exchange 2007 Permissions to Exchange 2010 Administrators

If you want Exchange 2010 administrators to administer Exchange 2007 servers, add the Exchange 2010 administrators to the USGs or the security group that corresponds to the particular Exchange 2007 administrator role. Alternatively, if you have customized ACL settings, add the administrators to the appropriate ACLs. Role groups are USGs, so role groups can be added directly to Exchange 2007 administrator role USGs.

After you finish, the Exchange 2010 administrators will be members of the appropriate Exchange 2007 administrator role or roles. The Exchange 2010 administrators can use the Exchange 2007 management tools to manage Exchange 2007 servers and recipients.

Re-Creating Exchange 2007 ACL Customization Using Management Scopes in Exchange 2010

In Exchange 2007, when you want to restrict who can administer a specific mailbox store, administer specific users, or control which mailbox store mailboxes are created on, you must modify the ACLs on the objects you want to restrict. Exchange 2010 provides the same capabilities, but without having to modify any ACLs. It does this by using management scopes, which are a component of RBAC.

Management scopes provide built-in scopes and custom scopes to define the objects that administrators can manage. By applying management scopes, you can define which recipients can be administered, which mailbox databases mailboxes can be created on, and which recipients or servers should be administered by a small group of administrators and by no one else.

You can create the following types of management scopes:

  • Predefined relative   Predefined relative scopes are included in Exchange 2010. You can control what a user sees and what a user modifies. For example, predefined relative scopes can control whether users see only information about themselves or information about the entire organization.

  • Recipient   Recipient scopes control which recipients an administrator can create, modify, or delete. These selections can be based on an organizational unit (OU), a recipient filter, or both. Recipient filters specify the criteria that a recipient must match to be included in the scope. For example, you might create a recipient filter scope that includes all users in a certain location or in a specific department. You can even combine OUs and recipient filters to match only users who are within a specific OU and who report to a specific manager.

  • Server   Server scopes control which servers an administrator can manage. You can specify either server lists or server filters. For server lists, you define a static list of servers that can be managed. Server filters work in the same manner as recipient filters in that you can specify the criteria that has to be matched. For example, you might create a server scope that matches all servers within a particular Active Directory site.

  • Database   Database scopes control which databases an administrator can manage. They can also control which databases mailboxes can be created on or which databases mailboxes can be moved to. Like server scopes, they can be defined as lists or as filters. For example, you might create a list or filter that allows administrators to create mailboxes on or move mailboxes to specific mailbox databases managed by a specific subsidiary.

  • Exclusive   Recipient, server, and database scopes can also be created as exclusive scopes. Exclusive scopes work in the same manner as deny access ACEs in ACLs. If anything matches an exclusive scope, only the administrators assigned an exclusive scope can manage that object. This is true even if another scope that isn't exclusive matches the same object. This is especially useful when you might want only a few, highly trusted individuals to be able to manage an executive's mailbox. Even if another regular recipient scope is broader and includes the executive's mailbox in the scope, the administrators assigned the broader, regular recipient scope won't be able to manage that executive's mailbox unless they are also assigned the exclusive scope.

Management scopes are used with management roles, management role assignments, and management role groups to control who can manage what objects and in what manner they can manage those objects. For more information, see the following topics:

To create the same permissions model in Exchange 2010 using management scopes that you might have defined using customized ACLs, you must inventory the ACLs that you've customized, and then create management scopes that match them. You can use the filterable properties available on recipient, server, and database objects to create management scopes that include the objects to which you want each management scope to control access. For more information about the properties that you can use with management scope filters, see Understanding Management Role Scope Filters.

For more information about how to create management scopes, see Create a Regular or Exclusive Scope.

 © 2010 Microsoft Corporation. All rights reserved.