6. Unscoped roles
Unscoped management roles are interesting because they enable
you to create tailored roles for administrative purposes. This area
might receive little attention as deployment teams handle the initial
implementation of RBAC within a company. As administrators become more
comfortable with RBAC over time, the notion of being able to create and
assign custom-built roles will become more interesting.
The
basic idea behind a custom unscoped role is as a mechanism that enables
administrators to grant access to non-Exchange cmdlets or Windows
PowerShell scripts to management role groups, individual users, or
USGs. For example, assume that you have written some PowerShell scripts
that can extract data for reporting purposes from Exchange, and you
want to assign access to those scripts to people who work on the help
desk so that they can generate the reports. Granting the ability to
perform specific work without the need to grant access to a particular
role or cmdlet is another reason you might create a custom role. For
example, you might want to allow the help desk to create mailboxes but
only in a specific OU, following a structured naming guideline, and
populating mailbox properties in a certain manner. You could do this by
writing a script that encodes all the business logic necessary to
create the mailboxes and granting access to the script. The help desk
users who receive the custom role can run the script, but they can’t
run the New-Mailbox cmdlet in any other manner.
To begin, you
have to delegate the ability to create unscoped roles to an account.
This ability is not granted by default, even to accounts that hold the
Organization Management role. However, accounts that hold the
Organization Management role can delegate the Unscoped Role Management
role to themselves or other accounts with the
New-ManagementRoleAssignment cmdlet. This command assigns the role to a
USG called Exchange Admins, which has to exist before you assign a role
to it:
New-ManagementRoleAssignment –Role 'Unscoped Role Management' –SecurityGroup 'Exchange Admins'
If
the account you use is a member of the Exchange Admins group, you can
now create an unscoped top-level management role. Remember that you
have to reinitialize a new EMS session after your account is assigned
the Unscoped Role Management role to enable RBAC to make the
UnscopedTopLevel parameter available for the New-ManagementRole cmdlet.
If you don’t do this, EMS will report an error when you run the
New-ManagementRole cmdlet and pass it the UnscopedTopLevel parameter.
New-ManagementRole –Name 'Exchange Admin Scripts' –UnscopedTopLevel
Name RoleType
---- --------
Exchange Admin Scripts UnScoped
The
management role is empty and now needs to be populated with the scripts
you want to make available to the users to whom you eventually assign
the role. The scripts need to be copied to the default remote script
directory on every server (\Program Files\Microsoft\Exchange
Server\V15\RemoteScripts\). Thereafter, you can add a role entry for
each script. For example:
Add-ManagementRoleEntry 'Exchange Admin Scripts\DBReportMail.PS1' –Type Script –UnscopedTopLevel
This
command associates the DBReportMail.PS1 script with the custom role and
allows the holders of the role to run the script. You can assign the
custom role to the users who need it, as usual:
New-ManagementRoleAssignment –Role 'Exchange Admin Scripts' –User 'Help Desk'
After the assignment is made, the users can run the script the next time they log on to EMS.
7. Which role groups do I belong to?
A simple question administrators often ask is to which role
groups have they—or someone else—been assigned. Assignment information
is held in the membership of the different role groups, so that’s what
you have to investigate to determine which roles a user possesses.
In
this example, you run the Get-RoleGroup cmdlet and pipe its output to
the Where-Object cmdlet to look for any entry in the membership of a
role group that has a partial match with a user called Redmond:
Get-RoleGroup | Where-Object {$_.Members –Like '*Redmond*'} | Format-List Name, MembersName : Organization Management
Members : {contoso.com/Exchange Users/Redmond, Eoin P, contoso.com/Exchange Users/Redmond,
Tony, contoso.com/Users/Administrator}
Name : Discovery Management
Members : {contoso.com/Exchange Users/Redmond, Tony, contoso.com/Users/Administrator}
The
output shows that a partial match for Redmond is discovered in the
membership of the Organization Management and Discovery Management role
groups. You can then scan the membership information that’s returned to
find the user in whom you are interested.
Of course, if you just
want to check the membership of a role group to see the list of users,
the Get-ManagementRoleAssignment cmdlet is the correct tool. In this
example, you retrieve the list of users who have an assignment for the
Mailbox Import Export role group:
Get-ManagementRoleAssignment –Role 'Mailbox Import Export'
| Format-Table RoleAssigneeName, RoleAssignmentDelegationType, RoleAssigneeType
RoleAssigneeName RoleAssignmentDelegationType RoleAssigneeType
---------------- ---------------------------- ----------------
Organization Management DelegatingOrgWide RoleGroup
Administrator Regular User
You can see two types of assignments reported here:
Members
of the Organization Management role group are allowed to delegate
access to the Mailbox Import Export role group, but they are not
granted the permissions assigned to a regular member; members of the
Organization Management role group can assign the role group to others,
but they are not allowed access to the functions made available to role
group members.
The Administrator
user account is a regular member. This is the result of a specific
assignment. In fact, because the Administrator account is usually a
member of the Organization Management role group, administrators can
assign themselves membership to Mailbox Import Export.
The
Get-ManagementRoleAssignment cmdlet is useful in terms of discovering
who can do what to an object. For example, you can use it to determine
who can write to different objects:
A user mailbox:
Get-ManagementRoleAssignment –WritableRecipient "Akers, Kim" –GetEffectiveUsers
A server object:
Get-ManagementRoleAssignment –WritableServer 'ExServer2' -GetEffectiveUsers
A mailbox database:
Get-ManagementRoleAssignment –WritableDatabase 'DB1'
If
you use the GetEffectiveUsers parameter, all the users who can modify
the object indirectly through membership of role groups and USGs are
returned. If you omit this parameter, only the role groups, users, and
USGs that are directly assigned the role are returned.
