Implementing Role Based Access Control (RBAC) with ConfigMgr Part 1 - Basic Security Roles

Part 1 - Implementing RBAC with ConfigMgr - Basic Security Roles
Part 2 - Implementing RBAC with ConfigMgr - Security Scopes [COMING SOON]

Part 3 - Implementing RBAC with ConfigMgr - Multiple Regions [COMING SOON]

Introduction

ConfigMgr is a very powerful tool, it can be used to refresh hundreds of computers with the latest operating system, deploy patches to servers and trigger reboots, provide remote access for service desk staff, and deploy applications across large environments. Which is why having the appropriate access controls in place and adhering to the principle of least privilege, is paramount.

Over the course of these blog posts I'll be providing guidance on how to implement RBAC at a basic level, demonstrating the effects of RBAC, and outlining a more complex scenario involving multiple administrative regions.

I'm going to make the assumption you've read the Microsoft doc surrounding RBAC in ConfigMgr so we can jump straight into configuring. 

Scenario

The requirements here are simple, users who access ConfigMgr need to be granted access based on their role within the organisation. The following organisational roles need to be catered for:

• ConfigMgr admins - Responsible for ConfigMgr operations, day to day tasks require full control of all objects.
• Server admins - Members of the server team responsible for maintaining Windows servers.
• Desktop admins - Members of the desktop team responsible for maintaining Windows desktops.
• Service desk admins - Support the end user environment and require limited functionality within ConfigMgr.
• Security auditors - Responsible for auditing organisational platforms, read only to all objects is sufficient.

Collection Limiting

You can skip to the implement section to get going, but one important thing to note is the distinction between server and desktop admins; both groups of admins should only be able to see devices relating to their role, i.e. server admins can only see servers, desktop admins only able to see desktops. Depending on the maturity of your ConfigMgr implementation, this may require a substantial amount of re-engineering.

To create this split, each admin group needs to be scoped to a device collection containing all servers or all workstations depending on role. Easy right? 

When implementing in a fresh environment maybe, however, the device collection used to scope needs to become the parent device collection for all device collections you want the admins to see.

For example, you have the following security groups and associated device collection scoping:

Server admins - Scoped to "Windows Servers" device collection
Desktop admins - Scoped to "Windows Desktops" device collection

The following custom device collections have been created with the limiting collection in brackets:

Windows 2016 Servers (Windows Servers)
*Deploy VMWare Tools (All Desktop and Server Clients)
Windows 10 Desktops (Windows Desktops)
*Deploy O365 ProPlus (All Desktop and Server Clients)

Neither a server admin or a desktop admin would be able to see the device collections highlighted with *.

To rectify this, simply change the limiting collection on both highlighted device collections. This can either directly reference the scoping collection or a "child" device collection. E.g.:

Windows 2016 Servers (Windows Servers)
Deploy VMWare Tools (Windows Servers)
Windows 10 Desktops (Windows Desktops)
Deploy O365 ProPlus (Windows Desktops)

You'll need to review the device collections in your environment and plan ahead for this.

Implement

Prerequisite: Import these operational device collections provided by Benoit Lecours.

1. Create device collection hierarchy

a. Create a new device collection folder called 'RBAC Collections' containing all RBAC related collections. For this scenario we only need two.

b. Create the following device collections in the RBAC Collections folder. Apply an incremental or regular collection evaluation schedule and include the device collections shown (from TechNet import).

(You'll also need to make sure the operational collections used above are set to incremental or a regular schedule)

2. Create Active Directory security groups

Create the following security groups in Active Directory

3. Add security groups to ConfigMgr security

a. In the ConfigMgr console, browse to Administration > Security > Administrative Users and hit Add User or Group.

b Add each ConfigMgr AD security group as outlined in the images below, take note of the assigned security scopes and collections for each:

4. Update limiting collections

Change the limiting device collection on collections you identified as needing to be scoped to either desktops or servers. This will vary between environments so I can't offer much more guidance here.

In the past, this PowerShell helped me bulk update limiting collections. 

Validate

At this point you should be able to add users into your ConfigMgr AD security groups and the console will be presented in a way which suits their role.

As an example, here is what the console looks like for a user with the service desk admin role. A very cut down view.

With fewer options available at the device level. Enough for service desk staff.

Conclusion

Hopefully this has provided an insight into the RBAC capabilities within ConfigMgr. This is just a basic example of how it can be used but it should satisfy most scenarios where ConfigMgr is used across multiple teams. Part 2 and 3 coming soon...