My Service Account Has Domain Admin Rights. How Do I Remove Them Without Breaking Production?

Before touching any permissions, you need to know exactly what the service account accesses. Assume the documentation is wrong or missing: verify against actual usage.

Enable account audit logging for the service account:

In Active Directory, configure detailed auditing for the specific account:

# Find the service account's DN
Get-ADUser -Identity "svc-sql" -Properties DistinguishedName

Then enable 'Audit Directory Service Access' in your Group Policy so any object accessed by this account is logged. This is broad and generates volume: run it for 5-7 business days to capture a full operational cycle including any weekly or monthly scheduled tasks.

Review Windows Security Event ID 4624 (logon) for the account:

# On each domain controller and server where the account might be used
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} |
    Where-Object { $_.Properties[5].Value -eq 'svc-sql' } |
    Select-Object TimeCreated, @{N='LogonType';E={$_.Properties[8].Value}}, @{N='SourceIP';E={$_.Properties[18].Value}}

This tells you: which machines the account is authenticating to, what logon type (interactive vs. network vs. service), and at what times. Build a list of every machine and service that uses this account.

Identify what the service actually does with DA rights:

For each machine identified:

1. What service or application runs as this account?
2. What does that service do: read files, write to a database, query AD, manage other services?
3. Does that function actually require DA, or was DA given because the setup guide said so?

Most service accounts with DA rights were given DA for one of three reasons:

• The installer required domain admin credentials (but the service itself does not)
• Someone gave DA to avoid debugging specific permission errors during setup
• The service was migrated from a less secure environment and DA was never revisited

Common operations that do NOT require Domain Admin:

• Reading from a SQL database (requires database-level read rights, not AD rights)
• Writing log files to a file share (requires share/NTFS permissions)
• Querying AD for user attributes (requires read access to specific OU, not DA)
• Running scheduled tasks (requires local admin on the target machine, not DA)

For each operation you discovered in Phase 1, determine the minimum permission required.

Common permission mappings:

Test minimum permissions without removing DA yet:

Create a new test account with only the minimum permissions you mapped:

New-ADUser -Name "svc-sql-test" -SamAccountName "svc-sql-test" -UserPrincipalName "svc-sql-test@domain.com" -AccountPassword (ConvertTo-SecureString 'ComplexP@ssw0rd!' -AsPlainText -Force) -Enabled $true

Grant this test account only the minimum permissions, then verify each operation works correctly using the test account in a non-production environment. This validation step is the difference between a smooth migration and an emergency rollback.

Never remove DA from a production service account without a rollback plan. The rollback plan is simple: restore DA membership. Document the restore command before you execute the migration:

# Rollback command (have this ready before removing DA)
Add-ADGroupMember -Identity "Domain Admins" -Members "svc-sql"

Migration steps:

1. Grant the minimum permissions to the existing svc-sql account (do not remove DA yet). Add the specific delegated permissions, share permissions, and group memberships identified in Phase 2.

2. Restart the dependent services and monitor for errors for 48 hours. Watch application event logs on every machine where the service runs. Any 'Access Denied' or authentication errors surface the permissions you missed.

3. After 48-72 hours with no errors, remove the Domain Admins group membership:

Remove-ADGroupMember -Identity "Domain Admins" -Members "svc-sql" -Confirm:$false

1. Force a Kerberos ticket refresh for the service account: existing TGTs carry the old group memberships for up to 10 hours. Force a logoff or service restart on each machine where the account is used.

2. Monitor for 48 more hours with the DA membership removed. This is the critical window: any missed permission surfaces as an error.

3. If any error appears: restore DA immediately using the rollback command, identify the missed permission, add the specific minimum permission, and repeat the removal after a 24-hour wait.

After successful migration: convert to a Group Managed Service Account (gMSA).

A gMSA is an AD-managed service account with a 120-character randomly generated password that rotates automatically every 30 days. No human ever knows the password, eliminating the Kerberoasting risk and the password management burden entirely.

# Create gMSA
New-ADServiceAccount -Name "gMSA-sql" -DNSHostName "gMSA-sql.domain.com" -PrincipalsAllowedToRetrieveManagedPassword "SERVER01$", "SERVER02$"

# Install on target server
Install-ADServiceAccount -Identity "gMSA-sql"

# Configure the service to use gMSA (use 'domain\gMSA-sql$' as the account, blank password)

The gMSA replaces the original service account permanently. The old account can then be disabled and eventually deleted after a 30-day observation period confirming no dependencies remain.

Occasionally, an application legitimately requires domain-level privileges: AD management tools, identity governance platforms, and some backup solutions have legitimate reasons to access AD objects broadly.

If after Phase 1 discovery you find the service actually requires broad AD access, the remediation is not 'give it DA and accept the risk.' The remediation options are:

Option 1: Delegate specific AD permissions rather than using DA group membership. Even if the service needs to read and write many AD objects, it probably does not need all DA capabilities (like adding members to privileged groups or modifying schema). Use AD delegation to grant exactly what is needed without DA group membership.

Option 2: Use Microsoft Entra ID (if applicable). Modern identity governance platforms often have Entra ID connectors that operate with service principal permissions rather than on-premises DA rights.

Option 3: Migrate to an AD Tier 0 account with hardened controls. If DA is genuinely required, the account should be a Tier 0 privileged account subject to Privileged Access Workstation (PAW) requirements: only used from hardened PAW machines, MFA required for any interactive use, all interactive sessions logged and reviewed.

The goal is that no service account with broad AD access also has a Kerberoastable SPN registered. If DA is genuinely required, at minimum remove the SPN so the account cannot be targeted via Kerberoasting: Set-ADUser -Identity "svc-ad-mgmt" -ServicePrincipalNames @{Remove="MSSQLSvc/server:1433"}