Chad DuffeySecurity engineer

Active Directory Operations and recovery

Managed service accounts

Check gMSA password generation, who can retrieve the password, and whether the service host and application are ready to use it.

Identify the account model

A standalone MSA, introduced in Windows Server 2008 R2, is associated with one computer. A group MSA, or gMSA, supports an identity shared across authorized hosts while Windows manages the password. It is useful when several service instances must authenticate as one principal. An ordinary user account named svcSomething does not acquire managed-password behavior from its name. Managed service account overview.

A gMSA still has an AD SID, group memberships, SPNs and permissions. Check that the application and OS support the account type, then record its hosts, the resources it accesses and who controls those hosts. A long automatically changed password won’t make excessive service privileges safe.

Follow generation and retrieval

The DC derives gMSA passwords using a KDS root key and account information. Authorized hosts retrieve the managed credential, so an operator shouldn’t need to type and distribute a shared password. If retrieval fails, check root-key availability, directory replication, retrieval permissions and the host’s current security context.

A newly created KDS root key has a replication safety interval of up to ten hours. A key created on one DC is not immediately usable everywhere. Limited replication schedules or failures can extend the practical problem. Microsoft’s KDS root-key procedure confines backdating the key’s effective time to single-DC test environments. Do not turn that lab shortcut into the production fix for failed replication.

Inventory the account without requesting its secret

From an AD administrative session:

Get-ADServiceAccount -Filter * |
    Select-Object Name,SamAccountName,ObjectClass,Enabled,DNSHostName

Get-ADServiceAccount -Identity 'svcWeb' -Server 'dc1.contoso.com' `
    -Properties PrincipalsAllowedToRetrieveManagedPassword,ServicePrincipalNames,
        KerberosEncryptionType,ManagedPasswordIntervalInDays |
    Format-List Name,SamAccountName,ObjectClass,Enabled,
        PrincipalsAllowedToRetrieveManagedPassword,ServicePrincipalNames,
        KerberosEncryptionType,ManagedPasswordIntervalInDays

Record the DC and distinguish sMSA from gMSA object classes. The requested properties describe configuration; the example does not request msDS-ManagedPassword. Avoid -Properties * in broad service-account exports. For the gMSA lifecycle, the management guide describes creation, host installation and supported services.

Review who can obtain the credential

PrincipalsAllowedToRetrieveManagedPassword is often a group containing service-host computer accounts. Expand that group, including nested paths, and review who can change its membership or ACL. Control of an authorized host can be relevant to use of the service identity.

This authorization permits retrieval of the actual managed-password blob, whose CurrentPassword field contains the cleartext password; it is more than permission to install an account locally. Review every allowed principal, including accidentally authorized user accounts. The DC evaluates access against the security descriptor in msDS-GroupMSAMembership. See the protocol’s retrieval access check and password-blob fields.

Get-ADGroupMember -Identity 'gMSA-Web-Hosts'
Get-ADGroupMember -Identity 'gMSA-Web-Hosts' -Recursive

Compare the intended hosts with the group’s actual members and who can change them. Check who can change the gMSA’s retrieval permissions, SPNs, group memberships and delegation settings too. Allowing every workstation to retrieve a powerful service identity’s password defeats the host restriction.

Group membership changes must reach the DC used for authentication and the host’s security context. A host that was just added to the group can still fail until it obtains a context reflecting that membership. Microsoft’s gMSA troubleshooting guidance includes this condition; its container-specific sections should not be generalized to unrelated services.

Check KDS availability without exporting root keys

Verify the expected key was created and that KDS Operational event 4004 and AD replication support the intended timeline. The root keys reside under the forest Configuration partition. A metadata-only inventory is:

$config = (Get-ADRootDSE -Server 'dc1.contoso.com').configurationNamingContext
$keyContainer = "CN=Master Root Keys,CN=Group Key Distribution Service,CN=Services,$config"
Get-ADObject -Server 'dc1.contoso.com' -SearchBase $keyContainer `
    -LDAPFilter '(objectClass=msKds-ProvRootKey)' -Properties whenCreated |
    Select-Object Name,ObjectGUID,whenCreated

Finding the object doesn’t tell you its effective time, whether it has replicated or whether password generation works. Keep the key material out of routine health reports. Get-KdsRootKey retrieves root-key values as well as names; see its reference. Don’t delete and recreate a root key as a routine troubleshooting step.

Install and test on the service host

After application/OS support, KDS availability, retrieval permissions, DNS, time and DC reachability have been verified, an authorized local administrator can install the account on the intended host:

Install-ADServiceAccount -Identity 'svcWeb'
Test-ADServiceAccount -Identity 'svcWeb'

Installation prepares the local computer to use the account. The test then checks credential readiness from that computer. True means the account can authenticate and access the domain using its credentials there; you still need to test application startup and access to its resources. Running it on an administrator’s workstation tests that workstation instead. Test-ADServiceAccount behavior.

If it returns False, keep the error and check retrieval permissions, replication and host membership before changing the account again. Repeatedly resetting unrelated computer accounts or creating new KDS keys can introduce more problems.

Verify service configuration and SPN ownership

Inspect Windows services on the host:

Get-CimInstance Win32_Service |
    Where-Object StartName -like '*svcWeb*' |
    Select-Object Name,State,StartMode,StartName

Inspect application pools and scheduled tasks separately. Configure the service using its documented gMSA support, including account syntax and logon rights. Then check the exact service name requested by clients:

setspn -L CONTOSO\svcWeb$
setspn -Q HTTP/app.contoso.com

Compare the requested SPN with the account holding the service key. A managed password does not correct a ticket encrypted for another account. Continue with SPN diagnosis for aliases, duplicates and ownership.

Test startup, a new client authentication and access to downstream resources. Repeat after a controlled restart and across each service instance. Preserve the original identity, rights and SPNs as part of the rollback plan for a migration.

Separate routine rotation from root-key compromise

The managed-password interval is set when creating a gMSA and becomes read-only afterward. Compromised KDS root-key material needs a different response from an application password problem. Microsoft’s Golden gMSA recovery procedure covers replacement KDS material and affected gMSAs, including domain/forest exposure. Follow that recovery plan. Changing an allowed-host group alone can’t invalidate credentials an attacker can derive from the compromised root material.

← All Active Directory topics