Blame it to RBAC!

                           

                             Blame it to RBAC  !

If you are working as an Administrator in an Exchange 2010 based environment and on one fine day you realized you are not able to execute certain command in your environment even after verifying syntax multiple times over Google...Blame it to RBAC guys !!!!

Introduction of DAG is the most technologically interesting  advancement in Microsoft Exchange Server 2010, the implementation of new permission model based on the concept of role based access control exerts the most pervasive influence on the most parts of product. RBAC is therefore the most important element for administrators to master !

Taken as a whole, RBAC is an approach to restrict access to system and data based on the need of administrators and users to do their job (that's why at one fine day, curious administrator like you all fell short of Cmdlet!)

RBAC is not new concept and it has been implemented in other operating systems and applications including HP-UX, Linux, Oracle, SAP R/3 etc.

Previous versions of Exchange uses Windows ACL to grant permissions to users and administrators. ACLs are effective way to manage permissions in environment which is well structured and does not tend to change much over the time. Exchange is little more dynamic and snaps thousands of hundreds of objects in its largest deployment. Tracking and updating ACL across such a dynamic environment for so many objects is real challenge and real world experience revealed that ACLs are often updated incorrectly, can be difficult to debug when things go wrong. Another issue is that the conventional model of creating, updating and setting permissions on objects often does not translate well into a task driven environment that exists within application such as Exchange where permissions have to support scenarios such as permitting help desk personnel to reset a user's password without being able to effect any other setting of the user's account.

The granularity available in RBAC  addresses this need !

It is impossible to understate influence of RBAC throughout Exchange 2010. It would require 300-page book to cover every aspect of RBAC in depth.

RBAC Basics :

To understand how RBAC defines and distributes roles, you will need to become familiar with a few new terms:

Management Role A management role, also referred to as a role, represents a grouping of

Exchange cmdlets that can be run by people who are assigned the role. These cmdlets are also referred to as management role entries.

Management Role Entry A management role entry, also known as a role entry, is the term used to refer to each Exchange cmdlet that is defined on a role. There is also a special type of role that allows your role entries to be able to execute PowerShell scripts or non-Exchange cmdlets.

Scope The scope defines the boundary of objects that a role can be applied to. By default, the scope of impact on roles is not very restrictive. However, you can create custom scopes that make the scope of impact for a role more restrictive, such as restricting a role to only an organization

Role Group A role group is a security group in Active Directory that defines who gets which

roles applied to them. Along with the specific roles, a role group can also define the scope to

which those roles are appliedal unit (OU) of recipients.

Role Assignment Policy A role assignment policy is similar to a role group, because it is a

representation of a collection of management roles. However, the role assignment policy is

used for distributing roles to end users, whereas the role group is used for assigning roles to

Exchange administrators.

Management Role Assignment Management role assignments, also known as role assignments, pulls everything together. RBAC defines who (the role group or user account)

has what permissions (the roles) and where (the scope) those permissions are in effect. The role assignment pulls this together by assigning a management role to a role group, a user account, or a role assignment policy. Each time a role is assigned to a unique role group, user account, or role assignment policy, a different role assignment is created. Each role assignment assigns only one role to one role group, user account, or role assignment policy.

Managing RBAC

You can manage RBAC either by using ECP or by using EMS. There is not really much you can do with RBAC using ECP and very soon you will turn to EMS to do wonders!

Below is the list of commands which can be used to manage RBAC through EMS

Component                      Cmdlet                                        Description

Management role

New-ManagementRole                  Creates a new role

Get-ManagementRole                    Gets the list of roles or the properties of a specific role

Remove-ManagementRole             Deletes a role

Management

role entry

Add-ManagementRoleEntry            Adds a role entry to an existing role

Get-ManagementRoleEntry             Retrieves the list of role entries on a role

Remove-ManagementRoleEntry      Removes a role entry from a role

Set-ManagementRoleEntry             Sets the parameters on an already defined role entry

Role group

Get-RoleGroup                             Gets the list of role groups or the

properties of a specific role group

New-RoleGroup                            Creates a new role group

Remove-RoleGroup                      Deletes a role group

Set-RoleGroup                             Changes the properties of the role group

Add-RoleGroupMember                 Adds an administrator to a role group

Get-RoleGroupMember                  Lists the members of a role group

Remove-RoleGroupMember            Removes an administrator from

a role group

Update-RoleGroupMember             Modifies the role group membership in bulk

Role assignment

policy

Get-RoleAssignmentPolicy              Retrieves the list of role assignment policies or retrieves the details of a specific role assignment policy

New-RoleAssignmentPolicy             Creates a new role assignment policy

Remove-RoleAssignmentPolicy        Deletes a role assignment policy

Set-RoleAssignmentPolicy              Configures the properties of a role

assignment policy, including whether the

policy is the default policy for the domain

Management role

assignment

Get-ManagementRoleAssignment    Retrieves the list of role assignments or the details of a specified role assignment

New-ManagementRoleAssignment   Creates a new role assignment

                          Remove-ManagementRoleAssignment           Deletes a role assignment

Set-ManagementRoleAssignment     Configures the properties of the role assignment, including the scope that the assignment uses.

The RBAC data is stored in Active Directory. Each management role has an associated object in Active Directory of the object type msExchRole.

The role objects are stored in the Configuration Naming Context inside the following container:  Services\Microsoft Exchange\Org Name\RBAC\Roles.

What could be one the trickest task for administrator is to choose what management role to assign to particular user based on the requirement of job role! It is always recommended to use built-in RBAC roles to fulfill your needs instead of creating any custom RBAC role group. Exchange has taken care of this and has many built-in RBAC role groups which are designed considering various needs of any organization. Let's look into it by an example.

Suppose you have an user Bhalu who needs to be able to import mailbox data and you don't know if any such built-in RBAC role is there in Exchange or not.

You can use wild card to search the required management role group as shown below

get-managementroleentry "*\import mailbox"  and you will be get an output as below

Name                               Role                                Parameters

----                                  ----                                  ----------

Import-Mailbox        Mailbox Import Export        {AllContentKeywords...

That's it ! now you know the name of ManagementRole which can fulfill Bhalu's need. Now is time for you to check what RoleEntries this role has and you can do it using below mentioned Cmdlet

get-ManagementRoleEntry "Mailbox Import Export\*" and the output looks like below

Name                               Role                                 Parameters

----                                  ----                                  ----------

Import-Mailbox        Mailbox Import Export                  {AllContentKeywords...

Get-Mailbox             Mailbox Import Export                  {Anr, Credential, D...

Export-Mailbox         Mailbox Import Export                  {AllContentKeywords...

As simple as that !

Unscoped Roles ( The exception ) :

Unscoped management roles are interesting because they allow you to create tailored roles for administrative purposes. This type of role does not have a parent ! and hence they are called as unscoped top level roles!

The basic idea behind a custom unscoped role is that it is a mechanism that allows administrators to grant access  to non-Exchange Cmdlets or Windows PowerShell scripts to management role groups, individual users or USGs. Granting access to the ability to perform  specific work without the need to grant access to particular role group or Cmdlet is another reason why you might create custom unscoped role.

For Example, You might want a helpdesk to be able to create mailboxes in some OU following a structured naming convention and populating mailbox properties in certain manner. You can do this by writing a script that encodes all the required business logic for this and grant access to helpdesk group to run the script. Now the helpdesk group members who receive this unscoped role can run the script however can not use 'New-mailbox' Cmdlet in any other way!

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 Organization Management role. Which means, by default, no one has access/permissions to create these role groups !!!

Special Roles

The list of roles included in the Organization Management role group includes the following five special roles that have to be delegated before they can be used :

       ApplicationImpersonation: This is a special purpose role intended primarily for use by Service Accounts that need to take on the persona of an user to accomplish a task.

       Mailbox Import Export:  This role allows user to import or export data into or from a mailbox.

       Mailbox Search: This role allows an user to search mailbox contents. The role is assigned to the 'Discovery Management ' role group. However the group has no default members and needs to be populated before searches can be performed.

       Support Diagnostics: This role allows access to diagnostics Cmdlets such as 'Test-ReplicationHealth' that are intended for use by Microsoft or other support personnel to retrieve diagnostic information from  an Exchange server or organization. This role is not assigned to any user by default.

       Unscoped Role Management: This role permits unscoped roles to be created and managed. Unscoped roles are used to authorize access to custom scripts and Cmdlets. This role is not assigned to any user by default but it can be delegated by holders of the Organization Management role. 

I hope, this will give fairly basic idea about what RBAC is and how it works!