SQL Server Service Account Losing Group Permissions: Research, Diagnosis, and Fixes

---

It is a Monday morning. SQL Server was running fine on Friday. Nothing was deployed over the weekend. But now SQL Server will not start, or it starts but Agent jobs fail, or backups are writing to the wrong path. You check the service account and everything looks correct. The account exists, the password has not changed, and there are no obvious errors in SQL Server Configuration Manager.

Then you find it. Group Policy ran over the weekend. The service account is no longer a member of the local Windows groups SQL Server needs. Or the local security policy rights that SQL Server added at setup time have been wiped out and replaced with a domain-level policy that does not include the service account. The SQL Server service is starting without the permissions it needs to function.

This problem is more common than most organizations realize, and it is almost always caused by the interaction between Group Policy and the local permissions SQL Server configures at installation time. This article explains what permissions SQL Server requires, why they disappear, how to diagnose each scenario, and how to fix and prevent recurrence.

1 What Permissions SQL Server Needs and Why Beginner

When SQL Server setup runs, it configures a specific set of Windows permissions for each service account. These are not optional. Without them, the services either will not start or will start but fail silently in ways that surface as intermittent, confusing errors hours or days later.

SQL Server manages these permissions through two separate mechanisms: local security policy rights (also called user rights assignments) and membership in local Windows groups that SQL Server creates. Both are required. Losing either one produces failures.

Local Security Policy Rights Required by the Database Engine

Right Name	Policy Name	Why SQL Server Needs It
Log on as a service	SeServiceLogonRight	Without this the Windows Service Control Manager will not start the SQL Server service. This is the first thing checked at startup.
Replace a process-level token	SeAssignPrimaryTokenPrivilege	Required when SQL Server spawns worker processes or changes the security context of threads. Missing this produces errors in the SQL Server error log at startup.
Bypass traverse checking	SeChangeNotifyPrivilege	Allows the service account to navigate directory paths even if it does not have explicit permissions on every parent folder. Losing this produces access denied errors when SQL Server tries to read or write data and log files.
Adjust memory quotas for a process	SeIncreaseQuotaPrivilege	Required for SQL Server to adjust memory allocation. Missing this can prevent startup or cause memory management failures under load.

SQL Server Agent requires the same four rights for its service account. If you run the engine and Agent under different accounts, both accounts need all four.

2 The Local Groups SQL Server Creates at Setup Beginner

In addition to the security policy rights, SQL Server setup creates local Windows groups on the host machine and grants those groups the file system, registry, and Windows permissions the service needs. SQL Server then adds the service account to these groups. This indirection means that when permissions need to be granted to the service account, they go through the group rather than directly to the account, which makes permission management more maintainable.

The group names follow this naming convention:

• Database Engine: SQLServerMSSQLUser$MACHINENAME$INSTANCENAME
• SQL Server Agent: SQLServerSQLAgentUser$MACHINENAME$INSTANCENAME
• SQL Server Browser: SQLServerSQLBrowserUser$MACHINENAME
• Analysis Services: SQLServerMSASUser$MACHINENAME$INSTANCENAME
• Reporting Services: SQLServerReportServerUser$MACHINENAME$INSTANCENAME

For the default instance on a server named SQLPROD01 the Database Engine group would be SQLServerMSSQLUser$SQLPROD01$MSSQLSERVER. For a named instance called SQL2022, it would be SQLServerMSSQLUser$SQLPROD01$SQL2022.

-- Find the local groups SQL Server created on this machine
-- Run this in PowerShell on the SQL Server host

Get-LocalGroup | Where-Object { $_.Name -like "SQLServer*" } |
    Select-Object Name, Description |
    Format-Table -AutoSize

-- See who is currently in each SQL Server group:
Get-LocalGroupMember -Group "SQLServerMSSQLUser$env:COMPUTERNAME$MSSQLSERVER" |
    Select-Object Name, ObjectClass, PrincipalSource

3 Common Symptoms and What They Mean Beginner

4 Cause 1: Group Policy Overwrites Local Security Policy Intermediate

This is the most common and most misunderstood cause. Domain Group Policy has higher precedence than local security policy. When a GPO is applied that defines the “Log on as a service” user right, it completely replaces the local setting rather than merging with it. If the GPO lists only BUILTIN\Administrators for that right and does not include the SQL Server service account, the service account loses the right on the next Group Policy refresh.

The critical detail: Group Policy does not remove the right individually from the service account. It replaces the entire list of accounts that have the right. The service account is simply not in the new list.

This most commonly happens when a security team or infrastructure team creates or modifies a GPO for “Log on as a service” to restrict which accounts can run as services, without realizing that SQL Server service accounts are in the existing local policy and must be explicitly included in the domain policy.

# PowerShell: check current User Rights Assignments on the local machine
# This shows who currently has each right -- compare against what SQL Server needs

# Check Log on as a service (SeServiceLogonRight)
$seceditOutput = secedit /export /cfg "$env:TEMP\secpol.cfg" /quiet
Get-Content "$env:TEMP\secpol.cfg" | Where-Object { $_ -match "SeServiceLogonRight" }

# Better approach: use the Carbon PowerShell module or ntrights.exe
# Install Carbon: Install-Module Carbon -Scope CurrentUser
Import-Module Carbon
Get-CPrivilege -Identity "DOMAIN\SQLSvcAccount"
# Returns all rights currently held by this account

# Or check via secpol.msc GUI:
# Local Security Policy > Security Settings > Local Policies > User Rights Assignment
# Look for: Log on as a service, Replace a process level token,
#           Bypass traverse checking, Adjust memory quotas for a process

5 Cause 2: Service Account Removed from SQL Server Local Groups Intermediate

The SQLServerMSSQLUser local group holds the ACEs (Access Control Entries) for the file system paths SQL Server needs: data directories, log directories, backup directories, and the SQL Server program directory. When the service account is removed from this group, SQL Server loses read and write access to these paths.

This typically happens during a security audit when an administrator reviews local group membership and removes accounts that “should not be there,” not knowing that these are SQL Server-specific groups that must contain the service account. It also happens when a service account is changed manually in Services.msc rather than through SQL Server Configuration Manager, leaving the old account in the group and the new account missing from it.

# Check if the service account is in the correct local groups
# Replace the group name with the actual group name for your instance

$dbEngineGroup = "SQLServerMSSQLUser$" + $env:COMPUTERNAME + "$MSSQLSERVER"
$agentGroup    = "SQLServerSQLAgentUser$" + $env:COMPUTERNAME + "$MSSQLSERVER"

Write-Host "Database Engine group members:"
Get-LocalGroupMember -Group $dbEngineGroup | Select-Object Name, ObjectClass

Write-Host "`nAgent group members:"
Get-LocalGroupMember -Group $agentGroup | Select-Object Name, ObjectClass

# Expected: your service account (e.g., DOMAIN\SQLSvcAcct or NT SERVICE\MSSQLSERVER)
# should appear in the Database Engine group
# The Agent service account should appear in the Agent group

6 Cause 3: Password Change Outside SQL Server Configuration Manager Beginner

When a domain service account password is changed in Active Directory Users and Computers without also updating it in SQL Server Configuration Manager, the service fails to start on the next restart. The Service Control Manager tries to start the service with the stored credentials, the credentials fail authentication, and the service stops.

This is not technically a “permissions lost” problem but it presents identically and is one of the most common reasons SQL Server suddenly will not start. Always change service account passwords through SQL Server Configuration Manager, never through Active Directory alone.

-- Diagnostic: check which account each SQL Server service is running under
-- Run in PowerShell on the SQL Server host

Get-WmiObject Win32_Service |
    Where-Object { $_.Name -like "MSSQL*" -or $_.Name -like "SQLAgent*" -or $_.Name -like "SQLBrowser" } |
    Select-Object Name, StartName, State, StartMode |
    Format-Table -AutoSize

-- If State = "Stopped" and the start account looks correct,
-- the problem is almost certainly the password or a missing right

7 Cause 4: Security Hardening Removes the Account from Local Administrators Intermediate

Some organizations run SQL Server service accounts as members of the local Administrators group, which is a security anti-pattern. When a security team correctly removes the service account from local Administrators as part of a hardening exercise, SQL Server may fail because it was relying on administrator-level permissions for operations it should have been getting through the SQL Server local groups and security policy rights.

The service account does not need to be a local administrator. It needs the four specific policy rights and membership in the SQL Server local groups. If SQL Server was configured correctly at setup, removing it from local Administrators changes nothing. If it was relying on administrative rights for file access or registry access, removing it exposes the misconfiguration.

The fix is not to add the account back to Administrators. The fix is to ensure the SQL Server local groups and security policy rights are correctly configured, as described in Sections 11 and 12.

8 Cause 5: Service Account Changed Without Using SQL Server Configuration Manager Beginner

SQL Server Configuration Manager does much more than just update the startup account. When you change a service account through Configuration Manager, it also adds the new account to the SQL Server local groups, grants it the required security policy rights, and updates ACLs on the data, log, and program directories. When you change the account in Windows Services (services.msc) or Task Manager instead, none of that happens. The new account starts the service but has none of the permissions it needs.

# Open SQL Server Configuration Manager via PowerShell:
Start-Process "SQLServerManager16.msc"   # SQL Server 2022
Start-Process "SQLServerManager15.msc"   # SQL Server 2019
Start-Process "SQLServerManager14.msc"   # SQL Server 2017

# Or navigate to it manually:
# C:\Windows\SysWOW64\mmc.exe /32 SQLServerManager16.msc

# After changing the account through Configuration Manager:
# 1. Go to SQL Server Services
# 2. Right-click the service > Properties > Log On tab
# 3. Enter the new account and password
# 4. Click OK and restart the service
# Configuration Manager handles all permission updates automatically

9 Reading the Event Log and SQL Server Error Log Beginner

The Windows System event log and the SQL Server error log together tell you exactly what failed. Read both before making any changes. The error messages are specific enough to point you directly at the missing permission.

# PowerShell: read recent SQL Server-related errors from the Windows Event Log

# System log: service start failures
Get-WinEvent -LogName System |
    Where-Object {
        $_.ProviderName -eq "Service Control Manager" -and
        $_.LevelDisplayName -eq "Error" -and
        $_.Message -like "*SQL*"
    } |
    Select-Object TimeCreated, Message |
    Sort-Object TimeCreated -Descending |
    Select-Object -First 20 | Format-List

# Application log: SQL Server startup and permission errors
Get-WinEvent -LogName Application |
    Where-Object {
        $_.ProviderName -like "MSSQLSERVER*" -and
        $_.LevelDisplayName -in "Error", "Warning"
    } |
    Select-Object TimeCreated, Message |
    Sort-Object TimeCreated -Descending |
    Select-Object -First 20 | Format-List

Key Error Messages and What They Point To

Error Message	Root Cause	Fix Section
“The service did not start due to a logon failure”	Wrong password, account locked, or account disabled in AD	Section 13
“Error 1069: The service did not start due to a logon failure”	Missing SeServiceLogonRight or password mismatch	Section 11
“initerrlog: Could not open error log file. Operating system error = 3”	Service account lost access to the SQL Server log directory	Section 12
“Access is denied” in SQL Server error log at startup	Service account not in SQLServerMSSQLUser local group	Section 12
“Error 1053: The service did not respond in a timely fashion”	Missing SeAssignPrimaryTokenPrivilege or SeIncreaseQuotaPrivilege	Section 11

-- Read the SQL Server error log directly via T-SQL after service starts
-- (if the service is currently running)
EXEC sp_readerrorlog 0, 1, 'Error';
EXEC sp_readerrorlog 0, 1, 'Access';
EXEC sp_readerrorlog 0, 1, 'permission';

-- Read the SQL Server error log file directly if the service will not start
-- Look in the SQL Server log directory (default path example):
-- C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Log\ERRORLOG
-- Open with Notepad or use PowerShell:
Get-Content "C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Log\ERRORLOG" |
    Select-String "Error|Access|permission|failed|denied" |
    Select-Object -Last 50

10 Checking Current Permissions and Group Membership Intermediate

Before applying any fix, run a complete check of the current state. This tells you exactly what is missing so you do not apply unnecessary changes.

# Complete permission audit for SQL Server service accounts
# Run on the SQL Server host as a local administrator

$svcAccount  = "DOMAIN\SQLSvcAccount"   # your actual service account
$instanceName = "MSSQLSERVER"            # or your named instance name
$machineName  = $env:COMPUTERNAME

# 1. Check Windows service status and startup account
Get-WmiObject Win32_Service |
    Where-Object { $_.Name -like "*MSSQL*" -or $_.Name -like "*SQLAgent*" } |
    Select-Object Name, StartName, State

# 2. Check local group membership
$groups = @(
    "SQLServerMSSQLUser`$$machineName`$$instanceName",
    "SQLServerSQLAgentUser`$$machineName`$$instanceName"
)
foreach ($group in $groups) {
    Write-Host "`nGroup: $group"
    try {
        Get-LocalGroupMember -Group $group | Select-Object Name, ObjectClass
    } catch {
        Write-Warning "Group not found: $group"
    }
}

# 3. Check User Rights Assignments via secedit export
secedit /export /cfg "$env:TEMP\sqlcheck_secpol.cfg" /quiet
$secpol = Get-Content "$env:TEMP\sqlcheck_secpol.cfg"
$rights = @(
    "SeServiceLogonRight",
    "SeAssignPrimaryTokenPrivilege",
    "SeChangeNotifyPrivilege",
    "SeIncreaseQuotaPrivilege"
)
Write-Host "`nCurrent User Rights Assignments:"
foreach ($right in $rights) {
    $line = $secpol | Where-Object { $_ -match $right }
    Write-Host "  $right`: $line"
}
Remove-Item "$env:TEMP\sqlcheck_secpol.cfg" -Force

11 Fix 1: Restore Missing Local Security Policy Rights Beginner

If the security policy rights were removed by Group Policy, adding them back locally will only hold until the next Group Policy refresh. The permanent fix requires working with your infrastructure team to include the SQL Server service accounts in the domain GPO. However the local fix gets SQL Server running immediately while you coordinate with the team.

Option A: Using Local Security Policy GUI (secpol.msc)

1. Open Local Security Policy (run secpol.msc as administrator)
2. Navigate to Security Settings > Local Policies > User Rights Assignment
3. Double-click Log on as a service
4. Click Add User or Group and add your SQL Server service account
5. Repeat for: Replace a process level token, Bypass traverse checking, Adjust memory quotas for a process
6. Restart the SQL Server service

Option B: Using PowerShell (ntrights or secedit)

# Grant User Rights Assignments via PowerShell
# Using the ntrights.exe approach (available as part of Windows Server toolkit)
# Or using the Carbon PowerShell module: Install-Module Carbon

# Using Carbon module (cleanest approach):
Import-Module Carbon

$svcAccount = "DOMAIN\SQLSvcAccount"

# Grant all four required rights
Grant-CPrivilege -Identity $svcAccount -Privilege SeServiceLogonRight
Grant-CPrivilege -Identity $svcAccount -Privilege SeAssignPrimaryTokenPrivilege
Grant-CPrivilege -Identity $svcAccount -Privilege SeChangeNotifyPrivilege
Grant-CPrivilege -Identity $svcAccount -Privilege SeIncreaseQuotaPrivilege

# Verify:
Get-CPrivilege -Identity $svcAccount

# Also grant the Agent service account if it runs under a different account:
$agentAccount = "DOMAIN\SQLAgentAccount"
Grant-CPrivilege -Identity $agentAccount -Privilege SeServiceLogonRight
Grant-CPrivilege -Identity $agentAccount -Privilege SeAssignPrimaryTokenPrivilege
Grant-CPrivilege -Identity $agentAccount -Privilege SeChangeNotifyPrivilege
Grant-CPrivilege -Identity $agentAccount -Privilege SeIncreaseQuotaPrivilege

12 Fix 2: Restore Missing Local Group Membership Intermediate

If the service account was removed from the SQL Server local groups, add it back. This restores file system and registry access without needing to configure individual ACLs on every directory.

# Add the service account back to the SQL Server local groups
# Replace placeholders with your actual values

$svcAccount  = "DOMAIN\SQLSvcAccount"
$machineName  = $env:COMPUTERNAME
$instanceName = "MSSQLSERVER"    # or your named instance

# Add to Database Engine group
Add-LocalGroupMember `
    -Group  "SQLServerMSSQLUser`$$machineName`$$instanceName" `
    -Member $svcAccount

# Add to SQL Server Agent group (if Agent runs under a different account):
$agentAccount = "DOMAIN\SQLAgentAccount"
Add-LocalGroupMember `
    -Group  "SQLServerSQLAgentUser`$$machineName`$$instanceName" `
    -Member $agentAccount

# Verify membership was added:
Get-LocalGroupMember -Group "SQLServerMSSQLUser`$$machineName`$$instanceName"

13 Fix 3: Correct a Service Account Change Done Outside Configuration Manager Intermediate

If someone changed the service account through Windows Services rather than SQL Server Configuration Manager, the new account is missing all the permissions. The cleanest fix is to go back into SQL Server Configuration Manager and re-enter the account credentials. Configuration Manager will detect the new account, add it to the SQL Server local groups, grant it the required policy rights, and update the service ACLs.

# If you cannot open Configuration Manager, fix the account manually:
# 1. Grant the four policy rights to the new account (Section 11)
# 2. Add the new account to the SQL Server local groups (Section 12)
# 3. Grant NTFS permissions on the data, log, and backup directories:

$newSvcAccount   = "DOMAIN\NewSQLSvcAccount"
$dataPath        = "D:\SQLData"
$logPath         = "D:\SQLLogs"
$backupPath      = "E:\SQLBackups"
$sqlProgramPath  = "C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER"

# Grant full control to data and log directories
# (the local group ACEs should handle this, but if the group was also lost,
#  you may need to set file system permissions directly)
icacls $dataPath   /grant "${newSvcAccount}:(OI)(CI)F" /T
icacls $logPath    /grant "${newSvcAccount}:(OI)(CI)F" /T
icacls $backupPath /grant "${newSvcAccount}:(OI)(CI)M" /T  # Modify for backups

# Restart the service after permissions are in place
Restart-Service MSSQLSERVER -Force
Get-Service MSSQLSERVER | Select-Object Status

14 Fix 4: Use a gMSA to Eliminate Password and Permission Problems Permanently Advanced

A Group Managed Service Account (gMSA) is a special Active Directory account type designed for services. Active Directory manages the password automatically, rotating it on a schedule (default every 30 days) without any administrator involvement. The service never fails due to a password change because the change happens transparently at the OS level.

SQL Server supports gMSAs as service accounts. When you configure SQL Server to run under a gMSA, you eliminate the entire category of password-related service failures and reduce the attack surface because the password is never known to any human.

# Creating and configuring a gMSA for SQL Server
# Run on a Domain Controller or with AD PowerShell module

# Step 1: Create the gMSA in Active Directory
New-ADServiceAccount `
    -Name              "SQLSvcgMSA" `
    -DNSHostName       "SQLSvcgMSA.yourdomain.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "SQLServerHosts"
    # SQLServerHosts = an AD security group containing the SQL Server computer accounts

# Step 2: Install the gMSA on the SQL Server host
# Run on the SQL Server machine:
Install-ADServiceAccount -Identity "SQLSvcgMSA"

# Step 3: Verify the gMSA is accessible from this machine:
Test-ADServiceAccount -Identity "SQLSvcgMSA"
# Returns: True if the machine can retrieve the managed password

# Step 4: In SQL Server Configuration Manager:
# Go to SQL Server (MSSQLSERVER) > Properties > Log On
# Account Name: YOURDOMAIN\SQLSvcgMSA$   (note the trailing $ sign)
# Password: leave blank (gMSA passwords are managed by AD)
# Click OK and restart the service

# Step 5: Verify the service started under the gMSA:
Get-WmiObject Win32_Service -Filter "Name='MSSQLSERVER'" |
    Select-Object Name, StartName, State

15 Working With Group Policy Instead of Against It Intermediate

The right long-term solution to Group Policy overwriting SQL Server’s local security policy rights is not to keep fixing the local policy after each GPO refresh. It is to include the SQL Server service accounts in the domain GPO so the right settings are distributed by Group Policy rather than conflicting with it.

Work with your Active Directory or infrastructure team to update the GPO that defines “Log on as a service” to explicitly include the SQL Server service accounts. Present it this way: the GPO is currently resetting the local setting that SQL Server setup configured. The fix is to include the SQL Server accounts in the GPO definition so that domain policy and SQL Server’s requirements are aligned.

# Identify which GPO is controlling the conflicting User Rights Assignment
# Run on the SQL Server host as a domain admin

# Run gpresult to see applied GPOs and which policy controls SeServiceLogonRight:
gpresult /H "$env:TEMP\gpresult.html" /F
# Open the generated HTML file and search for "Log on as a service"
# The "Winning GPO" column shows which GPO is controlling the setting

# Or use the faster command-line version:
gpresult /R | Select-String "Log on as a service" -Context 5

# For a remote server:
gpresult /S SQLServer01 /R /SCOPE COMPUTER | Select-String "SeServiceLogonRight" -Context 3

The GPO Change Request

When you raise the change request with the AD team, provide them with the exact account names to add and the exact right names to include. Be specific:

• Account: DOMAIN\SQLSvcAccount (the service account)
• Also include: NT SERVICE\MSSQLSERVER (per-service SID for default instance)
• Rights needed: SeServiceLogonRight, SeAssignPrimaryTokenPrivilege, SeChangeNotifyPrivilege, SeIncreaseQuotaPrivilege

16 Recommended Service Account Setup and Monitoring Advanced

These are the settings and monitoring practices that prevent this problem from recurring rather than repeatedly fixing it.

Recommended Account Types in Priority Order

Account Type	Recommendation	Notes
Group Managed Service Account (gMSA)	Best option for domain environments	Automatic password management, no manual intervention needed
Virtual Account (NT SERVICE\MSSQLSERVER)	Best option for standalone servers	No password, limited to local machine, no AD required
Dedicated low-privilege domain account	Acceptable with proper GPO alignment	Requires password management; use LAPS or vault-managed password
Local user account	Avoid for production	Cannot be used for network access, Kerberos, or linked servers
Local System / Network Service	Do not use in production	Over-privileged, security risk, cannot differentiate SQL instances
Domain Administrator	Never	Excessive privilege, violates least privilege principle, security audit finding

Monitoring Script: Daily Permission Verification

# Schedule this as a SQL Server Agent job or Task Scheduler task
# Run daily before business hours -- alerts if permissions look wrong

$svcAccount  = "DOMAIN\SQLSvcAccount"
$machineName  = $env:COMPUTERNAME
$instanceName = "MSSQLSERVER"
$alertEmail   = "dba@yourorg.com"
$issues       = @()

# Check 1: Service is running
$svc = Get-Service "MSSQLSERVER" -ErrorAction SilentlyContinue
if ($svc.Status -ne "Running") {
    $issues += "CRITICAL: SQL Server service is not running"
}

# Check 2: Service account has SeServiceLogonRight
secedit /export /cfg "$env:TEMP\check_secpol.cfg" /quiet
$secpol = Get-Content "$env:TEMP\check_secpol.cfg"
$logonRight = $secpol | Where-Object { $_ -match "SeServiceLogonRight" }
if ($logonRight -notmatch [regex]::Escape($svcAccount) -and
    $logonRight -notmatch "NT SERVICE\\MSSQLSERVER") {
    $issues += "WARNING: Service account may be missing SeServiceLogonRight"
}
Remove-Item "$env:TEMP\check_secpol.cfg" -Force

# Check 3: Service account in SQL Server local group
$groupName = "SQLServerMSSQLUser`$$machineName`$$instanceName"
$members = Get-LocalGroupMember -Group $groupName -ErrorAction SilentlyContinue |
    Select-Object -ExpandProperty Name
if ($members -notcontains $svcAccount) {
    $issues += "WARNING: Service account is not in $groupName"
}

# Alert if any issues found
if ($issues.Count -gt 0) {
    $body = "SQL Server permission check on $machineName`:`n`n" + ($issues -join "`n")
    Send-MailMessage `
        -To         $alertEmail `
        -From       "sqlmonitor@yourorg.com" `
        -Subject    "SQL Server Permission Alert: $machineName" `
        -Body       $body `
        -SmtpServer "smtp.yourorg.com"
    Write-Warning $body
} else {
    Write-Host "All permission checks passed on $machineName" -ForegroundColor Green
}

References

• Microsoft Docs: Configure Windows Service Accounts and Permissions (SQL Server 2016 and later)
• Microsoft Docs: Configure Windows Service Accounts and Permissions (SQL Server 2025)
• Microsoft Docs: Group Managed Service Accounts Overview
• Microsoft Q&A: Group Policy Settings for Database Service Accounts
• Microsoft Q&A: SQL Service Account Group Policy Permissions
• SQL Authority: Unable to Start SQL When Service Account Removed from Local Administrators
• Microsoft Docs: Change the Service Startup Account (SQL Server Configuration Manager)
• SQLYARD: SQL Server Orphan Users Guide
• SQLYARD: SQL Server DBA Health Check Toolkit