Catch-22: Securing ACS Reports AND scheduling them. Part III: Setting Security

--------------------------------------------------------------------------------- 
Postings in the same series:
Part   I: How Catch-22 was born…
Part  II: What do we need?
Part IV: Setting the subscriptions on the ACS Reports
Part  V: Auditing Security
---------------------------------------------------------------------------------

In this posting I will describe how to setup security. Also some groups and accounts need to be created. These groups and accounts will be used when adjusting the security settings on the SQL Server hosting the ACS Database which is also the SQL Server Reporting Services (SSRS aka SRS) for the ACS Reports.

Before continuing first a small Visio drawing about how the ACS components (Forwarders, Collector, Database, SSRS instance) are setup and relate to the SCOM managed environment:

Some explanation is at order here. As you can see most ACS components are separated from the SCOM environment. The ACS components are ‘highlighted’ by green circles. The circle around the monitored servers (SCOM Managed Servers) is not totally ‘closed’ since these servers report to the regular SCOM environment as well. The red arrows visualize the ACS related traffic.

Some SCOM Managed Servers have the ACS Forwarder enabled. These ACS Forwarders send all the Security Events to the ACS Collector. This is a separate SCOM Management Server which is purely dedicated to the ACS Collector role. The ACS Collector sends the collected events – after applying some basic filtering – to a dedicated SQL Server which only hosts the ACS database which is also the SQL Server Reporting Services (SSRS aka SRS) for the ACS Reports. On this server the ACS Reports will be rendered.

This server needs to be secured in such a manner that only a certain group of people (the auditors) can render the ACS Reports and that not a single domain administrator can do so as well. Also will the ACS Reports be configured in such a way that these can be scheduled as well.

Lets start!

Some comments:
Steps 1 to 3 are very well documented in SCOM Unleashed. Since I am not a copy cat I can only describe the outlines here. All steps described must be done on the SQL Server hosting the ACS Database which is also the SSRS Server for the ACS Reports.

1. Create a local group. Be sure to give this Group a logical name, like Local Auditors.
   
   
2. Grant this group access within SQL Server. Create for this purpose a new login referring to this group and select as default database the one used for ACS.
   
   
3. Grant this login db_datareader permissions on the ACS database
   
   
4. Change the group membership of the local Administrators group in such a way that the Domain Admins aren’t a member of that server any more.
   
   Make sure not to lock your self out!
   
   You can add the local group you created at Step 1 to the local Administrators group. However, this way the Auditors have total control of the ACS server which is a ‘bit’ too much. It is better to have them access the Report Server Web Console remotely through IE from another system. This way the server stays secure.
   
   Also, add a special account here. This account and password are only known to a small group of people (max. 3). This account is used for publishing reports and admin access to that server.
   
   
5. Open  Report Manager by opening this address in IE: http://localhost/Reports.
   
   Be sure to start IE with elevated permissions otherwise you bump into this issue.
   
   
6. Alter the Site Settings of SSRS by going to Site Settings > Security > New Role Assignment. Add the group created in Step 1. Grant them the role of System User. Save the new configuration.
   
   
7. Go back to the start page of Report Manager and alter the Object Settings by going to Properties > New Role Assignment. Add the group created in Step 1. Grant this Group the role of Browser. Save the new configuration.

With these steps the basic security has been altered in such a way that only a small group of people can access this server. Also has the access to the ACS Database been restricted. Of course, need the other groups with Admin access within SQL to be checked out as well. But that goes without saying… :)

And remember, the more difficult a security model is built the more gaps there are….

Next posting will be about Step 2: Setting the subscriptions on the ACS Reports.