Implementing RBAC in System Center 2012 R2 Service Manager

This blogpost will detail my experiences and insights gained from implementing Role Based Access Control (RBAC) in a System Center 2012 R2 Service Manager environment.

Overview:

After installing Service Manager a couple of so called User Roles are created:

Report User
End User
Read-Only Operator
Activity Implementer
Change Initiator
Incident Resolver
Problem Analyst
Change Manager
Advanced Operator
Author
Workflow
Administrator

In its simplest form you should simply add Active Directory groups to one of the groups above and users member of that group will receive the corresponding rights. Microsoft has outlined what each User Role profile can do in the following article on TechNet: Appendix A – List of User Role Profiles in System Center 2012 – Service Manager – http://technet.microsoft.com/en-us/library/hh495625.aspx

The roles above are scoped Global as mentioned in their description. This means that if you are member of one or more of these roles you can see every CI, task, view, templates etc.. So if you want to authorize users more granulary you have to create custom user roles.

It is possible to include an Active Directory Group into more than one custom user roles, you can for example create an custom user role for incident management and one for change management. If you add the AD group to both, the user in that group will receive the combination of those user roles. This can be handy for example if you have the scenario where incident creators should be able to create change requests, but you also have other groups which should only be able to create change requests.

Warning: The default End User role has too much rights, which causes serious issues when defining RBAC.

As you can see in the List of User Role Profiles overview on TechNet the EndUser role the the right to create Work Items.

After installation the Global End Users role contains NT Authority\Authenticated Users as its member. This is necessary because we want end user to be able to create incidents from the portal and request items from the Service Catalog. As mentioned before though, Microsoft actually gave the End User role too much rights which is if you ask me a design flaw.

Because what happens if we keep these default rights intact when creating a custom user role. The user in that role will receive the rights from its custom user role plus the rights the EndUser has because he is also an Authenticated User.

My advise is to remove NT Authority\Authenticated Users from the default End User role and create a new Customer End User role which doesn’t contain any rights to views, tasks etc..

Creating custom user roles:

Custom User roles are created by creating a new role based on one of the roles provided out of the box, with the exception of the Administrator, Report User and Workflows user role which cannot be used as a basis for a new role.

You can create a new user role by going to the Administration pane, selecting Security and User Roles and by clicking on Create User Role from the task pane.

As you can see in the screenshot above, creating a user role is done by filling in several screens in a wizard asking you to specify information for the new user role.

Tip: The wizard doesn’t allow resizing, which in my opinion sometimes makes the information difficult to read. When i create a custom user role, I normally select all the default settings, save the new user role and then edit the newly created user role in a maximized window.

My advise is to create the necessary information which you can select in the Create User profile first and then actually create the custom user roles.

The necessary information asked in the wizard is:

Management Packs

After specifying a name and an optional description for the to be created custom user role you will be asked to select which Management Packs should be used for the rest of the create user role wizard.

So if you have a clear overview of which Management Packs contain the information which you want to give out to this specific custom user role you can make a selection here.

My practical experience is that you just select all the Management Packs here, since the out-of-the-box provided Management Packs don’t give a clear overview of which item is in what Management Pack.

Queues

The name Queues is actually very badly chosen by Microsoft, because in the terminology of Incident Management a Queue is usually reffered to as an Incident Queue. The Queue in which incidents recide which belong to your support group. In this context though, Queues are used to group Work Items based on several criteria. And to make things even more complex, a criteria could be each incident assigned to a support group, giving you an incident queue as you can see in the screenshot below. IMHO Microsoft should have named this Scope, just like in ConfigMgr – which (for me at least) makes more sense.

Keep in mind though that there a several other criteria on which you can create a Queue. For Example you can create a Queue containing incidents which a high urgency.

So, why would you create Queues you might ask? Let me give some examples:

First of all, you need to create Queues when you want to leverage the Service Level Management functionality. If you create a Service Level Objective (SLO), you must supply a Queue for the service level. So if you want to define a SLO for Tier 1 you should create a Queue containing all the incidents for Tier 1.

Another reason to use Queues is to give users different rights depending on which Queue the Work Item is part of. You could for example create in Incident Resolver role which applies to incidents part of the Tier 1 Queue. This means that if an incident is assigned to Support Group Tier 1, the user will have the rights of an incident resolver. You can then make that same user a Read-Only operator for the incidents in the other Queues, giving that end user the right to see the incidents but not being able to modify them.

Configuration item Groups

Configuration Items are services, computers, software, software updates, users and other undefined imported objects in the Service Manager database in Service Manager. Most of the configuration items are automatically imported by using one of the connectors and from there can be extended with custom information. It is also possible to create your Configuration Items in Service Manager only.

You can use Configuration Item Groups in a scenario where you want to restrict access to Configuration Items to be seen and used by the custom user role. For example you could create a Configuration Item Group containing only SQL server computers, giving the custom user role only access to those computers and include those only in incidents, change requests etc..

Configuration Item Groups can contain Direct Members (which you manually select) or you can dynamically select them using several criteria, for example all Configuration items with Amsterdam as its location.

Its also possible to include subgroups – which allows you to include earlier created groups. For example you already created a group for IIS server and one for SQL servers and now you want to create a group containing both IIS and SQL servers. Its also possible to exclude groups, for example if you want to create a group containing all the SQL servers, but not the once running in a Cluster configuration.

The possibilities are endless here, which makes this very powerfull. You can use the View Group Members task to actually view the results of the newly created group.

Catalog item Groups

A Catalog Item Group allows you to group items which you use in your Service Catalog. You might want to group these items in order to present users with different options in the service catalog depending on their group membership. But you can also create Catalog item groups to specify the rights a Service Manager console user has on these items, giving them change rights in some cases and read-only rights in other cases.

Also here, there are endless possiblities, keep it simple and use the View Group Members task to see if the group contains the results you expect.

Tasks

Tasks actually allow you to execute certain actions based on the selected context. In the example of the screenshot below, I selected a computer. The tasks being made available only make sense for that computer.

So, if tasks only make sense for the selected object why would you want to limit them you might ask?

For example, I implemented the Advanced Send Email functionality from Cireson/itnetx. This addon for Service Manager allows me to send emails to Affected Users and actually replaces some standard functionality out of the box. In this case the Request User Input and Send Email tasks. Well, if you don’t want a user role to use the Request User Input task anymore, simply remove that form the list of tasks available for that user.

Another example is that i only want that incidents can be created from a template which I defined. I therefore restrict access to the Create Incident task by hiding that task to my custom user roles.

Views

Service Manager contains many views out of the box and allows you to create custom views as well. When creating views I strongly advise you to use the Advanced View Editor written by Anton Gritsenko and available on TechNet Gallery here. For each view you can specify whether a user role can see them or not. Why show Release Management views for example if you don’t use that functionality at all in the product.

Some remarks:

First of all, you cannot hide the root folders for the functionality in Service Manager. You can hide all the folders and views underneath them though. In my opinion Microsoft should give the possibility to move these root folders as well.

Second, under Activity Management Microsoft created several views with exact the same name. In the example below you can see the All Activities and Failed Activities view under both Manual Activities and Parallel Activities. If you don’t use the Parallel Activities functionality and you want to hide those views, there is no way to see in the Create User role properties which "All Activities" view belongs to Parallel Activities.

As you can see below, there are several All Activities views, which can be selected/unselected for a custom user role.

In my case I decided to just give every custom user role all the views related to Activity Management, whether or not the functionality was used.

Tip: If you create your own custom views, use unique names to clearly distinct them from each other.

Form Templates

Form Templates (not to be confused with email templates) can be used to prefill forms. You create these templates so that the user who fills in the template only needs to fill in the unique necessary information for that form. By creating templates you can enable more cosistency and reduce the time needed to fill in a specific form.

You can restrict which Form Templates a Service Manager user role can see by not selecting those templates.

Users

Here you can select which users or user groups (I prefer the last) should belong to the custom user role.

Some Guidance

In order to give me some guidance when diving into creating my custom user roles I decided to first write down all of the options available to me. I wrote these options down in a spreadsheet where i was able to map the different items described before to the different user roles.

I am sharing that spreadsheet with you here, so that you can use it as a guidance when modelling your own User Roles for use in Service Manager.

You can download the spreadsheet here and use it as a basis for you own custom RBAC mapping in Service Manager:

RBAC SCSM Documentation Sheet

Also make sure you create test users, and test for each user role the expected result in the console. Use the Run as a different user functionality to start the console.

Sources: