A Brief Introduction to Role-Based Access Control – Part 1
“If you want something done right, do it yourself.”
That, by the way, is excellent advice … unless, of course, you happen to be a Microsoft Lync Server 2010 administrator charged with managing thousands of users and multiple sites. After all, in a case like that, doing it yourself (right or wrong) might prove to be a bit … challenging ….
To say the least.
Of course, in previous versions of the software (e.g., Office Communications Server 2007 R2) you might have found it easier to just go ahead and do it yourself rather than trying to delegate administrative control of the product. With Office Communications Server you could easily make someone an all-powerful, full-fledged OCS administrator; unfortunately, it wasn’t quite as easy to give someone the rights to manage just Enterprise Voice, or just the users with accounts in a given OU, or just the – well, you get the idea. Delegating control wasn’t very easy, it wasn’t very granular, and – to be honest – it was probably more trouble than it was worth.
Which is why many administrators just ended up doing it themselves.
But now we have a brand-new version of Lync Server. Is delegation of control still a major hassle in Lync Server 2010? Apparently you haven’t heard of RBAC, have you?
Welcome to RBAC
Actually, you probably have heard of RBAC: Role-Based Access Control. Role-Based Access Control (which is used in other Microsoft products, including Active Directory and Microsoft Exchange) is the successor to the ACLs (access control lists) that we all know and … love …. With ACLs you had to assign users or groups cryptic permissions like readDLMemSubmitPermsBL, and you had to deal with permission inheritance from container to container, and you had to deal with Allow permissions vs. Deny permissions, and you had to – well, let’s just say that ACLs weren’t exactly a barrel of laughs. In fact, using ACLs as a way to delegate permissions was just plain hard.
Thanks to RBAC, however, it’s easy to delegate permissions in Lync Server 2010, and to delegate very specific permissions at that. With RBAC, your ability to carry out administrative tasks depends on the RBAC role (or roles) you have been assigned. For example, suppose there was an RBAC role that allowed you to manage archiving configuration settings and archiving policies, but only allowed you to manage archiving configuration settings and archiving policies. (As a matter of fact, there is such a role in Lync Server 2010: CsArchivingAdministrator.) Suppose you’ve been assigned that role. Can you create a new archiving policy and then assign that policy to a user? You bet you can; after all, that’s the whole idea. OK, so can you create a new dial plan and assign that to a user? Nope; that’s because the CsArchivingAdministrator role is limited to archiving-related activities, and users assigned that role can’t do anything but archiving-related activities: no creating and assigning dial plans; no disabling user accounts; no managing Response Group queues; etc. Do you need someone to help manage archiving activities, but you don’t want this same someone to be an all-powerful, full-fledged administrator? That’s fine: just assign them the CsArchivingAdministrator role.
It really is just that easy.
But wait: it gets even better. When you install Microsoft Lync Server 2010 the system automatically creates a number of RBAC roles for you (for example, CsArchivingAdministrator). You say none of those roles is exactly what you had in mind? That’s OK: Lync Server lets you create your own custom RBAC roles. Furthermore, you can also “scope” these roles any way you want. For example, you can limit user management activities to user accounts found in a specific OU; likewise, you can limit configuration activities to a specific site. The sky, as they say, is the limit.
Get the idea? If not, don’t worry: in the next section of this article we’ll explain a little more about RBAC and how it works.
A little more about how RBAC and how it works
OK, we admit it: sometimes software companies (not us, of course) implement features in ways that might make sense to, say, a Klingon, but don’t make any sense at all to human beings. But good news, fellow humans: RBAC isn’t one of those features. Instead, Lync Server’s implementation is pretty darn simple and – dare we say? – easy to understand. As our many Klingon readers would say, “MajQa'.”
Note. Which, as you probably know, is Klingon for “well-done.” Just like “Hab SoSlI' Quch!” is Klingon for “Your mother has a smooth forehead.” Hey, you can look it up .
So how does RBAC work? Well, to begin with, RBAC determines administrative privileges through the use of RBAC roles. When you install Microsoft Lync Server 2010 a number of these RBAC roles are automatically created for you; these so-called “standard roles” include the following:
- CsAdministrator
- CsVoiceAdministrator
- CsUserAdministrator
- CsResponseGroupAdministrator
- CsLocationAdministrator
- CsArchivingAdministrator
- CsViewOnlyAdministrator
- CsServerAdministrator
- CsHelpDesk
In turn, each role is assigned a number of cmdlets; for example, the CsUserAdministrator role is assigned these cmdlets:
- Disable-CsUser
- Enable-CsUser
- Get-CsAdUser
- Get-CsUser
- Get-CsUserClusterInfo
- Move-CsUser
- Move-CsLegacyUser
- Set-CsUser
- Grant-CsClientPolicy
- Grant-CsClientVersionPolicy
- Grant-CsConferencingPolicy
- Grant-CsDialPlan
- Grant-CsExternalAccessPolicy
- Grant-CsHostedVoicemailPolicy
- Grant-CsLocationPolicy
- Grant-CsPinPolicy
- Grant-CsVoicePolicy
- Get-CsArchivingPolicy
- Get-CsClientPolicy
- Get-CsClientVersionPolicy
- Get-CsConferencingPolicy
- Get-CsExternalAccessPolicy
- Get-CsHostedVoicemailPolicy
- Get-CsLocationPolicy
- Get-CsPinPolicy
- Get-CsVoicePolicy
- Get-CsClientPinInfo
- Unlock-CsClientPin
- Lock-CsClientPin
- Set-CsClientPin
- Get-CsClientVersionConfiguration
- Get-CsDialPlan
- Get-CsSite
- Get-CsComputer
- Get-CsNetworkInterface
- Get-CsPool
- Get-CsService
- Get-CsSipDomain
- Revoke-CsClientCertificate
So do we really care which cmdlets have been assigned to which RBAC roles? Well, we should: these cmdlets represent the only cmdlets that – in this case – a CsUserAdministrator can run. Get-CsDialPlan and Grant-CsDialPlan have been assigned to the CsUserAdministrator role; that means that user administrators can run both of those two cmdlets. So far so good, right?
However, note that New-CsDialPlan, Remove-CsDialPlan, and Set-CsDialPlan have not been assigned to the CsUserAdministrator role. What does that mean? That means that user administrators can get information about dial plans and they can assign (grant) dial plans to users; however, they can’t delete or modify existing dial plans, nor can they create new dial plans. That’s how the system works. When you try to perform an administrative task in Lync Server (either from the Windows PowerShell prompt or from the Lync Server Control Panel), the system checks to see which RBAC roles you have been assigned and, by extension, which cmdlets you’re allowed to run. If you try to run a cmdlet that hasn’t been assigned to your RBAC role, that command will fail.
Period.
And yes, RBAC roles are enforced by the Lync Server Control Panel. After all, each time you issue a command in the Control Panel you’re actually running a PowerShell cmdlet under the covers. (You may not have known that, but it’s true: Control Panel is really just a fancy, easy-to-use way to issue Windows PowerShell commands.)
To show you what we mean, take a look at the Control Panel as accessed by a full-blown Lync Server administrator:
Notice all the available management categories on the left-hand side of the Control Panel? Good. Now, let’s compare that by looking at the Control Panel as accessed by someone who holds the CsLocationAdministrator role:
Why are there so few management categories shown in this picture? That’s easy: because, based on your RBAC role assignments, Control Panel only shows you the items that you’re allowed to manage. Needless to say, a Location administrator simply doesn’t have anywhere near as many administrative privileges as a full administrator.
Cool, huh? We thought so, too.
Of course, that leads to another question: how do you actually assign one of these RBAC roles to a user? If you’re anything like us (a scary thought, in and of itself), you probably stopped reading this article and immediately looked through the complete list of Lync Server cmdlets trying to find one that had a name which sounded vaguely like something you’d use to assign RBAC roles.
However, before you searched through those 500+ cmdlets we should have mentioned one thing: there isn’t a cmdlet that assigns RBAC roles. Why isn’t there a cmdlet that assigns RBAC roles? To tell you the truth, we don’t know. But that’s OK, because – as it turns out – you don’t need a cmdlet to assign RBAC roles. Instead, RBAC roles are assigned based on your membership in an Active Directory security group. What’s that? Based on your membership in any Active Directory security group? Nope: based on your membership in a very specific Active Directory security group. As we noted earlier, when you install Lync Server the setup program automatically creates the following RBAC roles for you:
- CsAdministrator
- CsVoiceAdministrator
- CsUserAdministrator
- CsResponseGroupAdministrator
- CsLocationAdministrator
- CsArchivingAdministrator
- CsViewOnlyAdministrator
- CsServerAdministrator
- CsHelpDesk
Now, here’s a cool little trick: open up Active Directory Users and Computers, click on the Users container, then take a look at the security groups in that container. Tucked away along with all the other accounts in the Users container you should see the following universal security groups:
- CsAdministrator
- CsVoiceAdministrator
- CsUserAdministrator
- CsResponseGroupAdministrator
- CsLocationAdministrator
- CsArchivingAdministrator
- CsViewOnlyAdministrator
- CsServerAdministrator
- CsHelpDesk
Coincidence? Hardly.
Note. Here’s a coincidence for you: Sometime in the 1930s a man named Joseph Figlock was walking down a street in Detroit when a baby fell through a window and landed on him. Joseph broke the baby’s fall, and both Joseph and the baby walked away unharmed. (Well, the baby probably just crawled away. But you know what we mean.) A year later Joseph was walking down the same street when the same baby fell through the same window and landed on him again! Once more, both walked away unharmed. (Being a year older, we’re assuming the baby could now walk.) Now that’s a coincidence!
OK, it’s also – as near as anyone can tell – totally bogus. But as technical writers, we never let the facts get in the way of an important point.
At any rate, and before we were so rudely interrupted (albeit by ourselves) we were about to actually make an important point: the RBAC roles that are assigned to you are based on your membership in an Active Directory security group that has the exact same name as the RBAC role. You say you’re a member of the CsResponseGroupAdministrator security group? Then that also means you’ve been assigned the CsResponseGroupAdministrator RBAC role. If you’re a member of the group then you also hold the corresponding role. If you hold an RBAC role then you must also be a member of the corresponding security group. It’s a simple as that.
And you’re right: MajQa'!
That, by the way, is why you don’t need a cmdlet in order to assign someone an RBAC role; after all, you don’t really assign roles anyway. You want Ken Myer to be a Response Group administrator? That’s fine: open up Active Directory Users and Computers, find the CsResponseGroupAdministrator group and add Ken Myer to the membership list. That’s all you have to do. If you decide that you don’t want Ken to be a Response Group administrator after all then just remove him from CsResponseGroupAdministrator. To be honest, it can’t get much simpler than that.
Note. Yes, yes we know: it’s a Windows PowerShell world, and yet we keep talking about– gasp! – using a graphical user interface tool like Active Directory Users and Computers in order to manipulate RBAC roles and their associated security groups. If you just can’t stand the thought of using a GUI tool, well, take heart: the Microsoft Link Server 2010 Script Warehouse contains a number of scripts related to RBAC, scripts that let you create a new Active Directory security group that can be used for a custom RBAC role, and scripts that let you add and remove members from an RBAC group. But don’t just take our word for it: see for yourself.
Viewing RBAC roles
As we noted earlier, when you install Lync Server you get – absolutely free! – a number of built-in RBAC roles. (You can also create your own custom roles, something we’ll discuss in the forthcoming Part 2 of this series.) How did we know that Lync Server provides you with a number of built-in RBAC roles? Well, for one thing we are experts on Microsoft Lync Server. (Assuming you have a very loose definition of the word “expert.”) For another, we knew about the Get-CsAdminRole cmdlet, the cmdlet that returns information about all your RBAC roles (both the built-in roles and any custom roles you create yourself). To see what we’re talking about, just run this command:
Get-CsAdminRole
In return, you should get back information similar to this for each role:
Cmdlets : {Name=Disable-CSUser, Name=Enable-CSUser, Name=Get-CSAdUser, Name=Get-CSUser...}
ConfigScopes : {Global}
UserScopes : {Global}
SID : S-1-5-21-1573807623-1597889489-1765977225-1142
Identity : CSUserAdministrator
IsStandardRole : True
If you want to see the information for a particular role, just include the –Identity parameter, like so:
Get-CsAdminRole –Identity CsUserAdministrator
Or use the –Filter parameter to use wildcards when returning RBAC roles. For example, suppose you’ve created several custom roles that all include the word Paris in the Identity (ParisVoiceAdministrators; ParisLocationAdministrators; etc.). Here’s how you’d get back information about all those custom roles:
Get-CsAdminRole –Filter "*Paris*"
Etc., etc.
Tip. If you only want information about the built-in roles all you need to do is run the following command, which returns only the RBAC roles where the IsStandardRole property is equal to True ($True):
Get-CsAdminRole | Where-Object {$_.IsStandardRole –eq $True}
To get back information about custom roles you’ve created yourself, just look for cmdlets where the IsStandardRole property is equal to False ($False):
Get-CsAdminRole | Where-Object {$_.IsStandardRole –eq $False}
Viewing the cmdlets associated with an RBAC role
As we just witnessed, calling Get-CsAdminRole shows you all of the RBAC roles configured for use in your organization; included in that information is a list of all the cmdlets associated with those RBAC roles.
Well, sort of. For example, suppose we run the following command, a command that returns information for the RBAC role CsUserAdministrator:
Get-CsAdminRole -Identity CsUserAdministrator
When we run this command, and when we take a look at the data that gets returned, we should see something similar to this:
Cmdlets : {Name=Disable-CSUser, Name=Enable-CSUser, Name=Get-CSAdUser, Name=Get-CSUser...}
ConfigScopes : {Global}
UserScopes : {Global}
SID : S-1-5-21-1573807623-1597889489-1765977225-1142
Identity : CSUserAdministrator
IsStandardRole : True
Take a look at the value for the Cmdlets property. See the dreaded three dots at the end? That means there are more Cmdlets that have been assigned to the CsUserAdministrator role; unfortunately, though, all those cmdlets wouldn’t fit nicely on the screen. Consequently, PowerShell has … helpfully … shown you the first few cmdlets, then used the three dots to indicate that there are additional cmdlets assigned to this role. You can’t see them all.
Grammar note. We seriously doubt that you are wondering what those three dots are called, but on the off-chance that you are wondering what those three dots are called, well, here you go: those three dots are known as an ellipsis. And if you’re now wondering, “Gee, do the authors of this article consider themselves part of the full space ellipsis school or the flush dots ellipsis school ,” well, we happen to be flush dotters. And yes, you will have to pry those flush dots from our cold, dead fingers.
Hey, there are some things in life you just have to take a stand on.
Of course, regardless of whether you’re a full spacer or a flush dotter, the ellipsis can be a bit annoying: most likely you want to see all the cmdlets associated with an RBAC role, not just a handful of those cmdlets. But, hey, relax: there isn’t an ellipsis made that the authors can’t outwit:
Get-CsAdminRole -Identity CsUserAdministrator | Select-Object –ExpandProperty Cmdlets
What we’ve done here is grab all the property values for the CsUserAdministrator role and then pipe that information to the Select-Object cmdlet. From there we use the –ExpandProperty parameter to “expand” the value of the Cmdlets property. What does it mean to expand a property value? That’s an easy one: it just means that PowerShell is going to display all the values contained in that property, and in a nice, easy-to-read format. In other words, we’re going to get back a list of cmdlets that looks like this:
Disable-CsUser
Enable-CsUser
Get-CsAdUser
Get-CsUser
Get-CsUserClusterInfo
Move-CsUser
Move-CsLegacyUser
Set-CsUser
Grant-CsClientPolicy
Grant-CsClientVersionPolicy
Grant-CsConferencingPolicy
Grant-CsDialPlan
Grant-CsExternalAccessPolicy
Grant-CsHostedVoicemailPolicy
Grant-CsLocationPolicy
Grant-CsPinPolicy
Grant-CsVoicePolicy
Get-CsArchivingPolicy
Get-CsClientPolicy
Get-CsClientVersionPolicy
Get-CsConferencingPolicy
Get-CsExternalAccessPolicy
Get-CsHostedVoicemailPolicy
Get-CsLocationPolicy
Get-CsPinPolicy
Get-CsVoicePolicy
Get-CsClientPinInfo
Unlock-CsClientPin
Lock-CsClientPin
Set-CsClientPin
Get-CsClientVersionConfiguration
Get-CsDialPlan
Get-CsSite
Get-CsComputer
Get-CsNetworkInterface
Get-CsPool
Get-CsService
Get-CsSipDomain
Revoke-CsClientCertificate
Like we said: there isn’t an ellipsis made that we can’t outwit.
Well, OK: there isn’t an ellipsis made that Select-Object and the –ExpandProperty parameter can’t outwit.
Viewing RBAC role assignments
If you want to make the best possible use of RBAC you obviously need to know the different roles that are available to you. At the same time, however, it’s equally important to know which roles have been assigned to which users. So how do you know which roles have been assigned to which users? Good question. And a question that has several answers, with some of those answers being a little better than others.
To begin with, keep in mind that the RBAC role (or roles) that are assigned to you are based on your membership in the appropriate Active Directory security group. Are you a member of the CsUserAdministrator security group? Then congratulations: you also hold the CsUserAdministrator RBAC role. Are you a member of a custom Active Directory security group named RedmondVoiceAdministrators, a security group associated with a custom RBAC role named RedmondVoiceAdministrators? Then guess what: you also hold the RedmondVoiceAdministrators RBAC role.
What does that all mean? Well, we’ll get back to that in just a second. In the meantime, let’s see how you can determine all the RBAC roles held by a specific user. How can you determine all the RBAC roles held by a specific user? The best way is to use the Get-CsAdminRoleAssignment cmdlet:
Get-CsAdminRoleAssignment -Identity "kenmyer"
The preceding command is going to return the names of all the RBAC roles held by the user with the SamAccountName kenmyer. And, yes, for better or worse you have to use the SamAccountName as the user identity; passing the user’s display name or SIP address or UPN isn’t going to do the trick:
PS C:\> Get-CsAdminRoleAssignment "Ken Myer"
Get-CsAdminRoleAssignment : User cannot be found in the Active Directory with the SAMAccountName:Ken Myer.
At line:1 char:26
+ Get-CsAdminRoleAssignment <<<< "Ken Myer"
+ CategoryInfo : NotSpecified: (:) [Get-CsAdminRoleAssignment], ADObjectNotFoundException
+ FullyQualifiedErrorId : Microsoft.Rtc.Management.Authorization.ADObjectNotFoundException,Mic
rosoft.Rtc.Management.Authorization.GetOcsRoleAssignmentCmdlet
Of course, it’s theoretically possible that you might not have memorized the SamAccountNames for all your users; for that matter, it’s theoretically possible that you don’t even know what a SamAccountName is. (It’s basically the user’s logon name.) But that’s OK; here’s a tricky little command that does let you retrieve RBAC role assignments using the user’s display name:
Get-CsUser "Ken Myer" | ForEach-Object {Get-CsAdminRoleAssignment –Identity $_.SamAccountName}
What we’re doing here is using the Get-CsUser cmdlet to retrieve all the user account information for the user with the display name Ken Myer. We’re then piping that information to the ForEach-Object cmdlet, and asking ForEach-Object to take each user account passed to it (in this case, that’s just the Ken Myer account) and then call the Get-CsAdminRoleAssignment cmdlet, using the SamAccountName of the object currently in the pipeline ($_.SamAccountName) as the Identity. It’s a tiny bit convoluted, but that’s because Get-CsAdminRoleAssignment doesn’t directly accept pipelined input. And, convoluted or not, it works, which is all we really care about.
OK, that’s one of the good answers we were talking about: as you can see, it’s very easy to retrieve the RBAC roles that have been assigned to a given user. But suppose you want to flip this task on its head, and instead see all the users who have been assigned a given role; for example, what if you’d like to see all the users who have been assigned the CsUserAdministrator role? What’s the answer to that question? Well, that turns out to be one of those answers that isn’t quite as good.
Remember when we took time out to reiterate the fact that RBAC role assignments have a one-to-one correspondence to membership in selected Active Directory groups? We did that because one way to find out which users have been assigned the CsUserAdministrator role is to simply view the membership for the CsUserAdministrator group. That can be done by carrying out the following procedure:
- Open Active Directory Users and Computers.
- Click on the Users container.
- Right-click CsUserAdministrator and then click Properties.
- On the Members tab look at the users who are members of the group.
That works just fine although, admittedly, it’s a bit cumbersome; on top of that, you can’t do any of it from the comfort and security of the Lync Server Management Shell. At this point in time, however, there’s no cmdlet that lets you retrieve all the users who have been assigned a specific RBAC role. Like we said, it’s an answer, and a solution. It just might not be the answer and solution you were hoping for.
Note. But hey, cheer up: while there might not be a cmdlet that can return this information, there is a script that can list all the RBAC roles and all the users who have been assigned those roles. See the article How Do I List All the RBAC Roles and the Users that Hold Those Roles? for more information
Is that all I need to know about RBAC and Microsoft Lync Server 2010?
As a matter of fact it is … unless, of course, you’re interested in creating your own custom RBAC roles (and then, if you change your mind, interested in deleting those custom RBAC roles). For that information, you’re going to have to tune into the exciting conclusion of this two-part series: A Brief Introduction to Role-Based Access Control – Part 2 (coming soon).
We know: the suspense is killing you, isn’t it? In that case, you better drop everything else and go read Part 2. Well, just as soon as we post it, that is.
Comments
Anonymous
July 08, 2010
Excellent post! Looking forward to Part 2.Anonymous
September 26, 2011
More than 1 year has ellapsed, and still no Part2?Anonymous
December 28, 2011
nice Post, but ...still no part 2.. So if I create custom RBAC roles, can I create the corresponding security group and add the members? Does it work the same way as standard roles?Anonymous
June 12, 2014
Pingback from If your looking to ramp on Lync On Premises here are some useful Lync resources well worth investigating