Service accounts, sMSA, and gMSA: The relationship between identity, SPN, password, and access; a version note on dMSA

1. Core mechanism

The password for the service ID lives differently in three different places: in the manual service account, an ordinary password that the administrator knows and rotates manually; a Windows-managed secret connected to a single machine in SMSA; In gMSA, it is a value that does not remain statically in AD, is calculated by DC from the Key Distribution Service root and can only be received by authorized hosts. The boundary of the lesson is the 'identity-password-access relationship': Kerberos ticket mechanics in 06.xx, SPN format in this lesson only in the context of identity; Delegation detail is covered in 06.xx and computer account ownership in 08.03.

Interfaces and specifications

• manual service account: an ordinary domain user account; The administrator knows the password and returns it manually; The administrator manages the SPN.
• sMSA (standalone Managed Service Account): Came with Windows Server 2008 R2; It provides automatic password management and simplified SPN management, but is tied to a single host.
• gMSA (group Managed Service Account): Came with Windows Server 2012; multiple hosts in a server farm share the same identity; DC calculates the password.
• msDS-ManagedPassword: A constructed attribute in the gMSA object; It is not stored static, it is returned to the authorized caller as MSDS-MANAGEDPASSWORD_BLOB at the time of the request.
• MSDS-MANAGEDPASSWORD_BLOB: Version, Reserved, Length; CurrentPasswordOffset, PreviousPasswordOffset, QueryPasswordIntervalOffset, UnchangedPasswordIntervalOffset; current/optional previous WCHAR values and two distinct interval fields.
• msDS-GroupMSAMembership is a security descriptor. The DC evaluates the requester’s security context, including applicable account and group SIDs, for RIGHT_DS_READ_PROPERTY on this descriptor.
• msDS-ManagedPasswordInterval: Determines how many days the gMSA password will change; In PowerShell, the default is 30 days and is determined at creation time.
• An SPN requires <service class>/<host>; :<port> and /<service name> are optional components used when needed. For example, cifs/files.example.test needs neither extra component. The SPN must be unique within the forest.

Problem: who returns a shared service password

A service (web application, database, scheduled task) runs with an identity. If this identity is a domain user account, a human will know its password and must return it manually. If there are ten hosts in a server farm sharing the same identity, this manual rotation is both an operational burden and a security vulnerability: the password rarely changes, is stored in many places, and it becomes unclear who knows it.

Managed Service Accounts solve exactly this problem. sMSA (Windows Server 2008 R2) leaves the password to Windows for a single machine; but it is insufficient in the farming scenario because the identity is tied to a single host. gMSA (Windows Server 2012) extends the same functionality to multiple servers within the domain: In a Network Load Balanced solution, all service instances use the same principal and Windows manages the password instead of the administrator.

The heart of gMSA is the Microsoft Key Distribution Service (kdssvc.dll): it derives periodically changing keys from a secret root. For gMSA, the DC calculates the password based on this key and other attributes of the account. Member hosts can retrieve the current and previous value of the password by contacting a DC. Throughout the course we will monitor a single gMSA called svc-web.

gMSA password: It is not static in AD, it is calculated

The most important concept in gMSA is that the password does not remain as a static field in the directory. msDS-ManagedPassword is a constructed attribute: DC calculates it at the time of request, only for the correct object type and only for the authorized caller. For an unauthorized reader, the attribute either does not exist or access is denied. The plaintext of the password is not kept permanently in the directory.

The returned MSDS-MANAGEDPASSWORD_BLOB begins with Version 0x0001, Reserved 0x0000 and Length. Four offsets locate the current password, optional previous password and two intervals: CurrentPasswordOffset, PreviousPasswordOffset, QueryPasswordIntervalOffset and UnchangedPasswordIntervalOffset. Password fields are null-terminated WCHAR values; a zero PreviousPasswordOffset means the previous field is absent. Both intervals are eight-byte values in 10^-7 seconds, but their meanings differ: the receiver must re-query after QueryPasswordInterval; queries before UnchangedPasswordInterval expires return the same password value.

This 'current + previous' pair is no coincidence: when the password changes, the previous value is kept valid for a while so that a host that has just received the old password from a DC with a replication delay can continue authentication. How many days the password will change is determined by msDS-ManagedPasswordInterval; The default in PowerShell cmdlets is 30 days and is determined when creating the gMSA.

Access decision: access check in msDS-GroupMSAMembership

The security axis of gMSA is the question: who can get the password? The answer is in the msDS-GroupMSAMembership attribute. This attribute has the syntax String(NT-Sec-Desc); that is, it is a security descriptor. In the words of the AD schema, this attribute is used 'for the access check that determines whether a requestor has permission to retrieve the group MSA password'.

The decision is not based on the account SID alone. The DC evaluates applicable account and group SIDs in the requester’s security context against the msDS-GroupMSAMembership DACL. One ACE may grant WS-WEB1$ directly; another may grant the gMSA-Hosts group. In the latter case, the group SID must be applicable in that request’s security context. Current directory membership alone does not prove an older context was refreshed.

[MS-ADTS] The GetgMSAPasswordBlob procedure in 3.1.1.4.5.39 binds the decision to two ports. Connection first: ERROR_DS_CONFIDENTIALITY_REQUIRED is returned if the connection is not encrypted. Then authorization: operationsError / ERROR_DS_CANT_RETRIEVE_ATTRS is returned if the caller does not have RIGHT_DS_READ_PROPERTY control access right on this descriptor. So the right read is exactly RIGHT_DS_READ_PROPERTY; The RP token in the artifact encodes exactly this right.

So the real attack surface of a gMSA is which principals are included in that descriptor. In the Artifact section we will read exactly this security descriptor at the byte/ACE level: which trustee is on the list determines who can obtain the password.

sMSA/gMSA/dMSA: scope difference and Windows Server 2025 note

It is necessary to distinguish the three options by scope. SMSA depends on a single host; It provides automatic password and SPN management but does not solve the farm. gMSA extends the same identity to multiple hosts within the domain and is not valid on operating systems prior to Windows Server 2012. Both depend on the types of encryption Kerberos supports; If the msDS-SupportedEncryptionTypes setting is incorrect (e.g., the account does not define AES while the host has RC4 turned off), authentication will fail — Microsoft recommends configuring AES for MSAs.

SPN management is part of this picture: if a service is to be authenticated with Kerberos, it must have the correct SPN. The required SPN skeleton is <service class>/<host>; :<port> and /<service name> are optional and must be unique within the forest. A conflicting SPN breaks the Kerberos service ticket request; Windows Server 2012 R2 and later DCs prevent duplicate SPN writing and Directory Services event 2974 is generated with error ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST (0x21C7).

Version note — dMSA (delegated Managed Service Account) was introduced in Windows Server 2025. It is a distinct model that supports migration from a traditional service account and machine-identity-bound authentication. Creation, migration, and operating requirements are outside this lesson.

State and data flow

1. Installation: KDS root key is available; svc-web gMSA is created, the authorized host group is written to msDS-GroupMSAMembership.
2. Permission definition: descriptor ACEs can grant the required right to account or group trustees; the request’s security context is evaluated separately.
3. Request: the host sends an msDS-ManagedPassword read to the DC using its computer-account context. The encrypted-connection requirement is checked separately.
4. Access check: after the encrypted-connection check, the DC evaluates applicable account/group SIDs for RIGHT_DS_READ_PROPERTY on the msDS-GroupMSAMembership descriptor.
5. Calculation: if authorized, the DC calculates the password with the KDS key and account attributes and returns MSDS-MANAGEDPASSWORD_BLOB.
6. Returned content: current WCHAR and optional previous WCHAR; zero PreviousPasswordOffset means no previous field. Retrieval does not prove service authentication success.
7. Interval distinction: re-query after QueryPasswordInterval; queries before UnchangedPasswordInterval expires return the same value. The day-based msDS-ManagedPasswordInterval is a separate setting.

2. Exploitation

Broken trust assumption

The safe assumption is: 'no one can get the managed service account password because Windows manages it; gMSA is automatically safe.' Where it breaks: the authority to retrieve the password is defined in a security descriptor (msDS-GroupMSAMembership); A principal authorized in this descriptor (or someone who can change it) can obtain the gMSA's cleartext password via the legitimate API.

Technical prerequisites

• A principal controlled by the attacker is authorized in the msDS-GroupMSAMembership descriptor of the target gMSA (e.g., a computer account that is a member of the authorized host group).
• Or the attacker has the required Write Property right on the msDS-GroupMSAMembership attribute of the gMSA object and can change the descriptor to add its own principal.
• The target gMSA has meaningful access (otherwise obtaining the password has limited effect).
• The claim that 'gMSA password can be obtained by anyone' without these conditions is false; Access depends on access check.

Exploitation mechanism

The plaintext of the gMSA password is returned as a legitimate directory read via the msDS-ManagedPassword constructed attribute; Exploitation is not a separate 'deficit' but a misconstructed entitlement. If a principal is allowed in the msDS-GroupMSAMembership DACL, the DC gives him the CurrentPassword in MSDS-MANAGEDPASSWORD_BLOB and the attacker can impersonate gMSA with this password. The second way is for a principal that can write the msDS-GroupMSAMembership attribute to first add its own SID to the list and then retrieve the password; This explains why the specific attribute-write rights on gMSA and related computer objects are sensitive (related to the 08.03 ownership chain). The impact is limited to the resources gMSA accesses; Calculating the password again depends on the authorized caller and the correct object type.

If the authority is in the wrong place, the password will be leaked legitimately

In gMSA, the threat model is not 'breaking the password', but 'being authorized to obtain the password'. If msDS-GroupMSAMembership is written too broadly (e.g., an overly large group, or an incorrect computer account), any host in that list can obtain the cleartext password via a legitimate API. This is not a vulnerability but an authorization error; but the result is a real credential disclosure.

So the gMSA audit comes down to the question of 'who is in this descriptor?' Each trustee in Descriptor is a candidate who can access the gMSA ID. Artifact is designed to read exactly this descriptor.

Boundary and inhibitory control

Scope limit: Retrieving the gMSA password only opens resources that that gMSA can access; It does not automatically provide domain management. Additionally, password calculation still depends on the authorized caller and the correct object type; For an arbitrary reader, the attribute returns null or is rejected.

Blocking controls: limit msDS-GroupMSAMembership to the narrowest host group possible; control write rights on gMSA and computer objects (a principal who can change the descriptor can expand the list); Avoid making gMSAs members of highly privileged groups so that a password disclosure is unlikely.

3. Defense & Detection

Telemetry scope

• Since the gMSA password is not stored static, the permission surface is audited instead of searching for a 'password file': Who is in the msDS-GroupMSAMembership should be reviewed regularly.
• For attribute changes to be recorded as 5136, Audit Directory Service Changes Success must be enabled on the DC and the relevant object SACL must match the changed attribute.
• SPN conflict writing is blocked on 2012 R2 and later DCs and produces Directory Services event 2974 and ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST (0x21C7).
• Retrieval can be monitored through 4662 when the DC has Audit Directory Service Access and a SACL matching the target operation. Do not assume automatic events in every environment. 5136 records a descriptor change; 4662 conditionally records an object operation. Access to service resources requires separate evidence.
• Attributes such as msDS-ManagedPasswordInterval and msDS-SupportedEncryptionTypes are validated by the configuration check; An RC4-only gMSA is a silent vulnerability.

Events and relevant fields

• 5136 — Directory Service object modified; production requires the DC audit subcategory and a SACL Success audit ACE that matches the changed attribute. Validate field names against the OS version and event schema.
• 2974 — Directory Services: duplicate SPN writing prevented (ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST, 0x21C7).
• 4741/4742 — creation/change of host computer accounts (context of identity of machines using gMSA; see 08.03).
• 4662 — object operation under matching auditing/SACL; verify collection scope for gMSA retrieval monitoring.

No static passwords: control slides into the permission surface

In manual service account control revolves around 'where is the password, who knows'. This question becomes meaningless since the clear text password in gMSA is not static in the directory; It is replaced by the question 'who is authorized to receive it?' Therefore, the primary source of evidence is not the password value, but the trustee set in the msDS-GroupMSAMembership descriptor and its change history (5136).

Retrieval can be monitored through 4662 when the DC has Audit Directory Service Access and a SACL matching the target operation. Do not assume automatic events in every environment. 5136 records a descriptor change; 4662 conditionally records an object operation. Access to service resources requires separate evidence.

Configuration proof and verification

Verification of tightening is two-step. First the current state: for each gMSA, the principals in msDS-GroupMSAMembership are listed and compared with the expected host group. Then change: edits to this descriptor (5136) are tracked and verified to match only approved management processes.

On the SPN and encryption side, verification is an inventory of duplicate SPN blocks (2974) and msDS-SupportedEncryptionTypes values. These checks are permanent: when a new gMSA is added, the same check is applied again. The change must be reversible and implemented gradually.

Detection logic · Sigma

title: gMSA membership descriptor degisikligi (5136 uzerinden)
status: experimental
description: >
  msDS-GroupMSAMembership attribute'unun (parolayi alabilecek principal listesi)
  degistirildigi 5136 olaylarini daraltir. Yalniz ilgili nesnede SACL yapilandirilmis
  ve Audit Directory Service Changes acikken uretilir; DC-side ve yuksek hacimlidir.
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 5136
    AttributeLDAPDisplayName: 'msDS-GroupMSAMembership'
  condition: selection
fields:
  - SubjectUserSid
  - ObjectDN
  - AttributeValue
  - OperationType
falsepositives:
  - Mesru gMSA yonetimi (yeni host farm ekleme) ayni izi birakir
  - Toplu otomasyon/IaC ile yapilan yetki degisiklikleri
level: medium

Query assumptions

• Source: DC Security channel; Audit Directory Service Changes Success must be enabled, and the relevant gMSA object SACL must match successful Write Property changes to msDS-GroupMSAMembership.
• Events whose AttributeLDAPDisplayName field is msDS-GroupMSAMembership are selected; If there is no field, the rule does not match.
• It is assumed that the backend ingests 5136 EventData field names (AttributeLDAPDisplayName, AttributeValue, OperationType) with these names; Field mapping is required in different schemes.

False positives

• Legitimate gMSA administration (authorizing a new server farm) produces exactly the same 5136/attribute trace.
• Bulk authorization changes with IaC/automation can create high but benign volume.
• Changes are not visible outside scope if the SACL has no matching attribute ACE on some gMSA objects (telemetry gap).

Hardening

• Restrict msDS-GroupMSAMembership to narrowest host group; Review the 'who can get the password' list regularly and remove unnecessary principals.
• tighten write rights on gMSA and related computer objects; The principal, who can change the descriptor, can get the password by expanding the list.
• Configure AES encryption types for MSAs (msDS-SupportedEncryptionTypes); Don't let it remain RC4-only.
• Keep SPNs unique and accurate; Trace duplicate SPN block (2974) as a signal on 2012 R2+ DCs.
• Authorize gMSAs to only required resources; Avoid membership in high-privilege groups to avoid possible password disclosure.

Read the examples

O:BAG:BAD:(A;;RP;;;S-1-5-21-1109110911-2202220222-3303330333-6501)S:

Two reality checks

Assumption: Because the gMSA password is managed by Windows, no account can receive it in clear text.

In fact: The gMSA password is returned to an authorized caller as clear text (CurrentPassword, WCHAR) in MSDS-MANAGEDPASSWORD_BLOB via the msDS-ManagedPassword constructed attribute. The access check in the msDS-GroupMSAMembership security descriptor determines who is authorized; A principal on the list can obtain the password legitimately.

Assumption: Switching to gMSA makes SPN and encryption configuration unnecessary; everything is automatic.

In fact: gMSA automates password rotation, but SPN uniqueness and encryption types must still be correct. Conflicting SPN breaks the Kerberos service ticket (2012 R2+ DCs prevent duplicate writes, event 2974 / 0x21C7), and authentication fails if the account does not define AES while the host has RC4 disabled; Microsoft recommends AES for MSAs.

Sources

• Microsoft · Group Managed Service Accounts overview
  sMSA (WS2008R2) and gMSA (WS2012) scope difference; KDS (kdssvc.dll) key root; DC calculates the password; hosts retrieve current and preceding passwords from the DC; msDS-SupportedEncryptionTypes / AES recommendation.
• Microsoft Open Specifications · [MS-ADTS] msDS-ManagedPassword
  msDS-ManagedPassword constructed attribute; calculated only for an authorized caller and the correct object type; not stored statically.
• Microsoft Open Specifications · [MS-ADTS] MSDS-MANAGEDPASSWORD_BLOB
  Version 0x0001, Reserved 0x0000, Length, CurrentPasswordOffset, PreviousPasswordOffset, CurrentPassword/PreviousPassword (WCHAR), Query/UnchangedPasswordInterval (10^-7 s).
• Microsoft · ms-DS-GroupMSAMembership attribute (AD Schema)
  Syntax String(NT-Sec-Desc); 'used for access checks to determine if a requestor has permission to retrieve the password for a group MSA'; Windows Server 2012; default O:BAG:BAD:S:.
• Microsoft · Name Formats for Unique SPNs
  SPN format <service class>/<host>:<port>/<service name>; must be unique in the forest; a conflicting SPN breaks Kerberos service tickets.
• Microsoft · SPN and UPN uniqueness
  WS2012 R2+ DCs block duplicate SPN writes; ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST (0x21C7) and Directory Services event 2974.
• Microsoft · Delegated Managed Service Accounts overview
  dMSA introduced in Windows Server 2025; machine-identity-bound authentication and migration from a traditional service account. Detailed setup/migration is outside this lesson.
• Microsoft · Event 5136 / Audit Directory Service Changes
  Event 5136: Directory Service Changes Success audit and a matching SACL Write ACE are required; AttributeLDAPDisplayName identifies the changed attribute. This is a configured audit signal, not proof of password retrieval.
• Microsoft · Event 4662
  Selected passages reviewed: bounded permission/operation conditions; no runtime validation.
• [MS-ADTS] Extended Access Checks
  Selected passages reviewed: bounded permission/operation conditions; no runtime validation.