After publishing some recent articles on RBAC, there was some feedback that a primer on RBAC would also be welcomed.  So here it is!

What is RBAC?

It is not Really Boring Access Control. 

RBAC = Role Based Access Control.  As a concept it is not new, however Exchange 2010 was the first time that it has been natively supported in Exchange.  That being said, we still had the concept of roles in Exchange 2007 and older versions. 

For example in Exchange 2003 we had these roles:

• Exchange Full Administrators
• Exchange Administrators
• Exchange View Only Administrators

In Exchange 2007 we had slightly more roles:

• Exchange Organization Administrators
• Exchange Recipient Administrators
• Exchange View-Only Administrators
• Exchange Server Administrators
• Exchange Public Folder Administrators (after SP1)

As you can see the concept or roles is not new to Exchange, but why this RBAC thing? What’s that all about?

What’s In It For Me?

RBAC has many advantages compared to the previous administration model.  RBAC allows for:

• Flexible role implementation – The roles in Exchange 2003/2007 were fixed.  No modifications could be done to them at all.
• Simplified access control – Previously an Exchange administrator’s access level to groups & users was controlled by the access control entries (ACEs) on the actual object in question.  There is a delegation of control wizard, but no un-delegation of control wizard.  As a result ACL-Spray * would accumulate.  ACLs would be added but never removed as understanding the impact of removing ACLs across various applications was very complicated.  Also changing inheritance to OUs could drastically alter the effective permissions. This is not needed with RBAC.
• Task focussed approach – Previously the administrator had to work out what ACLs had to be set, and to what properties.  This meant the focus was on the permissions on the object.  With RBAC we now focus on the business task that we need to achieved and not the underlying AD property and permissions.
• Simplified auditing – Auditing is now controlled natively within Exchange for both mailbox and administrator activities.  Administrator Audit logging is enabled by default.   Mailbox audit logging is not enabled by default.
• Granular permission assignment – RBAC allows for control right down to the individual parameters on cmdlets.  Additionally we can specify a RBAC assignment that will allow someone to be in the Organizational Administrators group, but not allow them to add anyone else to the group.  Try doing that in Exchange 2003!
• Consistent permission model – RBAC is used to control access to both administrators and users.  It applies consistently across all mechanisms of accessing Exchange be it Outlook, PowerShell, OWA or ECP. 

What To Get Used To

All Access Is Controlled Via RBAC

Access to Exchange 2010/2013 is controlled via RBAC.  RBAC determines who can do what to a given object.  This applies to both administrators and end users.  RBAC will perform the action requested by the user and this will be in the security context of the Exchange Trusted Subsystem  (ETS) universal security group.  This is a change from previous versions where the credentials of the requesting users were used to access the object and make the necessary changes.  As a result previous auditing methodologies need to change, so that we now make use of the Exchange auditing capabilities.   ETS is a highly privileged group which contains read and write permissions to all Exchange objects.  Nothing else should be added to this group.

RBAC Controls Administrators & Users

RBAC is assigned to administrators to let them perform the necessary tasks on servers, connectors and mailboxes.  This is in the form of a Role Assignment.  RBAC to end users is delivered as a Role Assignment Policy.  They are very similar but are tailored to their respective purpose. 

Organisation Administrators Now Demi-Deities

In previous versions when a person was added to the Exchange Organization Administrators or Exchange Full Administrators roles they had every capability in Exchange.  This is not the case any more, so become accustomed to not having access to all keys of the kingdom.  Now, all the keys can be granted – it’s just that you do not have them by default.  Examples of permissions and capabilities that an Org Admin does not have out of the box in Exchange 2010 include:

• Mailbox import export
• Create un-scoped top level management roles
• Application impersonation

What Where & Who

There are three main points to consider when planning out RBAC -- Where, What and Who. 

1. Where can someone apply the permissions granted
2. What are the permissions
3. Who can wield them

OK – there is also the glue (role assignment that binds them), but let’s not mess up a nice list!

This is covered in detail by the RBAC Triangle Of Power.

Management Role This & Management Role That

Cutting through the terminology can be beneficial for reviewing RBAC.  One frequently heard comment is that the word “role” is overused.   When you see the main cmdlets laid out, it’s not bad!  These are the core components of RBAC:   

1. ManagementScope – Scope defines where the Role can be used.
2. ManagementRole – Role is a collection of Role Entries.  This is what you can do.
3. ManagementRoleEntry – the actual cmdlets and cmdlet parameters that get grouped into a Role.
4. RoleGroup  - This states who is able to leverage the cmdlets granted in the role. 
5. ManagementRoleAssignment – The glue which holds the triangle together. 

I’ll let you browse through the above content at your pleasure!

Role – The What

The end user RBAC roles contain cmdlets related to managing a user’s own mailbox and is scoped as such.  Administrator RBAC roles contain the necessary cmdlets to manage the messaging infrastructure. Examples of Management Roles are show below:

They are represented in Active Directory as universal security groups, stored in the Microsoft Exchange Security Groups OU:

The  Management Role contains Management Role Entries, which are the individual cmdlets and their parameters that actually let you do tasks.   To see the actual Management Role Entries use the Get-ManagementRoleEntry cmdlet.  Note that the Management Role Entries are stored within the Management Role, and this is why the syntax looks like  Get-ManagementRoleEntry  “ManagementRoleName\*”

Other examples to retrieve Management Role Entries could be:

• Get-ManagementRoleEntry “Mail Recipients\Set-Mailbox*”
• Get-ManagementRoleEntry “Mail Recipients\*”
• Get-ManagementRoleEntry “Mail Recipients\Set-*”
• Get-ManagementRoleEntry “Mail Recipients\Get-*”

It is fairly simple to understand how the built-in roles map to administrator or end user RBAC as the built in end user roles are prefixed with “My”.  Custom roles are not obliged to follow this nomenclature (though it does make life easier if they do). To be sure of a Role type examine its IsEndUserRole property.  The first role shown below is for end user RBAC, and the second is for administrators or specialist roles.

Role Group – The Who

You will encounter two types of Role Groups on your travels.  When Exchange 2010 or 2013 is installed into an AD forest all the necessary installation steps are executed, one of which is to install a base RBAC platform.  If you have a multi forest (Exchange resource forest) environment, since the installation is executed in one forest then there is no knowledge of RBAC in the other forest.  If you want to administer Exchange as a user from the account forest then you will need to tell Exchange in the resource forest who gets what administrative permissions in the user forest.  In other words you need to roll your own RBAC for the user forest, this is a task that you need to perform  as it is not automatically done. 

A one way trust is the minimum requirement so the relevant AD objects are visible, and the RBAC roles can be defined.    When assigning the roles, RBAC points to a Universal security group in the other forest and a Linked Role Group is created. 

You will see this if you look for the RoleGroupType.  Standard denotes a regular RBAC RoleGroup in the same forest as Exchange.  Linked indicates that this is a linked role group to a remote forest. 

Get-RoleGroup "Organization Management" | select Name, RoleGroupType | Format-Table -AutoSize

Scope – The Where

As the name implies, Management Scope stipulates where a particular set of permissions will apply.  This could be scoped to a:

• Server
• Exchange database (Exchange 2010 SP1 and newer feature)
• OU
• AD Group

To perform advanced RBAC tasks you will certainly want to get familiar with this concept of management scopes since scopes allow you to control where a particular permission will apply.  An example of a couple of scopes in one of my labs:

To create the Executive management scope we could run:

New-ManagementScope -name "Executives" -RecipientRestrictionFilter {memberofgroup -eq "cn=Execs,ou=VIP,dc=contoso,dc=com"}

On a related note, note that in PowerShell the equals character “ =  “ is not used to evaluate if values match.  The equals operator is   text based and is “ –eq “  with the not equals operator being “ –ne “. 

There is a handy table on TechNet or you can open PowerShell and review the output of:

Get-Help about_Comparison_Operators | More

Note that there are different aspects to scope, and the reason that I want to mention this is around scoping where users can read.  While it is possible to limit the write aspects for both configuration and user scopes, read is at the organisation level. 

Bringing RBAC Together

Some folks like the above triangle of power to represent RBAC, but I personally prefer this  graphic to really illustrate the relationships of the RBAC building blocks. 

It pulls together all the concepts from Management Role Entries, Role Assignments and Role Assignment Policies. 

Please see the previous posts to see how to create a custom RBAC role and then assign it to a group: 

Creating RBAC Role To Delegate Contact Management   - This one shows an example of using the “Mail Recipient Creation” role to create a customised role. 

Allow Users To Manage Distribution Groups Without Creating New Ones  - This one shows an example of customising the RBAC role assigned to an end user, and is something that RBC has already implemented in production.

How To Add Or Remove Cmdlet Parameter From RBAC Management Role   - illustrates the amazing precision that is possible within RBAC

In case you were wondering about the Wipe Only ActiveSync Role that is shown in a couple of examples, this is discussed in RBAC: Walkthrough of creating a role that can wipe ActiveSync Devices. 

Cheers,

Rhoderick

* – Should trademark that!