NT SERVICE Accounts in sysadmin: What They Are For

Those NT SERVICE logins in sysadmin are not strangers, they are Windows services that SQL Server itself depends on. A security scan flags them and asks you to remove them. Look first at what each one does.

Why a scan flags these logins

A junior DBA walks over with a printed audit report. “Four logins called NT SERVICE are in sysadmin. The report says remove them. Can I?” It is a fair question. Nobody created those logins by hand, and nobody remembers why they are there.

Please do not click Delete yet. These logins were created by SQL Server setup. Each one stands for a Windows service, and some of them keep a feature alive. The queries below only read. They create nothing, so there is nothing to clean up.

List the NT SERVICE logins and their roles

Start with an inventory. This query lists every login whose name starts with NT SERVICE, plus the server role it belongs to. A NULL role means the login is not in any fixed server role.

SELECT p.name AS login_name, r.name AS server_role
FROM sys.server_principals AS p
LEFT JOIN sys.server_role_members AS m ON m.member_principal_id = p.principal_id
LEFT JOIN sys.server_principals AS r ON r.principal_id = m.role_principal_id
WHERE p.name LIKE N'NT SERVICE\%'
ORDER BY p.name, r.name;

On my test instance, five logins came back. The database engine, the Agent, SQLWriter and Winmgmt are in sysadmin. The telemetry login has no role at all. Your list will differ with your edition, your components and whether the instance is named.

Match each login to a service

Each login belongs to a per-service identity. The name stays tied to the Windows service, even when the startup account changes. Named instances add the instance name, such as SQLAgent$ followed by the instance. This query shows which SQL Server services exist and how they run.

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

SELECT SERVERPROPERTY('InstanceName') AS instance_name;

Notice that the Agent on my test instance is set to Manual and shows as Stopped. Its login still sits in sysadmin. A stopped service does not mean an unused login. Start the service tomorrow and it needs that access.

Now put the two lists together. For every sysadmin login that starts with NT SERVICE, ask whether a SQL Server service on this instance uses that exact name.

SELECT p.name AS login_name,
       CASE WHEN EXISTS (SELECT 1 FROM sys.dm_server_services AS s
                         WHERE s.service_account = p.name COLLATE Latin1_General_CI_AS)
            THEN 'yes' ELSE 'no' END AS matches_a_sql_service
FROM sys.server_role_members AS m
JOIN sys.server_principals AS p ON p.principal_id = m.member_principal_id
JOIN sys.server_principals AS r ON r.principal_id = m.role_principal_id
WHERE r.name = N'sysadmin'
  AND p.name LIKE N'NT SERVICE\%'
ORDER BY p.name;

The engine and the Agent say yes. SQLWriter and Winmgmt say no. That does not make them leftovers. They are Windows services that talk to SQL Server, so they never show up in that DMV.

What each one is for

The Agent login lets SQL Server Agent run jobs. Take its access away and the service may start, then fail every job step. SQLWriter supports the SQL Server VSS writer, which snapshot-style backup tools use. If your backups never use VSS, you may not need it. Check before you decide.

Winmgmt supports the WMI provider, which some monitoring tools and Configuration Manager rely on. Three names, three different jobs. Do not apply the same fix to all of them just because they share a prefix.

Save the membership before you touch anything

If you do change something after your review, make undoing it easy. This query writes the statement that puts each membership back. Save the output in your change ticket.

SELECT N'ALTER SERVER ROLE ' + QUOTENAME(r.name) + N' ADD MEMBER ' + QUOTENAME(p.name) + N';' AS restore_statement
FROM sys.server_role_members AS m
JOIN sys.server_principals AS p ON p.principal_id = m.member_principal_id
JOIN sys.server_principals AS r ON r.principal_id = m.role_principal_id
WHERE p.name LIKE N'NT SERVICE\%'
ORDER BY p.name, r.name;

Then test on a copy of the server. Run a job, take a backup, open your monitoring tool. If all three still work, you have an answer you can defend to the auditor.

Decide per account, not per prefix

My advice is simple. Report each login on its own line: what it is, what it needs, and whether you tested a change. Keep real excess rights separate from rights a supported service needs. A clean audit is good. A broken backup is not.

The next time a report names a login you do not know, find out what it does before you decide.

A service login is not spare access, it is a dependency with a name.

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