RO Exchange blogging @ EHL(R)O

RO Exchange engineers share news or just interesting solutions with you

How to: RBAC

How to: RBAC

  • Comments 1
  • Likes

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: http://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!

 

Actions on the DBs included in the scope

Actions on the DBs not included in the scope

 Actions

administrator

VIP_Admin

administrator

VIP_Admin

mount/dismount/remove DB

NO

YES

YES

YES

Create recipients

NO

NO

YES

YES

Remove Recipients

YES

YES

YES

YES

move recipients from normal DB into special DB

NO

NO

 

move recipients from special DB into normal DB

YES

YES

 

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

 

 

Actions on RBAC-DB (database included in the scope)

Actions on DB (database not included in the scope)

 Actions

administrator

VIP_Admin

administrator

VIP_Admin

Create recipients

NO

YES

YES

YES

Remove Recipients

YES

YES

YES

YES

 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:

 

Actions on RBAC-DB (database included in the scope)

Actions on DB (database not included in the scope)

 Actions

administrator

VIP_Admin

administrator

VIP_Admin

Suspend DB Copies

NO

YES

YES

YES

Resume DB Copies

NO

YES

YES

YES

Activate DB Copies

NO

YES

YES

YES

Remove DB Copies

NO

YES

YES

YES

Move active Mailbox DB

NO

YES

YES

YES

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

Test results so far:

 

Actions on RBAC-DB (database included in the scope)

Actions on DB (database not included in the scope)

 Actions

administrator

VIP_Admin

administrator

VIP_Admin

move recipients from normal DB into special DB

NO

NO

 

move recipients from special DB into normal DB

YES

YES

 


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:

DBs included in the scope:

DBs not included in the scope:

 

RBAC_DB01

RBAC_DB02

RBAC_DB03

 

Mailbox Database 0074431211

Mailbox Database 1739103774

Mailbox Database 1239617449

 

 

Actions on RBAC-DB (database included in the scope)

Actions on DB (database not included in the scope)

 Actions

administrator

VIP_Admin

administrator

VIP_Admin

mount/dismount/remove DB

NO

YES

YES

YES

Create mailboxes

NO

YES

YES

YES

move recipients from and to the DB

NO

YES

YES

YES

Create/mount/dismount/remove DB

NO

YES

YES

YES

Create/delete/disable/enable/move recipients from and to the DB

NO

YES

NO

YES

Suspend/Resume/Activate/Remove DB copies

NO

YES

YES

YES

Move Active Mailbox DB

NO

YES

YES

YES

Create a new PF DB

NO

YES

YES

YES

Create new public folders in an existing PF DB

YES

YES

YES

YES

Replicate PF DBs

YES

YES

YES

YES

Modify/remove/mail enable/move/replicate existing public folders in PMC

YES

YES

YES

YES

Enable online archive for users

NO

YES

YES

YES

Modify Send As/Full Access permissions for users

NO

YES

YES

YES

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.

Comments
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment