RTC vs Cs Groups in Skype for Business (and some issues)

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.