DBA Scripts: Get Sysadmin Members

July 16, 2026

–

Part of the DBA-Tools Project.

Identify SQL Server Logins With Sysadmin Access

The sysadmin fixed server role provides unrestricted access to a SQL Server instance.

Members of this role can perform any operation on the server, including creating databases, changing security settings, accessing all data, and modifying server configuration. Because of this level of privilege, knowing exactly who has sysadmin access is a basic but important security review.

In many environments, sysadmin membership grows over time. Temporary access becomes permanent, old administrator accounts remain enabled, service accounts are granted excessive permissions, or accounts from previous teams are never removed.

Regularly reviewing sysadmin membership helps ensure privileged access is intentional and still required.

This script returns all members of the SQL Server sysadmin fixed server role, including account type, disabled status, and account creation details. A clean sysadmin list should never contain surprises. If you don’t recognise every account, you have something to investigate.

Why Sysadmin Members Matters

SQL Server security is built around controlling who can perform privileged actions.

The sysadmin role bypasses normal permission checks and effectively provides full control of the SQL Server instance.

Reviewing sysadmin membership helps with:

Security audits.
Access reviews.
Least privilege assessments.
Compliance checks.
New environment handovers.
Investigating unexpected administrative activity.
Identifying stale or unnecessary privileged accounts.

Things I typically look for:

Unexpected user accounts with sysadmin access.
Disabled accounts that should be removed.
Personal accounts used where groups should exist.
Service accounts with excessive permissions.
Old administrator access from previous teams or projects.

A healthy production environment should have a small, understood list of sysadmin members, with every account having a clear reason for requiring that level of access.

Unlike database permissions, sysadmin bypasses almost every security boundary inside SQL Server. Once a login becomes a sysadmin, it effectively owns the instance, making this one of the highest value security checks any DBA can perform.

When to Run This Script

Run this script during:

Routine SQL Server security reviews.
New server onboarding.
Access audits.
Compliance assessments.
Team or ownership changes.
After security incidents.
Before production go-lives.
Regular DBA health checks.

The Script

Run the following script against your SQL Server instance.

/*
Script Name : Get-SysadminMembers
Category    : security-and-permissions
Purpose     : List members of the sysadmin fixed server role for audits and privilege review.
Author      : Peter Whyte (https://sqldba.blog)
Requires    : VIEW ANY DATABASE
HealthCheck : Yes
*/

-- SAFE:ReadOnly
-- IMPACT:Low

SET NOCOUNT ON;

SELECT
    sp.name AS login_name,
    sp.type_desc,
    sp.is_disabled,
    sp.create_date,
    sp.modify_date
FROM sys.server_principals sp
JOIN sys.server_role_members srm 
    ON sp.principal_id = srm.member_principal_id
JOIN sys.server_principals sr 
    ON srm.role_principal_id = sr.principal_id
WHERE sr.name = 'sysadmin'
ORDER BY sp.name;

This joins sys.server_principals with sys.server_role_members to return every login assigned to the sysadmin fixed server role, together with its login type, disabled status and creation metadata. Internal certificate principals are excluded automatically by the role membership.

How To Run From The Repo

Clone DBA Tools, initialise the environment and run the script:

# Clone dba-tools repo:
git clone https://github.com/peterwhyte-lgtm/dba-tools

# Initialize environment:
cd dba-tools
.\Initialize-Environment.ps1

# List members of the sysadmin server role:
.\run.ps1 Get-SysadminMembers

# Run against a remote SQL Server:
.\run.ps1 Get-SysadminMembers -ServerInstance SQLSERVER01

This script lives in the repo at:

Example Output

login_name	type_desc	is_disabled	create_date	modify_date
DBA_Junior	SQL_LOGIN	False	15/02/2026 16:46:43	15/02/2026 16:46:43
DBA_ServiceAccount	SQL_LOGIN	False	15/02/2026 16:46:43	15/02/2026 16:46:43
DemoAdminUser	SQL_LOGIN	False	15/02/2026 16:45:57	15/02/2026 16:45:57
DemoDisabledAdmin	SQL_LOGIN	True	15/02/2026 16:45:57	15/02/2026 16:45:57
DemoOpsUser	SQL_LOGIN	False	15/02/2026 16:45:57	15/02/2026 16:45:57
HPAI01\Peter	WINDOWS_LOGIN	False	30/01/2026 00:05:40	30/01/2026 00:05:40
NT Service\MSSQLSERVER	WINDOWS_LOGIN	False	30/01/2026 00:05:40	30/01/2026 00:05:40
NT SERVICE\SQLSERVERAGENT	WINDOWS_LOGIN	False	30/01/2026 00:05:40	30/01/2026 00:05:40

Understanding the Results

The output shows every login currently assigned to the sysadmin server role.

login_name

The SQL Server login or Windows account with sysadmin access.

Review whether each account:

Is still required.
Belongs to the correct team.
Should be a direct login or a group membership.

type_desc

Shows whether the principal is:

SQL_LOGIN – SQL authenticated account.
WINDOWS_LOGIN – Windows authenticated account.

In many enterprise environments, Windows groups are preferred because access can be managed through Active Directory rather than individual SQL Server permissions.

If a WINDOWS_GROUP appears, remember that every current and future member of that Active Directory group inherits sysadmin rights. The SQL Server output only shows the group itself – you’ll need to review the group’s membership in Active Directory separately.

is_disabled

Shows whether the login is currently disabled. A disabled login in the sysadmin role is still worth removing. If it’s ever re-enabled, it immediately regains unrestricted access.

Disabled privileged accounts should still be reviewed. They may represent:

Former administrators.
Decommissioned applications.
Temporary access that was never removed.

create_date and modify_date

Useful timestamps when investigating older environments.

They can help identify:

Recently added privileged accounts.
Accounts created during migrations.
Changes made during access reviews.

Older privileged accounts that have never been modified are often remnants of previous projects, migrations or administrators and deserve closer review.

Best Practices

Good SQL Server security hygiene usually means:

Keep sysadmin membership as small as practical.
Prefer Windows groups over individual administrator accounts.
Avoid granting sysadmin to application service accounts.
Remove unused privileged accounts.
Review access regularly.
Document why each sysadmin member exists.
Review after every production support engagement.
Export results periodically as an audit baseline.
Treat every new sysadmin member as a change requiring approval.

The goal is not to eliminate sysadmin access. DBAs and operational teams need appropriate administrative access. The goal is ensuring every privileged account is intentional.

Related Scripts

You may also find these scripts useful:

Server Role Members
Database Permissions
Database Role Members
Failed Login Summary
Login Last Activity
Login Permissions
Orphaned Users
User Permissions Audit
Weak Login Settings

Frequently Asked Questions

What is the sysadmin role in SQL Server?

sysadmin is a fixed server role that provides unrestricted administrative access to a SQL Server instance. Members can perform any action on the server.

Should application accounts have sysadmin access?

Generally no.

Application accounts should normally have only the permissions required for the application workload.

Why don’t I see members of Windows groups?

SQL Server stores only the Windows group as the sysadmin member. Individual users are resolved by Active Directory, so you’ll need to inspect the group’s membership outside SQL Server.

Should every DBA be a sysadmin?

DBAs typically require elevated access, but membership should still be controlled, documented and reviewed regularly.

Is removing sysadmin access enough for security?

No.

Security reviews should also include database permissions, server roles, login activity and authentication settings.

Summary

Reviewing sysadmin membership is one of the simplest SQL Server security checks but one of the most important.

Over time, privileged access can accumulate through temporary requests, migrations, team changes and operational workarounds. Without regular reviews, SQL Server instances can end up with more administrators than intended.

This script provides a quick view of every login with sysadmin access, helping DBAs identify unexpected privileged accounts and maintain better access control.

Run this script regularly, keep historical outputs where appropriate, and investigate every unexpected account. A sysadmin list should never contain surprises.

Blog Categories

Comments

Leave a Reply Cancel reply