Role-based administration: The advanced case of no read resource rights in any collection

ProblemRBAThis week a pure ConfigMgr post and I have to admit that it’s been a long time since the last. This blog post will be about the role-based administration model and a really specific issue that I ran in to. This post will contain the scenario, the problem and a PowerShell script to get the complete solution.

Scenario

CollectionsRBALets start with a short description of the scenario that I’m dealing with. The environment has a lot of different administrators, all with different collections of devices that they’re managing. As an example of the structure see the screenshot on the right that shows different collection structures that are limited to the All Systems collections. In this example every administrator would be limited to their own top-level collection and, by that, automatically inherit permissions to the collections limited to that collection.

Problem

There is no problem with a collection structure like this, in fact the role-based administration model is build for structures like this. However, the problem that we were suddenly seeing was that administrators were not able to remove or edit collection membership rules of some collections that were limited to their top-level collection. Looking at the same scenario we were seeing that an administrator that was limited to the PTCLOUD_Level 2 collection was not able to edit the collection membership rules of the PTCLOUD_Level 2.1 collection. The very cryptic error message of User \”PTCLOUD\\lvanderwoude\” has no read resource rights in any collection for this ResourceID”; would show.

After digging in to this I suddenly noticed that for some reason the PTCLOUD_Level 2.1 collection contained a direct membership rule of a device that did not exist in the PTCLOUD_Level 2 collection. That can happen when an administrator with permissions on a level higher added that direct membership rule.

Solution

The solution for this problem is easy, simply remove that direct membership rule, with an administrator with permissions on a level higher, and everything will work as designed again. However, when that collection has a lot of direct membership rules it might be hard to determine which direct membership rule is causing the problem. That’s why I created a small, but effective, PowerShell script. Let’s quickly go through the highlights of the script.

Step 1: Get the required information

The first step that I need is to get information. I need to get the resources that the administrator has permissions to, which means the resources in the top-level collection, and I need the collection membership rules of the problematic collection. Keep in mind that I need the collection membership rules and not the collection members. That’s a big difference. To get the required information I used the Get-CMDevice and the Get-CMDeviceCollection cmdlets.

$AllResourceIDs = (Get-CMDevice ` -CollectionName $TopCollection).ResourceId $ProblemCollectionRules = (Get-CMDeviceCollection ` -Name $ProblemCollection).CollectionRules

Step 2: Get the device direct membership rules

The second step that I need to do is to filter the collection membership rules of the problematic collection. In this case I’m only interested in the direct membership rules for devices. To filter that information I looked for the collection membership rules with the ResourceClassName of SMS_R_System.

foreach ($ProblemCollectionRule in $ProblemCollectionRules) { if ($ProblemCollectionRule.ResourceClassName -eq "SMS_R_System") { $DirectResourceIDs += $ProblemCollectionRule.ResourceID } }

Step 3: Compare the two lists with resources

The third step that I need to do is to compare the two lists with resources that I created. To compare the two lists I used the Compare-Object cmdlet and to eventually get a readable device name I went back to the Get-CMDevice cmdlet.

$ResultList = Compare-Object $AllResourceIDs $DirectResourceIDs if ($ResultList.SideIndicator -eq "=>") { Write-Output (Get-CMDevice -ResourceId $ResultList.InputObject).Name }

Step 4: Final notes

The fourth and last step is more about some notes for completion. To use the above lines of code, make sure to import the ConfigurationManager module and make sure to provide the following variables. Keep in mind that I’ve set the values to match my example.

$AllResourceIDs = @() $DirectResourceIDs = @() $TopCollection = "PTCLOUD_Level 2" $ProblemCollection = "PTCLOUD_Level 2.1"

2 thoughts on “Role-based administration: The advanced case of no read resource rights in any collection

  1. Can’t thank you enough!

    I had a delegated admin come to me with this exact complaint. I searched and searched and stumbled upon this blog post. Worked like a charm!

    I had a bit of a stumble with the compare portion of the powershell script, but was able to view the results in $ResultsList to find the offender.

Leave a Comment