Video – Understanding RBAC for End-Users in Exchange Server 2010


In Exchange 2010 we use Role Based Access Control (RBAC) to determine or restrict what administrators can do in the administrative tools. End users also need to be able to run commands when they are in the ECP. This video is part of a full training course called EXCH2010: Designing and Implementing Microsoft Exchange Server 2010.

To help introduce Interface Video Training, the first 18 videos in this Microsoft Exchange Server 2010 course are available for free below. The entire Video Training Library is available for only $25 per month.

Instructor: Mike Pfeiffer, Microsoft MVP
Video Style: Screencast
View the entire Exchange Server 2010 Course

Microsoft Exchange Server Server 2010 online video training Interface Technical Training

Video transcript:
How to use RBAC for End-Users – Role Based Access Control in Exchange Server 2010

In Exchange Server 2010 we use Role Based Access Control (RBAC) to determine or restrict what administrators can do in the administrative tools. End‑users also need to be able to run commands when they are in the Exchange Controll Panel (ECP). Notice I'm logged in to ECP right now as Bob Smith.

He is just a regular user at this point. He has the ability to do things like set his out‑of‑office and he can come into his account information and click on Edit and change some things about his account.

So giving this guy some self service capabilities kind of takes the burden off of my administrators or my help desk because this guy can manage his own account and do some things in here.

He can come and change his contact information, change his contact numbers and really what is happening is just like the other graphical tools when we change things, we're executing PowerShell cmdlets. So if I wanted to change my display name as an end‑user, I would need to have the ability to run a specific cmdlet that would do that. I would also need to be given permissions by my exchange administrators to do that.

RBAC for end‑users is a separate concept than RBAC for administrators. However at the end of the day, still the same thing is happening. We are running cmdlets to make changes. In order to give end‑users the ability to run PowerShell cmdlets through RBAC, we use something called Role Assignment Policies.

I’ll log in to the ECP as an administrator and I'll show you what I mean.

I'm going to go to the CAS server to the / ECP virtual directory. I created an administrator account for myself.

Now we logged in under "Manage My Organization"

Next I'll go to "Roles and Auditing." Instead of "Administrator Roles", I want to go over to "User Roles."

Now we have this default role assignment policy. This gets assigned to every single mailbox as they're created. You can have multiple role assignment policies but really what it is is a way for us to assign cmdlets to end‑users so they can run cmdlets against their own account to change things. Give themselves the self‑service capabilities that we're talking about.

If you go under the details of this role assignment policy, you can see here that there's some stuff selected by default.

We know the contact information was available because we saw that when we were editing Bob's account. But these are really just RBAC roles, same kind that are assigned to the role groups in RBAC for administrators.

Let's say I wanted to give my users the ability to change of the display name, I can come under profile information and check my display name.

Notice it gives you a description here, "This role enables individual users to modify their display name." So it tells you exactly what it does. You can always drop in to the shell and look at the cmdlets assigned in this role as well.

I'm going to go and hit save here. Notice that it tells me this may affect many users?

Go ahead and say yes to that.

Now if I wanted to create one say for maybe VIPs. I could have different role assignment policies but I would assign them individually to each mailbox. Let's go into PowerShell and look at Bob's mailbox. I'm going to pipe that out to FL for format list.

Basically, I just want to look at the properties that have the word "role" on them.

Obviously, he's got the default role assignment policy assigned. Now if I wanted to change that, I wanted to create a custom or a special role assignment policy I could do that. Then I would just come in here and say, >Set-Mailbox bsmith – RoleAssignmentPolicy.Then I could say VIPs something like that.

That would need to match in whatever one I created my organization. So it will show up in the list. That's how I would kind of customize that.

It could get difficult though imagining on a user by user basis and keep in mind that this default role assignment policy is going to be assigned to everybody. But now that I have enabled the display name options, let me sign out.

I'm going to go back in as Bob Smith.

Go back into ECP, edit my account information.

As you can see the display name field is no longer grayed out.

I can edit it now. I can come in. I can change in my own name. So RBAC for end users is very simple. As you can see it's controlled using "Default Role Assignment Policies" or "Custom Role Assignment Policies."

Posted in Exchange Server | Posted in , , , , , , , , | Leave a comment

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">