The Dot Net Factory Identity Management Blog

Microsoft recently announced that the soon to be released Exchange 2010 was moving to an entirely Role-Based Access Control model. This represents a major change from the split permissions ACL model used in previous versions and one that is sure to be welcomed by security professionals everywhere. From what I've read so far, it looks like a complete swap out of the administrative delegation model from granting ACLs for attributes on objects moving instead to controlling "Operations" which represent PowerShell commandlets that perform specific human identifiable tasks. The ACLs model was cited by the Exchange team as a leading source of support calls and a major area of frustration for administrators.

Interestingly enough, the Exchange 2010 RBAC model maps on an almost one-to-one level with EmpowerID's implementation of RBAC at the technical role or "Management Role" level. These are the roles defined per type of Resource (mailbox, user, group, web page, etc...) to provide consistency for delegation of management tasks and also for reporting who has access to what. In EmpowerID, our "Operations" are workflow shapes that can, like Exchange, be PowerShell commandlets or almost anything else: custom code, web service calls, SSH calls, etc...

We are in complete agreement with the Exchange teams assesment of the lack of viability of ACL-based permissions management and are looking forward to seeing how AD moves down this path in future releases of the Windows Server platform. Given that Windows Server 2008 R2 includes a large number of PowerShell commandlets for AD administration, using these as the basis for AD management "Operations" an RBAC management model seems like a natural next step.

 Read more about our take on Exchange's move to RBAC