How to: RBAC

The topic of this blog is to achieve a RBAC-based solution through which we can limit, or split the access administrators have on a set of databases.

In laymen terms we will have two groups of administrators:

1) The first group is able to access any database and perform actions on it (we will call this group the “special administrator”)

2) The second group has absolutely no access on what we will call our “special database” but can perform actions on regular databases, he’s the normal administrator.

For this scenario, we have defined two databases, DB being a regular database and RBAC-DB being the “special database” that should only be accessed by the “special” administrator.

To understand the topology a little better:

Our “special administrator” is called Admin, and has all the necessary administrator permissions:

We start with the basic scope on the database level, an exclusive scope as opposed to a regular scope, because we want Admin to have access to RBAC-DB (and all other DBs) and Administrator to have access to all DBs but not RBAC-DB. For this we use the below cmdlet:

New-managementscope –Name “RBAC-DB” –DatabaseList: RBAC-DB -Exclusive

You can see that the ScopeRestrictionType is set to DatabaseScope, as I have named these databases with the parameter –DatabaseList. However the same should be achievable also on Server level, in which you just use the parameter –ServerList.

As soon as the scope has been defined, we need to introduce the Role Assignments, which basically tie the Scope to the Role Entry and to the Person being assigned the scope (can be a Role Group, Security Group or a single User), as observed in the below picture:

In order to do this you need to think about what your administrator is allowed to do. If you want a better overview of what he “can” do, just run the bellow cmdlets:

Get-ManagementRoleAssignment |fl *Role* or use any other filter to get the necessary information.

The list can be quite long, as we have a substantial number of Role Assignments created by default in Exchange 2010, but you can also have a quick look at the TechNet article describing Management roles assigned to this role group:

Organization Management: https://technet.microsoft.com/en-us/library/dd335087(v=exchg.150).aspx

What we want to see is that when the normal administrator tries to access the “special DB” in any way, he gets the bellow error message, as opposed to our “special admin” being able to complete any actions he wants:

We want our administrator to have all the necessary permissions a normal administrator has, so we will use the bellow Management Role Assignments:

New-ManagementRoleAssignment –Name “Config-Databases” –Role Databases –SecurityGroup Admins –ExclusiveConfigWriteScope RBAC-DB

Test results so far:

Note: PowerShell and the Exchange Management Console need to be restarted for the changes to be applied!

We are not satisfied with these results yet, the special administrator’s actions should be all green on the special DB.

Hence we are adding a second Role Assignment, as the error messages we are getting show us that we don’t have the necessary access rights yet:

For example, the below management role assignment allowed my special administrator to create mailboxes on the special DB without getting the error message.

New-ManagementRoleAssignment –Name “VIP Recipient Creation” –Role “Mail Recipient Creation” –SecurityGroup Admins –ExclusiveConfigWriteScope RBAC-DB

For a quick reference of what a RoleEntry exactly contains, you can run the cmdlet “Get-ManagementRoleEntry “Mail Recipients\*”, for example.

As an Exchange Administrator, I want to take advantage of what a DAG has to offer, so I need to make sure that I will still be able to run the DAG cmdlets:

This RoleAssignment allows us to:

New-ManagementRoleAssignment –Name Moves –Role “Move Mailboxes” –SecurityGroup Admins –ExclusiveConfigWriteScope RBAC-DB

Test results so far:

Upon doing another move test, the results remained the same. The reason for this escaped me until I realized that the move action is done on a recipient level.

At this point I realized we need to introduce a second Management Scope, to be able to include a set of cmdlets found only under Recipient Scopes (we noticed that we cannot do mailbox moves or mailbox imports and exports just with the above configuration).

Basically the cmdlets in the roles "Move Mailboxes" and "Mailbox Import Export" only work at a recipient level, which is why we need to add a Recipient Scope to our Database Scope.

New-ManagementScope -Name “VIP_Scope” -RecipientRestrictionFilter { MemberOfGroup -eq ‘Thresh.com/Users/VIP’ } –Exclusive

For this new scope we add the three Role Assignments, to be able to complete our necessary set of actions, as follows:

New-ManagementRoleAssignment -Name “Recipient Creation” -Role “Mail Recipient Creation” –SecurityGroup “Admins” –ExclusiveRecipientWriteScope “VIP_Scope”

New-ManagementRoleAssignment -Name “VIP_Move_Mailboxes” -Role “Move Mailboxes” –SecurityGroup “Admins” –ExclusiveRecipientWriteScope “VIP_Scope”

New-ManagementRoleAssignment -Name “VIP_ Import_Export” -Role “Mailbox Import Export” –SecurityGroup “Admins” –ExclusiveRecipientWriteScope “VIP_Scope”

Upon further testing, the results are really good:

To sum things up, what makes the difference:

1 Scope on DB level set on RestrictiveRecipientConfigScope +ManagementRoleAssigments:

New-ManagementRoleAssignment –Name “Config-Databases” –Role Databases –SecurityGroup Admins –ExclusiveConfigWriteScope RBAC-DB

New-ManagementRoleAssignment –Name “VIP Recipient Creation” –Role “Mail Recipient Creation” –SecurityGroup Admins –ExclusiveConfigWriteScope RBAC-DB

New-ManagementRoleAssignment –Name Moves –Role “Move Mailboxes” –SecurityGroup Admins –ExclusiveConfigWriteScope RBAC-DB

1 Scope on Recipient level set on RestrictiveRecipientWriteScope + ManagementRoleAssigments:

New-ManagementRoleAssignment -Name “Recipient Creation” -Role “Mail Recipient Creation” –SecurityGroup “Admins” –ExclusiveRecipientWriteScope “VIP_Scope”

New-ManagementRoleAssignment -Name “VIP_Move_Mailboxes” -Role “Move Mailboxes” –SecurityGroup “Admins” –ExclusiveRecipientWriteScope “VIP_Scope”

New-ManagementRoleAssignment -Name “VIP_ Import_Export” -Role “Mailbox Import Export” –SecurityGroup “Admins” –ExclusiveRecipientWriteScope “VIP_Scope”

+ You need to consider what necessary Management Scope Assignments need to be added for further functionalities to work. I recommend testing the environment before deployment as it's quite a tricky configuration.