Save SCCM from your own Sysadmin: Using Security Scopes

Revision Control in SCCM is not easy, but it does work extremely well if you are willing to put some effort into it.

My personal use case scenario for for this is attaching security scopes to Task Sequences for the purpose of version control.

This approach is a bit ham-fisted, but it requires the least privileges to be given to the ‘Operator’ and the least amount of training–which in turns allows more time for writing blogs. Most importantly it prevents your helpdesk guy who somehow has admin access to SCCM from deleting all the things.

One of the strategies you can use to keep track of changes to your Task Sequences is to force your admins to make a copy of the Task Sequence every time they want to alter it.

Four extra steps you can perform to enforce this behavior:

1. Create and attach a new, more restrictive Security Scope to the TS
2. Remove ‘ALL’ Security Scope from all SCCM admin accounts (except your own)
3. Remove ‘Default’ Security Scope from Task Sequences you are trying to protect
4. Optional: Remove admins’ ability to alter security scopes (except you, naturally)

What we’re doing here is preventing an admin from making ‘improvements’ to a production Task Sequence without testing it.

Step 1: Create a Security Scope

Pretty basic, it’s a single click.

Step 2: Remove ‘All’ Permission from User Accounts / Groups

Be default the first account that installs SCCM gets the ‘All’ Security Scope added to it. Most organizations just add a single Security Group called ‘SCCM Admins’ which inherits the ‘All’ Security Scope. We need to change this.

Definition of Scopes:

ALL – All current permissions and future permissions. Does NOT respect Security Scopes.

DEFAULT –As above except it DOES Respect Security Scopes. New objects receive ‘Default’ scope.

Steps to Remove ‘All’ and apply our new scope:

1. In Administration, Security, edit the SCCM Security Group
2. Edit ‘Security Scopes’
3. Remove ‘All’ Scope
4. Add ‘Default’ Scope
5. OPTIONAL: Add ‘PEI-Backups’ (in this example I am giving myself access to delete Task Sequences)

Step 3: Apply Security Scope to Task Sequences

In my example we are only preventing the ‘Backup’ task sequences from being modified, deleted, or otherwise ‘improved’. Best practice would be to apply these changes to production Task Sequences but this will make your phone ring. Either approach allows you to restore a TS within seconds and without having to yourself make a call to the backup admin.

In the screenshot above we removed ‘Default’ scope. This step is mandatory, otherise default permissions will not be removed.

Step 4: Remove Permissions to alter Security Scopes from all (other) admins

So far in steps 1-3 we have completely removed the permissions for non-authorized users to delete or modify Task Sequences. What we have NOT done is disallow access to altering these permissions.

This is acutally by design. As it stands right now no user, other than yourself, can delete or modify the highlighted Task Sequences but any admin worth their salt can undo changes we made in Step 3 and re-gain access.

If this is not desirable, you will need to modify copy and reassign ‘Full Administrator’ role to all users / groups (except yourself) and remove the ‘Modify Security Scopes’ permission while you do it.

Final Notes and Task Sequence Update Process

One thing we did not cover yet is what is an admin to do with an old task sequence after he created and deployed a new one? Since we removed their ability to delete these, how do they move forward?

Here is a simple workflow your admin goes through in order to update a Task Sequence in this scenario:

1. Copy ProductionTaskSequenceV1
2. Make Changes in ProductionTaskSequenceV2
3. Deploy ProductionTaskSequenceV2
4. Delete deployment of ProductionTaskSequenceV1

This is the final step. Instead of Deleting a task sequence which they now do not have permission to, the admin should delete the Deployment of this task sequence and preserve the original as a backup.

JacobR, PEI