Role-based Access Control (RBAC) was a big security improvement for Lync Server 2010. You’d expect further improvement in Lync’s next version, right?
Lync Server 2013 delivers on improving RBAC in two ways. Some new predefined access roles…and an extremely valuable ability.
The ability to assign cmdlets to a custom access role. (Including LIMITING the cmdlets that role can use.)
Let’s talk about why that’s so valuable.
Background: What RBAC is There For
The standard roles predefined in Lync 2010 are:
(A list of tasks allowed for each of these roles is available here.)
Lync 2010 DID have the ability to create custom roles, using the New-CsAdminRole cmdlet. Essentially, this cmdlet allowed you to copy the rights of a predefined role and subsequently change the scope it could affect.
With this you could create roles for things like:
- Designating an administrator for a specific location (Location Scope)
- Limit administrative access to selected server roles (Server Scope)
- Assign users to admins, to make support process faster (User Scope)
Mike at the Interface Technical Training Blog wrote up a how-to post in April on creating custom Lync admin roles:
Creating a Custom RBAC Role with the Lync Server Management Shell – Interface Technical Training Blog
But these roles came with a limitation: No ability to assign cmdlets to the custom role. When you copied a predefined role to create a custom one, it received full access to every cmdlet the predefined role could use.
What if you mistyped the cmdlet and instead of typing (emphasis on bolded):
New-CsAdminRole -Identity NewLyncAdmins -Template CsUserAdministrator
You accidentally typed:
New-CsAdminRole -Identity NewLyncAdmins -Template CsAdministrator
See the problem? The custom admin role has full access to all the CsAdministrator cmdlets. All thanks to a typo. BAD security risk!
And an avoidable risk, if you had the ability to set which cmdlets a custom role could use…
2013 Lets You Assign Only the Cmdlets You Want Admins to Use for their Role
Unfortunately Lync Server 2010 just doesn’t have the ability to custom-assign cmdlets. Instead of adding the functionality in a Cumulative Update, Microsoft opted to build it into Lync Server 2013.
Assigning cmdlets means not only can you customize a new access role by location or server scope…you can also define their role by function.
Say you want to create a custom role for Rob. Rob is not a Lync administrator; he’s your Support Lead. He doesn’t need administrative access to the Lync servers.
But he IS in charge of backup maintenance. So he wants to export Lync configurations for regular offsite backup.
Let’s create Rob a custom admin role to do this (so he doesn’t have to bug anyone for config backups). We’ll grant him access to only 3 cmdlets: Export-CsArchivingData, Export-CsConfiguration, and Export-CsLisConfiguration.
The format is the same as in Lync Server 2010, with the -Cmdlets parameter added. Here’s what you’d enter into PowerShell:
New-CsAdminRole -Identity BackupMan -Template CsHelpDesk -Cmdlets “Export-CsArchivingData”,”Export-CsConfiguration”,”Export-CsLisConfiguration”
(You’ll see I used the CsHelpDesk predefined role for my template. That might be a higher role than Rob needs, but it’ll do for this example.)
Lync Server 2013 RBAC: Defined By Role Security Limitations You Set
I almost forgot the other RBAC improvement in Lync Server 2013. It adds two more predefined roles:
- Response Group Manager, for managing specific Response Group queues.
- Persistent Chat Manager, for managing specific Persistent Chat rooms.
Limited, but useful managerial access roles. Narrowing the focus of admin roles, whether through predefined access level or custom cmdlet assignment, is the big RBAC change coming in Lync Server 2013.
What are the custom administrative roles you’ve set in Lync Server 2010? How would you whittle their access down using custom cmdlet assignment in 2013?