Auditing gMSA usage — what methods exist beyond Event ID 4662?

Event 4662 remains the authoritative record of a gMSA password-property read; complement it with host logon auditing, Kerberos events, Defender for Identity service-account inventory and hunting, and Sentinel correlation rather than expecting another native AD field to provide equivalent usage history.

1. Audit actual use on hosts and resources

A password retrieval proves that a computer requested the managed password, but not which service subsequently used it. Audit the resulting authentication separately:

• On each host running the gMSA, enable: Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\Logon/Logoff\Audit Logon for Success and Failure.
• Review Security events:
  • 4624 — successful logon
  • 4625 — failed logon
  • 4648 — logon attempted with explicit credentials

Logon events are written on the computer where the logon occurs; for network access, that is normally the resource server being accessed, not necessarily the gMSA’s service host.^1^

Also inventory the local configuration that references the gMSA:

$gmsa = 'CONTOSO\svc-app$'

Get-CimInstance Win32_Service |
    Where-Object StartName -eq $gmsa |
    Select-Object SystemName, Name, State, StartMode, StartName

Get-ScheduledTask |
    Where-Object Principal.UserId -eq $gmsa |
    Select-Object TaskPath, TaskName, State

For Windows services, the Service Control Manager logs on the configured account when starting the service and attaches the resulting token to its process.^2^ Correlate the service’s startup or application logs with 4624/4625; there is no single host event documented here as “gMSA password retrieved.”

2. Correlate domain authentication

On domain controllers, Kerberos auditing provides evidence that the identity was authenticated or used for access:

• 4768 — TGT requested
• 4771/4772 — Kerberos authentication/preauthentication failure
• 4769 — service ticket requested
• 4770 — service ticket renewed

Enable Audit Kerberos Authentication Service and, where the volume is acceptable, Audit Kerberos Service Ticket Operations. Microsoft classifies the latter as potentially high-volume on KDCs.^3^

These events answer different questions:

3. Native AD assessment

AD PowerShell can enumerate gMSAs, configuration, group membership, and principals authorized to retrieve the password, but it does not provide a historical usage ledger. Microsoft recommends reviewing privileged memberships and auditing access to sensitive resources, with archival to a SIEM.^4^

Useful checks include:

Get-ADServiceAccount -Filter * -Properties `
    PrincipalsAllowedToRetrieveManagedPassword,LastLogonDate,Enabled |
Where-Object ObjectClass -eq 'msDS-GroupManagedServiceAccount' |
Select-Object Name,Enabled,LastLogonDate,
    PrincipalsAllowedToRetrieveManagedPassword

Test-ADServiceAccount -Identity <name> is a point-in-time host test: True means the account can authenticate and access the domain using its current credentials.^5^ It is not usage auditing.

Do not retire a gMSA solely from a stale timestamp. Microsoft notes that service accounts can legitimately go extended periods without logging on and recommends multiple checks before disabling or deleting an account.^6^ Correlate 4662, host configuration, 4624/4768/4769, and application ownership.

4. Defender for Identity and Defender XDR

Defender for Identity provides two relevant capabilities:

• Service-account discovery identifies gMSAs and exposes recent authentications, including source and destination insights, in the Defender service-account inventory and IdentityInfo.^7^
• Suspicious Golden gMSA related activity is a high-severity credential-access alert for suspicious reads of sensitive gMSA objects. Its detector ID is xdr_SuspiciousGoldenGmsaActivity.^8^

For normal-use hunting, query IdentityLogonEvents, which contains on-premises AD authentication captured by Defender for Identity:^9^

let Gmsa = "svc-app";
IdentityLogonEvents
| where Timestamp > ago(30d)
| where AccountName =~ Gmsa or AccountName =~ strcat(Gmsa, "$")
| project Timestamp, ActionType, AccountDomain, AccountName,
          DeviceName, Application, LogonType, Protocol, FailureReason
| order by Timestamp desc

This hunts authentication, not password retrieval. MDI requires properly configured sensors on the domain controllers for on-premises AD data to populate identity hunting tables.^10^

5. Sentinel

Send the DC and host Security logs through Windows Security Events via AMA. It writes to SecurityEvent; Windows Event Forwarding writes to WindowsEvent, so rules must query the table actually used. Use All or a Custom data collection rule when an event required by your gMSA correlation is not included in the selected predefined set.^11^

Create a custom hunting query or scheduled analytics rule correlating:

1. 4662 retrievals,
2. 4624/4625 host logons,
3. 4768/4769 Kerberos activity,
4. the approved retrieval-principal list.

Sentinel supports promoting a hunting query through New alert rule → Create Microsoft Sentinel alert.^12^

The gMSA-specific Sentinel repository results identified under the BloodHound Enterprise solution concern principals or large groups holding password-read privileges on high-value objects. They assess exposure; they do not replace 4662-based detection of an actual password read. For native Microsoft detection of a suspicious read, use the MDI Suspicious Golden gMSA related activity alert, then build environment-specific Sentinel rules for ordinary retrieval and authentication baselines.

References

1. Windows security baseline
2. Service User Accounts
3. Advanced Audit Policy Configuration
4. Secure group managed service accounts
5. Test-ADServiceAccount-Syntax
6. Regularly check for and remove inactive user accounts in the Active Directory - Microsoft Engage Center
7. Investigate and protect Service Accounts
8. Microsoft Defender for Identity alerts in Microsoft Defender format
9. IdentityLogonEvents
10. Extend advanced hunting coverage with the right settings
11. Windows security event sets that can be sent to Microsoft Sentinel
12. Threat hunting in Microsoft Sentinel