This post is an attempt to clear up some of the confusion regarding the difference between the RTC groups and the Cs groups (also known as the RBAC groups) within Skype for Business. These security group types vary in some important ways and have implications for how administrative privileges need to be setup.
Thanks to the confusion around the topic, a lot of people end up granting administrators the CsAdministrator, RTCUniversalServerAdmins, and RTCUniversalUserAdmins roles.
Part of this confusion comes from the fact that the roles seem to be duplicates of each other. Let’s compare some of the administrative roles:
The three administrative RTC groups are:
- RTCUniversalServerAdmins: Allows members to manage server and pool settings, including all server roles, global settings, and users.
- RTCUniversalUserAdmins: Allows members to manage user settings and move users from one server or pool to another.
- RTCUniversalReadOnlyAdmins: Allows members to read server, pool, and user settings.
And some comparable Cs groups:
- CsServerAdministrator: Can manage, monitor, and troubleshoot servers and services. Can prevent new connections to servers, stop and start services, and apply software updates. Cannot make changes with global configuration impact.
- CsUserAdministrator: Can enable and disable users for Lync Server, move users and assign existing policies to users. Cannot modify policies.
- CsViewOnlyAdministrator: Can view the deployment, including user and server information, in order to monitor deployment health.
- CsAdministrator: Can perform all administrative tasks and modify all settings, including creating roles and assigning users to roles. Can expand a deployment by adding new sites, pools, and services
Given the similarities, it might actually seem like you could choose one a method of granting an administrator either RTC membership OR Cs membership.
This is not the case and I’ll explain why.
Cs Groups Rely on RTC Groups
Some people mistakenly think that RTC groups are legacy and RBAC rules are the newer way to grant permissions. While it’s true that RBAC roles were added in 2010 and provided a new and flexible way to split up administrative capabilities, it’s not nearly that straightforward.
One major difference is that RTC groups are everywhere within a deployment, such as special permissions on AD objects, folder permissions, SQL permissions, CMS replication, topology changes, and of course, administration. These groups are critical to Skype for Business services running.
Cs groups on the other hand are purely used for administration and are not really found anywhere in a deployment aside from within the OU where they are created.
This is because the Cs groups do not actually have permission to anything themselves. Instead, the Cs groups are used through the Cs Management Web Service. This service checks the RBAC roles which the user account is a member of, checks the cmdlets that are allowed by these roles, and then runs the commands under the SfB server computer account.
These local computer accounts are able to execute these commands because they are themselves members of certain RTC security groups which do have all of the correct permissions. (there’s a great explanation of this process in this book)
Without the RTC groups, the RBAC roles actually don’t do anything.
Local vs Remote Administration
Now when you look at the Technet article on RBAC, you will see an interesting note at the top:
“RBAC restrictions work only on administrators working remotely, using either the Lync Server Control Panel or Lync Server Management Shell. A user sitting at a server running Lync Server is not restricted by RBAC. Therefore, physical security of your Lync Server is important to preserve RBAC restrictions.”
That might seem like a helpful statement but the ambiguity of it actually makes things even more confusing. Let’s check out a handful of scenarios which demonstrate how weird this is.
I made a user named Tom Jensen. He is only a member of one administrative security group: CsAdministrator. Let’s see what type of access this actually gets the user.
Remote Control Panel
If I open up a browser and go to the control panel remotely I will be able to login no problem. This is the most straightforward scenario and is the behavior I would expect. It is consistent with the role’s description and with the statement that these roles are for remote use only.
Local Control Panel
Ok — this one is tricky. Remember the statement about RBAC restrictions only applying to remote connections? Well opening the SfB Control panel is essentially a remote connection. You get directed to internal web services which points you to a random FE server and ultimately gets you to the Cs Management Web Service.
So yes, locally on the server you will be able to use your CsAdministrator account to launch the control panel and perform administration. However, it is not enough to ONLY grant the user that RBAC role as it does not give them rights to get login to the server.
This means that the user must be granted the CsAdministrator role AND be granted permission to login to the FE server in the first place.
Local Powershell
This one is pretty straight forward as well. As we would expect, you will not be able to perform any administration whatsoever via Powershell while on a FE server with just CsAdministrator. You will see an error like this:
Cannot open database “xds” requested by the login. The login failed.
Unlike with the Skype Control Panel, having the ability to login to the server in conjunction with the CsAdministrator role still will not allow you to run commands.
Remote Powershell
Now above it did say “RBAC restrictions work only on administrators working remotely, using either the Lync Server Control Panel or Lync Server Management Shell.”
So should we expect this to work? Let’s try. First a normal remote Powershell session:
Same error as a local Powershell session. What about a remote Skype Management Shell session?
Same error as before. What gives?
First of all, the Management Shell and Powershell are the same thing so that won’t make a difference. Second, Powershell remoting is still running the commands on the remote server. It is the almost identical to sitting locally on the server and trying to run Powershell commands.
It still is not connecting to the Cs Management Web Service and therefore RBAC membership is completely useless.
And just like with local Powershell, the ability to login to the server in conjunction with the CsAdministrator role still will not allow you to run commands.
Alternative Powershell Remoting Session
The only way to use Powershell with a pure RBAC role such as CsAdministrator is to connect using a special ConnectionURI. Connecting in this way is actually just a connection to the Cs Management Web Service.
I’ll open Powershell as this user with CsAdministrator and run the following command:
New-PSSession -ConnectionUri https://fepool01.mhickok.me/ocspowershell -Credential (Get-Credential)
The format is similar to a normal remote Powershell session, however you change the connection type to ConnectionURI and enter the value of https://poolname/ocspowershell.
Note that you need to do -Credential even if you are running Powershell as the user which you are wanting to connect with. You ALWAYS need to provide it.
And as you can see, the connection is to the pool rather than to an individual server. Now running the same command as before:
And there we have it — we can now run any command which is allowed by the CsAdministrator role (more on this later).
Why RBAC Groups Are Still Not Enough
Ok, so this proves it — RBAC is great and is how we should handle administration.
Not exactly.
RBAC groups do have their advantages:
- Allows you to scope administration to specific OUs or to sites
- Provides a lot of pre-built roles which will be sufficient for many people
- You can customize the roles using these templates and allow exactly the right cmdlets
- Encourages people to connect to the server remotely without starting an RDP session to a FE server
While these groups work well for groups like Help Desks, RBAC roles by themselves are not sufficient to manage a Skype for Business site.
You need Powershell to manage SfB. There is no way around that. Let’s say you want to modify a Common Area Phone. With a CsAdministrator only role you need connect using the ConnectionURI method as shown above. But that is not a normal Powershell session.
There are severe limitations. Let’s say you want to get the number of users. You would run something like (Get-CsUsers).Count
“Property references are not allowed in restricted language mode”
That’s right. You can’t invoke methods or access properties.
How about something as simple as a | measure statement
Nope, that doesn’t work either because you cannot use any alias (you need to do measure-object in this case). And of course you can’t do things like Get-Process, Get-Service (you can do Get-CsWindowsService), output to a CSV or HTML, and many other things you probably will need to do.
There is a very specific list of commands that each of these Cs groups can execute, and even the most privileged Cs group has missing cmdlets that will prohibit you from doing meaningful troubleshooting.
And sure, you can add additional cmdlets to each Cs group you create. But this adds a lot of overhead and administrative time.
But even if you add every cmdlet you can think of, the other limitations (no pipeline or tab-complete) still make this too difficult.
Who Cares?
You might be wondering why any of this matters. It matters because you have to use Powershell for many things. And when the Powershell experience is so awful with the RBAC groups it becomes a problem.
The obvious solution is to just provide the administrators with RTC group membership as well. The problem with this approach is that there is no easy way to scope the RTC groups.
If you have an administrator who should only have access to a single site within your deployment, you need to use the RBAC groups to limit access. However, then the administrator is limited to using the special Powershell session.
Right now there is no easy solution to this problem (as far as I can tell). You really need to grant both RTC and Cs group membership to properly administer an environment and if you need to have an admin who needs to administer a single site and use Powershell, he’s going to have a bad time.
wow, thanks for the article, this is exactly what I’m looking for.
we are having a problem, where we getting SQL errors logged reporting helpdesk Admins are getting denied on xds database. ONLY when they open skype control panel on a management server where administration tool is installed.
If they open from a browser from their own computer, error doesn’t get logged.
So this is because they are only csuseradministrators.
looking from your article, if we want to make that problem go away, we would have to give them RDP access to all FE servers?
or can we just add them to rtcuniversaluseradmins group?
Also, which RTC group we can add people so they can only manage setting up commonareaphones remotly?
we try to give them as limited access as possible.
Thanks for your help.
LikeLike
Hey Roger, glad it was helpful.
I actually can’t explain the behavior you described. When you launch the control panel, it is going to your internal web services and then going to the SE server or being load balanced between your front ends to hit the management web service. That means the control panel is never really local, it’s always remote and will always respect the restrictions of the RBAC roles (the Cs* groups). This means you should have the same experience regardless of where you are connecting to the control panel from.
I would be curious to see exactly where in the control panel you are seeing that error.
As for common area phones, that gets a bit tricky. The CsUserAdministrator role is sufficient for managing common area phones, but this must be done using the special remote Powershell session I showed in the article (using the connectionURI). If you don’t want to be limited by that limited Powershell session, you can grant them RTCUniversalUserAdmins membership so that they can connect to a front end via remote Powershell or RDP into the server for the Powershell session.
Keep in mind, depending on how locked down your AD is and where the common area phone OU is located, you may need to change permissions on the OU. You can do that with the Grant-CsOUPermission cmdlet and you would use ‘Device’ as the object type (CAPs are Contacts in AD, not Device objects, so this is confusing).
So in my case, I had to run the command: Grant-CsOUPermission -OU “OU=Common Area Phones,OU=mhickok,DC=mhickok,DC=me” -ObjectType Device
With that command run, any of your CsUserAdministrator members will be able to manage and add CAPs using connectionURI method as long as that is the OU where the phones will reside. If they need to add or manage phones in a different OU you would need to run that same command against the other OU.
Best
LikeLike
What RTC stands for ?
LikeLike
Real Time Communications
LikeLike
Thank you for the very well laid out article. In our SfB2015 installation we just started getting the xds errors for accounts that are members of both CS and RTC groups. One of the account that is getting the errors is the account used to install our SfB installation. I can start a PS session and log into the control panel however once there i can see any users or run commands like get-csuser. Nothing has change in our setup that I am aware of so I dont understand why the error showed up. I will check the SQL server permissions next. Any ideas?
LikeLike
Disregard my above comment. DB servers are in Always on Availability and the servers had failed over. Failed over the DB servers and all is well.
LikeLiked by 1 person
Glad to hear it!
LikeLike