RBAC Manager: making Exchange role-based access control more understandable

Until Exchange 2010, control over Exchange objects was exercised by good 'ol Windows Access Control Lists (ACLs) and Access Control Entries (ACEs). The upside of this implementation was that it was shared with Windows so if you understood how ACLs worked for Windows, you had a fair chance of understanding it for Exchange. The downside is that ACLs are a crude control mechanism that works well when configuring user access to objects such as files but is less satisfactory in the world of Exchange.

ITPro Today

March 24, 2015

4 Min Read
RBAC Manager: making Exchange role-based access control more understandable

Until Exchange 2010, control over Exchange objects was exercised by good 'ol Windows Access Control Lists (ACLs) and Access Control Entries (ACEs). The upside of this implementation was that it was shared with Windows so if you understood how ACLs worked for Windows, you had a fair chance of understanding it for Exchange. The downside is that ACLs are a crude control mechanism that works well when configuring user access to objects such as files but is less satisfactory in the world of Exchange.

So Microsoft decided to shake things up in Exchange 2010 and replaced ACLs with Role-Based Access Control (RBAC). The history of RBAC goes back to 1992 and has been implemented in many other computer systems. Essentially the idea is simple. Define the roles (like a user or an administrator) that exist within a system. Then figure out the actions that each role should be able to perform (like creating mailboxes or setting transport parameters). Each action is granular in nature because it governs what the holder of a role can do, so you gather all the actions (or entries) together into a "role group" that represents the complete set of actions that the holder of that role can perform when working in the role, like "Message Tracking" or "Move Mailboxes".

All of which is what happens in Exchange RBAC. Management role groups contain sets of tasks that can be assigned to individual users. The tasks break down into the PowerShell cmdlets that are run to execute the tasks. Even more granular, specific parameters for the cmdlets can be allowed or denied.  The same approach is taken to grant users the ability to work with Exchange, so that they can access their mailbox and update user settings.

RBAC is supported by Exchange 2010, Exchange 2013, and Exchange Online. Exchange 2013 makes it easier to work with RBAC than Exchange 2010 because a GUI is exposed in the Permissions section of the Exchange Administration Center (EAC). Exchange Online supports the same GUI but the nature of Office 365 means that the management role groups and the cmdlets made available to administrators are quite different.

Logical as it all seems, from bitter experience of attempting to explain how Exchange RBAC works, I know that many people have difficulties figuring out how roles interact with role assignments and management role groups and user assignment policies. It might be that the terms used for the RBAC components get in the way or that a light bulb needs to fire before people get it. Or perhaps it's the way that the PowerShell cmdlets used to manipulate RBAC assignments work or that the EAC GUI is not flexible enough. For whatever reason, RBAC is challenging for some.

This is a real pity because RBAC tweaks can make Exchange do exactly what you need it to do. For example, you can create a management role group for support personnel that allows them to deal with specific situations without allowing them full rein over servers.

Which brings me to a CodePlex project named "RBAC Manager R2 for Exchange 2010 SP2, Exchange 2013 Preview and Office 365" (quite a mouthful). The current version is 1.5.5.1 and the code hasn't been updated since September 2012, which accounts for the "preview" label against Exchange 2013.

RBAC Manager is really quite a nice utility for those looking for a graphic interface for RBAC. It's easy to install (just an executable and a configuration file) and will work as long as .NET Framework 3.5 features are installed on the workstation or server. The program functions quite well against Exchange 2013 CU8 but less so against Office 365 where the utility is both slow and buggy, probably as a result of the additional overhead necessary to fetch RBAC data from the service.

For all that, RBAC Manager is useful when it comes to navigating through role groups, assignments, and cmdlets that underpin everything. The screen shot shows the complete set of role groups from my on-premises Exchange 2013 organization, including some customized role groups that I have added (like the selected Help Desk Level 2 role group).  You can see the roles assigned to the group, including Distribution Groups, Mail Recipients, and Mailbox Import Export (which has to be assigned before PST export or import is allowed). And you can see the users who are currently members of the role group. All in all, it's a nice overview.

RBAC Manager allows you to create new role groups too and to work with other RBAC components such as removing a parameter from a cmdlet or establishing a new scope for an RBAC role. Like any tool, it takes time to appreciate what can be done with RBAC Manager, but that time is well invested if you're looking for something to help you manage RBAC roles.

All of which means that it is a pity that this utility has laid untouched since September 2012. True, Codeplex makes the C# source code available to those brave enough to plunge into an unknown project, but it would be nicer if the original author returned to the code and upgraded it, especially in terms of the program's ability to work with Exchange Online.

Follow Tony @12Knocksinna

Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like