Role Based Security


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_allProvides full access to SentryOne's features. Place all non - sa users in this role, and then add to deny roles to restrict access.
allow_readonlyAllows 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_readDenies the ability to view all General, Failsafe, Audit, and Custom Condition actions.
deny_actions_updateDenies the ability to make changes to any actions, but allows the viewing of those settings, making them read-only.
deny_appsettings_updateDenies any changes made under the SentryOne Monitoring Service > Settings node.
deny_contact_updateDenies the ability to update information for individual users, but allows viewing the information, making it read-only.
deny_contactgroup_updateDenies the ability to update group information, making it read-only.
deny_customconditions_updateDenies the ability to enable, disable, create, or edit Advisory Conditions.
deny_eventchain_readDenies the ability to view Event Chain information.
deny_eventchain_updateDenies the ability to make changes to Event Chains.
deny_settings_connection_readDenies the ability to view information under the Settings tab at the instance level for the specified instance type.
deny_settings_connection_updateDenies the ability to make changes under the Settings tab at the instance level for the specified instance type.
deny_settings_object_readDenies the ability to view information under the Settings tab at the object level.
deny_settings_object_updateDenies the ability to make changes under the Settings tab at the object level.
deny_settings_source_readDenies the ability to view source information from the Settings tab.
deny_settings_source_updateDenies the ability to make changes to Source information from the Settings tab.
deny_site_updateDenies changes made to Site Configuration.
deny_watch_connectionDenies the ability to watch or stop watching an instance.
deny_watch_objectDenies the ability to watch or stop watching an individual object.


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.