⌚ About 2 min read

Active Directory Intermediate. 15-30 min

This BAOI guide provides a structured method for diagnosing a gmsa without multiplying unnecessary changes.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une backup ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

1

Set perimeter

Identify the equipment, service, affected users and start time.
2

Collect Elements

Record the exact messages, logs and useful settings.
3

Test methodically

Start with the basic dependencies before the application components.
4

Apply correction

Change only the identified parameter or component.
5

Validate

Rewrite the full scenario and document the result.

Commands utiles

Test-ADServiceAccount nommsa

À retenir

Keep the initial values for a backwards.
Avoid multiple simultaneous changes.
Compare with a functional configuration when possible.

Technical deep dive

AD authentication: correlate code, DC and account

Technical checkpoints

Event ID 4625 contains Status/SubStatus values that distinguish bad password, disabled account, restrictions and other causes.
Lockout is logged as 4740 on the DC handling it; Caller Computer Name helps locate the offending host/service.
A gMSA depends on the KDS root key, hosts allowed to retrieve its password, SPNs and time/Kerberos.

Correlation

Find the event at the exact time and correlate user, source, LogonType and SubStatus.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625}
Get-ADUser user -Properties LockedOut,LastBadPasswordAttempt

Topic-specific pitfalls

Unlocking the account without removing the bad-password source causes another lockout.
A service, scheduled task, phone or mapped drive can keep using an old secret.

How to validate

The failure source is identified and 4625/4740 events stop after remediation.
The account/gMSA authenticates from the actually affected system.

Operational context

A group Managed Service Account (gMSA) failure is usually caused by host authorization, KDS/domain readiness, account retrieval, SPN identity or the service configuration consuming the account. Diagnose the account from Active Directory and from the exact host that runs the workload.

Step-by-step checks

Confirm the gMSA exists, is enabled and has the expected DNS host name and service principal names for the workload.
Verify the target computer or authorized security group is allowed to retrieve the managed password and that group membership has replicated to the domain controller being used.
Run the gMSA installation/readiness test from the actual workload host and inspect the resulting error rather than testing only from an admin workstation.
Check the Windows service, scheduled task or application configuration uses the gMSA in the supported account format and is not storing a manual password.

Useful verification commands

Use commands only on systems you administer and capture the read-only output before making a configuration change.

Get-ADServiceAccount -Identity MyGmsa -Properties *

Test-ADServiceAccount -Identity MyGmsa

setspn -L EXAMPLE\MyGmsa$

How to validate the result

The workload host must pass the gMSA test and the consuming service must start/authenticate successfully using the managed account without a stored password.

Evidence to keep

Keep the gMSA name, authorized principals, SPNs, workload host, selected DC, Test-ADServiceAccount result and relevant service/security event IDs.

Frequently asked question

Can a gMSA be tested successfully on one server and fail on another?

Yes. Password retrieval authorization is host-specific and depends on computer/group membership plus replication, so the test must be run on the host that will consume the account.

Related BAOI resources: IT tools · procedures · IT dictionary.