Exchange Server 2010 SP1 Hosting Deployment - RBAC simplified #1 - Introduction

  • Article

Introduction

One of the biggest changes from Exchange Server 2007 to Exchange Server 2010 is Role Based Access Control or in short, RBAC. RBAC changes a lot of things, some said it has simplified management, some said it has added tons of flexibilities but some said it has added tons of complexities particularly for smaller companies and there are even some who said the concept is too difficult to grasp. In my own personal view, RBAC is all of those.

As one of the V-team members who worked on the Exchange Server 2007 to Exchange Server 2010 readiness program for the America's Messaging Premier Field Engineers and I can tell you that the RBAC took a big chunk of those readiness time, that's how big this topic is. The good news is that RBAC has been around for a while now because Exchange Server 2010 has been out for a while. Of course in the Hosting world, we are only starting to get into it as Hosting Deployment is just being introduced in Exchange Server 2010 SP1.

RBAC is too big of a topic to cover here in blog and I don't attempt to go too deep into this as there are better blogs and materials you can get to understand this. What I will do, however is to briefly go over RBAC from hosting perspective such as what kind of management roles that will be created when you create a tenant organization and how do we limit the access and etc. Understanding RBAC in Hosting is rather essential, IMHO. You will see it later that you may need to understand it so that you can better understand the service plan, the mail plan, the delegated partner model and etc.

Now, I can't just jump into it without at least attempting to give a brief overview what RBAC is. So, I am going walk through it from a very high level and then I will jump right into the RBAC in the hosting deployment in the next post. You folks can absolutely skip this if you already know RBAC.

The concept of roles aren't something new in Exchange. Back in the days of Exchange Server 2003, if you remember, we also have a few Exchange Roles like Exchange Full Administrator and Exchange View Only Administrator and etc. In Exchange Server 2007, we have it too like Exchange Recipient Administrators, Exchange Organization Administrators and a few more roles to provide more granular management. Each of the roles usually has a corresponding security groups.

While these are all good, they do not always play well with all the companies especially those who deploys split permissions model. Obviously, they won't play well with some scenarios too, Hosting is one of them. If you folks remember, in order to perform hosting deployment in HMC, we have to modify quite a few areas in Active Directory to provide appropriate segregation and also to create tenant administrators and etc. It is rather complicated. HMC was developed as solution to do a lot of those stuff in the background.

Fast forward to today, Exchange Server 2010 introduces the concept of RBAC. Instead of using security group to represent a role, it really creates a whole layer of security on top of the infrastructure. Your access, security, features and management (when it comes to Exchange) will all be going through that layer. Obviously the architecture and technology developed are more complicated than that but in a simplistic term, that's how I would put it. The graphical representation of RBAC I love the most is actually this,

 

  • Role: The definition of a role is like a list of cmdlets and the switches in each cmdlet. For example, Set-CASMailbox and the attributes you can set using this cmdlet. You will find each of the default role has a whole list of cmdlets instead of just one defined.
  • User, USG, Policy: Then you have the user object, groups and policy which literally is the user object, security group and potentially a policy.
  • Role Assignment: You then create the mapping between Role and User or group or policy object(s). Think of this like a table to maintain the Many to Many relationship.
  • Scope: Lastly, you also need to specify where can this person use those define roles on.

Let me give you an example, look at the following,

  • Role: MyName
    • Cmdlets included: 
      • Set-User -FirstName -Identity -Initials -LastName - Notes
      • Get-Mailbox -Identity
    • The above is what this person can execute if it is being assigned to this role.
  • User: John Doe (johnd@alpineskihouse.com)
  • Scope: Self

So, if I create an assignment and assign John Doe to this role and then the scope is self, it means if John Doe logs in, it can perform the above cmdlets and only the specified switches and only on himself. If he tries to change the First Name of another user, it will fail. Of course, the above is very simple example.

Let's take a look at a better example in our Hosting Deployment,

Here, I am retrieving a specific Management Role in the AlpineSkiHouse tenant organization. The Role is called MyProfileInformation. As you can see from the highlighted below, those are the cmdlets that this role will have. I also highlighted the implicit scope which I thought will be something that you folks should know and probably go and spend some time to understand and read.

[PS] C:\> Get-ManagementRole -Organization AlpineSkiHouse MyProfileInformation | FL

RunspaceId : 3fada12d-cfef-4723-a029-c6f159a26ec2

RoleEntries : {(Microsoft.Exchange.Management.PowerShell.E2010) Set-User -DisplayName -FirstName -Identity -Initials -LastName -Notes -SimpleDisplayName, (Microsoft.Exchange.Management.PowerShell.E2010) Set-Mailbox -DisplayName -Identity -SimpleDisplayName, (Microsoft.Exchange.Management.PowerShell.E2010) Get-Mailbox -Identity}

RoleType : MyProfileInformation

ImplicitRecipientReadScope : Self

ImplicitRecipientWriteScope : Self

ImplicitConfigReadScope : OrganizationConfig

ImplicitConfigWriteScope : OrganizationConfig

IsRootRole : True

IsEndUserRole : True

MailboxPlanIndex :

Description : This role enables individual users to modify their name.

IsDeprecated : False

AdminDisplayName :

ExchangeVersion : 0.12 (14.0.451.0)

Name : MyProfileInformation

DistinguishedName : CN=MyProfileInformation,CN=Roles,CN=RBAC,CN=Configuration,CN=AlpineSkiHouse,CN=ConfigurationUnits,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=fabrikam,DC=com

Identity : AlpineSkiHouse\MyProfileInformation

Guid : 6c279593-fc9c-43b1-9703-537bb873f242

ObjectCategory : fabrikam.com/Configuration/Schema/ms-Exch-Role

ObjectClass : {top, msExchRole}

WhenChanged : 9/4/2010 12:12:34 PM

WhenCreated : 9/4/2010 12:12:34 PM

WhenChangedUTC : 9/4/2010 7:12:34 PM

WhenCreatedUTC : 9/4/2010 7:12:34 PM

OrganizationId : fabrikam.com/Microsoft Exchange Hosted Organizations/AlpineSkiHouse - fabrikam.com/Configuration/Services/Microsoft Exchange/ConfigurationUnits/AlpineSkiHouse/Configuration

OriginatingServer : AD01.fabrikam.com

IsValid : True

Next, I am going to see what are the assignments in place for this role, I ran the following,

[PS] C:\> Get-ManagementRoleAssignment -Organization AlpineSkiHouse | WHERE {$_.Role -like "AlpineSkihouse\MyProfileInformation" | SELECT Identity, RoleAssignee, EffectiveUserName | FL

Name : MyProfileInformation-Organization Management-Delegating

RoleAssignee : fabrikam.com/Microsoft Exchange Hosted Organizations/AlpineSkiHouse/Organization Management

EffectiveUserName : All Group Members

Name : MyProfileInformation-Default Role Assignment Policy

RoleAssignee : AlpineSkiHouse\Default Role Assignment Policy

EffectiveUserName : All Policy Assignees

You can see from the above that this role has 2 assignments. One to the Tenant Administrator Role Group (you can read more about Role Group from here, https://technet.microsoft.com/en-us/library/dd638105.aspx) called Organization Management and the other is through policy (you can read more about policies from here, https://technet.microsoft.com/en-us/library/dd638100.aspx). The effective users is everyone in that group or in that policy. You can probably see, the topic can definitely go much deeper and longer and I am more happy to respond to any question if you have any but it will be difficult for me to blog everything here.  

Now, we have some basic understanding of RBAC (which honestly if this is your first exposure to RBAC, I will strongly recommend you to spend some time to read about Permissions here, https://technet.microsoft.com/en-us/library/dd351175.aspx), we will proceed with exploring the types of roles, role groups and default assignment created in Hosting deployment.

Cheers.

Read More on this RBAC Series.

Read all other Exchange Server 2010 SP1 Hosting Deployment blog posts.