If you would like to read the other parts in this article series please go to:
- Exchange 2010 Role Based Access Control (Part 2)
- Exchange 2010 Role Based Access Control (Part 3)
- Exchange 2010 Role Based Access Control (Part 4)
In Exchange 2000 and Exchange 2003, permissions were assigned via the Delegation Wizard that was found in the Exchange System Manager console. This Delegation Wizard allowed the administrator to assign one of three roles to a user that they wished to grant administrative access to. These three roles were the Exchange View-Only Administrator, Exchange Administrator and Exchange Full Administrator roles. Although assigning these roles to administrative users gave those users varying levels of permissions within Exchange, the main issue with this model was that it simply wasn’t granular enough for many organizations. For example, although it was possible to grant permissions at both the organization and administrative group levels, it wasn’t possible to grant rights over specific servers; once an administrator had been granted rights at the administrative group level, that administrator had rights against all Exchange servers in that administrative group.
The permissions granularity issue was improved in Exchange 2007. The Exchange Full Administrator role found in Exchange 2000 and Exchange 2003 became known as the Exchange Organization Administrators role in Exchange 2007 and still gave administrators full access to all Exchange objects in the entire organization. The Exchange View-Only Administrators role also remained, giving administrators read-only access to the entire Exchange organization. There were effectively three new additions to the Exchange 2007 roles:
- Exchange Recipient Administrators - Allowed administrators to modify Exchange settings on users, groups, contacts and public folders
- Exchange Public Folder Administrators - Was introduced in Exchange 2007 Service Pack 1 and as its name suggests allowed administrators to manage public folders
- Exchange Server Administrators - Allowed administrators to fully manage a particular Exchange 2007 server as long as they were also a member of the local Administrators group on that server
Although the permissions model in Exchange 2007 was a vast improvement over those models found in earlier versions of Exchange, it still wasn’t able to satisfy a lot of the administrative scenarios found in various organizations. Essentially, the roles in Exchange 2007 still offered too much administrative power to administrators in a decentralized Exchange organization and it was therefore difficult to limit the permissions available to certain administrators. Although it was possible to implement a split permissions model in Exchange 2007 by modifying Access Control Lists (ACLs), this was a complex procedure that could sometimes result in errors and issues that were difficult to troubleshoot.
The design of Exchange 2010 has needed to take into account the more demanding and granular permissions requirements of organizations. Exchange 2010 now supports a model where specialist users can be granted specific Exchange permissions required to perform their duties. For example, there may be the scenario where a compliance officer within a company needs to conduct a search across all employees’ mailboxes for legal reasons, or perhaps a member of the Human Resources department needs to update user information in Active Directory that is seen on the properties of users’ mailboxes. In these example cases, the relevant specialist user should only be given the rights to perform the required task and should not be assigned, for example, additional rights that could allow them to affect the overall configuration of the Exchange environment.
The RBAC Model
The permissions model that Exchange 2010 uses is called Role Based Access Control (RBAC). The key element to RBAC is that it allows fine-grained adjustment so that you can easily control the level of permissions assigned to your users and administrators. For example, if you have help-desk staff that need to manage mailbox quotas, then RBAC allows this.
In this particular article series we won’t be going into custom RBAC solutions just yet as we’ll leave that for a later article series here on MSExchange.org. The idea behind this article series is to introduce you to the RBAC model and you will see that understanding all the various component names that comprise RBAC is fundamental to understanding the process. To fully understand RBAC, you need to understand the differences between components such as management role groups, management roles, management role assignments and so on. Understanding the component names can be difficult when you first start learning about RBAC because many of them sound very similar.
The first key principle to understand about RBAC is that there are three ways that permissions can be assigned:
- Management role groups
- Management role assignment policies
- Direct user role assignment
The first two methods listed above, namely management role groups and management role assignment policies, are the main methods used to assign permissions using RBAC. The direct user role assignment method is considered an advanced method that won’t be covered any further in this article series. It is quite possible that management role groups and management role assignment policies will cover your requirements sufficiently. In fact, Microsoft recommends that management role groups and management role assignment policies are used in preference to direct user role assignment to simplify the overall permissions model within your Exchange organization.
If the user that requires permissions is either an administrator or what Microsoft refers to as a specialist user, then you will probably want to assign that user to a management role group. The term specialist user is used to refer to someone who needs to perform a particular task, such as a compliance officer who needs to search the contents of all user mailboxes across the Exchange organization. If, however, the user is essentially an end-user then management role assignment policies are generally used to assign the necessary permissions.
In this article series we will first look at the management role group method and will then proceed to look at the management role assignment policy method. We will start our look at the management role group method by looking at the default management role groups that are created with Exchange 2010 and will focus on breaking down the various components piece by piece so that the overall RBAC model can be understood. We will then go on to see how management role groups can be used to assign permissions to administrators or specialist users.
Management Role Groups
In Exchange 2010, Microsoft has made the task of assigning a series of common permissions to administrative and specialist users very easy by providing 11 default management role groups. By placing a user or group into a management role group, the management roles associated with that management role group are assigned accordingly thereby giving the user or group the relevant permissions. The term role holder is used by Microsoft to denote the administrative or specialist user that is added to the management role group. These 11 default management role groups are created during Exchange 2010 setup. Specifically, these management role groups are created when Exchange 2010 setup runs the Active Directory preparation steps that can be performed individually by running the Exchange 2010 setup.com program with the /PrepareAD switch. The management role groups can be seen in the Microsoft Exchange Security Groups Organizational Unit (OU) that is created in the root domain during the Exchange setup process. You can see this OU and the groups within it in Figure 1. Note that of the 16 groups shown in Figure 1, only 11 are management role groups; these are highlighted.
Figure 1: The Default Management Role Groups
Here is a brief description of the default management role groups created automatically when you install Exchange 2010:
- Delegated Setup - This management role group gives members the ability to run the Exchange 2010 setup program and therefore deploy, but not administer, a new Exchange 2010 server. Deployment can only be performed on servers that have already been provisioned by an administrator with additional permissions.
- Discovery Management - A member of the Discovery Management role group has the ability to perform searches of all mailboxes within the Exchange organization as well as implement the Legal Hold feature of Exchange 2010. We shall be looking at this management role group in detail later in this article series.
- Help Desk - The Help Desk management role group gives members permissions that are typically required by members of a help desk, such as modifying users’ details such as their address and phone number.
- Hygiene Management - This management role group is used to provide permissions associated with managing and configuring both the antivirus and anti-spam elements found in Exchange 2010.
- Organization Management - The Organization Management role group is synonymous with the Exchange Full Administrator role in Exchange 2003 and the Exchange Organization Administrators role in Exchange 2007. Essentially, membership of this management role group gives the user the ability to perform pretty much any task in Exchange 2010, with the main missing task being the ability to perform mailbox searches; that itself is achieved via the Discovery Management role group.
- Public Folder Management - This management role group naturally gives members the ability to manage the public folder environment.
- Recipient Management - A member of this management role group can create and modify Exchange recipients.
- Records Management - The Records Management role group gives the ability for members to control and configure the compliance features of Exchange 2010. Examples of such features include transport rules configured on a Hub Transport server as well as message classifications in Outlook.
- Server Management - This management role group gives the ability to manage all Exchange servers within the organization. Permissions granted as membership of this management role group therefore work at the server configuration level found in the Exchange Management Console and do not work at, say, the organization level found in the Exchange Management Console.
- UM Management - As its name suggests, membership of this management role group grants permissions to manage all aspects of the Unified Messaging environment.
- View-Only Organization Management - This management role group allows members to view the configuration of any element found within the Exchange organization.
That completes part one of this article series that takes an introductory look at the RBAC feature of Exchange 2010. In this first part we’ve covered a bit of background information on RBAC and then begun our look at the use of management role groups which we’ll continue in part two.
If you would like to read the other parts in this article series please go to: