SQL Sentry Client Security
When Does the SQL Sentry Client Connect Directly to a Monitored Server?
Although the SQL Sentry client receives the majority of its information from the SQL Sentry database, there are times when the client must connect directly to a monitored server. The SQL Sentry client connects directly to a monitored server during the following:
- Watching an instance
- Initiating a real-time action:
- Killing a SPID
- Defragmenting an index
- Updating statistics
- Getting an estimated plan
- Executing a query for an actual plan
- Job-related tasks:
- Start
- Stop
- Copy
- Disable
- Delete
- Enable
- Reschedule
- Changes to Agent alerts and Windows tasks (through event chains and context menus):
- Start
- Stop
- Disable
- Delete
- Enable
- Changes to Agent services:
- Start
- Stop
- Reporting (uses SSRS)
- Running a QuickTrace™
Restricting Access and Server Visibility in the SQL Sentry Client
Authentication Method Used When the Client Connects to a Monitored Target
In cases where the client needs to connect directly to a monitored instance, the authentication method used varies depending on the specified User Connection Properties of that instance.
As an alternative to integrated authentication, specify database specific credentials in the User Connection Properties. For example, for a SQL Server instance enter a SQL Server Authentication Account with the desired Server Role. To specify database credentials in User Connection Properties, complete the following steps:
- Access the User Connection Properties for an instance by right-clicking the desired instance to open the context menu, and then select User Connection Properties.
- Deselect the Use Integrated Authentication check-box, enter your desired account information, and then select Ok to save your information.
Shared Groups Node vs. SQL Server Registrations Node
Unsupported: As of June 2020, the SQL Server Registrations feature is deprecated and no longer supported.
There are a few differences regarding how authentication works depending on whether you're accessing the instance from the context of the Shared Groups node or the context of the SQL Server Registrations node in the Navigator pane.
For SQL Server instances accessed within the context of the Shared Groups node, Windows Authentication is used by default. However, if you've specified SQL Server credentials using the User Connection Properties context item, those credentials are used instead.
For SQL Server instances accessed within the context of the SQL Server Registrations node, the client uses the authentication method and credentials defined for the corresponding SSMS registration. This is also referred to as the native registration and is accessed using the instance's Edit Registration Properties context menu item.
If SQL Server authentication credentials are set using the User Connection Properties context item, those credentials are used instead, and they effectively override the authentication settings of the native registration. The initial connection to the target is always made using the native registration credentials to allow the client to determine the identity of the SQL Server, and ensure it isn't already being watched using a different name.