The joys of Microsoft Exchange 2010’s RBAC

It’s a great new day for access control management in Microsoft Exchange 2010. Older versions of Microsoft Exchange worked off the Windows access control model, which uses access control lists (ACLs) and a permission structure with hierarchal levels. ACLs are made up of access control entries and security identifiers (SIDs), and really, if you’ve been in IT for more than a day, you know how all of these combine in Windows to provide object access control. The combination of allow/deny access with a combination of permission settings on object — or in this case, on mailboxes and public folders and so forth — is all part of the Windows world.

Older versions of Exchange combined that concept with predefined administration groups you could assign. For example, in Exchange 2003 you can assign one of these three: Full Administrator, Administrator, and View Administrator. Exchange 2007 SP1 provides four administration groups: Organization Administrators, Recipient Administrators, View-Only Administrators, and Public Folder Administrators.

[ Read J. Peter Bruzzese’s top 8 tips for transitioning to Exchange 2010. | Stay up to date on the key developments in Microsoft and Windows technology with InfoWorld’s Technology: Microsoft newsletter. ]

In smaller environments, these few administration groups might be just what you need. But in more complex environments, where people have specific job functions (or roles) to perform, there is a need for a more granular approach to access control. Where Exchange 2010’s role-based access control (RBAC) comes in is that the permissions are assigned to specific operations, not necessarily to objects themselves at the lower levels.

Looking at how RBAC is used in Exchange 2010, you can see the thinking shift from the ACLs-on-objects approach and more to the operations a person can perform or, more appropriately, the role a person has in the organization.

For starters, there are 11 built-in role groups. These appear in Active Directory as Universal Security Groups, but assigning folks into these groups is actually handled through the Exchange Management Shell (EMS) via PowerShell cmdlets or the Exchange Control Panel, which is a new Web-based method of administration for Exchange 2010. Whereas the 3 or 4 administration groups were fitting for their time, these 11 groups make greater sense when you think about the complexity that Exchange brings with it. In some cases, these groups are not for admins only but can be delegated to users who can perform job functions or roles within Exchange as a result.

One example is the Discovery Management role group. Assigning users into this group allows them to use the Exchange Control Panel to perform searches through mailboxes for specific criteria, such as to assist with litigation that would call for discovery compliance.

Obviously, the majority of the RBAC roles in Exchange relate to what administrators can and cannot do. That is the nature of Exchange: to ensure you have professionals handling those responsibilities, not users. However, there are roles in Exchange environments that, while not a hierarchy or a pecking order per se, require different people to have different abilities. That’s where the role groups come in.

The 11 groups are actually a combination of roughly 65 roles. These roles are made up of entries — that is, PowerShell cmdlets and parameters for the built-in management roles as defined by the Exchange development team. This is where we see the exciting piece to this puzzle; since Exchange 2007, Exchange administration has been built on PowerShell, a shift in design that allows you to control a role by manipulating the cmdlets and parameters assigned to that role.

Now, where it really becomes fun — and, for many, confusing — is that you can create your own role groups by mixing predefined roles and/or by creating your own roles and defining the entries (cmdlets and parameters) for those roles as you see fit.

The immediate beauty of RBAC as it is implemented in Exchange 2010 is how you can assign broad access and permission settings through the built-in role groups, establish a midlevel of granularity by mixing predefined management roles, or really get into the guts of RBAC by creating your own roles, defining the cmdlets and parameters, scope assignments, and more (to the nth degree) and building exactly what your environment needs.

Microsoft has known the value of RBAC for quite some time. Role-based security (another term used for RBAC) was built into the .Net framework, and Windows Server 2003 has the Authorization Manager snap-in for the MMC Console that uses the same approach; this tool continues to be available in Windows Server 2008.

The RBAC apporach could get even more useful if other development teams at Microsoft pick up on the value of this model. If they redesign their tools with PowerShell control throughout, they could take advantage of the same RBAC model and allow the same choice of broad, midrange, and granular control for each and every enterprise product. Already, Communications Server 2010 has implemented RBAC based on PowerShell cmdlets and parameters. The next version of System Center Configuration Manager (SCCM) is also embracing the concept of RBAC.

This article, “The joys of Microsoft Exchange 2010’s RBAC,” was originally published at InfoWorld.com. Read more of J. Peter Bruzzese’s Enterprise Windows blog and follow the latest developments in Windows at InfoWorld.com.