SQL Service Account group policy permissions

Question

I'm trying to establish the best practice standards for configuring service account permissions in Group Policy. Based on Microsoft documentation, SQL Server setup requests permissions for the per-service SIDs or local Windows groups used by SQL Server components. E.g.

SQL Server Database Engine:

---

The Default instance: NT SERVICE\MSSQLSERVER.Named instance: NT Service\MSSQL$<instance_name> is granted the permissions below during SQL Server setup. The local group policy permissions are visible under user rights assignment.

· Log on as a service (SeServiceLogonRight)

·Replace a process-level token (SeAssignPrimaryTokenPrivilege)

· Bypass traverse checking (SeChangeNotifyPrivilege)

·Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)

SQL Server Agent

---

Default instance: NT Service\SQLSERVERAGENT. Named instance: NT Named instance: NT Service\SQLAGENT$<instance_name>.) is granted the following permissions during setup.

·Log on as a service (SeServiceLogonRight)

· Replace a process-level token (SeAssignPrimaryTokenPrivilege)

·Bypass traverse checking (SeChangeNotifyPrivilege)

·Adjust memory quotas for a process (SeIncreaseQuotaPrivilege)

I also noticed that the SQL Service and Agent start-up accounts are also automatically granted “Log on as a service” permissions during setup.

Question

---

Is anyone using domain level group policy to apply the above permissions to the service start-up accounts-(e.g. gMSA’s) + per service SID? Trying to determine if there is any benefit of using domain group policy to enforce these permissions on SQL Server VM’s rather than relying on the local group policy permissions assigned by SQL Server during setup ?

Answer 1

Trying to determine if there is any benefit of using domain group policy to enforce these permissions on SQL Server VM’s rather than relying on the local group policy permissions assigned by SQL Server during setup

None. Setup grants the required permissions to the per-service SID. And any optional permissions (like perform volume maintenance tasks, and lock pages in memory, or network share permissions) should likewise be granted to the per-service SID (or computer account) so that a service account change doesn't break anything.

The Service account doesn't need any additional permissions beyond the logon permission.