Get started Bring yourself up to speed with our introductory content.

Exchange management roles limit unsolicited admin access

RBAC allows admins to perform certain tasks in Exchange, and the unscoped top-level management roles limit admins authorized to gain access to accounts and scripts.

This article covers a special kind of Role-Based Access Control (RBAC) Management Role, the unscoped top-level...

management role. As the name implies, unscoped management roles are not bound to a scope and apply at the global level.

Unscoped management roles provide restricted access to administrators or user accounts to execute specific scripts or non-Exchange cmdlets from a different PowerShell module (regular PowerShell cmdlets remain available).

To create an Unscoped management role, you need to be a member of the Unscoped Role Management Group. To assign the Administrator to the Unscoped Role Management Group, use:

New-ManagementRoleAssignment –Name 'Unscoped Role Management-Administrators' –User Administrator –Role 'Unscoped Role Management'

If you want to assign this role to a group, use SecurityGroup instead of User parameter and specify the group name.

Restart Exchange Management Shell (EMS) for the new permission to become effective, making the UnScopedTopLevel parameter available. Now, create an unscoped management role by specifying the Unscoped switch when using New-ManagementRole:

New-ManagementRole –Name 'Exchange Maintenance' -UnScopedTopLevel

The scripts you want to associate with an unscoped management role need to reside in the $exinstall\RemoteScripts folder on each relevant Exchange server. By default, this will be the location: C:\Program Files\Microsoft\Exchange Server\v15\RemoteScripts. The format for assigning a script to an Unscoped Management Role is:

Add-ManagementRoleEntry –Identity 'Role Name\Script Filename' [–Parameters <Param1>, <Param2>, ..] –Type Script –UnscopedTopLevel

To assign a non-Exchange cmdlet, replace Script Filename with the name of the cmdlet and set type to Cmdlet. Specify all parameters you want to allow to be used with the script or cmdlet.

Assume you want to assign permissions to run a script HealthCheck.ps1 using a parameter named Notify, use:

Add-ManagementRoleEntry –Identity 'Exchange Maintenance\HealthCheck.ps1' –Parameters 'Notify' –Type Script –UnscopedTopLevel

Create a management role group

In this example, I have created an Unscoped Top Level Management Role named 'Exchange Maintenance', which is allowed to run a script HealthCheck.ps1 and specify a parameter Notify. Now, I can create a role group, assign the Unscoped Management Role to this role group, and add accounts or groups that need to be able to run that script or cmdlet.

Let's assume you have a service account saExchange. Run the following cmdlets to create the Role Group and add this account (specifying BypassSecurityGroupManagerChecks as it is not configured to manage this group through the ManagedBy property):

New-RoleGroup –Name 'Run Exchange Maintenance' –Roles 'Exchange Maintenance'

Add-RoleGroupMember –Identity 'Run Exchange Maintenance' –Member saExchange -BypassSecurityGroupManagerChecks

When saExchange opens an EMS session, it will show HealthCheck.ps1 as the available non-regular PowerShell commands (Figure 1).

Irregular PowerShell commands

While saExchange has permission to run this script, it does not necessarily have permissions to run Exchange or other cmdlets. In other words, the account needs to execute every cmdlet used in the script in order to run successfully. Make sure you assign the account a proper role group, or specify individual Management Role Entries.

To be able to run a non-Exchange cmdlet from a specific module, use Add-ManagementRoleEntry. Assume you have the Quest Active Roles snap-in installed on every Exchange server, and allow running a specific cmdlet in your script. To allow saExchange to run Get-QADUser, use:

Add-ManagementRoleEntry –Identity 'Exchange Maintenance\Get-QADUser –PSSnapIn Quest.ActiveRoles.ADManagement –UnscopedTopLevel

If you change your mind, use Remove-ManagementRoleEntry to remove the script or cmdlet:

Remove-ManagementRoleEntry –Identity 'Exchange Maintenance\HealthCheck.ps1'

To remove the Unscoped Top Level Management Role, use:

Remove-ManagementRole –Identity 'Exchange Maintenance' –UnScopedTopLevel

While this may take a while to set up, Unscoped Top-Level Management Roles allow for configuring fine-grained permissions, aimed at specific tasks. Apart from Exchange permissions, you can limit the scope of an account in terms of which scripts or non-Exchange cmdlets it can run, in combination with what parameters. Depending on your requirements, this may be a welcome method to lock down the Exchange environment, limiting chances of mistakes and potential consequences.

Next Steps

RBAC permissions options in Exchange 2013

Define which commands, tasks end users can access

How does RBAC work?

Exchange 2010 role based access control basics

RBAC management in Exchange 2013

This was last published in November 2015

Dig Deeper on Microsoft Exchange Server Scripts and Programming

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

How do you use RBAC in Exchange to control permissions?
Cancel
Can you limit any PowerShell command to be run by the Organization Management Role Group?
Cancel

-ADS BY GOOGLE

SearchWindowsServer

SearchEnterpriseDesktop

SearchCloudComputing

SearchSQLServer

Close