A gMSA object is not a migrated service
A gMSA first deployment pilot should end with a working service under its new identity, an approved rollback decision, and evidence from the hosts that actually run it. Creating a group managed service account in Active Directory establishes an account. It does not establish that a production workload uses that account, that every required host can retrieve its credentials, or that the workload retains the right access after cutover.
This distinction matters when an audit reports that gMSAs are not in use. Treat that result as a prompt to investigate the directory inventory and service estate. A new object can make an inventory signal disappear while every service continues running under its old identity. Conversely, incomplete collection can overlook an existing object. Neither outcome answers the operational question: which service has successfully moved?
Keep three records separate: directory objects, host readiness, and service adoption. The first identifies accounts; the second records whether a particular host can use the selected account; the third records a tested workload using it. This article proposes a gate for the first adoption, with one service and an explicit recovery plan. It does not assume that all SPN-bearing users represent compatible, active services.
How a gMSA first deployment pilot works
Start with a service owner and a workload inventory, rather than an account-creation request. Record the service name, current identity, host list, application version, startup configuration, clients, and downstream resources. Ask the owner which functions must remain available and what evidence would establish that the change worked. A process that starts but cannot write its scheduled output has failed the pilot.
Microsoft documents gMSA support for services configured through Service Control Manager, IIS application pools, Task Scheduler, and products supporting the managed-account APIs. The Cluster service itself does not support gMSAs; compatible services running above it can. Confirm the exact product and deployment topology with its owner before selecting the pilot. Microsoft Learn — Manage group Managed Service Accounts.
Build the change record around these independent gates:
| Gate | Evidence to retain | Decision if evidence is missing |
|---|---|---|
| Directory inventory | Class-based gMSA search, domain/DC, scope, time, and any query errors | Resolve the inventory discrepancy before interpreting the finding |
| KDS readiness | Existing key identified and replication readiness reviewed by the AD owner | Hold account use until the directory dependency is ready |
| Host authorization | Intended retrieval principals and host-by-host account test | Correct the specific authorization or connectivity problem |
| Compatibility and permissions | Supported service configuration and approved resource permissions | Choose another candidate or document the unresolved dependency |
| Service cutover | Running identity, restart result, workload and resource tests | Roll back under the agreed criteria |
These are proposed pilot controls, not results already measured in your environment. Assign an owner to each gate. The AD owner handles the forest dependency; the service owner accepts workload behavior; the change approver authorizes cutover and recovery. Record who can stop the pilot when those judgments differ.
Detection: inspect objects, KDS readiness, and each host
Reconcile a class-based directory inventory
Use an independent class search to check what the collector inventory means. The following is a read-only example composed from the documented Get-ADServiceAccount parameters. Replace the illustrative DC and domain DN with the approved scope; repeat for each domain included in the pilot. It has not been executed against your directory.
Get-ADServiceAccount -LDAPFilter '(objectClass=msDS-GroupManagedServiceAccount)' -SearchBase 'DC=example,DC=com' -SearchScope Subtree -Server 'dc01.example.com' -ResultSetSize $null
-LDAPFilter selects the structural class independently of the collector's membership-attribute heuristic. -SearchBase, -SearchScope, and -Server make the intended boundary explicit; -ResultSetSize $null avoids imposing a total result limit. The cmdlet returns both standalone and group managed accounts when used more generally, so preserve the class restriction for this inventory. Microsoft Learn — Get-ADServiceAccount.
Record the returned identities and enabled state, alongside the scope and query outcome. If this search finds a gMSA that the collector did not recognize, investigate permissions, requested attributes, search boundaries, and result limits. Do not resolve the discrepancy by creating another account. If the search fails, retain the error as a collection failure; an empty successful query and an unsuccessful query are different evidence.
Next, map each relevant object to real service configurations. Ask whether it is unused, staged, retired, or used by a tested workload. Keep an unmapped object as unmapped. A directory account name alone cannot supply a service owner or prove that any host uses it.
Inspect existing KDS keys before requesting a new one
From an authorized administrative context with the KDS module, use the documented read command:
Get-KdsRootKey
It retrieves the existing root-key list, including key values. Inspect it in the administrative environment and retain only the necessary identifiers and readiness decision in the change record; do not paste raw key material into a general ticket. This command is an inventory step, not a replication test. Microsoft Learn — Get-KdsRootKey.
Microsoft describes a wait of up to ten hours after root-key creation so DC replication can converge before gMSA use. Limited replication schedules or replication faults can still cause retrieval failures. Ask the AD owner to verify the key's availability and replication health for the DCs serving the pilot hosts; elapsed time alone is not that evidence. Microsoft Learn — Create a KDS root key.
If a suitable key already exists, the management procedure says to skip key creation. If none exists, make the AD owner's documented key-creation and replication process a prerequisite, with its own timing and authorization. Do not fold a forest dependency into an unreviewed service-account change.
Test readiness on the actual authorized hosts
Review the approved password-retrieval principals and confirm they match the intended host population. Microsoft's management guidance also requires appropriate SPNs, DNS, network access, clock synchronization, and supported Kerberos encryption types. Treat these as prerequisites to investigate, rather than assuming a successful directory search verifies them.
Run the documented account test locally on each intended host, replacing the illustrative account name:
Test-ADServiceAccount -Identity 'svc-pilot'
Microsoft defines a successful test as readiness to authenticate and access the domain with the account's current credentials. Record host, time, account, and actual result. It does not exercise your application's database queries, file writes, client authentication, or restart behavior. Microsoft Learn — Test-ADServiceAccount.
A failure holds the cutover. Investigate the host's intended authorization, directory access, and KDS/replication dependency with the responsible owners. Expanding retrieval access to a broad group is not an acceptable shortcut. The existing gMSA password-retrieval permissions review explains why the reader population is a security boundary worth reviewing separately.
Remediation: pilot one service with a usable rollback
1. Agree the acceptance tests and recovery path
Choose one compatible workload whose owner can observe both normal operation and failure. Before changing its identity, retain its approved configuration, existing permissions, startup behavior, and baseline workload results. Write down the maintenance window, the person approving the change, the person executing recovery, and the conditions that trigger it.
Make the conditions specific to the service: a required client cannot authenticate, a scheduled operation fails, an expected resource is inaccessible, or a restart does not restore service. Define the observation period with the owner rather than inventing a universal duration. A workload that runs only at a scheduled time needs that execution covered by the acceptance decision.
2. Prepare the authorized host and account permissions
Review the candidate's local service rights and downstream permissions before the change. Request the permissions needed for the workload's expected operations; retain the old identity's dependencies for the recovery window. Keep password-retrieval authorization separate from authorization to access application data. Passing the account test does not demonstrate either the application's complete permission set or its correct configuration.
After the directory and authorization gates pass, Microsoft's procedure installs the account on each host where the service runs. Execute locally in an elevated PowerShell session under the approved change:
Install-ADServiceAccount -Identity 'svc-pilot'
The cmdlet prepares the existing managed account on the local computer. It does not change the application's configured identity. Its reference requires retrieval authorization to be set for a gMSA. Microsoft Learn — Install-ADServiceAccount.
Repeat the account-readiness test on that host and preserve the outcome. If installation or testing fails, stop at this gate and investigate. Do not record an administrative command's completion as a successful service migration.
3. Cut over through the service's supported configuration
Use the product's supported identity configuration procedure to move the selected service. A generic command cannot safely describe every Windows service, app pool, task, and application. Keep that product-specific procedure and its reverse steps in the approved change record.
Verify the configured identity, then start or restart the workload as agreed. Have the owner execute representative client operations and downstream reads or writes. Compare the results with the baseline and inspect the application's actual errors. Where authentication matters, confirm the expected client and resource authentication behavior through the organization's established diagnostics. No single startup result substitutes for these tests.
If the acceptance criteria fail, follow those steps and document both the triggering failure and the restored service behavior. Preserve the evidence for investigation. Leaving an account object in AD while recovering the workload does not mean the pilot succeeded.
4. Close the pilot and track the remaining estate
After acceptance, record the service, hosts, new identity, tests, timestamps, approver, and unresolved limitations. Review all remaining consumers of the old identity before retiring it. Remove that identity only after validation and the approved recovery period; its name disappearing from one service configuration is not proof that no other workload depends on it.
The existing service-account remediation that recommends gMSA migration establishes a reason to migrate. This pilot supplies the operational evidence for that recommendation. Track later candidates separately: an accepted first service is progress, while estate adoption still requires a service-by-service inventory and decision.
How EtcSec Detects This
The relevant EtcSec check is GMSA_NOT_IN_USE. In the reviewed etc-collector implementation, it counts recognized gMSA users and enabled users with at least one SPN. It returns a Low-severity finding with Count = 1 only when the recognized gMSA count is zero and the enabled SPN-bearing user count is positive. Otherwise it returns Count = 0.
The recognition is narrower than a structural-class inventory: User.IsGMSA is set when the binary msDS-GroupMSAMembership attribute is nonempty. The LDAP user filter includes msDS-GroupManagedServiceAccount, but the parser does not use that class to set this user flag. A missing or unreadable membership attribute can therefore affect recognition; an incomplete LDAP boundary or MaxUsers limit can affect the inventory. A GetUsers error stops the engine rather than producing a successful empty inventory.
Every recognized gMSA contributes, including disabled objects. One recognized object is enough to make this signal zero, even if no service has migrated. Zero also occurs when no enabled SPN-bearing users were collected. This check does not inspect KDS keys, replication readiness, host installation, service configuration, application compatibility, or real service logons. It measures neither the proportion of services using gMSAs nor the success of the pilot.
Explore the identity security pages that support this topic