The Control Server permission on the DVLS_Owner account may appear excessive at first glance. This article explains exactly why it is required, when it is used, and how to avoid granting it.
Devolutions Server requires the DVLS_Scheduler account to hold the View server state server level permission. The Scheduler service uses this permission to query SQL Server dynamic management views (DMVs) in order to monitor the current load on the SQL instance and throttle its own work accordingly ensuring the Scheduler never overloads your SQL Server during background operations.
SQL Server enforces a rule: to grant a server-level permission to another account, the grantor must itself hold Control Server (or be a member of the sysadmin role). There is no lower-privilege alternative for granting server-level permissions in SQL Server.
This means DVLS_Owner needs Control Server not to use it directly, but solely to be able to issue the following grant to DVLS_Scheduler: GRANT VIEW SERVER STATE TO [DVLS_Scheduler];
Control Server is not a runtime permission. Devolutions Server never uses it during normal operation. It is only exercised at the following specific administrative moments:
Initial installation: when the database and accounts are first provisioned.
Product updates: when the permission model is re-applied after an upgrade.
Manual re-application: when an administrator explicitly clicks Apply Least Permissions in the Advanced credentials section of the Devolutions Server Console.
Credentials window (typically only needed when the service account is changed).
Outside of these moments, DVLS_Owner does not connect to SQL Server during normal operation and is not the runtime account.
If your security policy does not permit granting Control Server to DVLS_Owner, there are two supported alternatives. Both achieve the same result: DVLS_Scheduler holding View Server State without requiring DVLS_Owner to hold Control.
Server
Devolutions Server can generate the SQL script that it would otherwise execute itself. A SQL Server administrator with the appropriate privileges (e.g., a sysadmin account) can then review and run the script manually.
A SQL Server administrator can grant the permission directly to DVLS_Scheduler without involving DVLS_Owner at all.
Share your feedback