Avoiding connections to SQL Server with an account that has administrative privileges (Basic) - Security Center does not require the SQL sysadmin server role on SQL Server 2017 and later versions. Each Security Center role requires a different set of permissions. - Security Center 5.14 - Administrator guides - Best practices

Security Center Hardening Guide 5.14
Product
Security Center
Content type
Guides > Administrator guides
Version
5.14
Release
5.14
ft:locale
en-US
Last updated
2026-03-19

Security Center does not require the SQL sysadmin server role on SQL Server 2017 and later versions. Each Security Center role requires a different set of permissions.

IMPORTANT: In SQL Server 2016 and earlier, the sysadmin role is required to perform backup and restore operations.

Server-level roles

A broader set of permissions is necessary during the first execution of Security Center for the creation of the Security Center role databases. Therefore, it is possible to restrict the permission set after the first execution. You can also start with the restricted permission set by creating the required databases outside of Security Center. Refer to the table below for more information.

The Security Center Directory role requires the VIEW SERVER STATE permission to work properly. This permission is mandatory when Directory failover is configured. VIEW SERVER STATE should always be enabled.

The processadmin server-level role is required to obtain the VIEW SERVER STATE permission (refer to this document to see the permissions associated with the fixed server-level roles). In return, this permission grants access to the server-scoped Dynamic Management Views and functions.

The public server-level role allows the execution of stored procedures created by default in SQL Server. Revoke the EXECUTE permission of the xp_dirtree stored procedure.
Server-level role requirements for Security Center roles
Security Center roles public dbcreator processadmin
Access Manager X X1 X
ALPR Manager X X1 X
ALPR Matcher X X1 X
Archiver X X1 X
Automation Manager X X1,2,3 X
Auxiliary Archiver X X1 X
Directory X X1,2,3 X
Health Monitor X X1 X
Intrusion Manager X X1 X
Media Router X X1 X
Mobile Credential Manager X X1 X
Mobile Server X X1 X
Plugin (roles with their own database) X X1 X
Plugin (roles connecting to another role's database) X - -
Point of Sale X X1 X
Record Caching Service X X1 X
Unit Assistant X X1 X
Zone Manager X X1 X

1 dbcreator is only necessary if you want Security Center to create the databases for you; and only for the first system execution. Remove it after the first execution. You also have the option to create empty databases yourself. When the system runs for the first time, the service user creates the tables in empty databases, and therefore the dbcreator role is not needed.

2 dbcreator is necessary when using Directory database failover through backup and restore. If database failover through backup and restore is not used, dbcreator is only necessary for the first system execution, and only if you are letting the system create the Directory database.

3 dbcreator is also required during a Security Center upgrade when the Automation feature is enabled. An extra database named DirectoryAutomationEvents is created beside the Directory database. This database works as an event cache when the connection between the Directory and the Automation Manager is lost.

Database-level roles

Databases are created during the first execution of a Security Center role.

The db_owner role is automatically created on the databases of Security Center roles after their creation. However, Security Center roles only need the database-level roles listed in the following table during normal operations.

The public database-level role is required to list the databases for selection in Config Tool. Security Center roles using dynamic schemas require the db_ddladmin database-level role to alter their database schema. They need to constantly create new tables, new columns, new indexes, and so on. For this reason, they need to operate as database owners.

There is the db_owner role in SQL Server that grants full permission on the database. However, assigning this role to Security Center roles defeats the purpose of reducing their permissions. Instead of using the db_owner role, replace it with the less privileged db_ddladmin role. The latter allows you to create and alter tables without the full permission of the db_owner role.
Database-level role requirements for Security Center roles
Security Center roles public db_datareader db_datawriter db_backupoperator db_ddladmin
Access Manager X X X X X
ALPR Manager X X X X X
ALPR Matcher X X X X X
Archiver X X X X -
Automation Manager X X X X X
Auxiliary Archiver X X X X  
Directory X X X X X
Health Monitor X X X X X
Intrusion Manager X X X X -
Media Router X X X X -
Mobile Credential Manager X X X X X
Mobile Server X X X X  
Plugin (roles with their own database) X X X X X
Plugin (roles connecting to another role's database) X X X - -
Point of Sale X X X X X
Record Caching Service X X X X X
Unit Assistant X X X X  
Zone Manager X X X X X
NOTE: Security Center roles require the EXECUTE permission on the dbo schema. This permission can be granted by using the following T-SQL command on each database: 
GRANT EXECUTE ON SCHEMA::[dbo] TO [ principal used by the Security Center role ]