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

Question

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

MOD Administrator 0

While investigating a stale gMSA finding (154 days, Active = False), I realised our environment had no gMSA auditing in place. I’ve now configured:

DS Access audit policy (Success) via GPO on Domain Controllers
SACL on Managed Service Accounts container → Descendant msDS-GroupManagedServiceAccount objects → Everyone → Read all properties → Success
This generates Event ID 4662 whenever a host retrieves the gMSA password

This lets me see who is requesting the password and when.

Looking for: Are there additional auditing methods for gMSA accounts? For example:

Anything at the host/service level?
Any native AD tooling beyond event logs?
Any MDI or Sentinel detection rules specifically for gMSA activity?

0 comments

2 answers

Your answer

Answer 1

AFAIK, there are a few additional options...

Host/Service level auditing

Event ID 4662 targets the Domain Controller (DC) tracking the password request, but the member servers fetching and running the services generate their own events.

Event ID 2946 (Microsoft-Windows-Security-Netlogon): This event logs on the host server whenever it successfully reads the gMSA msDS-ManagedPassword attribute. This is highly useful for validating which servers are natively fetching the password using the Group Policy/Netlogon mechanism versus third-party actors.
Event ID 4624 (Security - Type 5 Logon): When the service initializes, it logs a Logon Type 5 (Service) on the host. You can cross-reference the TargetUserName (the gMSA account name) to verify that a background service actually spawned under that identity.
Failed Retrievals (Event ID 4211 / Netlogon errors): If a stale host or an unauthorized host attempts to fetch the password but lacks permissions, it logs failures under the Microsoft-Windows-Directory-Services-Service-Principal-Name or Netlogon logs.

Native AD tooling

You can query the Attribute Replication Metadata via PowerShell to see when and which DC last modified or replicated the gMSA object.

Get-ADReplicationAttributeMetadata -Object "CN=yourgMSA,CN=Managed Service Accounts,DC=domain,DC=com" -Server "YourDC"

Microsoft Defender for Identity and Sentinel

Both platforms natively parse identity telemetry to surface anomalous gMSA behavior.

MDI treats service accounts with high value. You can tag your gMSAs as Sensitive or use the Honeytoken feature inside the Microsoft Defender portal. If an unauthorized endpoint or user attempts to enumerate or read the properties of a Honeytoken gMSA, MDI generates an instant high-severity alert.

MDI flags automated sensor authentication health. If you are using a gMSA for the MDI Directory Service Account (DSA) sensor itself, MDI monitors its password rotation state and fires a health alert if the workspace-level credentials fall out of sync.

If you deploy newer v3.x sensors, you can turn on Automatic Windows auditing configuration under Settings -> Identities -> Advanced features. This ensures your DC advanced audit policies don't suffer from configuration drift or manual GPO overrides.

Once your 4662 logs are flowing into Sentinel via the Windows Security Events connector, you can run KQL hunting rules. Because regular hosts retrieve passwords roughly every 30 days, any user account or unexpected host querying msDS-ManagedPassword is a major indicator of credential exposure or reconnaissance.

To detect non-computer accounts or unauthorized hosts fetching gMSA passwords, try the following

SecurityEvent
| where EventID == 4662
| where ObjectServer == "DS"
// msDS-ManagedPassword attribute GUID
| where Properties has "7622da0d-9b0f-48c2-84c4-754f33744040"
// Extract the account doing the requesting
| extend RequestingAccount = Account
// Filter out legitimate machine accounts if they follow a naming convention (e.g., ends with $)
// Or filter by an approved Watchlist of servers allowed to use gMSAs
| where not(RequestingAccount endswith "$")
| project TimeGenerated, Computer, RequestingAccount, ObjectName, SubjectLogonId

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Answer 2

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:

Evidence	Meaning
4662 on the gMSA object	A principal read the audited password-related property
4624/4625	The gMSA succeeded or failed in a logon on that system
4768	The gMSA requested a TGT
4769	The gMSA requested a ticket for a particular service

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:

4662 retrievals,
4624/4625 host logons,
4768/4769 Kerberos activity,
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