Service accounts compared: sMSA, gMSA, dMSA and virtual accounts

A service account provides the security context a service runs in. Windows Server 2025 offers four managed options alongside the traditional domain user account, and choosing between them is a core exam skill.

Choosing a service account type

sMSAs were introduced in Windows Server 2008 R2, gMSAs in Windows Server 2012 (the Key Distribution Service doesn’t run on earlier versions) and dMSAs in Windows Server 2025. sMSAs and gMSAs both provide automatic password management, simplified service principal name (SPN) management and delegation of account management to non-administrators.

Common trap: Choosing an sMSA for a service that runs on several load-balanced servers - an sMSA can’t be shared among computers or used across cluster nodes; mutual authentication across instances needs one principal, which is what a gMSA provides.

gMSA prerequisites: the KDS root key

Domain controllers need a Key Distribution Service (KDS) root key before they can generate gMSA passwords. It is created once per forest with Add-KdsRootKey by a member of Domain Admins or Enterprise Admins. Despite its name, -EffectiveImmediately doesn’t make the key usable everywhere at once: DCs wait up to 10 hours from creation so that the key replicates to every DC. Only in a single-DC test environment should the effective time be backdated with -EffectiveTime ((Get-Date).AddHours(-10)). Creating more than one root key, or deleting and recreating it, causes failures.

Add-KdsRootKey -EffectiveImmediately          # once per forest; usable after replication (up to 10 hours)
New-ADServiceAccount -Name svcWeb -DNSHostName svcWeb.corp.example `
    -PrincipalsAllowedToRetrieveManagedPassword 'WebServers'
New-ADServiceAccount -Name svcApp -RestrictToSingleComputer   # sMSA

New-ADServiceAccount creates a gMSA by default; RestrictToSingleComputer creates an sMSA, CreateDelegatedServiceAccount creates a dMSA, and RestrictToOutboundAuthenticationOnly creates a gMSA usable only for outbound (client) connections. The cmdlet doesn’t work against a read-only domain controller. Managed service accounts depend on Kerberos encryption types, so AES should always be configured for them; a host that doesn’t support RC4 fails authentication if the account’s msDS-SupportedEncryptionTypes attribute is missing.

Common trap: Running Add-KdsRootKey -EffectiveImmediately in a multi-DC production domain and expecting to create a working gMSA straight away - DCs allow up to 10 hours for the root key to replicate; backdating the effective time is only for single-DC test labs.

Delegated managed service accounts (dMSA)

A dMSA can be created standalone or used to supersede an existing traditional service account. Migration runs in two steps: Start-ADServiceAccountMigration links the old account (identified by its distinguished name) to the dMSA, and while the migration is running the dMSA learns which devices use the account. Complete-ADServiceAccountMigration copies the SPNs, delegation settings and authentication policy assignments to the dMSA and disables the original account. After that, authentication with the old password is blocked and requests are redirected to the Local Security Authority to authenticate as the dMSA.

Key constraints:

• You can’t migrate from an sMSA or a gMSA to a dMSA; dMSA replaces traditional user-based service accounts.
• Migration needs a writable domain controller, and every machine that uses the account must support dMSA, otherwise those machines fail authentication once the old account is disabled.
• Wait at least two ticket lifetimes (14 days) after changing the security descriptor before completing the migration; keeping the service in the start state for four ticket lifetimes (28 days) is recommended.
• Unconstrained delegation stops working after migration if the old account used it.
• dMSA logons are enabled with the Enable Delegated Managed Service Account logons policy setting under Computer ConfigurationTemplates.

Service accounts and password policy

A traditional service account follows the domain password policy in the Default Domain Policy unless a fine-grained password policy overrides it. Fine-grained policies are stored as Password Settings Objects (PSOs) in the Password Settings Container (under System in ADAC), need a domain functional level of Windows Server 2012 or higher, and apply only to user objects and global security groups, not to OUs. Each PSO requires a name and a precedence value. Get-ADUserResultantPasswordPolicy (or View Resultant Password Settings in ADAC) shows which PSO wins for a user. Password and lockout policy design is covered in Chapter 13, Securing Active Directory Domain Services.

Common trap: Linking a fine-grained password policy to the OU that holds service accounts - PSOs can’t be applied to OUs; apply them to the user objects or to a global security group that contains them.

Get the whole book

This note is one section of Ultra Transcenders AZ-802: Administering Windows Server, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.

About the book · AZ-802 terms in the glossary · All AZ-802 study notes