Running SQL Server Under a Group Managed Service Account

A service account password that never changes is an invitation to trouble, and manual rotation can stop a service at the worst time. A group managed service account lets Active Directory manage the password for approved hosts. SQL Server still needs a careful account change and a Kerberos check.

Decide Which Services Need a Group Managed Service Account

A gMSA is a domain principal whose password is managed by Active Directory. It can serve more than one approved host, which matters for clustered or availability setups. Decide whether the Database Engine and SQL Server Agent should share one gMSA or use separate accounts. Separate accounts give clearer permission boundaries. The choice depends on jobs, network resources, and operational ownership.

I inventory the current service identities, SPNs, backup shares, proxies, linked servers, and file permissions before changing anything. A service can start successfully and still fail its nightly backup because the new account cannot reach a network path. What external resource does the current identity use that will need an explicit grant?

Prepare the Group Managed Service Account in Active Directory

The domain administrator confirms that the forest has the required KDS root key and that the SQL hosts can retrieve managed passwords. Create the gMSA and restrict retrieval to an approved computer group. The PowerShell example is a template for the administrator to adapt to the real domain. It is not a command to run on an unknown production domain unchanged.

# PowerShell
New-ADServiceAccount -Name SqlEngineSvc -DNSHostName 'SqlEngineSvc.example.test' -PrincipalsAllowedToRetrieveManagedPassword 'SQL-Service-Hosts'

Keep the command on one line when adapting it. The name ending in a dollar sign appears when the account is used as a Windows service identity. The gMSA object must exist before SQL Server Configuration Manager can use it.

Install and Test on Every Approved Host

On each SQL Server host, install the account with the Active Directory PowerShell module and test password retrieval. Run from an elevated PowerShell session. A failed test is a domain or permission problem to resolve before touching SQL Server services. The machine account or its security group membership must be allowed to retrieve the gMSA password.

# PowerShell
Install-ADServiceAccount -Identity SqlEngineSvc
Test-ADServiceAccount -Identity SqlEngineSvc

Expect True from the test. If group membership changed recently, refresh the computer's authorization state as directed by the Windows administrator. Do not work around a failed test by typing a password into a service dialog. The value of a gMSA is that the host obtains the managed secret through the supported Windows mechanism.

Change the Services in Configuration Manager

Use SQL Server Configuration Manager for the Engine and Agent account changes. It updates service permissions and related settings that a generic Windows Services dialog does not handle in the same way. Enter the identity as DOMAIN\SqlEngineSvc$ and leave the password field blank. If Agent has a separate gMSA, install and test that account too before switching it.

Plan a service restart window and a rollback identity. SQL Server Configuration Manager can make some credential changes immediately, but changing the running identity requires controlled service handling and validation. Confirm startup, database recovery, Agent job execution, and error log health. I check the Engine first, then Agent, so a failure can be isolated to one service.

Regrant External Rights Deliberately

The service SID can preserve some local SQL Server permissions, but the domain identity has changed. Recheck backup shares, file imports, certificates, network storage, proxy credential use, and any service account grants on remote systems. Use the minimum rights needed for each path. Avoid making the new account a local administrator just to silence an access denied error.

A service account migration is also a chance to find old permissions nobody can explain. Record the required ones before the switch and test each with the workload that uses it. A successful SELECT 1 does not prove that a backup to a share or an Agent PowerShell step can run. Keep the test list tied to real jobs and dependencies.

Verify SPNs and Kerberos

An SPN maps the SQL service endpoint to the account running the Engine. For a default instance over TCP, it commonly has the form MSSQLSvc/server.example.test:port. Named instances and listeners need their own correct entries. Work with the domain administrator to ensure the old account no longer owns conflicting SPNs and that the gMSA can register or has the required SPNs. Duplicate SPNs can break Kerberos.

REM Command line
setspn -L DOMAIN\SqlEngineSvc$
setspn -X

Run those commands in Command Prompt with appropriate directory permissions. Then connect from a remote Windows client using the normal application endpoint and Windows authentication. A local shared-memory connection does not test the same path. The query below reports the authentication scheme for the current connection.

SELECT session_id, net_transport, auth_scheme
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

For the remote Windows-authenticated test, expect KERBEROS when the SPN and client path support it. If you see NTLM, check the endpoint name, DNS, service identity, SPN ownership, and delegation needs. Do not assume every NTLM connection means the SQL service failed; the connection method matters. I record the client, server name used, port, and result so the check can be repeated after failover.

Let the Group Managed Service Account Rotate Quietly

The managed password changes without the DBA distributing a new password. That is the benefit, but it does not remove the need for monitoring. Check service startup after patching, scheduled job access, backup success, and Kerberos after changes to hosts or listeners. Keep the approved host group current when nodes are added or removed.

The final runbook should name the gMSA, approved hosts, dependent services, SPNs, external grants, and rollback identity. No secret belongs in that document. A clean migration means users keep connecting, Agent keeps working, and the DBA no longer has a password rotation date on the calendar.

Related reading on this blog: gMSA: The Service Did Not Start Due to a Logon Failure and SQL Service Not Getting Started Automatically After Server Reboot While Using gMSA Account.

A managed password is not complete service security, it is one part of permissions and Kerberos setup.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.