Thursday, January 20, 2011

RBAC Explained

RBAC is a newer technology with Exchange 2010 that seems to have a lot of IT professionals scratching their heads; especially when it comes to the terminology. First off, what is RBAC?

Role Based Access Control (RBAC) is a new permission model introduced in Exchange 2010. In the past, manually changing ACLs could cause collateral damage, and often times had longer reaching implications. For this reason, Microsoft opted to go with a model where administrators could easily allocate permissions via default or custom Role Groups. Now let’s try to decipher what this means in a way that is easier to understand.

Role Group: A Role Group is essentially a special Universal Security Group (USG) that has members and Roles assigned to it. You can actually see these in ADUC. These Role Groups are essentially used like any other kind of group; they are for standard permission allocation to a subset of users.

Predefined Role Group Example:

Discovery Management Role – Grants the ability to perform multi-mailbox search, and compliance exports. Encompasses the Legal Hold and Mailbox Search Roles.

Assigning a user to a Role Group:

Add-RoleGroupMember -Identity "Discovery Management" -Member

Role: A Role is basically a predefined list of Role Entities packaged up, and ready to assign to a Role Group (or directly to a user, though it is generally better to create a Custom Role Group if one does not currently exist that meets the need). By default, Exchange 2010 has 65 built-in roles.

Administrators can create child roles as well. These roles are limited by their parents by what rights they can have. Child roles cannot have more roles than the parent.

Predefined Role Example:

Mailbox Search – Contains the following permissions:

Mailbox Search

Get-ADServerSettings

Mailbox Search

Get-DomainController

Mailbox Search

Get-Mailbox

Mailbox Search

Get-MailboxExportRequest

Mailbox Search

Get-MailboxExportRequestStatistics

Mailbox Search

Get-MailboxSearch

Mailbox Search

Get-Recipient

Mailbox Search

New-MailboxExportRequest

Mailbox Search

New-MailboxSearch

Mailbox Search

Remove-MailboxExportRequest

Mailbox Search

Remove-MailboxSearch

Mailbox Search

Search-Mailbox

Mailbox Search

Set-ADServerSettings

Mailbox Search

Set-MailboxExportRequest

Mailbox Search

Set-MailboxSearch

Mailbox Search

Start-MailboxSearch

Mailbox Search

Stop-MailboxSearch

Mailbox Search

Suspend-MailboxExportRequest

Mailbox Search

Write-AdminAuditLog

To output the list of Role Entries assigned to the “Mailbox Search” role, you would run:

Get-ManagementRoleEntry "Mailbox Search\*”









Assigning a Role to a Role Group:

New-ManagementRoleAssignment -SecurityGroup -Role

Role Scope: A Role Scope is essentially the scope of the rights provided to the user receiving the permissions. All Roles have a default Role Scope, so if you don’t set one, then it will be provided with the defaults. You can also create custom scopes to quickly apply to Roles when necessary.

Example of a scope:

New-ManagementScope -name "Tier 3 Technicians" -RecipientRestrictionFilter {memberofgroup -eq "cn=Executives,ou=Exec,dc=domain,dc=com"}

Role Entries: These are the tools that Roles have access to in their toolbox, limited of course by scope.

Example: Get-User and other cmdlets

Role Assignment: This is the tricky one. A Role Assignment is essentially an object that links together a Role, a Role Group, and a Role Scope into one package. Anytime you apply a Role with a Scope to a Role Group (yes even if they are defaults), you are creating a Role Assignment.

Given how many different combinations you can have, Exchange comes with around 160 Role Assignments by default according to the Exchange team!

Role Delegates: A delegate is someone who can assign the role to users/groups/etc, but they don't necessarily have the role themselves. The most common application of this is that the Organization Management role tends to have delegate rights to most roles, which means they can assign roles to users or groups, while not having the permission themselves. The auditing for this comes in at the Admin Audit Log level.

Example:

The Discovery Management role can be assigned by the Organization Management role, but members of only the Organization Management role do not have the discovery functionality by default that those belonging to the Discovery Management role have.

Conclusion

The bottom line is that people learn in different ways. If this article didn’t help you, then the EHLO blog’s explanation very good as well, but with a slightly different style that may compliment your learning style.

One thing they mention is labeling them in a way that is familiar to us:

Who: Role Group

What: Role

Where: Scope

Glue (holds it all together) : Role Assignment

For the triangle of power explanation, visit the EHLO blog:

http://msexchangeteam.com/archive/2009/11/16/453222.aspx

1 comment:

Tech Blog said...

Thanks for explaination