# Group Managed Service Accounts (gMSA): Complete Windows Server 2025 Guide

Source: https://srvscripts.com/guides/gmsa-group-managed-service-accounts/
Updated: 2026-10-03
Publisher: srvScripts (https://srvscripts.com/)

Group managed service accounts (gMSAs) are Active Directory accounts whose 240-byte random passwords are generated and rotated by domain controllers and retrieved only by the computers you authorise. They replace the classic “svc_something” user account with a password that never expires and sits in a spreadsheet. This guide shows how to create the KDS root key, create a gMSA, install it on servers, and run Windows services, scheduled tasks, IIS application pools and SQL Server under it, plus what changes with the delegated MSA in Windows Server 2025.

**Short answer:** Run `Add-KdsRootKey -EffectiveImmediately` once per forest and wait 10 hours. Create a security group containing the servers that will use the account, then run `New-ADServiceAccount -Name gmsa-app -DNSHostName gmsa-app.contoso.com -PrincipalsAllowedToRetrieveManagedPassword APP-Servers`. On each server, run `Install-ADServiceAccount gmsa-app` and `Test-ADServiceAccount gmsa-app`, then configure the service to log on as `CONTOSO\gmsa-app$` with a blank password.

In short: Run Add-KdsRootKey -EffectiveImmediately once per forest and wait 10 hours.

## Which service account type to use

| Account type | Password managed by | Used on | Best for | Limits |
| --- | --- | --- | --- | --- |
| Domain user account | You | Any number of machines | Legacy apps that need a typed password | Passwords rarely rotated; open to Kerberoasting |
| Standalone MSA (sMSA) | AD | One computer | A single server’s service | Cannot be shared between servers |
| Group managed service account (gMSA) | AD (KDS) | All computers in the allowed group | Services, tasks, IIS pools, SQL, farms and clusters of servers | App must accept a blank password; not for interactive logon |
| Delegated MSA (dMSA) | AD, bound to the machine | Machines you authorise | Migrating existing service accounts on Windows Server 2025 | Needs Windows Server 2025 DCs; newer and less widely supported |
| Virtual account (NT SERVICE\name) | Local | One computer | Services that only touch local resources | Uses the computer account on the network |

For most server workloads, group managed service accounts are the right default: they work on Windows Server 2012 and later, need no application changes beyond the logon account, and cover services on several servers at once.

## Prerequisites

- A domain with at least one Windows Server 2012 or later DC and the matching schema. Any supported forest today (Windows Server 2016 to 2025 DCs) qualifies.

- **Domain Admins** or **Enterprise Admins** membership to create the KDS root key, and rights to create objects in the **Managed Service Accounts** container.

- The **Active Directory module for Windows PowerShell** on each host that installs the account: `Install-WindowsFeature RSAT-AD-PowerShell` on servers, or the RSAT feature on Windows 11.

- Hosts running Windows Server 2012 or later (or Windows 8 and later clients) joined to the domain.

- The service or application must support running as a managed service account. Windows services, Task Scheduler, IIS application pools and SQL Server do.

## Step 1: create the KDS root key

Domain controllers derive the passwords of all group managed service accounts from a Key Distribution Services (KDS) root key. You create it once per forest:

```
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately
```

Despite its name, `-EffectiveImmediately` does not make the key usable immediately. Domain controllers wait up to 10 hours from the key’s creation before they allow gMSA creation, so that every DC has replicated the key and can answer password requests. Plan the key the day before you need the first account.

In an isolated lab with a single DC, you can backdate the key to skip the wait:

```
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))
```

Never use the backdated form in production: a DC that has not yet received the key cannot compute the password, and services fail to start on hosts that ask that DC. Confirm the key exists with `Get-KdsRootKey` and check the **KdsSvc** operational log for event **4004**.

## Step 2: create a group for the hosts

Only principals listed in `PrincipalsAllowedToRetrieveManagedPassword` can read the password. Use a security group, not individual computer accounts, so you can add servers later without touching the gMSA:

```
New-ADGroup -Name "gMSA-App-Hosts" -GroupScope Global -GroupCategory Security -Path "OU=Groups,DC=contoso,DC=com"
Add-ADGroupMember -Identity "gMSA-App-Hosts" -Members "APP01$", "APP02$"
```

Note the trailing `$` on computer account names.

## Step 3: create the gMSA

```
New-ADServiceAccount -Name "gmsa-app" -DNSHostName "gmsa-app.contoso.com" -PrincipalsAllowedToRetrieveManagedPassword "gMSA-App-Hosts" -KerberosEncryptionType AES128, AES256
```

- `-Name` becomes the `sAMAccountName` (with `$` appended) and must be unique in the forest. Keep it at 15 characters or fewer.

- `-DNSHostName` is required; use the account name plus your domain.

- `-ServicePrincipalNames` registers SPNs, for example `-ServicePrincipalNames "HTTP/app.contoso.com"` for a load-balanced web app using Kerberos.

- `-ManagedPasswordIntervalInDays` sets the rotation interval (default 30 days). It can only be set at creation; to change it later you must create a new gMSA.

- `-RestrictToOutboundAuthenticationOnly` creates an account that only authenticates outbound and has no password retrievable for inbound Kerberos.

The account appears in the **Managed Service Accounts** container. To grant more hosts later, add them to the group, or change the allowed principals directly:

```
Set-ADServiceAccount -Identity "gmsa-app" -PrincipalsAllowedToRetrieveManagedPassword "gMSA-App-Hosts", "gMSA-DR-Hosts"
```

`Set-ADServiceAccount` replaces the list, so include every principal you want to keep.

## Step 4: install and test the gMSA on each host

A computer’s group memberships are part of its Kerberos ticket, which is issued at startup. After adding a server to the host group, restart it, or purge the computer’s tickets so it picks up the new membership without a restart:

```
klist -li 0x3e7 purge
Install-ADServiceAccount -Identity "gmsa-app"
Test-ADServiceAccount -Identity "gmsa-app"
```

`Test-ADServiceAccount` returns `True` when the host can retrieve the password. `False` nearly always means the computer is not (yet) in the allowed group or has not refreshed its ticket.

## Use the gMSA with Windows services

Windows services were the first workload built for group managed service accounts, and the setup takes a minute per service:

- Open `services.msc`, open the service and go to the **Log On** tab.

- Choose **This account** and enter `CONTOSO\gmsa-app$`, or browse and set **Object Types** to include **Service Accounts**.

- Clear both password boxes and click **OK**. Windows grants the **Log on as a service** right automatically.

- Restart the service.

With PowerShell or `sc.exe`:

```
sc.exe config "AppService" obj= "CONTOSO\gmsa-app$"
Restart-Service -Name "AppService"
```

If the service needs local rights (writing to a folder, reading a certificate private key, local admin for a legacy agent), grant them to `CONTOSO\gmsa-app$` exactly as you would to a user account. Group Policy “User Rights Assignment” settings can reference the gMSA too.

## Use the gMSA with scheduled tasks

The Task Scheduler GUI cannot save a task with a blank password for “Run whether user is logged on or not”, so create or update the task with PowerShell. `-LogonType Password` is the setting that corresponds to “Run whether user is logged on or not”; Windows retrieves the password from AD at run time:

```
$action    = New-ScheduledTaskAction -Execute "powershell.exe" -Argument "-NoProfile -File C:\Scripts\Export-Report.ps1"
$trigger   = New-ScheduledTaskTrigger -Daily -At 02:00
$principal = New-ScheduledTaskPrincipal -UserId "CONTOSO\gmsa-app$" -LogonType Password
Register-ScheduledTask -TaskName "Nightly report" -Action $action -Trigger $trigger -Principal $principal
```

To switch an existing task to the gMSA:

```
$principal = New-ScheduledTaskPrincipal -UserId "CONTOSO\gmsa-app$" -LogonType Password
Set-ScheduledTask -TaskName "Nightly report" -Principal $principal
```

The gMSA needs the **Log on as a batch job** right on the server (`Computer Configuration » Policies » Windows Settings » Security Settings » Local Policies » User Rights Assignment » "Log on as a batch job"`). Changing a task with `schtasks /change /ru` tends to reset it to “Run only when user is logged on”, so prefer the PowerShell cmdlets.

## Use the gMSA with IIS application pools

- Install the gMSA on every web server in the farm (Step 4).

- In IIS Manager, open **Application Pools**, select the pool and click **Advanced Settings**.

- Under **Process Model » Identity**, choose **Custom account » Set**, enter `CONTOSO\gmsa-app$` and leave both password fields empty.

- Recycle the pool and give the gMSA NTFS rights on the site content if it no longer runs as `ApplicationPoolIdentity`.

For Kerberos authentication behind a load balancer, register the site’s SPN on the gMSA (`setspn -S HTTP/app.contoso.com CONTOSO\gmsa-app$`) and enable **useAppPoolCredentials** for Windows Authentication, so every node decrypts tickets with the same account.

## Use the gMSA with SQL Server

- Install the gMSA on the SQL Server host (or on every node of an Always On availability group).

- Open **SQL Server Configuration Manager » SQL Server Services**, open the SQL Server service and go to the **Log On** tab.

- Enter `CONTOSO\gmsa-sql$`, leave the password empty and apply. Configuration Manager grants the required local permissions. Repeat for SQL Server Agent, ideally with a separate gMSA.

- Register the SQL SPNs on the gMSA (`MSSQLSvc/sql01.contoso.com:1433`) with `setspn -S`, or give the account the right to register its own SPNs.

Use a separate gMSA per application or tier. Group managed service accounts cost nothing to create, and one account for everything means one compromise reaches everything.

## Migrate an existing user service account

Most domains move to group managed service accounts one application at a time. A safe sequence:

- Find where the old account is used. On each server, list services and tasks that run as it:

```
Get-CimInstance Win32_Service | Where-Object StartName -like "*svc_app*" | Select-Object PSComputerName, Name, StartNameGet-ScheduledTask | Where-Object { $_.Principal.UserId -like "*svc_app*" } | Select-Object TaskPath, TaskName
```

Check IIS application pools, SQL Server services, COM+ applications and application configuration files as well. The account’s logon events (4624, 4768, 4769) on the domain controllers show which hosts still authenticate with it.

- Copy the old account’s permissions to the gMSA: group memberships, NTFS and share rights, SQL logins, certificate private key access and user rights such as “Log on as a service”.

- Move any SPNs from the old account to the gMSA with `setspn -D` and `setspn -S` in the same change window, because duplicate SPNs break Kerberos.

- Switch one server, test the application, then switch the rest.

- Disable the old account and keep it disabled for a few weeks before deleting it, so a forgotten dependency fails loudly and can be fixed.

## Security best practices

- Create one gMSA per application or tier, and restrict `PrincipalsAllowedToRetrieveManagedPassword` to the servers that run it. Anyone who controls an allowed host can retrieve the password.

- Protect the host group: only Tier 0 or server administrators should be able to change its membership, because adding a computer to it grants access to the account.

- Do not add group managed service accounts to Domain Admins or other privileged groups. Grant the specific rights the application needs.

- Prefer AES encryption types (`-KerberosEncryptionType AES128, AES256`) so tickets for the account are not issued with RC4.

- Mark the account “sensitive and cannot be delegated” unless the application genuinely needs Kerberos delegation, and use constrained delegation when it does.

## Delegated MSA in Windows Server 2025

Windows Server 2025 adds the **delegated managed service account** (dMSA). Like a gMSA, its keys are managed and randomised by AD, but authentication is bound to the device identities mapped in AD, and the secret stays on the domain controllers, which blocks credential theft techniques such as Kerberoasting. Its main purpose is migration: a dMSA can supersede an existing user-based service account without reconfiguring every application.

- dMSA requires Windows Server 2025 domain controllers and a KDS root key.

- You create one with `New-ADServiceAccount -Name dmsa-app -DNSHostName dmsa-app.contoso.com -CreateDelegatedServiceAccount -KerberosEncryptionType AES256`.

- Migration uses `Start-ADServiceAccountMigration -Identity dmsa-app -SupersededAccount "CN=svc_app,OU=Service Accounts,DC=contoso,DC=com"`, followed later by `Complete-ADServiceAccountMigration`. `Undo-ADServiceAccountMigration` and `Reset-ADServiceAccountMigration` roll back.

- After completion, the original account is disabled. Microsoft states that you cannot migrate a gMSA or sMSA to a dMSA.

- Machines using a dMSA need dMSA logons enabled: the policy `Computer Configuration » Administrative Templates » System » Kerberos » "Enable Delegated Managed Service Account logons"`, or the registry value `DelegatedMSAEnabled = 1` (REG_DWORD) under `HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters`.

For new services, group managed service accounts remain the simpler and more widely supported choice. Consider dMSA when you must retire many legacy service accounts in a Windows Server 2025 forest, and test the migration in a lab first.

## Verify it works

Check the account, the hosts and the workloads that use it:

```
Get-ADServiceAccount -Identity "gmsa-app" -Properties PrincipalsAllowedToRetrieveManagedPassword, PasswordLastSet, msDS-ManagedPasswordInterval, ServicePrincipalNames
Test-ADServiceAccount -Identity "gmsa-app"
Get-CimInstance Win32_Service | Where-Object StartName -like "*gmsa*" | Select-Object Name, StartName, State
Get-ScheduledTask | Where-Object { $_.Principal.UserId -like "*gmsa*" } | Select-Object TaskName, State
```

On the domain controller, successful logons by the gMSA appear as event 4624 with the account name ending in `$`.

## Troubleshooting

| Symptom | Cause | Fix |
| --- | --- | --- |
| New-ADServiceAccount: “Key does not exist” | No KDS root key, or created less than 10 hours ago | Create it with Add-KdsRootKey and wait; check Get-KdsRootKey |
| Test-ADServiceAccount returns False | Host not in allowed group or stale ticket | Check group membership, run klist -li 0x3e7 purge or restart |
| Service fails with error 1069 (logon failure) | Missing $, password typed, or host not allowed | Use DOMAIN\name$ with a blank password; verify Step 4 |
| Scheduled task does not run | No “Log on as a batch job” right, or wrong LogonType | Grant the right; recreate the principal with -LogonType Password |
| “No mapping between account names and security IDs” | Account name typed without the domain or $ | Use CONTOSO\gmsa-app$ |
| Kerberos fails for a web or SQL app | SPN missing or registered on another account | setspn -Q HTTP/app.contoso.com, then move the SPN to the gMSA |

## Roll back or remove

To return a service to its old account, set the previous logon account and password in `services.msc` (or the task principal), then remove the gMSA from the host:

```
Uninstall-ADServiceAccount -Identity "gmsa-app"
Remove-ADServiceAccount -Identity "gmsa-app"
```

Remove the account from AD only after every host has stopped using it. Deleted group managed service accounts can be recovered from the AD Recycle Bin like any other object while the deleted-object lifetime lasts.

## Group managed service accounts at a glance

**Official documentation:** [Manage group Managed Service Accounts](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/group-managed-service-accounts/group-managed-service-accounts/getting-started-with-group-managed-service-accounts), [Create the Key Distribution Services KDS Root Key](https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/create-the-key-distribution-services-kds-root-key), [Delegated Managed Service Accounts overview](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-overview).

**Related guides:** [Set up Windows LAPS on Windows Server 2025 and Windows 11](/guides/windows-laps-setup/) · [Audit and disable NTLM in Active Directory](/guides/disable-ntlm-active-directory/) · [Fine-Grained Password Policy (PSO) in Active Directory: Easy 2026 Setup](/guides/fine-grained-password-policy-pso/).

## Frequently asked questions

### Why does Add-KdsRootKey -EffectiveImmediately still make me wait?

Domain controllers wait up to 10 hours after the KDS root key is created before allowing gMSA creation, so the key can replicate to every DC. Only in a single-DC lab should you backdate the key with -EffectiveTime ((Get-Date).AddHours(-10)).

### What password do I enter for a gMSA?

None. Enter the account as DOMAIN\name$ with the dollar sign and leave the password fields blank. Windows retrieves the current password from a domain controller.

### How often does a gMSA password change?

Every 30 days by default. The interval is set with -ManagedPasswordIntervalInDays when the account is created and cannot be changed afterwards; create a new gMSA if you need a different interval.

### Can I use a gMSA for a scheduled task?

Yes. Create the task principal with New-ScheduledTaskPrincipal -UserId ‘DOMAIN\name$’ -LogonType Password and register or update the task with PowerShell. The account needs the Log on as a batch job right.

### Should I use a gMSA or the new dMSA?

Use group managed service accounts for new services on any supported Windows Server version. The Windows Server 2025 delegated MSA is mainly for migrating existing user-based service accounts and needs Windows Server 2025 domain controllers.