Share via

Remove a User from an RBAC Group

  • Article

OK, so you assigned Ken Myer the CsArchivingAdministrator role, one of the Role-Based Access Control (RBAC) groups that is automatically created when you install Microsoft Lync Server 2010.

Note. If you have no idea what a Role-Based Access Control group is then you should take a peek at the article A Brief Introduction to RBAC .

 
Now, however, you’re having second thoughts: you’re not so sure Ken has what it takes to be a Lync Server Archiving Administrator after all. You’d like to take back the CsArchivingAdministrator role you assigned to Ken Myer, and you’d do so, too. Except for one thing: once assigned, how do you unassign an RBAC role?

 
That’s a good question, and here’s your answer: without much effort whatsoever. As you probably know, RBAC roles are assigned by membership in the appropriate Active Directory security group. Ken is an Archiving Administrator because he has been assigned to the CsArchivingAdministrator group. If you don’t want Ken to be an Archiving Administrator then just remove him from the CsArchivingAdministrator group. It’s that easy.

 
Admittedly, you can remove a user from an Active Directory group by using Active Directory Users and Computers. But you’re right: in these high-tech days, Active Directory Users and Computers does seem a little old-fashioned, doesn’t it? If you want to be cool (and who doesn’t want to be cool?) you can also remove a user from a group by running the following Windows PowerShell script:

 
$x = $ErrorActionPreference
$ErrorActionPreference = "SilentlyContinue"

$strFilter = "(&(objectCategory=Group)(SamAccountName=" + $args[0] +"))"

$objDomain = New-Object System.DirectoryServices.DirectoryEntry

$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $objDomain
$objSearcher.Filter = $strFilter
$objSearcher.SearchScope = "Subtree"

$colProplist = "distinguishedName"
foreach ($i in $colPropList)
    {[void] $objSearcher.PropertiesToLoad.Add($i)}

$colResults = $objSearcher.FindAll()

foreach ($objResult in $colResults)
    {$groupDN = $objResult.Path}

$userDN = (Get-CsUser -Identity $args[1]).DistinguishedName
$user = [ADSI] "LDAP://$userDN"

$group = [ADSI] $groupDN

$group.Remove($user.PsBase.Path)

$ErrorActionPreference = $x

 
To be perfectly honest (and we always strive to be perfect, especially when it comes to honesty) this script is perhaps a little more complicated than it needs to be (which we’ll explain in a moment). When you run this script, you need to pass in two pieces of information: the name of the RBAC role the user should be removed from, and the Identity of the user. (This can be any of the standard user Identities used with the CsUser and CsAdUser cmdlets; here, we’ve opted to use the person’s Active Directory display name.) For example, and assuming we named our script C:\Scripts\Remove-RoleAssignment.ps1, we need to run a command similar to this:

 
C:\Scripts\Remove-RoleAssignment.ps1 "CsArchivingAdministrator" "Ken Myer"

 
The first thing the script does is search Active Directory for a security group with the SamAccountName CsArchivingAdministrator. To be honest, that’s the part that might be overkill. In the current incarnation of Lync Server, all the security groups used for RBAC roles must be housed in the Users containers; because of that, we could have hardwired the script to simply look for the group in the Users container. So why didn’t we do that? Three reasons:

  1. Future versions of Lync Server might allow you to put these security groups anywhere you want.
  2. The less we hardwire the less you have to do in order to make this script work in your organization.
  3. We already had some code for searching Active Directory, and it seemed a shame to let it go to waste.

 

At any rate, after locating the group, the script binds to the user account and then uses this somewhat-cryptic looking line of code to remove the user from the group (and, not coincidentally, unassign the RBAC role):

 
$group.Remove($user.PsBase.Path)

 
As soon as that line finishes executing, Ken Myer’s days as an Archiving Administrator will have come to an end. But, then again, nothing lasts forever, right?