Understanding Permissions Coexistence with Exchange 2003
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
Permissions in Microsoft Exchange Server 2010 and Exchange Server 2003 are completely separate. This is because the permissions models used by Exchange 2010 and Exchange 2003 are different. You must take steps to grant existing Exchange 2003 administrators permissions to your Exchange 2010 servers, and vice versa. Additionally, management of Exchange 2010 and Exchange 2003 is performed separately using the management tools provided by each version. You can grant permissions to your administrators so that they can manage your combined Exchange 2010 and Exchange 2003 organization.
For more information about planning coexistence between Exchange 2010 and Exchange 2003, see Exchange 2003 - Planning Roadmap for Upgrade and Coexistence.
Exchange 2010 Permissions
Exchange 2010 uses the Role Based Access Control (RBAC) permissions model. This model consists of management role groups that are assigned one of a number of 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 the roles provide. The following table provides an example of the role groups, some of the roles that they're assigned, and a description of the type 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 are some of the roles assigned to this role group:
|
Users who need to 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 are the roles assigned to this role group:
|
Users who need to view the configuration of the entire Exchange 2010 organization should be members of this role group. These users need to be able to view server configuration, recipient information, and be able to 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 are the roles assigned to this role group:
|
Users who need to 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 are some of the roles assigned to this role group:
|
Users who need to 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 are the roles assigned to this role group:
|
Users who need to perform searches of mailboxes to support legal proceedings or 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 your legal department. This allows legal personnel to 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. |
As shown in the previous table, Exchange 2010 provides a granular level of control over the permissions you grant to your administrators. You can choose from 11 role groups in Exchange 2010. For a complete list of role groups and the permissions they provide, see Built-in Role Groups.
Because of the number of role groups Exchange 2010 provides, and because further customization is possible by creating role groups with different role combinations, manipulating access control lists (ACLs) on Active Directory objects is no longer necessary and won't have any 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 if it's allowed, Exchange performs the task on behalf of the user in the Exchange Trusted Subsystem universal security group (USG). With some exceptions, all of the ACLs on objects in Active Directory that Exchange 2010 needs to access are granted to the Exchange Trusted Subsystem USG. This is a fundamental change from how permissions are handled in Exchange 2003.
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 2003 Permissions
Exchange 2003 has the following administrative roles:
Exchange View Only This role grants permissions to view Exchange 2003 server and recipient information to an Exchange 2003 administrator.
Exchange Administrator This role grants all permissions to Exchange 2003 servers and recipients except for the ability to take ownership, change permissions, or open user mailboxes, to Exchange 2003 administrators. If the administrator will need to add objects or modify object properties, but won't be required to delegate permissions on the objects, this role is assigned.
Exchange Full Administrator This role grants all permissions to Exchange 2003 servers and recipients, including the ability to change permissions, to an Exchange 2003 administrator. This role is assigned to administrators who are required to delegate permissions to objects.
Exchange 2003 enables you to segment your administrators into one of these roles. The permissions are assigned directly to either the user or to the USG the user is a member of. Any actions performed by the user are performed in the context of that user's Active Directory account.
If you need to assign permissions at a more granular level, you must modify the ACLs on individual Exchange 2003 objects, such as address lists and databases. As with the administrative roles, the user, or the security group the user is a member of, is added to the ACL directly, and the actions are performed in the context of the user.
For more information about Exchange 2003 administrative groups, see Microsoft Knowledge Base article 823018, Overview of Exchange administrative role permissions in Exchange 2003.
Permissions in Exchange 2010 and Exchange 2003 Coexistence
As describe earlier in this topic, the permissions models for Exchange 2010 and Exchange 2003 are different. Exchange 2010 uses role groups to grant permissions, while Exchange 2003 uses a combination of administrative groups and ACLs to grant permissions. Exchange 2010 and Exchange 2003 permissions are completely separate, even though both versions exist in the same forest. This means that by default and without any additional configuration, Exchange 2003 administrators don't have permissions to manage Exchange 2010 servers and Exchange 2010 administrators don't have permissions to manage Exchange 2003 servers. This situation creates questions that you need to consider:
Do you want to grant Exchange 2010 administrators access to administer Exchange 2003 servers and vice versa?
Do you want to customize Exchange 2010 permissions so that they match the customizations you made to Exchange 2003?
Grant Exchange 2010 Permissions to Exchange 2003 Administrators
If you want Exchange 2003 administrators to administer Exchange 2010 servers, your Exchange 2003 administrators must be added as members to one or more Exchange 2010 role groups. You can add either users or USGs to role groups. The permissions granted to the role groups will then be applied to the users or USGs 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 provides a mapping between Exchange 2003 administrative roles and Exchange 2010 role groups.
Exchange 2003 administrative roles and Exchange 2010 role groups
| Exchange 2003 administrative role | Exchange 2010 role group |
|---|---|
Exchange Full Administrator |
Organization Management |
Exchange Administrator |
There is no equivalent role group included with Exchange 2010. A custom role group that's based on the Organization Management role group, but without any delegating role assignments, must be created in Exchange 2010 to have a role group equivalent to the Exchange Administrator role group. For more information about creating custom role groups, see Create a Role Group. |
Exchange View Only |
View Only Organization Management |
If all your Exchange 2003 administrators are members of one of the three Exchange 2003 administrative roles, you need to add the members of each of the administrative groups to their equivalent Exchange 2010 role group. For more information about adding users and USGs to role groups, see Add Members to a Role Group.
If you've modified ACLs on Exchange 2003 objects to grant more granular permissions to Exchange 2003 administrators, and want to assign similar permissions to Exchange 2010 servers to those administrators, you must do the following:
Inventory the ACL customization you've done on your Exchange 2003 objects, and identify the administrators granted permissions to each.
Classify each Exchange 2003 object, for example, whether it's a database, server, or recipient object.
Map the objects to the corresponding Exchange 2010 role group. For a list of built-in role groups, see Built-in Role Groups.
Add the USGs or users for each type of object to the corresponding Exchange 2010 role groups. For more information about adding users and USGs to role groups, see Add Members to a Role Group.
When you're done, your Exchange 2003 administrators should be members of the role group that maps to the Exchange 2010 objects they need to administer. They can now use the Exchange 2010 management tools to manage the Exchange 2010 servers and recipients.
Important
In general, Exchange 2003 servers and recipients must be managed by Exchange 2003 management tools, and Exchange 2010 servers and recipients must be managed by Exchange 2010 management tools. For more information, see Exchange 2003 - Planning Roadmap for Upgrade and Coexistence.
If the built-in role groups don't give you the specific set of permissions you want to grant to some administrators, you can create custom role groups. When you create a custom role group, you can choose which roles you want to add to it. This enables you to define the specific features you want members of the role group to manage. For example, if you only want administrators to manage distribution groups, you can create a custom role group and choose just the Distribution Groups role. Members of that custom role group will only be able to manage distribution groups. For more information about how to create custom role groups, see Create a Role Group.
If you've given selective permissions to certain Exchange 2003 objects, such as allowing administrators to administer only specific databases, and you want to apply the same configuration to your Exchange 2010 servers, see "Re-Create Exchange 2003 ACL Customization Using Management Scopes in Exchange 2010" later in this topic.
Grant Exchange 2003 Permissions to Exchange 2010 Administrators
If you want Exchange 2010 administrators to administer Exchange 2003 servers, you need to add your Exchange 2010 administrators to one of the three Exchange 2003 administrative groups or add them to the appropriate ACLs if you've customized your Exchange 2003 permissions. You can add either users or USGs to Exchange 2003 administrative groups. Role groups are USGs so they can be added directly to Exchange 2003 administrative groups. This topic discusses adding Exchange 2010 administrators to the built-in Exchange 2003 administrative groups.
The same mapping between Exchange 2010 role groups and Exchange 2003 administrative roles that's shown in the "Exchange 2003 administrative roles and Exchange 2010 role groups" table earlier in this topic applies. If you want your Exchange 2010 organization administrators to have full access to your Exchange 2003 administrative roles, add the Organization Management role group to the Exchange Full Administrators administrative group. Do the same with the View Only Organization Management role group and the Exchange View Only administrative group.
When you're done, your Exchange 2010 administrators should be members of the administrative group that maps to the role group they're in. They can now use the Exchange 2003 management tools to manage the Exchange 2003 servers and recipients.
Important
In general, Exchange 2003 servers and recipients must be managed by Exchange 2003 management tools and Exchange 2010 servers and recipients must be managed by Exchange 2010 management tools. For more information, see Exchange 2003 - Planning Roadmap for Upgrade and Coexistence.
For more information about adding users or USGs to Exchange 2003 administrative groups, see Knowledge Base article 823018, Overview of Exchange administrative role permissions in Exchange 2003.
Re-Create Exchange 2003 ACL Customization Using Management Scopes in Exchange 2010
In Exchange 2003, if you want to restrict who can administer a specific mailbox store, administer specific users, or control which mailbox store mailboxes are created on, you need to 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 making use of management scopes, which are a component of RBAC.
Management scopes provide the ability to use built-in scopes and custom scopes to define what objects 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 no one else.
The following types of management scopes can be created:
Predefined relative Predefined relative scopes are included with Exchange 2010. You can control what a user sees and is able to modify. For example, predefined relative scopes can control whether users see only information about themselves or information about the whole organization.
Recipient Recipient scopes control which recipients an administrator can create, modify, or delete. These 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 only report to a specific manager.
Server Server scopes control which servers an administrator can manage. You can specify either server lists or server filters. With server lists, you define a static list of servers that can be managed. Server filters work the same way as recipient filters, where you can specify criteria that needs 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 moved to. Like server scopes, they can be defined as lists or as filters. For example, you might want to create a list or filter that allows administrators to create or move mailboxes on specific mailbox databases managed by a particular subsidiary.
Exclusive With the exception of predefined relative scopes, any of the preceding scopes can also be created as exclusive scopes. Exclusive scopes work like deny access control entries (ACEs) in ACLs. If anything matches an exclusive scope, only the administrators assigned an exclusive scope can manage that object, even if another scope that's not exclusive, matches the same object. This is especially useful for executives, where you might want only a few highly trusted individuals to be able to manage their mailboxes. Even if another, broader, regular recipient scope includes the executive's mailbox in their 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 where. For more information, see the following topics:
To create the same permissions model in Exchange 2010 using management scopes that you might have defined in Exchange 2003 using customized ACLs, you need to inventory the ACLs you've customized and 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 you want each management scope to control access to. For more information about the properties you can use with management scope filters, see Understanding Management Role Scope Filters.
For more information about creating management scopes, see Create a Regular or Exclusive Scope.
© 2010 Microsoft Corporation. All rights reserved.