To provide a more secure environment and allow non system administrators to take advantage of SentryOne's features, roles are placed on the SentryOne database during its installation or upgrade. Users are placed in these roles to allow them access to the features they need, while restricting access to features that may be above and beyond their responsibility.
Setting up Role Based Security
Role Based Security is configured through T-SQL statements or by using SSMS to set up database roles in SQL Server. Create a User on the SentryOne database, and add them to the allow_all role. This provides full access to the SentryOne database.
From here add the user to any of the custom deny_ roles to restrict that user's access to the different functions of SentryOne. Typically, there's a role to deny updating the specified information, and one to deny reading the information at all.
|allow_all||Provides full access to SentryOne's features. Place all non - sa users in this role, and then add to deny roles to restrict access.|
|allow_readonly||Allows read-only access to SentryOne's features. This role denies the user the ability to make any changes in the client, and denies the ability to change the watched status of connections or objects. The user can view all of SentryOne's features.|
|deny_actions_read||Denies the ability to view all General, Failsafe, Audit, and Custom Condition actions.|
|deny_actions_update||Denies the ability to make changes to any actions, but allows the viewing of those settings, making them read-only.|
|deny_appsettings_update||Denies any changes made under the SentryOne Monitoring Service > Settings node.|
|deny_contact_update||Denies the ability to update information for individual users, but allows viewing the information, making it read-only.|
|deny_contactgroup_update||Denies the ability to update group information, making it read-only.|
|deny_customconditions_update||Denies the ability to enable, disable, create, or edit Advisory Conditions.|
|deny_eventchain_read||Denies the ability to view Event Chain information.|
|deny_eventchain_update||Denies the ability to make changes to Event Chains.|
|deny_settings_connection_read||Denies the ability to view information under the Settings tab at the instance level for the specified instance type.|
|deny_settings_connection_update||Denies the ability to make changes under the Settings tab at the instance level for the specified instance type.|
|deny_settings_object_read||Denies the ability to view information under the Settings tab at the object level.|
|deny_settings_object_update||Denies the ability to make changes under the Settings tab at the object level.|
|deny_settings_source_read||Denies the ability to view source information from the Settings tab.|
|deny_settings_source_update||Denies the ability to make changes to Source information from the Settings tab.|
|deny_site_update||Denies changes made to Site Configuration.|
|deny_watch_connection||Denies the ability to watch or stop watching an instance.|
|deny_watch_object||Denies the ability to watch or stop watching an individual object.|
Warning:The roles starting with db_ are SQL Server default roles placed on every database. Using these roles in the SentryOne database may cause unpredictable behavior.
Note: On an older version without allow_readonly, you can make the SentryOne client read-only for a user by selecting all of the roles that end in _update.
An Example of Role Based Security
You have a junior DBA that needs to use SentryOne's Calendar view to check for any failures or long running jobs overnight, but you don't want them to make changes to any of SentryOne's settings.
Add their login as a User on the SentryOne database. Place that user in the allow_all role. This ensures the user has access to all the information they need while being explicitly denied any information specified in the additional roles assigned to them. Finally, for this example, you may want to add this user to all deny_ roles except the ones ending in _read. This denies changes to any settings along with the ability to Watch or Stop Watching an instance or object.
It's important to remember that logins using SQL Server Authentication must be specified in the SentryOne client instance information. To specify SQL Server Authentication, select File > Connect to Installation. Uncheck the box marked Integrated Windows Authentication, and then enter the user's login and password. Restart the SentryOne client to apply the settings. These new settings remain in effect on this SentryOne client until explicitly changed.