Security and filtering

Now the most complex part of the job!

Of course, it works as-is, but what if your tool works only on a device that has a client and a user select a non-client one?

And what if one user is not allowed to modify a parameter your tool has to change?

It will be frustrating for him to see the option but received an error message as soon as he tries to use it. Especially if you build a complex tool that requires a lot of input that will finally fail at the last step.

The first case is quite simple to cover. Just add 2 lines to your XML file:

<MatchPattern>True</MatchPattern>
<MatchValueToTest>##SUB:IsClient##</MatchValueToTest>

Now your menu item will only be available if the device selected has his “IsClient” parameter sets to “True”, otherwise it will be greyed out!

Debug view is of good help to determine which properties you can rely on.

Attention! You can’t rely on all properties with this method! For example, you can’t rely safely on the “IsActive” or “ClientActiveStatus” properties as they are available only if the device is a client of your SCCM infrastructure. If you set a filter on one of these properties and the user selects a device that is not a client, the SCCM console will simply crash trying to check a value of an inexistent property!

To handle this, you have to create a new function in your assembly to check the validity of the device instead, Like this one:

public static bool checkIfIsActive(object sender, ScopeNode scopeNode, ActionDescription action, ResultObjectBase resultObject)
{
   int isActive = 0;
   try
   {
      isActive = ((IResultObject)resultObject).Properties["ClientActiveStatus"].IntegerValue;
   }
   catch(NullReferenceException)
   {
      return false;
   }

   if (isActive == 1)
   {
      return true;
   }else
   {
      return false;
   }
}

Then you can use another way to filter by calling your function and grey out your menu if it returns a “false” value. Your XML file will look close to this:

<ActionDescription Class="AssemblyType" DisplayName="show collections" MnemonicDisplayName="show collections" Description="Shows the list of collection IDs this device is member of">
   <ImagesDescription>
      <ResourceAssembly>
         <Assembly>C:\Program Files (x86)\myCompany\myextension\MyFirstExtension.dll</Assembly>
         <Type>MyFirstExtension.Properties.Resources.resources</Type>
      </ResourceAssembly>
      <ImageResourceName>collinfo</ImageResourceName>
   </ImagesDescription>
   <ShowOn>
      <string>ContextMenu</string>
      <string>DefaultHomeTab</string>
   </ShowOn>
   <ActionAssembly>
      <Assembly>C:\Program Files (x86)\myCompany\myextension\MyFirstExtension.dll</Assembly>
      <Type>MyFirstExtension.DeviceTools</Type>
      <Method>deviceCollections</Method>
   </ActionAssembly>
   <ActionStateAssembly>
      <Assembly>C:\Program Files (x86)\myCompany\myextension\MyFirstExtension.dll</Assembly>
      <Type>MyFirstExtension.DeviceTools</Type>
      <Method>checkIfIsActive</Method>
   </ActionStateAssembly>
</ActionDescription>

Now just imagine that you want to propose this tool to users that are allowed to add to modify boundaries. Sound’s crazy? Yes, I know! But that’s just an example.

Explanation In the SDK wasn’t so clear to me and gave me headaches for several hours. This is what I finally understood. Don’t hesitate to let me know if I am wrong.

There are two ways to place access permissions on your tool: ClassPermissions and InstancePermissions.

Concretely, if you limit access to a “collection tool” for those who have read permission on SMS_Collection using “InstancePermissions”, it will be available to users who got the rights specifically on the currently selected object.

On the other hand, using “ClassPermissions” will make this tool available if the user has the “generic” Read permission on collections.

Not clear? Here are some use-cases.

1. Target: a collection.
   Required rights: read collection.
   There you can rely on “InstancePermissions”. Collections are instances of the securable class SMS_Collection, then you can rely on Instance’s permission.
2. Target: a collection.
   Required rights: read boundarygroups (why not?) It seems obvious that you can’t rely on “InstancePermissions” because you’re working on a SMS_Collection instance, not on a boundarygroup instance. So you must use “ClassPermissions” instead.
3. Target: a workstation.
   Required rights: modify workstation settings to change variables values and add devices to a collection.
   This is the trickiest one ^^ ! No other choice than using “ClassPermissions” because a workstation is an instance of SMS_R_SYSTEM Class which is not one of the securable class! The required modify permission is placed on the SMS_Collection Class and is named “Modify Resource”

Hope this will make things clearer to you!

Sadly, the SDK provides only information about permission bits regarding the SMS_Collection class. Fortunately, all information can be found in the SCCM database with a simple query.

As I’m a nice guy, you will find just here an XLS sheet with the information extracted from an SCCM 2012 R2 database and the query I ran to get them.

RCT right mgmt (xlsx)

It’s time to use all that.

If you just copy-paste the code sample from the SDK you will face the same issue as I did: it doesn’t work! There is a missing information: InstancePermission and ClassPermissions must be surrounded by a <SecurityConfiguration> tag.

Here are two samples for use-case 1 and 3:

Case 1:

<SecurityConfiguration>
   <InstancePermissions>
      <SecurityFlagsDetailDescription BitName="Read" BitValue="1" DependsOn="1" />
   </InstancePermissions>
</SecurityConfiguration>

Case 3:

<SecurityConfiguration>
   <ClassPermissions>
      <ActionSecurityDescription ClassObject="SMS_Collection" RequiredPermissions="2" />
      <ActionSecurityDescription ClassObject="SMS_Collection" RequiredPermissions="128" />
   </ClassPermissions>
</SecurityConfiguration>

Of course, you can mix ClassPermission and InstancePermission in a single SecurityConfiguration section.