Skip to content

AD-ACL-006: gMSA passwords readable outside tier 0

high   Permissions   MITRE ATT&CK T1555   Reads: LDAP

A group managed service account's password can be retrieved by a broad group, or a privileged gMSA's by someone outside tier 0, so they can act as that service account.

Also known as: gmsa-password

Why it matters

A gMSA's password is generated and rotated by the domain controllers. Any principal listed in its msDS-GroupMSAMembership security descriptor (shown by the AD module as PrincipalsAllowedToRetrieveManagedPassword) can read the constructed attribute msDS-ManagedPassword and derive the account's NT hash from it.

  1. An attacker controls any member of the allowed group, for example any domain user when the group is Domain Users.
  2. They read msDS-ManagedPassword over LDAP (gMSADumper, DSInternals, BloodHound's ReadGMSAPassword edge) and compute the NT hash.
  3. They pass the hash or request Kerberos tickets as the gMSA, and inherit whatever it can do: local admin on the servers it runs on, database access, or more when the gMSA sits in a privileged group.

Automatic rotation does not help: the attacker simply reads the new password.

How ad-doctor detects it

ad-doctor reads every msDS-GroupManagedServiceAccount object and parses the allow ACEs in msDS-GroupMSAMembership; every SID they name is treated as a reader. A gMSA is reported when a reader is:

  • a broad group (Everyone, Anonymous Logon, Authenticated Users, Users, Pre-Windows 2000 Compatible Access, Domain Users, Domain Guests, Domain Computers), or
  • anyone outside tier 0 and the operator groups, when the gMSA is itself a (transitive) member of a privileged group.

Each object names the gMSA and the risky readers, for example gmsa_web$ (readable by Domain Users).

Attributes and probes read
  • msDS-GroupMSAMembership (PrincipalsAllowedToRetrieveManagedPassword)
  • sAMAccountName of msDS-GroupManagedServiceAccount objects
  • member (privileged groups, transitively)

Severity

Always high as the check stands: it reports a gMSA only when a broad group can read the password, or when the gMSA is itself privileged and a non-tier-0 principal can read it. Both hand the account's identity to people who should not have it.

False positives and limits

  • Domain Computers as the reader is a shortcut some installers take so that any server can run the service. It is still a real finding: any computer account, including one a user creates through ms-DS-MachineAccountQuota, can read the password.

Fix

  1. See who can read the password (read-only):

    Get-ADServiceAccount gmsa_web -Properties PrincipalsAllowedToRetrieveManagedPassword |
    Select-Object -ExpandProperty PrincipalsAllowedToRetrieveManagedPassword

  2. Limit the readers to the hosts that run the service, ideally through a dedicated group that contains only those computer accounts:

    Set-ADServiceAccount gmsa_web -PrincipalsAllowedToRetrieveManagedPassword 'WEB01$', 'WEB02$' -WhatIf

  3. Assume the identity was exposed: review what the gMSA can reach and its recent logons. If abuse is suspected, replace it with a new gMSA rather than waiting for the next rotation.

  4. Keep privileged gMSAs readable only from tier-0 hosts, and do not put gMSAs in tier-0 groups unless the hosts that run them are tier 0.

Verify

ad-doctor scan dc01.corp.example --ldaps -u 'CORP\auditor' --only AD-ACL-006

To accept the risk instead, add an entry to the file passed with --accept (see accepted risks):

[[accept]]
check = "AD-ACL-006"
objects = ["..."]        # optional; without it the whole check is accepted
reason = "..."
expires = 2027-03-31

References

Microsoft and vendors

Research

Tools

MITRE ATT&CK

Available since 0.1.0.