Wednesday, June 12, 2013

Exchange 2010 - RBAC (Role Based Access Control)

Before 2010: delegation in Exchange 2007

Until Exchange 2010, delegation was rather simple and somewhat limited. Exchange 2007, for example, included only four administration groups to which one could be assigned:
Exchange Organization Administrators
These have full control over the Exchange organization.
Exchange Recipient Administrators
These can manage recipients: mailbox users, mail enabled users, contacts and distribution groups. But there's a catch: to modify Active Directory user, contact or group objects, they must also belong the the Active Directory "Account Operators" group or (preferable option when possible) have delegated control over a particular OU (organizational unit). Some might argue that "Account Operator" membership is excessive since members could modify all kinds of objects (even computer objects) and violate the principal of least power.
Exchange View-Only Administrators
As its name implies, this allows members to view the entire Exchange organization but not make changes.
Exchange Public Folder Administrators
Exchange 2010 and RBAC
Exchange 2010 implements "RBAC", a far more flexible and granular  method of assigning necessary permissions - and only necessary permissions -  to administrators and even to the point where one can create custom roles affecting only a particular property of a user.
The RBAC delegation framework also exists in Exchange 2013 and Exchange Online with Office 365. So it is a useful system to know. Now, much has already been written on the subject, from Technet articles to blogs by various Exchange MVPs. Therefore, I will not present RBAC point by point but relate some experiments I performed for myself.
For reference, however, I'm providing this link:
Role Groups, Roles and Role Entries

In Exchange 2010 there are 11 predefined "Role Groups" which include various "Roles" which in turn are composed of various "Role Entries". The Role Entries are the very specific actions that an administrator, when added to a Role Group, can perform on an object. I've listed the 11 roles below with a brief explaination:
  • Delegated Setup (install Exchange servers)
  • Discovery Management (search mailboxes for compliance reasons)
  • Help Desk (manage limited user properties - but NOT resetting passwords)
  • Hygiene Management (manage spam filtering)
  • Organization Management (includes almost all rights by default)
  • Public Folder Management
  • Recipient Management
  • Records Management (compliance features, retention, transport rules)
  • Server Management
  • UM Management (for Unified Messaging)
  • View-Only Organization Management (read-only access to the entire organization)
Better yet, roles can be customized. If the primary Exchange administrator wanted to delegate only the right to manage transport rules (and nothing else) a custom role could be created for this purpose, based on the Records Management role.
So let us demonstrate how delegates can be added to various Role Groups and thus perform various tasks based on the Roles (and in turn the Role Entries) assigned to these groups.
We first need to access the ECP (Exchange Control Panel), logged in as an Organization Administrator.
1. Enter the URL for the ECP:
2. Enter your logon credentials:
3. Go to "Manage My Organization" (if not already selected) and then "Roles & Auditing".
4. You'll see the 11 Role Groups:
5. Select "Help Desk".
Note the details. The members of the group can manage only certains aspects of a user's mailbox:
6. Now "Trevor Reece" will manage users via the ECP, once he is member of the group in question.
Note that without this status, Trevor cannot even access the ECP at all:
7. So we add Trevor to the group by double-clicking on the group and selecting his name (we can search for it as I have done here).
Click "OK" and then "Save".
Now Trevor can not only access the ECP but can access particular user properties. Let's pretend he needs to manage Teresa Wood's mailbox.
Once in the ECP, he selects the option "Another User" and opens Teresa's user properties (with a double-click) after highlighting her name:

He can edit her account information...
Organize or troubleshoot Inbox Rules or Automatic Replies...
And manage various settings, like the Show BCC or show From...
Unfortunately, the Help Desk specialist cannot change passwords via the ECP.

Will making Trevor a member of the Recipient Administrator Role Group make a difference?
In theory, "Members of this mangement role group have the rights to create, manage, and remove Exchange recipient objects..." In reality, there is no option to create a new mailbox user, although delegates can create distribution lists:
I attempted to create a custom group with the "Security Group Creation and Membership" role, thinking it might allow something necessary to happen in the background. But no luck!
It looks like the Exchange development team simply removed what seems like a fundamental feature:
Finally, let's delegate the "Discovery Management" role to someone. This role allows the delegate to search the entire mailbox database (all the mailboxes) for compliance with whatever policy may be in effect in the organization. By default, no one has this role assigned to them, not even administrators.
So, if the user has not been granted the Discovery Management role, the Mail Control | Discovery option does not even appear:
On the other hand, Teresa Woods has been granted this role. When she connects, the Discovery option is available:
This concludes my post on RBAC. I intend to follow up with a post about conducting a mailbox search once granted the Mailbox Discovery role.


  1. Thanks for such sharing such a kind information! i would like o know how to troubleshoot inbox?

  2. What is the problem exactly?

  3. uperb posts with lots of information!!! This is really the most miraculous blog site dude….
    cabling services ct.