This session focused on the all-new permissions model of Exchange 2010/SP1. Back in the days of Exchange 2003/2007, Microsoft had a very, very limited permission model that just consisted of a handful of rights. This caused problems in organizations where you want to granularly delegate permissions to specific groups such as helpdesk, server admins, or various Exchange admins. To address these concerns, Microsoft has introduced a full RBAC (role based access control) model to Exchange 2010.
Features of this model include:
– Align organizational structure with their Exchange role and responsibilities.
– Replaces the AD-centric model of previous Exchange versions.
– Provides a consistent authorization model whether you are using the EMC, ECP, or EMS.
– SP1 provides over 65 roles to chose from
– The model consists of the three following components:
1. Role – What you can do, such as change attributes on a DL or manage a server.
2. Scope – Where and on what type of objects you can act (users, groups, OU, database, etc.)
3. User – The group or users which are added to the various roles
– The “Exchange Trusted Subsystems” performs all actions be it in AD or on servers. Exchange 2010 acts a a proxy and only allows authorized users to perform authorized tasks on objects within their scope. No more futzing around with individual ACLs on objects in AD or servers.
– SP1 will enhance RBAC by providing a best practices analyzer to find gaps in your RBAC permissions (such as only allowing administration of a specific object by a group, but that group is empty).
– SP1 will also add enhancements to the Exchange Control Panel to more fully manage RBAC roles, members, and permissions.
– SP1 will facilitate the split Exchange/AD-Windows model so that you can strictly limit what administrators can do (such as having AD only admins and Exchange only admins).
All in all, the new RBAC model is a major change from previous Exchange versions. This aligns with the all-new RBAC model in OCS “14” as well. Organizations can now more granularly assign permissions, not over-delegate rights, and better audit access into these critical services.
