Understanding Split Permissions

Applies to: Exchange Server 2010

Organizations that separate the management of Microsoft Exchange Server 2010 objects and Active Directory objects use what's called a split permissions model. Split permissions enable organizations to assign specific permissions and related tasks to specific groups within the organization. This separation of work helps to maintain standards and workflows, and helps to control change in the organization.

The highest level of split permissions is the separation of Exchange management and Active Directory management. Many organizations have two groups: administrators that manage the organization's Exchange infrastructure, including servers and recipients, and administrators that manage the Active Directory infrastructure. This is an important separation for many organizations because the Active Directory infrastructure often spans many locations, domains, services, applications, and even Active Directory forests. Active Directory administrators must ensure that changes made to Active Directory don't negatively impact any other services. As a result, typically only a small group of administrators is allowed to manage that infrastructure.

At the same time, the infrastructure for Exchange, including servers and recipients, can also be complex and require specialized knowledge. Additionally, Exchange stores extremely confidential information about the business of the organization. Exchange administrators can potentially access this information. By limiting the number of Exchange administrators, the organization limits who can make changes to Exchange configuration and who can access sensitive information.

Split permissions typically make a distinction between the creation of security principals in Active Directory, such as users and security groups, and the subsequent configuration of those objects. This helps to reduce the chance of unauthorized access to the network by controlling who can create objects that grant access to it. Most often only Active Directory administrators can create security principals while other administrators, such as Exchange administrators, can manage specific attributes on existing Active Directory objects.

To support the varying needs to separate the management of Exchange and Active Directory, Exchange 2010 lets you choose between a shared permissions model and a split permissions model. Exchange 2010 defaults to a shared permissions model.

Contents

• Explanation of Role Based Access Control and Active Directory
• Shared Permissions
• Split Permissions

Explanation of Role Based Access Control and Active Directory

To understand split permissions, you need to understand how the Role Based Access Control (RBAC) permissions model in Exchange 2010 works with Active Directory. The RBAC model controls who can perform what actions, and on which objects those actions can be performed. For more information about the various components of RBAC that are discussed in this topic, see Understanding Role Based Access Control.

In Exchange 2010, all tasks that are performed on Exchange objects must be done through the Exchange Management Console, the Exchange Management Shell, or the Exchange Web administrative interface. Each of these management tools uses RBAC to authorize all tasks that are performed.

RBAC is a component that exists on every server running Exchange 2010. RBAC checks whether the user performing an action is authorized to do so:

• If the user isn't authorized to perform the action, RBAC doesn't allow the action to proceed.
• If the user is authorized to perform the action, RBAC checks whether the user is authorized to perform the action against the specific object being requested:
  • If the user is authorized, RBAC allows the action to proceed.
  • If the user isn't authorized, RBAC doesn't allow the action to proceed.

If RBAC allows an action to proceed, the action is performed in the context of the Exchange Trusted Subsystem and not the user's context. The Exchange Trusted Subsystem is a highly privileged universal security group (USG) that has read/write access to every Exchange-related object in the Exchange organization. It's also a member of the Administrators local security group and the Exchange Windows Permissions USG, which enables Exchange to create and manage Active Directory objects.

It's important to understand that it doesn't matter what Active Directory permissions a user has when using the Exchange management tools. If the user is authorized, via RBAC, to perform an action in the Exchange management tools, the user can perform the action regardless of his or her Active Directory permissions. Conversely, if a user is an Enterprise Admin in Active Directory but isn't authorized to perform an action, such as creating a mailbox, in the Exchange management tools, the action won't succeed because the user doesn't have the required permissions according to RBAC.

Return to top

Shared Permissions

The shared permissions model is the default model for Exchange 2010. You don't need to change anything if this is the permissions model you want to use. This model doesn't separate the management of Exchange and Active Directory objects from within the Exchange management tools. It allows administrators using the Exchange management tools to create security principals in Active Directory.

The following table shows the roles that enable the creation of security principals in Exchange and the management role groups they're assigned to by default.

Security principal management roles

Only role groups, users, or USGs that are assigned the Mail Recipient Creation role can create security principals such as Active Directory users. By default, the Organization Management and Recipient Management role groups are assigned this role. Therefore members of these role groups can create security principals.

Only role groups, users, or USGs that are assigned the Security Group Creation and Membership role can create security groups or manage their memberships. By default, only the Organization Management role group is assigned this role. Therefore only members of the Organization Management role group can create or manage the membership of security groups.

You can assign the Mail Recipient Creation role and the Security Group Creation and Membership role to other role groups, users, or USGs if you want other users to be able to create security principals.

To enable the management of existing security principals in Exchange 2010, the Mail Recipients role is assigned to the Organization Management and Recipient Management role groups by default. Only role groups, users, or USGs that are assigned the Mail Recipients role can manage existing security principals. If you want other role groups, users, or USGs to be able to manage existing security principals, you must assign the Mail Recipients role to them.

For more information about how to add roles to role groups, users, or USGs, see the following topics:

• Add a Role to a Role Group
• Add a Role to a User or USG

If you switched to a split permissions model and want to change back to a shared permissions model, see Configure Exchange 2010 for Shared Permissions.

Return to top

Split Permissions

If your organization separates Exchange management and Active Directory management, you need to configure Exchange to support the split permissions model. When configured correctly, only the administrators who you want to create security principals, such as Active Directory administrators, will be able to do so and only Exchange administrators will be able to modify the Exchange attributes on existing security principals.

The following table shows the roles that enable the creation of security principals in Exchange and the management role groups they're assigned to by default.

Security principal management roles

By default, members of the Organization Management and Recipient Management role groups can create security principals. You must transfer the ability to create security principals from the built-in role groups to a new role group that you create.

To configure a split permissions model, you must do the following:

1. Create a role group, which will contain the Active Directory administrators that will be able to create security principals.
2. Create regular and delegating role assignments between the Mail Recipient Creation role and the new role group.
3. Create regular and delegating role assignments between the Security Group Creation and Membership role and the new role group.
4. Remove the regular and delegating management role assignments between the Mail Recipient Creation role and the Organization Management and Recipient Management role groups.
5. Remove the regular and delegating role assignments between the Security Group Creation and Membership role and the Organization Management role group.

After doing this, only members of the new role group that you create will be able to create security principals, such as mailboxes. The new group will only be able to create the objects. It won't be able to configure the Exchange attributes on the new object. An Active Directory administrator will need to create the object and then an Exchange administrator will need to configure the Exchange attributes on the object. Exchange administrators won't be able to use the following cmdlets:

• New-Mailbox
• New-MailUser
• New-MailContact
• New-LinkedUser
• Remove-Mailbox
• Remove-MailUser
• Remove-MailContact
• Remove-LinkedUser
• Add-MailboxPermission
• Add-MailboxFolderPermission

Exchange administrators will, however, be able to create and manage Exchange-specific objects, such as transport rules, distribution groups, and so on.

If you want the new role group to also be able to manage the Exchange attributes on the new object, the Mail Recipients role also needs to be assigned to the new role group.

For more information about configuring a split permissions model, see Configure Exchange 2010 for Split Permissions.

Return to top