All databases have a standard set of “fixed” database security roles which have been available since SQL Server 2000 and hopefully, even if you are new to SQL Server, you are familiar with this set:
Back in the day, the msdb database was primarily used for managing backups, SQLAgent jobs, and DTS packages. And, other than the TargetServersRole role for multi-server job management via a master server and target servers, there were no other database roles defined for helping establish a separation of duties security model for tasks controlled via msdb.
In SQL Server 2005 some long awaited new roles were added to msdb (http://msdn.microsoft.com/en-us/library/ms188283(SQL.90).aspx) which help with segregating permissions for managing SQLAgent Jobs, DTS\SSIS, Database Mirroring, and Database Mail (the replacement for SQL Mail):
- db_dtsadmin – renamed in later versions as db_ssisadmin
- db_dtsltduser -renamed in later versions as db_ssisltduser
- db_dtsoperator – renamed in later versions as db_ssisoperator
- dbm_monitor – does not appear until database mirroring is implemented
Then, in SQL Server 2008 even more roles appeared as msdb took on increased importance in the management of new features such as the CMS (Central Management Server), PBM (Policy Based Management), Data Collection, and MDW (Management Data Warehouse).
Thus, the following new roles may be found in SQL Server 2008+:
- dc_admin – see BOL for description of permissions for Data Collector & MDW roles
- PolicyAdministratorRole – members can manage policies
- ServerGroupAdministratorRole – members can manage the CMS
- ServerGroupReaderRole – members can read from the CMS
In SQL 2008 R2 one more set of roles was added for the Server Utility (UCP) feature:
The above UCP roles are primarily assigned via the Server Utility configuration wizard and Utility Explorer Security tab. The “Utility Reader role” referenced in the Security tab is equivalent to the UtilityCMRReader role. As you may notice, certain service and administrator accounts are automatically in this role and cannot be changed (grayed out).
And, now in SQL Server 2012, believe it or not, there are no new roles in msdb! So, if you haven’t kept up with all the changes in msdb in the past few versions, this is your chance to catch up and make sure that you are fully utilizing these features and roles as needed in your environment. For a recap of all the features which utilize msdb, you can also refer to an earlier post I wrote – “What’s in Your msdb?”.