The introduction of role-based access control (RBAC) in Microsoft Exchange Server 2010 makes it easier for administrators to enforce the principle of least privilege for tighter security and better compliance around email access and operations.
Implementing role-based access control via Exchange Server 2010 gives companies the ability to align email administration with business operations for regular tasks and special circumstances where they want to give someone temporary privileges without giving them abilities.
Exchange Server has relied, in part, on several administrator levels. Starting with Exchange 2007, these are defined as:
- Organization, for top-level admins;
- Recipient, with limited power for daily tasks such as adding and removing users;
- View-Only, which grants read access, and;
- Server, which grants admin rights over specific Exchange Servers.
But these aren't flexible enough for many companies.
"Organizations really didn't use those other levels [aside from Organization]," said Rand Morimoto, CEO of Oakland, Calif.-based Convergent Computing and co-author of Microsoft Exchange Server 2010 Unleashed. "For the most part, you are either an Exchange admin or you're not."
In practice, companies find it easier to give someone full administrative rights, so they can deal with any situation -- say, an emergency call outside of business hours
EXCHANGE SERVER 2010 ELIMINATES ACCESS CONTROL LISTS
Earlier versions of Exchange try to address this problem through access control lists (ACLs), which have been completely replaced by role-based control in Exchange Server 2010. The essential difference is that RBAC is based on defining what you can do, while ACLs focus entirely on what objects you have access to.
The combination of choosing from of one the existing admin levels and designing their access with ACLs isn't flexible enough to effectively delegate management based on the way you want people to work. Moreover, adding and removing permissions through ACLs is tedious, highly detailed and error-prone, experts say.
Exchange 2010 relies on the use of roles and role groups. The roles are assigned to role groups, which include things such as mailboxes and users. These assignments also include scope -- in other words, what that role group is allowed to manage. The roles themselves are made up of individual role entries, each of which enables a specific task.
In practical terms, you can now create roles based on precisely what you need, no more, no less. These can be permanent or created on the fly for temporary projects.
So, for example, you can define an Exchange Help Desk role to handle operational chores, such as starting and stopping mail queues. Or, if policy, allows, you may want to delegate some tasks, such as adding and removing mailboxes at the department level. Or, legal counsel may need ongoing or short-term ability to retrieve and read email within a certain scope for e-discovery. You can create a carefully defined role that gives your lawyer access to the data, but no Exchange operations.
"It is no longer just about IT people," Morimoto said. "A lot is based on someone's role to add or delete somebody, or perform email recovery. It gives us the granularity to do daily tasks by creating these little groups and doling them out to people."
Specialized roles make sense if they allow people to perform frequent tasks that can unburden IT and bring operations closer to the business model. But if the tasks are needed once a month, or once a quarter, it's not worth it.
EXCHANGE CONTROL PANEL ENABLES REMOTE MANAGEMENT
Exchange 2010 makes role-based access control more accessible to both high-level admins and limited purpose managers through a new remote interface, the Exchange Control Panel. Admins can now manage Exchange through Outlook Web Access, which gives them the same level of control previously limited to the Exchange Management Console without setting up a terminal services session.
This is a tremendous convenience for high-level admins, Morimoto noted, because they can now manage from home, from Starbucks, from a remote laptop or even their smartphone. It makes those types of limited roles we mentioned a lot more practical because their tasks are accessible.
If you are preparing to step up to Exchange Server 2010, handle the changeover first, then turn your attention to implementing role-based access. Migrate the users and mailboxes and make sure everything is stable, Morimoto advises. Trying to do both adds complexity: The migration will take longer, there's more room for error and problems will be harder to troubleshoot -- is it a configuration problem or a user mistake?
Before the migration, remove users who have full admin rights to perform infrequent tasks. After your Exchange 2010 environment is running smoothly, begin to apply RBAC, limiting high-level administrative rights to perhaps two or three key people, and deciding what other roles and role groups you may want and who to assign them to.
"It's [RBAC] is one of the most popular things admins get a chance to work with," said Morimoto. "Get familiar with it, play with it, but don't lock things down until you really understand what you are doing."
This was first published in December 2009