How to scope the SCOM R2 Reports for certain Report Operators

As mentioned before, I would write a posting about how to scope the SCOM R2 Report for certain Report Operators User Roles. This posting will cover that topic.

There are a few things to reckon with:

• For starters, it is better to leave the User Role Operations Manager Report Operators, which is available by default when SCOM R2 Reporting is installed, as it is. Do not use that User Role. Just create the Report Operator Roles as required and use those custom created User Roles as a basis for scoping the Report Operators role. This way there is always a way back when things act differently as expected.
  
  
• Secondly, a valid backup mechanism of the related SSRS database (ReportServer is its default name) needs to be in place and functional since the scoping of the Views of the available SCOM R2 Reports is set within that DB. When that DB goes down and there is NO valid backup at hand of that DB, all the scoping of Views will be gone as well.
  
  
• Thirdly, use the AGDLP approach here. Sometimes I see environments where they simply put a user into a User Role but that is NOT the way to go, only when you want to get an environment which runs out of control. So AGDLP it is.

Lets start. In this example I will create a SCOM R2 User Role Report Operators where they are only allowed to view the Server OS related reports. All the other Reports are not to be used by these people. For this three procedures are required:

• Active Directory (AD) – Group creation and population
• SCOM R2 – User Role ‘Report Operator’ Creation
• SSRS – Security Configuration

Procedure 01: AD – Group creation and population

1. First create a Domain Local Group, using the naming convention of your company;
   
2. Create a Global group, also using the naming convention of your company;
   
3. Put the Global Group created in Step 2 into the Domain Local Group created in Step 1;
   
4. Put the users who need to have special Report Operator Access into Global Group created in Step 2.
   

OK, now we have covered the AD side of it all. Time to move on to the SCOM R2 Console.

Procedure 02: SCOM R2 Console – User Role ‘Report Operator’ Creation

1. Open the SCOM R2 Console with SCOM Admin permissions, go to the Administration Wunderbar > Administration > Security > User Roles;
2. Right click Profile: Report Operator (x) > New User Role > Report Operator
   
3. Give it a proper name and a description. Add the Local Domain Group here since AGLP is the way to go;
   
4. Next > Create. When the new User Role is created open it again and go to the tab Identity and hit the button Copy. Now the ID is copied into the memory.
   

Now we have covered the SCOM R2 side of it all.

Lets see how far we are. We have created the Global Group ‘GG_SCOM_Report_Operators_ServerOS_Only’. This Global Group has been added to the Domain Local Group ‘DLG_SCOM_Report_Operators_ServerOS_Only’. In the SCOM R2 Console we have added this same group to the User Role ‘Report Operators – Server OS Reports Only’. And the user Test is a member of the earlier mentioned Global Group. And we have copied the ID related to this User Role.

Time to move on to the last and most important procedure. Without it, all previous actions are pointless.

Procedure 03: SSRS – Security Configuration

1. Open the webpage of the SSRS instance hosting the SCOM R2 Reporting component (http://servername/myreports);
2. Go to the tab Properties and hit the button New Role Assignment > paste the copied ID into the field Group or user name > select the Roles Browser and My Reports > OK;
   
   and
   
3. When we use the Test account now for opening the SCOM R2 Console you will see that ALL the Reports will be shown:
   
   Close the Console;
4. Go back to IE with the SSRS instance. Remember, we need to limit access to only the Server OS Reports. In order to achieve that we need to have the ID (Step 4, Procedure 02). So what we basically need to do is change the security on the folders which DO NOT contain the Server OS Reports. It is better NOT to alter the security on the folders ‘My Reports’, ‘Users Folders’ since these are directly related to the SSRS configuration and not to SCOM R2 Reporting.
   
5. Example: Click on the first folder which needs to be altered. In this case, I click on the folder Microsoft.SQLServer.2008.Monitoring > click on Properties > Security > Edit Item Security. This dialog box is shown now:
   
   This basically tells you are about to change the security settings which are inherited from its parent. Click OK;
6. Select the Group/User with the ID (Step 4, Procedure 02) by placing a checkmark in the box. Click Delete:
   
   and
   
   Click OK. Please note this button:
   
   so there is always a way back :) ;
7. Repeat Steps 5 and 6 for every Report this User Role is not allowed to access. Now open the SCOM R2 Console with the test user account and check out the Reporting Tree:
   
   Wow! That looks a lot better compared to the View in Step 3! Run a report in order to test it completely. Close the Console and you’re done.

Recap:

In this posting I showed how to scope the available Reports to certain User Roles. It can be done but it is labor intensive. Actions are needed in AD, SCOM R2 and SSRS.

Also know that by accessing the Reporting Server directly (http://servername/myreports), the security which has been set in SCOM and SSRS will be circumvented. So people still can run those ‘forbidden’ Reports.

However, the interface which SCOM R2 offers is not present so it can be a challenge for those people to get those reports running. For instance compare the SCOM R2 Reporting parameter area for the SQL Report ‘Top 5 Deadlocked Databases’

with the one in the SSRS instance:

I know which one I prefer… :)