Secure Active Directory service accounts: gMSA, SPNs and delegation

Give each service identity a clear scope

A forgotten service account can retain sensitive access for years. Sharing a password across applications makes rotation difficult, while excessive privileges increase the impact of a compromised server. Start by assigning every identity a purpose, an owner and the minimum resources it needs.

This guide covers Windows services integrated with Active Directory. Examples use the fictional corp.contoso.com domain. They provide a targeted configuration workflow, not a substitute for validating each application's dependencies and permissions.

• Microsoft — On-premises service accounts ↗

Choose the right account type

A gMSA lets Windows manage its password. It does not remove privileges or fix application permissions. Use a separate identity for each application and security boundary; avoid a universal gMSA shared across production, development and administration tools.

Confirm support for the product and version. Windows services, IIS pools and scheduled tasks do not all use the same configuration procedure. The cluster service itself and applications hosted on a cluster are also different cases.

• Microsoft — gMSA overview ↗

1. Find actual dependencies before changing identities

A svc_* naming convention is not an inventory. Start with applications and their owners, then identify services, tasks, IIS pools, SQL connections, shares, scripts, vaults and third-party tools. An account without an SPN may still run a task or connector.

Record hosts, local and remote permissions, dependencies, execution frequency and a success test for each use. A monthly task missing from recent logs does not prove that its account is unused.

• Run with appropriate read permissions; results may be incomplete without elevation.
• Store results in a restricted location: they describe identities and architecture.
• Do not export passwords, private keys or the msDS-ManagedPassword attribute.

Get-CimInstance Win32_Service |
  Select-Object Name,State,StartMode,StartName

Get-ScheduledTask | Select-Object TaskPath,TaskName,
  @{Name='RunAs';Expression={$_.Principal.UserId}},
  @{Name='LogonType';Expression={$_.Principal.LogonType}}

# On an IIS server with the WebAdministration module available
Import-Module WebAdministration
Get-ChildItem IIS:\AppPools | Select-Object Name,
  @{Name='IdentityType';Expression={$_.processModel.identityType}},
  @{Name='UserName';Expression={$_.processModel.userName}}

2. Check AD and KDS prerequisites

Validate supported functional levels and operating systems, AD replication, DNS, time synchronization and connectivity to domain controllers. Install the required RSAT tools on your administration workstation; an application server does not need to become a domain controller.

KDS provides the foundation for generating gMSA passwords. Check for an existing root key before creating one. Microsoft allows up to ten hours before using a new key so that it can converge across domain controllers. Do not apply the backdating shortcut intended for a single-DC test lab in production.

Import-Module ActiveDirectory
Get-ADDomain | Select-Object DNSRoot,DomainMode
Get-ADForest | Select-Object RootDomain,ForestMode

# In an administrative session with the Kds module
Get-KdsRootKey

# FOREST CHANGE: only after validation and when necessary
# Add-KdsRootKey -EffectiveImmediately
# Allow the convergence period before starting the pilot.

• Microsoft — Create the KDS root key ↗

3. Create a gMSA restricted to the required hosts

This example creates a dedicated group containing only APP01 and a gMSA for a reporting application. It changes AD and requires an administrator with the necessary delegated permissions. Adjust names and object locations before running it.

DNSHostName describes the account; it does not create an application DNS record. Application SPNs are handled separately. Choose the password interval when creating the account; do not assume it can be changed later.

Import-Module ActiveDirectory
New-ADGroup -Name 'GG-gMSA-Reports-Hosts' -GroupScope Global `
  -GroupCategory Security
Add-ADGroupMember -Identity 'GG-gMSA-Reports-Hosts' `
  -Members (Get-ADComputer 'APP01')

$params = @{
  Name = 'gmsaReports'
  DNSHostName = 'gmsaReports.corp.contoso.com'
  PrincipalsAllowedToRetrieveManagedPassword = 'GG-gMSA-Reports-Hosts'
  KerberosEncryptionType = @('AES128','AES256')
  ManagedPasswordIntervalInDays = 30
}
New-ADServiceAccount @params

• Microsoft — New-ADServiceAccount parameters ↗

4. Protect password retrieval and validate the host

Control who can modify the host group, the gMSA's ACLs and its member servers. An administrator on an authorized host can compromise an identity available to that server. Do not grant password retrieval to Domain Computers or a general administrative group.

After adding the computer account to the group, schedule a reboot of the pilot host to refresh its security context. Install the account and test availability. A True result confirms that step, not that the application works correctly.

Install-ADServiceAccount -Identity 'gmsaReports'
Test-ADServiceAccount -Identity 'gmsaReports'

Get-ADServiceAccount 'gmsaReports' -Properties `
  PrincipalsAllowedToRetrieveManagedPassword,ServicePrincipalNames |
  Select-Object Name,PrincipalsAllowedToRetrieveManagedPassword,
                ServicePrincipalNames

• Microsoft — Manage gMSAs ↗
• Microsoft — Test-ADServiceAccount ↗

5. Reduce permissions and configure the service

Configure CORP\gmsaReports$ through the vendor-supported tool. Never copy a gMSA password into a script. For SQL Server, use SQL Server Configuration Manager; for IIS, also review the application's authentication settings.

Under Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment, grant Log on as a service only where required. A scheduled task may need Log on as a batch job. Deny rights override allow rights; check the effective policy before restarting.

Block unnecessary interactive use after testing. Do not indiscriminately deny network access to an identity that must access SQL or a share. Grant only required NTFS, share and SQL permissions; the account should not normally be a local or domain administrator.

• Test expected reads and writes, but also denial on an out-of-scope resource.
• Identify encrypted files, DPAPI secrets and profiles tied to the previous identity: changing accounts can make that data unreadable.
• Check whether a GPO replaces a user-rights list already used by other services.

6. Manage SPNs without introducing duplicates

An SPN maps a service name to its Kerberos identity. The name used by clients, including aliases, must match the effective configuration. Search for existing registrations before making changes. The HTTP registration below is an example, not a universal IIS recipe.

During migration, stop the old use, remove the SPN from its previous owner and assign it to the new one in a controlled change window. Keep the reverse commands ready. Do not use setspn -A when -S can check for duplicates.

REM Read-only; a forest-wide query can take time in a large forest
setspn -F -Q HTTP/reports.corp.contoso.com
setspn -L CORP\svcReports
setspn -L CORP\gmsaReports$

REM CHANGES: only after validating ownership and stopping the service
REM setspn -D HTTP/reports.corp.contoso.com CORP\svcReports
REM setspn -S HTTP/reports.corp.contoso.com CORP\gmsaReports$

REM On a test client, in the relevant user's context
klist get HTTP/reports.corp.contoso.com
klist

• Microsoft — setspn ↗

7. Separate SPN registration from Kerberos delegation

Running a service under a gMSA does not require delegation. Delegation matters when one service accesses another on behalf of the user. An application connecting to SQL under its own service identity is a different scenario.

Unconstrained delegation creates an unnecessarily broad boundary for a new application deployment. Classic constrained delegation limits target services on the upstream identity; resource-based constrained delegation, or RBCD, controls allowed identities at the target. In both cases, limit destinations and protect modification rights.

Protocol transition and accounts that cannot be delegated can change the outcome. Validate the entire double-hop flow before adding permissions. Never change delegation merely to make an authentication error disappear.

Get-ADUser 'svcReports' -Properties TrustedForDelegation,
  TrustedToAuthForDelegation,AccountNotDelegated,'msDS-AllowedToDelegateTo' |
  Select-Object SamAccountName,TrustedForDelegation,
    TrustedToAuthForDelegation,AccountNotDelegated,'msDS-AllowedToDelegateTo'

# Example computer target for RBCD; adapt to the actual target principal
Get-ADComputer 'SQL01' -Properties PrincipalsAllowedToDelegateToAccount |
  Select-Object Name,PrincipalsAllowedToDelegateToAccount

• Microsoft — Kerberos constrained delegation ↗

8. Prepare AES and rotate legacy account passwords

Configuring AES is useful, but keys must exist and every component must support it. An older user-based service account may need a password rotation to generate its keys; coordinate this with every consumer. Do not bulk-change msDS-SupportedEncryptionTypes without examining actual tickets.

For an application that cannot use a gMSA, retain a unique least-privilege account and a random secret stored in a vault. Document who retrieves it, how services receive updates and how failed rotation is detected. Avoid secrets in command lines, shared configuration files or logs.

An identity migration rollback can temporarily reuse the old account if its secret remains valid and protected. After a password rotation, restoring an old configuration alone is not enough. Following compromise, never restore an exposed secret.

• Microsoft — Detect and remediate RC4 ↗
• Guide — Move Kerberos from RC4 to AES →

9. Migrate one application and observe a complete cycle

Define stop criteria before switching: failed business processing, access errors or unexpected authentication. Restore the documented identity, SPNs and permissions if needed. Do not immediately delete the previous account, but do not leave it enabled without an expiry for the transition.

Monitor service-ticket event 4769 on DCs with appropriate auditing, sign-in events 4624/4625 on relevant systems, and application logs. A high ticket count is not proof of an attack by itself; compare expected hosts, schedules and services. Available fields depend on versions and patches.

• Microsoft — Kerberos service ticket event 4769 ↗

Maintain the control over time

When a server is retired, also remove its permission to retrieve the password. When an application changes owners, update its rotation procedure and tests. Periodically review host-group membership, SPNs, delegation and access to resources.

The goal is an identity with a known purpose whose access can be changed without an unexpected outage. Targeted assistance is especially valuable when applications share accounts, Kerberos double hops are poorly documented or critical services depend on historical secrets.

• Service — Active Directory security assessment →
• Guide — Forest recovery after a cyberattack →