Maxim_Kazmin - Fotolia
Many organizations running a modern Exchange Server environment have high expectations of email availability. Exchange Server has matured with features that improve uptime, including Database Availability Groups, which were introduced in Exchange Server 2010, and the self-healing capabilities through Managed Availability in Exchange Server 2013.
To make Exchange secure, Exchange 2003 and earlier were often deployed with implemented hardening guidelines to reduce the potential attack surface. Exchange Server 2007 deployments were more secure by default. While all this was going on, something was already under development that can be seen as the predecessor of today's Role Based Access Control (RBAC) model, being the Authorization Manager (AzMan), a role-based security framework for .NET applications first introduced with Windows Server 2003.
Earlier versions of Exchange came with a small number of security groups -- three in Exchange 2003 and five in Exchange 2007. Those groups were task-oriented. However, membership still allowed access to the whole Exchange organization, so many looked for ways to configure more fine-grained permissions. Options were the split permissions model, in which management of Exchange is separated from the management of Exchange-related objects in Active Directory, or configuring Exchange Access Control Lists in Active Directory.
How does Exchange access control work?
The RBAC implementation revolves around a Universal Security Group called the Exchange Trusted Subsystem, which has permissions on every Exchange-related object in the Active Directory forest. The Exchange Trusted Subsystem also has Domain Administrator permissions when split permissions aren't used. This enables it to create and configure mailboxes, create and manage related user objects in Active Directory and manage the file share witness on a domain member. By default, all installed Exchange Servers will be members of the Exchange Trusted Subsystem group (Figure 1).
RBAC in Exchange Server more or less proxies commands after validating them against the RBAC configuration, which determines what cmdlets and parameters are available to end users. The Exchange Trusted Subsystem has the required permissions to perform tasks, and the end user, who is likely the main reason why bypassing RBAC by importing the Exchange PowerShell snap-in directly is unsupported -- e.g.,
Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.E2010. After all, end users can have insufficient permissions on the Active Directory level than implicitly provided through RBAC.
That RBAC authorization model is built on three pillars:
- Types of tasks you can perform -- These are configured in Management Roles, which define the available cmdlets and parameters to that role through so-called Management Role Entries.
- Who is allowed to perform these tasks -- Linking Role Groups to one or more Management Roles through Management Role Assignments, determines the set of tasks available to members of these Role Groups (Figure 2).
- Where those tasks can be executed within the organization -- These scopes are applied to Management Role Assignment. This allows organizations to not only create segmented permissions, but also to have Role Groups with different permissions throughout the organization, depending on the Management Role assigned.
Exchange 2013 comes with a decent RBAC configuration that works for most organizations. If it doesn't meet your needs, use the RBAC configuration as a starting point for building a custom RBAC implementation. Note that customizing RBAC through the Exchange Admin Center (EAC) or Exchange Online is limited, and RBAC is more of an administration tool than a configuration tool. For example, you can't create a custom scope in the EAC that's part of the "where" configuration.
About the author:
Michel de Rooij is a consultant and Exchange MVP from the Netherlands. Michel started originally as a developer back in 1994 but quickly switched to infrastructure-related projects and started focusing on Exchange in 2004, covering a number of areas, including migrations, transitions, consolidation and disentanglement. Besides Exchange, Michel's other areas of interest are PowerShell, Active Directory, Lync and messaging in general. Michel is a contributor to The UC Architects podcast theucarchitects.com and blogs about Exchange and related subjects at eightwone.com.