The Core ProblemTraditionally, services ran under standard user accounts with manually managed passwords. Passwords expired, got shared, or were set to "never expire" — weakening security posture and creating audit gaps across the entire domain.
Traditional Service Accounts
- Manual password management required
- Passwords often set to never expire
- Shared across multiple services
- Inconsistent audit trails
- High human error risk
sMSA (Standalone)
- Introduced in Windows Server 2008 R2
- Automatic password management (30d)
- Single computer scope only
- Automatic SPN registration
- Cannot be used interactively
gMSA (Group)
- Introduced in Windows Server 2012
- Works across multiple servers / farms
- Password managed by AD via KDS
- Supports up to 256 authorized hosts
- Ideal for load-balanced services
| Feature | Standard User Account | sMSA | gMSA |
|---|---|---|---|
| Automatic Password Rotation | No | Yes (30d) | Yes (30d) |
| Multi-Server Support | Yes | No — 1 host only | Yes — up to 256 |
| Automatic SPN Management | No | Yes | Yes |
| Interactive Logon Possible | Yes | No | No |
| Password Visible to Admins | Potentially | No | No |
| Requires KDS Root Key | N/A | N/A | Yes |
| Secret Server Vaulting Required | Yes — Recommended | Not Required | Not Required |
| Minimum Windows Server Version | Any | 2008 R2 | 2012 |
Best PracticePrefer gMSA for all new service deployments where supported. Fall back to sMSA for single-host legacy apps, and use standard accounts only when neither MSA type is supported — always vault those in Secret Server.
Use Cases
- Windows services on a single host
- IIS application pools (single server)
- Scheduled tasks needing domain identity
- SQL Server Agent on standalone instances
- Legacy apps requiring AD authentication
Key Characteristics
- Password auto-rotates every 30 days
- Tied to exactly one computer object in AD
- Cannot log on interactively or via RDP
- SPN registration is fully automatic
- Account name always ends with
$
▸ Click any step to expand the PowerShell commands
Create the sMSA in Active Directory
Run on a Domain Controller or a host with AD PowerShell tools.
# Create a standalone Managed Service Account in AD New-ADServiceAccount -Name "svc-MyApp" ` -Description "sMSA for MyApp on WEB01" ` -RestrictToSingleComputer # Verify the account was created Get-ADServiceAccount -Identity "svc-MyApp"
Install the sMSA on the Target Server
Run on the server that will host the service. Binds the account to this machine.
# Ensure the AD PowerShell module is available Install-WindowsFeature RSAT-AD-PowerShell # Install the sMSA onto this computer Install-ADServiceAccount -Identity "svc-MyApp" # Verify — must return True before proceeding Test-ADServiceAccount -Identity "svc-MyApp"
Assign the sMSA to a Windows Service
Password field is left blank — Windows retrieves it automatically.
# Via SC.exe — note the trailing $ on the account name sc.exe config "MyApplicationService" obj= "DOMAIN\svc-MyApp$" password= "" # Or via PowerShell WMI $svc = Get-WmiObject Win32_Service -Filter "Name='MyApplicationService'" $svc.Change($null,$null,$null,$null,$null,$null,"DOMAIN\svc-MyApp$","") # Restart the service to apply Restart-Service "MyApplicationService"
Grant Required NTFS / Application Permissions
Assign file system or SQL permissions to the sMSA identity.
# Grant read/write to app folder $acl = Get-Acl "C:\Apps\MyApp" $rule = New-Object System.Security.AccessControl.FileSystemAccessRule( "DOMAIN\svc-MyApp$", "ReadAndExecute,Write", "ContainerInherit,ObjectInherit", "None", "Allow") $acl.SetAccessRule($rule) Set-Acl "C:\Apps\MyApp" $acl
sMSA Limitation — One Host OnlyAn sMSA can be installed on exactly one computer. If you need the same managed identity across web farm nodes, clustered services, or load-balanced deployments, you must use a gMSA instead. Attempting to install an sMSA on a second machine will fail with an access denied error.
How gMSA Password Management WorksThe Key Distribution Service (KDS) on a Domain Controller generates and distributes the managed password. Authorized hosts retrieve it via the encrypted msDS-ManagedPassword AD attribute using Kerberos. No human ever sees or enters the password — AD rotates it automatically every 30 days with zero service interruption.
Architecture Prerequisites
- Domain Functional Level: Windows Server 2012+
- At least one 2012+ DC to serve KDS requests
- KDS Root Key created (one-time domain setup)
- RSAT-AD-PowerShell on management hosts
- All target hosts must be domain-joined
Ideal Use Cases
- IIS web farms (NLB or ARR clusters)
- SQL Server Always On Availability Groups
- Scheduled tasks across multiple servers
- Windows services requiring Kerberos across hosts
- Print services and distributed file access
▸ Click any step to expand the PowerShell commands
Create the KDS Root Key — One-Time Domain Setup
Enables the DC to generate and serve managed passwords for gMSAs.
# Production: key becomes effective after 10-hour AD replication window Add-KdsRootKey -EffectiveImmediately # Lab/testing only — bypass replication wait (NOT for production) Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10)) # Verify the key exists Get-KdsRootKey
Create a Security Group for Authorized Hosts
Best practice: manage which computers can use the gMSA via an AD group.
# Create the group that authorizes hosts to retrieve the gMSA password New-ADGroup -Name "gMSA-WebFarm-Hosts" ` -GroupScope Global ` -GroupCategory Security ` -Description "Authorized hosts for gMSA-WebSvc" # Add the server computer accounts to the group Add-ADGroupMember -Identity "gMSA-WebFarm-Hosts" ` -Members ( Get-ADComputer "WEB01", Get-ADComputer "WEB02", Get-ADComputer "WEB03" )
Create the gMSA in Active Directory
Bind the account to the authorized host group and define the DNS hostname for SPNs.
New-ADServiceAccount -Name "gMSA-WebSvc" ` -DNSHostName "websvc.corp.contoso.com" ` -PrincipalsAllowedToRetrieveManagedPassword "gMSA-WebFarm-Hosts" ` -ServicePrincipalNames "http/websvc","http/websvc.corp.contoso.com" ` -Description "gMSA for Web Farm — WEB01/02/03" # Confirm the account and its managed password attributes Get-ADServiceAccount -Identity "gMSA-WebSvc" -Properties *
Install the gMSA on Each Authorized Host
Run on every server in the farm. May require a Kerberos ticket purge.
# Install the gMSA on this host Install-ADServiceAccount -Identity "gMSA-WebSvc" # Verify — must return True before using the account Test-ADServiceAccount -Identity "gMSA-WebSvc" # If this fails after group membership change, purge cached Kerberos tickets klist.exe purge # Then retry Install-ADServiceAccount, or reboot the server
Configure an IIS Application Pool to Use the gMSA
Set the identity on each node — password field is always empty.
Import-Module WebAdministration $pool = "MyWebAppPool" $account = "CONTOSO\gMSA-WebSvc$" Set-ItemProperty "IIS:\AppPools\$pool" -Name processModel -Value @{ userName = $account password = "" identitytype = "SpecificUser" } Restart-WebAppPool -Name $pool Get-WebConfiguration "system.applicationHost/applicationPools/add[@name='$pool']/processModel"
Adding New Hosts LaterSimply add the new computer account to gMSA-WebFarm-Hosts, then run Install-ADServiceAccount on the new server. No password resets, no changes to existing nodes, no service interruption.
The Core PrincipleSecret Server is designed to protect credentials that humans or systems can read, copy, and potentially misuse. gMSA and sMSA passwords are never exposed in any readable form — they are cryptographically managed by Active Directory itself. There is no secret to vault because there is no secret that can be retrieved by a person.
Passwords Are Cryptographically Opaque
The msDS-ManagedPassword attribute is stored as an encrypted binary blob. Only authorized computer accounts can decrypt it via Kerberos. No human — not even a Domain Admin — can retrieve the plaintext password from Active Directory.
Automatic Rotation Is Built In
Active Directory rotates MSA passwords automatically every 30 days without any human involvement. Secret Server's primary value for standard accounts is enforcing rotation — that function is already native to AD for MSAs, making duplication unnecessary.
No Interactive Logon Risk
MSAs cannot be used to interactively log on to any system. The primary threat vector Secret Server mitigates — an admin retrieving a service account password and then using it for lateral movement or interactive access — simply does not exist for MSA account types.
Access Control Lives in AD
Which hosts can use an MSA is governed by the PrincipalsAllowedToRetrieveManagedPassword attribute and AD group membership. AD is the authoritative control plane — there is no separate credential to protect.
No Credential Sprawl Possible
Secret Server eliminates credential sprawl — the same password stored in config files, scripts, and sticky notes. MSAs eliminate this by design: the password is never entered anywhere by anyone, so it can never be copied into an insecure location.
Discovery Still Provides Governance
While vaulting MSA credentials isn't needed, Secret Server's Discovery feature can still enumerate sMSA and gMSA accounts — providing full inventory visibility of which managed accounts exist, what services use them, and which hosts are authorized.
| Account Type | Vault in Secret Server? | Rationale |
|---|---|---|
| Standard Domain User (service account) | Yes — Required | Human-readable password; must be rotated, audited, and protected |
| Local Administrator (non-LAPS) | Yes — Recommended | Shared passwords across machines; high lateral movement risk |
| Application / API Service Account | Yes — Required | Credentials embedded in configs; no automatic rotation mechanism |
| Domain Admin / Privileged Accounts | Yes — Critical | High-value target; requires break-glass procedures and full audit trail |
| sMSA | Not Required | AD-managed; no retrievable password; no interactive logon capability |
| gMSA | Not Required | KDS cryptographic management; password never exposed to any person |
| LAPS-managed Local Admin | Optional | LAPS handles rotation; Secret Server can provide additional audit layer |
Governance RecommendationEven though you don't vault the credential, track all gMSA and sMSA accounts in your CMDB or via Secret Server Discovery. You should have clear visibility into which managed accounts exist, which services depend on them, and which hosts are authorized — use Secret Server's reporting capabilities for this governance layer without active credential management overhead.
Q1Which Active Directory component is responsible for generating and distributing the password for a gMSA?
Add-KdsRootKey, enables DCs to generate and serve the gMSA managed password only to authorized computer accounts via Kerberos.Q2What is the key limitation of an sMSA compared to a gMSA?
-RestrictToSingleComputer. It cannot be installed on additional hosts. For multi-server scenarios, a gMSA is required.Q3Why is it NOT necessary to vault a gMSA password in Delinea Secret Server?
Q4What PowerShell cmdlet verifies that an MSA is correctly installed and usable on a target server?
Test-ADServiceAccount confirms the MSA is properly installed and that the current host can successfully retrieve the managed password. It returns True on success.