On 10.11.12 Microsoft released Exchange 2013, Lync 2013, and SharePoint 2013. These three products were designed to work together in new and unprecedented ways. None of these products is “complete” without being intergraded with the other two. Given that, one would assume that if you know how a feature like RBAC works for one of these products you would know how it works for the others. Turns out that is not the case.

Role Based Access Control is a permissions scheme used for the current versions of Lync and Exchange. RBAC is used in replacement of Access Control List (ACL) based scheme. RBAC is not is system that is exclusive to Microsoft, and several different manufactures have different implementations of RBAC. In fact Microsoft uses several different implementations of RBAC, even within it owns products that are designed to work together. I’m going to highlight 3 differences between the RBAC implementations in Exchange and Lync.

Creating custom roles: Both Exchange and Lync come with pre-built RBAC roles. The pre-built roles include things for jobs like help desk, server administrator, user administrator, or view-only administrator. Each product has its own set of pre-built roles, and for the purposes of this post the details of those roles are not important. Both Exchange and Lync allow you, as the administrator, build custom roles. What we’re going to focus on here is that Lync and Exchange have different rules for building those custom roles. With Exchange, building these custom RBAC roles is a matter of taking one of the pre-built roles and removing command-lets. With Exchange, you cannot create a custom role by starting from scratch and add the command-lets you want this role to have. The rules for creating customer roles with Lync are different. With Lync, you can start with a custom role and either add or remove command-lets. With Lync, you can also start from scratch with a brand new role and add whatever command-lets you’d like.

Scripts: With the RBAC implementation of both Exchange and Lync, you can assign the rights to run custom scripts to a RBAC role. The difference is that with Exchange you can assign an administrator rights to run a script that contains command-lets that cannot be run by that administrator outside of that script. That means that an Exchange administrator can be given rights to run a script containing “New-Mailbox”, but not have rights to open a PowerShell window and run the “New-Mailbox” by itself. With Lync, you can assign rights for an administrator to run a specific script but the command-lets in that script all have to be allowed by that role.

Local rights: RBAC for both Exchange and Lync work through remote PowerShell. That means that if you are not connected through Remote PowerShell, RBAC cannot control what rights an admin have. The difference between Exchange and Lync in this case is that all Exchange Management Shell (and subsequently EAC) sessions run through remote PowerShell. If you launch EMS on an Exchange server, those sessions still connects through remote PowerShell, and thusly RBAC roles take effect. If an admin launches the Lync Management Shell locally on a Lync server, that session does not go through remote PowerShell so RBAC cannot control that session. To be fair, the RBAC implementation on Exchange is not full proof. If you give an administrator help desk level rights then allow that person to logon to the console of your Exchange server, it’s not that hard to for that person to defeat RBAC and gain access to the full suite of Exchange command-lets. I’m not going to post a guide explaining how to defeat RBAC, I will say that I would not allow anyone with less than full rights in Exchange to logon my Exchange server console.

The moral of the story is that Microsoft still has some way to go with these products. I’m sure there are many and varied reasons why these two implementations of RBAC do not work the same, but my feature request for the next versions of these products would be that they work to more closely align the way these products work.