Exchange

Exchange permissions model

Exchange Server offers a large set of predefined permissions based on the Role-Based Access Control (RBAC) model, which you can use to delegate object creation or modify permissions even on an attribute level. RBAC was introduced in Exchange 2010 to allow precise permission management within the Exchange organization for administrators and users.

Active Directory groups in Exchange

During Exchange Setup, Exchange creates a set of groups in the Microsoft Exchange Security Groups organizational unit (OU) of your root domain in Active Directory that are used for assigning permissions to the Exchange system. Table 1 describes these groups and their respective functionality. The table describes only Exchange system groups, not the Default Management Role Groups used to assign RBAC permissions; those are described later in this section.

Table 1 Exchange security groups

Exchange Group Description
Exchange Servers This group is used in the same way it is used in Exchange 2007 and Exchange 2010: to assign permissions to Exchange servers. It automatically includes all Exchange 2007, 2010, and 2013 computer objects so that they can authenticate against each other. By default, all Exchange servers and the Domain Install Servers groups of all Exchange-prepared domains in your forest are part of this group.
Exchange Trusted Subsystem This group is used to perform all RBAC-controlled operations in Exchange to manage existing objects in Active Directory and to create Exchange-related objects, such as connectors. It is a highly privileged group and has read/write access to every Exchange-related object in all Exchange-prepared domains in the forest.

If Split Permissions is not enabled, this group is a member of the Exchange Windows Permissions group.

Exchange Windows Permissions This group is used to create and modify permissions to all Active Directory objects in all domains. When Split Permissions is not enabled, the Exchange Trusted Subsystem group is automatically added to this group.
ExchangeLegacyInterop This was used for newer versions of Exchange (2007 and later) when a particular version takes inbound mail routed via legacy routing group connectors—essentially, when an Exchange 2003 or earlier server attempts to send mail to a newer Exchange server. For Exchange 2013, the group was never cleaned up and can be deleted when only Exchange 2013 server exists.
Managed Availability Servers This group is used to monitor the Exchange 2013 high-availability platform. Members of this group are all Exchange 2013 computer objects in the forest and the Exchange Servers group.

Exchange Servers:

This group is used in the same way it is used in Exchange 2007 and Exchange 2010: to assign permissions to Exchange servers. It automatically includes all Exchange 2007, 2010, and 2013 computer objects so that they can authenticate against each other. By default, all Exchange servers and the Domain Install Servers groups of all Exchange-prepared domains in your forest are part of this group.

Exchange Trusted Subsystem:

This group is used to perform all RBAC-controlled operations in Exchange to manage existing objects in Active Directory and to create Exchange-related objects, such as connectors. It is a highly privileged group and has read/write access to every Exchange-related object in all Exchange-prepared domains in the forest.

If Split Permissions is not enabled, this group is a member of the Exchange Windows Permissions group.

Exchange Windows Permissions:

This group is used to create and modify permissions to all Active Directory objects in all domains. When Split Permissions is not enabled, the Exchange Trusted Subsystem group is automatically added to this group.

ExchangeLegacyInterop:

This was used for newer versions of Exchange (2007 and later) when a particular version takes inbound mail routed via legacy routing group connectors—essentially, when an Exchange 2003 or earlier server attempts to send mail to a newer Exchange server. For Exchange 2013, the group was never cleaned up and can be deleted when only Exchange 2013 server exists.

Managed Availability Servers:

This group is used to monitor the Exchange 2013 high-availability platform. Members of this group are all Exchange 2013 computer objects in the forest and the Exchange Servers group.

Note: The Exchange Trusted Subsystem is not a member of the local Administrators group by default. This is the reason why if you create a Database Availability Group (DAG) and want to use a server that doesn’t run Exchange as the witness server, you have to add the Exchange Trusted Subsystem to the local Administrators group on the server. Otherwise, you will see an error message while creating the DAG and the witness directory.

Role-Based Access Control permission model

Role-Based Access Control is the permissions model used in Exchange Server 2013. Since Exchange 2010, you have not needed to manage permissions using access control lists (ACLs) in Active Directory. With RBAC, you can configure and control in a very granular way the administrative tasks that administrators or users can perform. RBAC controls both the administrative tasks that can be performed and the extent to which users can now administer their own mailbox and distribution groups. Understand that, with RBAC, it doesn’t matter what Active Directory permissions you have when using Exchange management tools—everything is authorized and controlled via RBAC. You can define precisely which cmdlets and parameters a user can run or modify.

Note: RBAC also filters which cmdlets and functionality are available in Exchange Admin Center (EAC) or Exchange Management Shell (EMS), and it displays only the options available to you. For example, if you do not have the Mailbox Import Export permission, you won’t see the New-MailboxExportRequest cmdlet and thus cannot use it.

The RBAC permission model applies to all Exchange management tools—EAC, EMS, and all Exchange server roles that are part of your Exchange organization, except for the Edge Transport Server role. The Edge Transport Server role is managed using the local built-in Microsoft Windows groups on the computer, not by RBAC.

RBAC assigns permission in two primary ways, depending on whether the user is an administrator or an end-user:

  • Management role groups: Management Role groups are used to assign permissions to administrators. These administrators might require permissions to manage the Exchange Server organization or some part of it. Some administrators might require limited permissions to manage specific Exchange Server features, such as compliance or specific recipients. To use management role groups, add users to the appropriate built-in management role group or to a custom management role group as described later in this section.

  • Management role assignment policies: Management role assignment policies are used to assign end-user management roles. Role assignment policies consist of roles that control what users can do with their mailboxes or distribution groups. These roles do not allow users to manage features that they are not associated with directly.

In addition to using EMS, you can manage RBAC settings in the EAC. For example, the management role groups can be found on the Admin Roles tab as shown in

Figure 1.

Figure 1 Administrator roles in the EAC

Management role groups

Exchange Server includes several built-in role groups you can use to provide varying levels of administrative permissions to user groups. The management role group is a universal security group that associates management roles with a group of administrators or specialist users for managing Exchange-specific users, such as compliance. RBAC assigns each role group one or more management roles that define the precise permissions that RBAC grants to the group. You can add users to or remove users from any built-in role group. For most companies, the default management role groups shown in Table 2 should be sufficient to manage Exchange permissions in the environment.

Table 2 Default management role groups

Role Group Assigned Roles Description
Organization Management Has all assigned roles except the following: LegalHoldApplication, Mailbox Import Export, Mailbox Search, MailboxSearchApplication, OfficeExtensionApplication, Reset Password, Support Diagnostics, TeamMailboxLifecycleApplication, Unscoped Management, UserApplication, My Custom Apps, My Marketplace Apps, MyBaseOptions, MyContactInformation, MyDiagnostics, MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation, MyRetentionPolicies, MyTeamMailboxes, MyTextMessaging, MyVoiceMail Provides access to the entire Exchange Server organization, and can perform almost any task against any Exchange Server object, including delegating permissions to others.
Server Management Database Copies, Databases, Exchange Connectors, Exchange Server Certificates, Exchange Servers, Exchange Virtual Directories, Monitoring, POP3 And IMAP4 Protocols, Receive Connectors, Transport Queues Manages all Exchange servers within the Exchange organization, but members don’t have permission to perform operations that have global impact in the Exchange organization.
Delegated Setup View-Only Configuration Used to install and uninstall Exchange on provisioned servers.
View-Only Organization Management Monitoring, View-Only Configuration, View-Only Recipients View recipient and configuration objects and their properties in the Exchange organization.
Recipient Management Distribution Groups, Mail Recipient Creation, Mail Recipients, Message Tracking, Migration, Move Mailboxes, Recipient Policies, Team Mailboxes Create, manage, and remove Exchange recipient objects in the Exchange organization.
Help Desk User Options, View-Only Recipients View and manage the configuration for individual recipients, and view recipients in an Exchange organization. Members of this role group can manage only the configuration each user can manage on her own mailbox. Additional permissions can be added by assigning additional management roles to this role group.
Discovery Management Legal Hold, Mailbox Search Create and run discovery searches of mailboxes.
Public Folder Management Mail Enabled Public Folders, Public Folders Manage public folders. Members can create and delete public folders and manage public-folder settings—such as quotas, age limits, and permissions—as well as mail-enable and mail-disable public folders on servers running Exchange.
Hygiene Management Application Impersonation, Receive Connectors, Transport Agents, Transport Hygiene, View-Only Configuration, View-Only Recipients Manage Exchange anti-spam features, and grant permissions for antivirus products to integrate with Exchange.
Records Management Audit Logs, Journaling, Message Tracking, Retention Management, Transport Rules Configure compliance features, such as retention-policy tags, message classifications, transport rules, and more.
UM Management UM Mailboxes, UM Prompts, Unified Messaging Manage Unified Messaging (UM) organization, server, prompts, and recipient configuration.
Compliance Management Information Rights Management, Retention Management, View-Only Audit Logs, View-Only Configuration, View-Only Recipients This role group will allow a specified user, responsible for compliance, to properly configure and manage compliance settings within Exchange in accordance  the group’s policy.

Organization Management:

Has all assigned roles except the following: LegalHoldApplication, Mailbox Import Export, Mailbox Search, MailboxSearchApplication, OfficeExtensionApplication, Reset Password, Support Diagnostics, TeamMailboxLifecycleApplication, Unscoped Management, UserApplication, My Custom Apps, My Marketplace Apps, MyBaseOptions, MyContactInformation, MyDiagnostics, MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation, MyRetentionPolicies, MyTeamMailboxes, MyTextMessaging, MyVoiceMail

Provides access to the entire Exchange Server organization, and can perform almost any task against any Exchange Server object, including delegating permissions to others.

Server Management:

Database Copies, Databases, Exchange Connectors, Exchange Server Certificates, Exchange Servers, Exchange Virtual Directories, Monitoring, POP3 And IMAP4 Protocols, Receive Connectors, Transport Queues

Manages all Exchange servers within the Exchange organization, but members don’t have permission to perform operations that have global impact in the Exchange organization.

Delegated Setup:

View-Only Configuration

Used to install and uninstall Exchange on provisioned servers.

View-Only Organization Management:

Monitoring, View-Only Configuration, View-Only Recipients

View recipient and configuration objects and their properties in the Exchange organization.

Recipient Management:

Distribution Groups, Mail Recipient Creation, Mail Recipients, Message Tracking, Migration, Move Mailboxes, Recipient Policies, Team Mailboxes

Create, manage, and remove Exchange recipient objects in the Exchange organization.

Help Desk:

User Options, View-Only Recipients

View and manage the configuration for individual recipients, and view recipients in an Exchange organization. Members of this role group can manage only the configuration each user can manage on her own mailbox. Additional permissions can be added by assigning additional management roles to this role group.

Discovery Management:

Legal Hold, Mailbox Search

Create and run discovery searches of mailboxes.

Public Folder Management:

Mail Enabled Public Folders, Public Folders

Manage public folders. Members can create and delete public folders and manage public-folder settings—such as quotas, age limits, and permissions—as well as mail-enable and mail-disable public folders on servers running Exchange.

Hygiene Management:

Application Impersonation, Receive Connectors, Transport Agents, Transport Hygiene, View-Only Configuration, View-Only Recipients

Manage Exchange anti-spam features, and grant permissions for antivirus products to integrate with Exchange.

Records Management:

Audit Logs, Journaling, Message Tracking, Retention Management, Transport Rules

Configure compliance features, such as retention-policy tags, message classifications, transport rules, and more.

UM Management:

UM Mailboxes, UM Prompts, Unified Messaging

Manage Unified Messaging (UM) organization, server, prompts, and recipient configuration.

Compliance Management:

Information Rights Management, Retention Management, View-Only Audit Logs, View-Only Configuration, View-Only Recipients

This role group will allow a specified user, responsible for compliance, to properly configure and manage compliance settings within Exchange in accordance with the group’s policy.

Management Role Group Components

Use management role groups to assign administrator permissions to groups of users. To understand how management role groups work, you need to understand their components. Figure 2 provides an overview of all the components that are part of a management role group.

Figure 2 Management role group components

The management role groups use the following components to define how RBAC assigns permissions:

  • Management role entries: Defines a cmdlet, including its parameters, which you add to a management role. For example, if you want to see which management role entries are included in the Move Mailboxes management role, you can use the Get-ManagementRoleEntry “Move Mailboxes\*” cmdlet.

  • Management role: A role is a collection of one or more management role entries. These entries define the tasks that users can perform if RBAC assigns them the role using management role assignments. It is best practice to copy existing roles using the New-ManagementRole cmdlet and modify them by removing the unneeded role entries with the Remove-ManagementRoleEntrycmdlet.

  • Management role scope: A management role scope is the scope of influence or impact that the role holder has after RBAC assigns a management role. When assigning a management role, use management scopes to target which objects that role controls. Scopes can include servers, organizational units, recipient objects, and more.

  • Management role assignment: A management role assignment assigns a management role to a role group. When you create a management role, you must assign it to a role group so that the role holders use it. Assigning a management role to a role group grants the role holders the ability to use the cmdlets that the management role defines.

  • Role holder: A role holder is a user or security group you can add to a management role group. When a user becomes a management role group member, RBAC grants it all the permissions that the management roles provide. You can either add user accounts to the group or use the Add-RoleGroupMember cmdlet.

  • Management role group: The management role group is a universal security group that contains users or groups that are role group members. Management role groups are assigned to management roles. The combination of all the roles assigned to a role group defines everything that users who are added to a role group can manage in the Exchange Server organization.

Configuring Custom Role Groups

In addition to using built-in role groups, you also can create custom role groups to delegate specific permissions within the Exchange Server organization. Use this option when your ability to limit permissions is beyond the scope of the built-in role groups.

RBAC provides complete flexibility in how you assign permissions in an Exchange Server environment. For example, consider the Fabrikam scenario, where you have regional offices that are managing their recipients and Exchange servers on their own. To develop your RBAC permission model, you need to take the following steps:

1.     Identify what roles are required by the administrators. To delegate permissions to a custom role group, you can use one or more of the default built-in management roles, or you can create a custom management role that is based on one of the built-in management roles. To view a complete list of available management roles, use the Get-ManagementRole cmdlet.

2.     Define the management scope. You should consider what servers or recipients the administrators can manage. You can create a management scope based on a server list, filter, or domain. Also, you can create a scope based on a database.

3.     Create a new management role group using the information you collected. Use the New-RoleGroup cmdlet to create the link between the role group, the management roles you want to assign to the group, and the management scope.

4.     Add members to your role group to assign permissions. This task basically adds user accounts to the role group’s universal security group that is located in the root domain’s Microsoft Exchange Security Groups OU.

Configuring direct user role assignment

The third and last option to delegate specific permissions within the Exchange Server organization are direct role assignments. This is an advanced method for assigning management roles directly to a user or universal security group without using a role group or role assignment policy. This configuration can be more complex because you have to manually remove and update the permissions if a user changes jobs or leaves the company.

Management role assignment policies

Management role assignment policies are a collection of one or more end-user management roles that are associated with user accounts. You do not configure administrative permissions with management role assignment policies. Rather, you use management role assignment policies to configure what changes users can make to their mailbox settings and to distribution groups they own. Every user with an Exchange Server mailbox is assigned, a role assignment policy. You can define the assignment policy as follows:

  • Decide which role assignment policy to assign by default.

  • Choose what to include in the default role assignment policy.

  • Override the default policy for specific mailboxes.

  • Choose not to assign role assignment policies by default.

Role Assignment Components

Role assignment policies consist of the following components, which define what users can do with their mailboxes:

  • Mailbox: Mailboxes are assigned a single role assignment policy. When a mailbox is assigned a role assignment policy, the policy is applied to the mailbox. This grants the mailbox all the permissio: ns that the management roles provide.

  • Management role assignment policyThe management role assignment policy is an object in Exchange Server. Users are associated with a role assignment policy when you create their mailboxes or change the role assignment policy on their mailboxes. The combination of all the roles included in a role assignment policy defines everything that associated users can manage on their mailboxes or distribution groups.

  • Management role assignment: Management role assignments link management roles and role assignment policies. Assigning a management role to a role assignment policy grants users the ability to use the cmdlets in the management role. When you create a role assignment, you cannot specify a scope. The scope that the assignment applies is based on the management role and is either Self or MyGAL.

  • Management role: A management role is a container for a group of management role entries. Roles define the specific tasks that users can do with their mailboxes or distribution groups.

  • Management role entry: A management role entry is a cmdlet, script, or special permission that enables users to perform a specific task. Each role entry consists of a single cmdlet and the parameters that the management role can access.

Working With Management Role Assignment Policies

Exchange includes a default role assignment policy that provides end users with the most commonly used permissions. For most organizations, you do not need to modify the configuration. However, you can change the management role assignment policy if your organization has specific requirements regarding how users can interact with their mailboxes or groups.

To view the default management role assignment policy configuration, use the Get-ManagementRoleAssignment –RoleAssignee “Default Role Assignment Policy” cmdlet. This cmdlet lists all the management roles that are assigned to the default role assignment policy. To view the details of each management role, use the Get-ManagementRole | FL cmdlet.

Working with Assignment Policies

You can modify the default role assignment configuration in the following ways:

  • Change the default permissions on the default role assignment policy by adding or removing management roles. For example, if you want to enable users to perform additional tasks on their mailboxes, you can identify the management role that grants them the necessary permissions and add the role to the Default Role Assignment Policy.

  • Define a new role assignment, and then configure that role assignment to be the default for all mailboxes. Use the Set-RoleAssignmentPolicy cmdlet to replace the built-in default role assignment policy with your own. When you do this, RBAC assigns the role assignment policy you specify to new mailboxes by default.

Note: When you create an additional role assignment policy, RBAC does not assign the new default role assignment policy automatically. The cmdlets and parameters covered by the roles included in this management policy are not implemented by RBAC until the policy is assigned to mailboxes. For example, you need to use theSet-Mailbox cmdlet to update previously created mailboxes to the new default role assignment policy.

  • Configure additional role assignment policies, and assign the policies to a mailbox manually by using the RoleAssignmentPolicy parameter on the New-Mailbox, Set-Mailbox, or Enable-Mailbox cmdlet. When you assign an explicit role assignment policy, the new policy takes effect immediately and replaces the previously assigned explicit role assignment policy. If you have many different user groups with special needs, you can create role assignment policies for each group.

Split permissions

By default, Exchange Server is configured using a shared permission model meaning that Exchange administrators can also manage Active Directory objects. However, you can separate Active Directory Domain Services administration and Exchange administration, this is called split permissions. Exchange 2013 supports two types of split permissions: RBAC split permissions and Active Directory split permissions.

RBAC split permissions

Because RBAC is based on Active Directory groups, if you have permissions to change these groups, you can grant more permissions than you might have currently in Active Directory. For example, if you add your user account to the Exchange Trusted Subsystem group, you gain access to powerful permissions over objects in the entire forest.

To prevent this from happening, Exchange Server allows administrators to separate the Exchange role groups from the security groups, such as Exchange Trusted Subsystem.

Note: Implementing a split permissions model is probably not of interest to you if your Exchange administrators are also Enterprise or Domain administrators.

Separating control over these groups is especially important when you want to make sure that Exchange administrators have only limited access to recipient objects in Active Directory, such as when they can manage recipient objects only in a specific OU in a domain. This design enables two separate sets of users—such as Active Directory administrators and Microsoft Exchange Server 2013 administrators—to manage their respective services, objects, and attributes separately. The authorization model for account creation is performed by your Active Directory administrators, not the Exchange administrators.

If you enable RBAC split permissions, Exchange Server administrators cannot use the following cmdlets:

  • New-Mailbox

  • New-RemoteMailbox

  • New-MailContact

  • New-MailUser

  • Remove-Mailbox

  • Remove-RemoteMailbox

  • Remove-MailContact

  • Remove-MailUser

Enabling RBAC split permissions does not prevent administrators from using the Active Directory Domain Services management tools if an Exchange server administrator has been assigned Active Directory Domain Services. RBAC split permissions does not remove permissions from the Exchange Trusted Subsystem group—it only removes permissions to run cmdlets from Exchange server administrators.

To configure RBAC split permissions, the following steps are necessary:

  1. Verify that Active Directory split permissions are disabled.
  2. Create a new role group for Active Directory Domain Services administrators. (This step is optional and required only if administrators grant permissions to create Active Directory Domain Services objects to the Exchange group.)
  3. Create regular and delegating role assignments for the new role group. (This step is optional and required only if administrators grant permissions to create Active Directory Domain Services objects to the Exchange group.)
  4. Remove regular and delegating management role assignments between the Mail Recipient Creation role and both the Organization Management and Recipient Management role groups.
  5. Remove the regular and delegation role assignments between the Organization Management role group and the Security Group Creation And Membership role.
Active Directory split permissions

The Active Directory split permissions model does not replace the RBAC authorization model; RBAC is still used by the Exchange management tools and will prevent Exchange administrators from creating objects such as user accounts. Active Directory administrators will retain control of the Exchange Windows Permissions group, and thus retain control of which Exchange administrators, if any, are allowed to create objects within Active Directory. For your root domain, Domain Admins and Enterprise Admins still own the forest and therefore own any object placed within the root domain and your Active Directory configuration container. For example, this model is used in Exchange organizations where the Exchange administration is not performed by the same administrators that manage Active Directory objects. It is to completely separate object creation in Active Directory and the Exchange management.

When you enable Active Directory split permissions, the following changes are made in the root domain of your forest:

  • The Microsoft Exchange Protected Groups OU are created, which includes the Exchange Windows Permissions group. Microsoft recommends moving this group out of this OU and into an OU that is controlled by the Active Directory administrators.

  • The Exchange Windows Permissions group does not include the Exchange Trusted Subsystem group.

  • Remove any nondelegating RBAC role assignments to the MailRecipientCreation and SecurityGroupCreationAndMembership roles.

You can enable or disable Active Directory split permissions as required. To enable it, run the following commands at a command prompt:

Setup /PrepareAD /ActiveDirectorySplitPermissions:true
Setup /PrepareAllDomains

Enabling Active Directory split permissions means that

  • You can no longer create or delete security principals, such as creating or deleting user accounts. But you can create a mailbox if the user account already exists from the Exchange management tools.

  • You cannot add or remove distribution group members from the Exchange Server management tools.

  • Exchange servers and the Exchange Server management tools can modify only the Exchange Server attributes of existing security principals in Active Directory Domain Services.

If you want to change back to the model used with the release version, run the Setup /PrepareAD /ActiveDirectorySplitPermissions:false command. To gain back full permissions, you need to run the following cmdlets:

New-ManagementRoleAssignment “Mail Recipient Creation_Organization Management” –Role “Mail Recipient Creation” –SecurityGroup “Organization Management”

New-ManagementRoleAssignment “Security Group Creation and Membership_Organization Management” –Role “Security Group Creation and Membership” –SecurityGroup “Organization Management”

New-ManagementRoleAssignment “Mail Recipient Creation_Recipient Management” –Role “Mail Recipient Creation” –SecurityGroup “Recipient Management”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s