Checking Which Accounts the SQL Server Services Run As

The engine is patched, yet its service account belongs to Domain Admins. Checking the accounts behind SQL Server services exposes privileges a login review cannot show. A compromised process can use the Windows rights of that account, so service identity belongs in the security review.

Read the Inventory of SQL Server Services

Start with sys.dm_server_services. It reports the engine and related services for this instance, including account, startup type, state, and executable path. The instant file initialization column applies to the Database Engine, not every listed service. Save the inventory before making changes so the post-change check has a real reference.

SELECT servicename,service_account,startup_type_desc,status_desc,
       last_startup_time,filename,
       instant_file_initialization_enabled
FROM sys.dm_server_services
ORDER BY servicename;

On current versions, this view requires VIEW SERVER SECURITY STATE. Earlier versions use VIEW SERVER STATE. Check the documented requirement for your build. An empty or denied result is a permission issue, not evidence that services have no accounts. I collect this inventory with the same care as server-role membership.

Interpret the Account's Actual Rights

LocalSystem has extensive local privileges. A domain administrator identity exposes a much wider set of resources. Avoid either as a routine SQL Server service account. The account name alone does not describe every effective right, however. Local groups, domain groups, file permissions, and delegated privileges all contribute.

I ask the Windows owner for group membership and policy evidence. What can this identity access outside the database host? The SQL query cannot answer that. Include backup shares, remote storage, deployment folders, and network services. An account described as "just for SQL" can still have inherited rights nobody reviewed.

Understand Virtual Service Accounts

A virtual account such as NT SERVICE\MSSQLSERVER identifies a local service without a password an operator manages. A named instance has its own service identity. When accessing network resources, a virtual account generally uses the computer account. That makes local isolation convenient, but the remote share must grant the intended computer identity access.

Keep engine and Agent needs separate. An Agent job's access can involve its service account or a configured proxy, depending on the subsystem. Do not give the engine broad network rights to make one job succeed. The account should fit the actual service duties. A master key remains a master key even when the key ring looks tidy.

Compare Managed and Domain Accounts

Managed service accounts let Windows manage credentials under supported conditions. A group managed service account supports managed credentials across authorized computers. Setup still requires the right Active Directory preparation and permissions. Password management is only part of the design; storage access, Service Principal Names, and service rights still need verification.

A dedicated domain account can also be valid when its permissions are narrow and its credential lifecycle is managed. Avoid sharing one privileged account across unrelated services. Record the owner, permitted hosts, network resources, and rotation process. I favor an identity whose purpose is easy to explain and whose effective rights can be reviewed independently.

Change SQL Server Services in Configuration Manager

Change the service account through SQL Server Configuration Manager. It performs SQL Server-specific work beyond the Windows Services dialog. Select the correct instance and service, open its properties, and use the Log On page. Follow the documented process for the account type, especially a managed identity whose password is not manually supplied.

Plan the engine restart and application disconnects. Record the previous account and a tested return path. Verify directory permissions and remote access before the window. Change one service at a time, then test it. An engine account change and an Agent account change are separate changes with different workloads.

Recheck SQL Server Services After the Restart

After restart, query the service view again. Confirm the intended account, Running status, startup behavior, and new startup time. Read the SQL Server error log for file access, certificate, or authentication failures. Check data, log, tempdb, backup, and error-log locations with their expected permissions.

SELECT name,type_desc,physical_name
FROM sys.master_files
ORDER BY database_id,file_id;
SELECT servicename,service_account,status_desc,
       instant_file_initialization_enabled
FROM sys.dm_server_services;

The catalog lists registered database files. It does not prove the account can access every future backup destination or job folder. I verify a controlled backup to an approved test location and inspect its outcome. Do not grant Full Control over an entire drive when the service needs rights on specific folders.

Verify Network Authentication and Agent Work

Test from a remote client through the application's normal server name. Check the authentication scheme for that connection. A local login test does not prove Kerberos or the remote path. Coordinate Service Principal Name registration with the directory owner, then inspect errors instead of weakening authentication to make the test pass.

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

Run that query from the remote session you are testing. Next, execute representative Agent jobs: a database backup, a network-share step, and any proxy-dependent task. Check both job history and output artifacts. A green Agent service icon proves the service started; it does not prove every scheduled task retained access.

Check Initialization and Keep the Record

Instant file initialization can reduce data-file allocation time when the required right is granted. Inspect the view after the account change and confirm the intended policy. Its behavior has version and encryption considerations, and it does not mean every log growth operation skips initialization. Test file growth on an isolated instance rather than experimenting on a busy production file.

Preserve the before and after inventory, permission changes, restart time, remote-login result, backup result, and Agent outcomes. I also review the old account after the migration. Remove rights no longer needed through the normal Windows ownership process, so the change does not leave an abandoned privileged identity behind.

The useful result is an account with enough access to perform its duties and no unexplained reach beyond them. Repeat the inventory after upgrades and service changes. Names drift less visibly than query plans, but their consequences extend much farther than one slow query.

Related reading on this blog: Running SQL Server Under a Group Managed Service Account and How to Find Service Account for SQL Server and SQL Server Agent? Interview Question of the Week #179.

A service account is not a startup setting, it is the Windows authority behind the running process.

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