RBAC in Exchange Online Part 2 - Scoping admin roles
In the first article in this series, I covered the basic GUI based ways that you can use RBAC in Exchange Online to allow users to control their own contact information in Exchange Online and to allow you to designate administrators with limited sets of rights.
In this article, I’m going to show you how to really use RBAC. We’re going to dive into PowerShell and see how to do things like give an administrator rights to manage a specific sub-set of your users.
RBAC, it’s still not that hard
The original question I was trying to answer in part 1 was “How do setup Exchange Online so that I can have one administrator control a sub-set of my users?”
I showed you how to go into the Exchange Admin Center and see the admin roles that are pre-created for you. From there, it’s pretty easy to see how to give an administrator a limited set of rights by assigning that person to one or more of the available admin roles.
The pre-existing admin roles may not fit every possible need for a limited set admin rights, but they do fit a lot of them. We’ll look at what we can do if your organization needs more granular control of those admin roles in a later article, but first let’s look at that pesky “scope” pull down we saw in part 1.
Let’s say, for example, your organization wants to divide the administration of Exchange Online into two different sites. You have a site in Portland and a site in New York, each hosting about one half of your user base. You want the Exchange admins in Portland to have full control over all the users in Portland, but no access to the users in New York. You also want the opposite to be true for the administrators in New York.
If you go into the existing Organization Management admin role, you’ll see the Write Scope section is set to Default (pictured below). If you try to expand that on your Exchange Online tenant, you’ll see there are no other possible choices.
In order to complete our requirement of having admins in Portland control users in Portland, and admins in New York control users in New York we’re going to need to add scopes for Portland and New York.
To add those two scopes, first we need to connect remote PowerShell to your Exchange Online tenant. Once that is done, run the following two commands
New-ManagementScope -Name "Portland Scope" -RecipientRestrictionFilter { Office -Eq "Portland" }
New-ManagementScope -Name "New York Scope" -RecipientRestrictionFilter { Office -Eq "New York" }
Let’s stop here for a minute and talk about the New-ManagementScope command. In on-premises Exchange 2013, there are a number of different ways you can set a new management scope, but with Exchange Online you are pretty much just limited to using a RecipientRestrictionFilter.
The syntax for a filter query is
Opening Bracket – “{“
Property to examine – Any property value on the objects you want to test. This can be “Name”, “City”, “Department”, or pretty much any other property you can see with a Get-MsolUser command
Comparison operator – directs how to query should evaluate the value you specify. Basic examples are –Eq (Equals), -Ne (not equals), and –Contains. This link shows a full list of available comparison operators.
Value to compare – What the property you specified is compared to. Wildcard charterers that are supported by the comparison operator work.
Closing bracket – “}”
You can also use parentheses and logical operations to make your filter more complex. For instances if you want your filter to apply to everyone in the Portland office except for those in the sales department unless that person is a manager, you can use this filter
{ (City –Eq “Portland”) –And (Department –Ne “Sales”) –Or (Title –Like “*manager*”) }
Going back to the command I used to setup our scopes for Portland and New York offices, you can now see I just set the scope to users with Office parameter defined to Portland or New York to fall into their respective scopes. After running those two commands, we can go back to our Organization Management admin role and see the two scopes present
BUT… it would be a bad idea to start scoping down this specific admin role. This is a default role that is used by Office 365. If you scroll down to the members section of this role, you’ll see TenantAdmins_aae12 is a member. This is where you the users you define as tenant admins in the Office 365 Admin portal get their rights to Exchange Online.
Let’s create a new admin role. Use the + at the top of the list of admin roles to create a new role group. Give your new role group a name, description, and write scope. Add all the same roles you see in the default Organization Management role group. That is 22 of the 49 available roles. We’ll talk about what each of those does later.
I called mine “Portland Org Management” and set it to the now available Portland write scope. I created a new “In Cloud” user called “Portland Admin” in my Office 365 Admin portal, and designated that user as a normal user with no admin rights. Then I added “Portland Admin” to the new role group “Portland Org Management”.
Now if I launch a new session of the EAC by going to
https://outlook.office365.com/ecp/
…and logging in at “Portland Admin”, I’ll see what this new account can do.
Just going to recipients > mailboxes I see a full list of all users with Exchange Online mailboxes. The first users there is “Joe Tester”. If I highlight Joe, on the right hand side of the screen I see the following information.
Notice how Joe does not have anything filled in for his Office? When I go to Edit Joe’s account all the boxes are greyed out.
I cannot make any changes to Joe’s account with this “Portland Admin” account because Joe does not have “Portland” listed in his Office field. If I look at the same screen on my account, which does have Portland listed as my Office, I see this
The “Portland Admin” account has admin rights to my account. It should be noted that my account is a Global Admin on my tenant, while “Portland Admin” has no admin rights at all expect that I added it to the new Portland Org Management role group we just created. You may be used to on-premises situations where a lower level administrator will automatically not be able to edit a higher level admin. This is not the case here. You've been warned.
Make sense? Good. Next time we’ll look at how we can figure out exactly what rights we’re giving to new admin roles.
-Nathan