For SQL Server, you can:

• Use the Windows / Active Directory Monitoring service account to access both Windows and SQL Server if you have selected a Windows service account for the Base Monitor service, or
• Specify a Windows / Active Directory login on the monitored server to collect data from Windows, or
• Specify either a Windows / Active Directory account or a SQL Server login to collect data from SQL Server.

In the first case, the Base Monitor service may be a group Managed Service Account (gMSA). 

For Azure SQL Databases and Managed Instances, see: Azure SQL Databases and Azure Managed Instances.

For PostgreSQL instances, see Monitoring PostgreSQL instances. If the instance is running on a Linux host (as opposed to Amazon RDS), also see Monitoring a Linux host.

The account used to monitor any server requires a number of permissions both within Windows and within any SQL Server instance.

Monitoring a Windows host

The simplest configuration is achieved by making the monitoring account an administrator on the remote Windows host machine. If this isn't possible, see: Monitoring host Windows machines without admin permissions.

• The account should have login rights locally on the machine where the Base Monitor is installed, so that SQL Monitor can authenticate the account.

Monitoring host Windows machines without admin permissions

1. If connecting via DCOM, the account should have Remote Launch  and Remote Activation  permissions on the target machine, and Remote Access for Anonymous Login. For information on how to assign these permissions, see:  Securing a Remote WMI Connection.
2. If connecting via WinRM the account should be a member of the WinRMRemoteWMIUsers__ group (2 underscores).
   Note: you will need to create this group if it doesn't exist already and you might need to restart the Windows Remote Management (WS-Management) service for the new settings to take effect
   For further information, see: Authentication for Remote Connections.
3. The account should have  Remote Enable  and  Enable Account  permissions for the WMI namespaces CIMV2, Root and MSCluster (if it exists on the machine). This can be done from WMI Control in Computer Management.
4. The account should be a member of the  Performance Monitor Users  group on the target machine.

5. For the next section you will need to obtain the SID of the monitoring account. The SID can be obtained by opening a command prompt and running:

   wmic useraccount where name='<account_name>' get sid

6. The account should have Create Child (CC), List Children (LC), Read Property (RP) and Read Control (RC) permissions for scmanager on the target machine to allow SQL Monitor to access the list of running Windows processes.  This can be done by adding (A;;CCLCRPRC;;;<sid>) to scmanager’s security descriptor, where <sid> is the SID of the account. An example of how this is done is shown below. 

   sc sdset scmanager "D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)(A;;CCLCRPRC;;;<sid>)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)"

   If scmanager permissions have already been configured on this server, the command above will overwrite them.

7. The account should have List Children (LC) permissions on all SQL Server services on the target machine to ensure that they are visible to SQL Monitor. This can be done by adding (A;;LC;;;<sid>) to the security descriptor of each service, replacing <sid> with the SID of the account as obtained above. An example of how this is done is shown below using the named instance SQL2012CS (with service name MSSQL$SQL2012CS - the default instance name is MSSQLSERVER).
   Note: this will replace any other permissions set for the SQL Server services.

   sc sdset MSSQL$SQL2012CS "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;LC;;;<sid>)S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)"

   If permissions have alerady been set on the SQL Server service, the command above will overwrite them.

8. If the server is part of a Windows Server Failover Cluster, e.g. it hosts part of a  SQL Server Always On Failover Cluster Instance or part of an Always On Availability Group, SQL Monitor will require access to the Windows Server Failover Cluster to identify and monitor cluster resources.  On the monitored machine, run the following PowerShell as an administrator, substituting in the account you are using for monitoring:

   > Import-Module FailoverClusters
   > Grant-ClusterAccess -User <accountname> -Full

Monitoring a Linux host

To monitor a Linux host, SQL Monitor needs a user to establish SSH connections for data collection. The user does not need to have administrative (sudo) access.

The following permissions on the file system would be sufficient;

Monitoring SQL Server instances

For SQL Server versions:

• SQL Server 2014 (12.x) and older
• SQL Server 2016 (13.x) before SP2.
• SQL Server 2017 (14.x) before CU9.

The account used to monitor your SQL Server instance should have the following permission:

• Member of the sysadmin role - role only required for Integrity check overdue alerts (to run DBCC DBINFO) and to allow SQL Monitor to turn on the deadlock trace flag (trace flag only for SQL Server versions before 2008R2 (10.50.x) SP2 CU12).

For all other SQL Server versions, or if not providing sysadmin, the account used to monitor your SQL Server instance should have the following permissions:

• Member of the db_datareader role on the msdb system database.

  -- if the user account does not exist in all databases, the below script can be used to create it in every one of them
  -- EXEC master.dbo.sp_MSforeachdb 'USE [?]; CREATE USER sql_monitor_account;'
  
  USE msdb;
  ALTER ROLE db_datareader ADD MEMBER sql_monitor_account;

• Member of SQLAgentReader role on the msdb system database.

  USE msdb;
  ALTER ROLE SQLAgentReaderRole ADD MEMBER sql_monitor_account;

• VIEW ANY DEFINITION server permission.

  GRANT VIEW ANY DEFINITION TO sql_monitor_account;

• ALTER TRACE server permission (if you want to enable trace data).

  GRANT ALTER TRACE TO sql_monitor_account;

• ALTER ANY EVENT SESSION server permission.

  GRANT ALTER ANY EVENT SESSION TO sql_monitor_account;

• VIEW SERVER STATE and VIEW DATABASE STATE database permissions on all databases.

  GRANT VIEW SERVER STATE TO sql_monitor_account;
  EXEC master.dbo.sp_MSforeachdb 'USE [?]; GRANT VIEW DATABASE STATE TO sql_monitor_account;'

• There are two options for tempdb permissions, either granting membership of the db_owner role on the tempdb database:

  USE tempdb;
  ALTER ROLE db_owner ADD MEMBER sql_monitor_account;

  Otherwise the need for this permission can be avoided by enabling the option to remove the need for this permission by running the following SQL on the SQL Monitor repository:

  USE [SqlMonitor]
  GO
  
  INSERT INTO [settings].[KeyValuePairs]
             ([KeyName]
             ,[KeyValue]
             ,[KeyValueType])
       VALUES ('ReducePermissionsRequiredOnTempDb','True','BOOLEAN')
  GO

• EXECUTE on xp_readerrorlog.

  GRANT EXECUTE on xp_readerrorlog TO sql_monitor_account;

• SELECT on sys.sql_expression_dependencies on all databases.

  EXEC master.dbo.sp_MSforeachdb 'USE [?]; GRANT SELECT ON sys.sql_expression_dependencies TO sql_monitor_account;'

Monitoring Azure SQL Databases

The account used to monitor your Azure SQL Database can be a server admin account or a user with reduced permissions as mentioned below.

Admin User

• Typically this would be the account used to create the Azure SQL Server if connecting via SQL Server Authentication.
• However, you can additionally assign a Microsoft Entra ID as admin which will allow you to connect using either Microsoft Entra Password Authentication or Microsoft Entra Integrated Authentication (if configured).
  • The assigned admin can either be a single user or a group (in which case every member of the group will have access).

Reduced Permissions User and login

The following permissions are required as a minimum to monitor Azure SQL Database. Please note for managed identity authentication, sql_monitor_login is the name of the system-assigned or user-assigned managed identity. For example, if you have a VM with a system-assigned managed identity then sql_monitor_login should be replaced with the name of the VM. For user-assigned managed identities, replace sql_monitor_login with the name of the user-assigned managed identity.

• SERVER ROLES permissions

  -- on master--
  -- Requires the login sql_monitor_login to be created on master database.
  ALTER SERVER ROLE ##MS_ServerStateReader## ADD MEMBER sql_monitor_login;
  ALTER SERVER ROLE ##MS_DefinitionReader## ADD MEMBER sql_monitor_login;

• SELECT sys.sql_expression_dependencies permission and ALTER ANY DATABASE EVENT SESSION permission required on the databases that will be monitored.

  You are required to use the login which was granted the server roles when creating the user account in the databases that will be monitored

  -- On database being monitored--
  -- Requires the login sql_monitor_login created on master with the server roles assigned.
  CREATE USER  sql_monitor_account FROM LOGIN  sql_monitor_login;
  GRANT SELECT ON sys.sql_expression_dependencies TO sql_monitor_account;
  GRANT ALTER ANY DATABASE EVENT SESSION TO sql_monitor_account;

Monitoring Azure Managed Instances

The account used to monitor your Azure Managed Instance can be a server admin account or a user with reduced permissions as mentioned below.

Admin User

• Typically this would be the account used to create the Azure Managed Instance if connecting via SQL Server Authentication.
• It could also be a user who is a member of the sysadmin role.
• However, you can additionally assign a Microsoft Entra ID as admin which will allow you to connect using either Microsoft Entra Password Authentication or Microsoft Entra Integrated Authentication (if configured).
  
  • The assigned admin can either be a single user or a group (in which case every group member will have access).

Reduced Permissions User and login

The following permissions are required as a minimum to monitor Azure Managed Instances. Please note for managed identity authentication, sql_monitor_login is the name of the system-assigned or user-assigned managed identity. For example, if you have a VM with a system-assigned managed identity then sql_monitor_login should be replaced with the name of the VM. For user-assigned managed identities, replace sql_monitor_login with the name of the user-assigned managed identity.

• VIEW ANY DEFINITION, VIEW SERVER STATE, ALTER ANY EVENT SESSION  server permission and EXECUTE on xp_readerrorlog.

  USE master;
  GRANT VIEW ANY DEFINITION TO sql_monitor_login;
  GRANT VIEW SERVER STATE TO sql_monitor_login;
  GRANT ALTER ANY EVENT SESSION TO sql_monitor_login;
  GRANT EXECUTE on xp_readerrorlog TO sql_monitor_login;

• Member of the db_datareader and SQLAgentReader role on the msdb system database.

  You are required to use the login which was granted the server permissions when creating the user account in the databases that will be monitored

  -- if the user account does not exist in all databases, the below script can be used to create it in every one of them
  -- EXEC master.dbo.sp_MSforeachdb 'USE [?]; CREATE USER sql_monitor_account FROM sql_monitor_login;'
  
  USE msdb;
  ALTER ROLE db_datareader ADD MEMBER sql_monitor_account;
  ALTER ROLE SQLAgentReaderRole ADD MEMBER sql_monitor_account;

• SELECT sys.sql_expression_dependencies and VIEW DATABASE STATE database permissions on all databases.

  EXEC master.dbo.sp_MSforeachdb 'USE [?]; GRANT SELECT ON sys.sql_expression_dependencies TO sql_monitor_account;'
  EXEC master.dbo.sp_MSforeachdb 'USE [?]; GRANT VIEW DATABASE STATE TO sql_monitor_account;'

• There are two options for tempdb permissions, either granting membership of the db_owner role on the tempdb database:

  USE tempdb;
  ALTER ROLE db_owner ADD MEMBER sql_monitor_account;

  Alternatively, the requirement for this permission can be avoided by enabling the option to use reduced permissions on the tempdb database by running the following SQL on the SQL Monitor repository:

  USE [SqlMonitor]
  GO
  
  INSERT INTO [settings].[KeyValuePairs]
             ([KeyName]
             ,[KeyValue]
             ,[KeyValueType])
       VALUES ('ReducePermissionsRequiredOnTempDb','True','BOOLEAN')
  GO

Monitoring Amazon RDS SQL Servers

The account used to monitor your Amazon RDS SQL Server must be either the server admin account provided upon creation of the RDS instance or a user that has the following permissions below.

• VIEW SERVER STATE permission

  -- if the user account does not exist in all databases, the below script can be used to create it in every one of them
  -- EXEC master.dbo.sp_MSforeachdb 'USE [?]; IF DB_NAME() NOT IN(''master'',''rdsadmin'') CREATE USER sql_monitor_account;'
  USE master;
  GRANT VIEW SERVER STATE TO sql_monitor_account

• Member of SQLAgentOperatorRole role on the msdb system database.

  USE msdb; 
  EXEC sp_addrolemember SQLAgentOperatorRole, sql_monitor_account;

• SELECT permission on sysjobs and sysjobhistory tables on the msdb system database.

  USE msdb; 
  GRANT SELECT ON sysjobhistory TO sql_monitor_account;
  GRANT SELECT ON sysjobs TO sql_monitor_account;

• SELECT permission on sys.sql_expression_dependencies on all databases.

  EXEC master.dbo.sp_MSforeachdb 'USE [?]; IF DB_NAME() NOT IN(''master'',''msdb'',''rdsadmin'') GRANT SELECT ON sys.sql_expression_dependencies TO sql_monitor_account;'

• VIEW ANY DEFINITION server permission.

  USE master;
  GRANT VIEW ANY DEFINITION TO sql_monitor_account;

• ALTER ANY EVENT SESSION server permission.

  USE master;
  GRANT ALTER ANY EVENT SESSION TO sql_monitor_account;

• Enable the option for reducing the tempdb permissions by running the following SQL on the SQL Monitor repository:

  USE [SqlMonitor]
  GO
  
  INSERT INTO [settings].[KeyValuePairs]
             ([KeyName]
             ,[KeyValue]
             ,[KeyValueType])
       VALUES ('ReducePermissionsRequiredOnTempDb','True','BOOLEAN')
  GO