The New Ouroboros Technique and How It Fits in dMSA’s Security Model

• Delegated Managed Service Accounts (dMSAs) represent a significant update to Microsoft Active Directory identity management. 

• Unlike traditional service accounts or group Managed Service Accounts (gMSAs), dMSAs move away from LDAP-based password retrieval toward a Kerberos-based credential issuance flow. 

• Although this improves security by integrating with features like Credential Guard, it introduces new logic-based risks. Specifically, the Ouroboros primitive demonstrates that if an attacker controls dMSA permissions, they can inherit the privileges of the superseded legacy account.

• Organizations should adopt dMSAs to simplify migrations and enhance security, but they must monitor the internal authorization paths that define successor status. 

Delegated Managed Service Accounts (dMSAs) are one of the most meaningful identity changes Microsoft has introduced to Active Directory in years. They were designed to solve a real operational problem: moving services off legacy service accounts without breaking the environments that still depend on them.

But a dMSA is not just a migration feature. It also appears to introduce a different security model for managed service identities, shifting away from direct password retrieval and toward a Kerberos-based authentication flow that is intended to be more secure.

In this blog post, we’ll explore what changed in that model, explain what dMSA protects and how, and identify where that security boundary is frequently misunderstood.

Note: This post is a companion to Andrew Schwartz’s Huntress write-up on Ouroboros. Andrew’s post covers the Ouroboros chain directly; ours focuses on the broader dMSA security model and the assumptions behind it. Briefly, Ouroboros is an account takeover and persistence primitive: A user with sufficient permissions over a dMSA object can gain control over the dMSA itself and over the privileges of the superseded account, and can even turn the dMSA into a way to authorize its own use.

To understand what changed with dMSA, it helps to start with gMSA.

A group Managed Service Account (gMSA) is a managed domain account that Windows can use for services. Instead of an administrator setting and rotating the account password manually, the domain controller generates and rotates it automatically. Authorized systems can retrieve the account’s managed password through the constructed attribute msDS-ManagedPassword, derive the Kerberos keys from it, and use the account. If you want more background on gMSA, Microsoft’s documentation is a good place to start.

That solution already solved some of the classic service account problems. It reduced password management pain, and because gMSA passwords are long and rotated automatically, it also made techniques like Kerberoasting far less practical. But the model still depended on retrieving the account’s password through Lightweight Directory Access Protocol (LDAP).

dMSA appears to change that model.

Microsoft describes dMSA as a design in which "the secret cannot be retrieved or found anywhere other than on the domain controller." Microsoft also describes dMSA authentication as linked to device identity, and says Credential Guard can further protect that model.

At the same time, a dMSA still has to function as a service identity. A machine using the dMSA still needs the account’s Kerberos keys. Otherwise, it would not be able to function as the service, including decrypting service tickets issued to it.

With dMSA, that material is not exposed through the old LDAP retrieval model. Instead, the Kerberos keys are being delivered through a Kerberos-based flow.

This is where the system uses KERB-DMSA-KEY-PACKAGE. When the account is used through the intended dMSA Kerberos flow, which is tied to msDS-GroupMSAMembership, the Key Distribution Center (KDC) can attach a KERB-DMSA-KEY-PACKAGE to the Ticket Granting Ticket (TGT) issued for the dMSA. In practical terms, that package provides the Kerberos material the caller needs to operate as the service identity.

This is also where Credential Guard matters. The point is not that the keys are somehow unique per host. “Machine-bound” is easy to read that way, but that is not the case. The point is simpler: The dMSA flow is tied to authentication, and Credential Guard protects authentication material on the host, including TGTs. 

So when the dMSA flow issues the material the service needs, Credential Guard can protect it just like any other TGT, without any changes to the feature itself (Figure 1).

The point of dMSA is that an organization should be able to assign meaningful privileges to a managed service identity without making those privileges easy to steal.

A machine should be able to use the dMSA, but compromising that machine should not automatically mean that the attacker now owns the identity in the same way they might with an older managed service account. 

If that promise holds, then dMSA is doing more than making service account management easier. It is trying to make service account privileges safer to assign, and that changes the boundary defenders need to think about. The question is no longer only whether a secret can be retrieved, but whether the identity can be used only through the intended path.

At the object level, a dMSA still looks familiar. Like a gMSA, it has the msDS-ManagedPassword attribute, and by default it also has a DENY ACE on that attribute. A natural assumption is that this discretionary access control list (DACL) is the whole protection story.

Our testing showed that it is not. Even after removing that DENY ACE, an LDAP read of msDS-ManagedPassword for a dMSA still failed. We identified a specific protection in ntdsai.dll for LDAP reads of msDS-ManagedPassword on dMSA objects. In other words, the attribute is not just denied by default in the DACL; the domain controller (DC) also blocks this LDAP read path specifically for dMSA.

That makes the older logging from our BadSuccessor research especially interesting. In that research, using a dMSA generated the older gMSA-style event: “A caller has successfully fetched the password of a group managed service account.” At first glance, that appears to contradict the behavior described above: If msDS-ManagedPassword is not normally retrievable for dMSA, why did the DC log a successful password fetch at all?

The event was odd for several reasons. We were not trying to read msDS-ManagedPassword, but instead we authenticated as the dMSA. The caller details also did not look like a normal authorized password read: The caller SID was S-1-5-7 (ANONYMOUS LOGON), and the caller IP was empty (Figure 2). In that context, the fact that the event was logged as a success made the behavior even harder to interpret.

Code analysis helped explain this. In addition to the LDAP path that explicitly blocks dMSA password reads, we identified another path in ntdsai.dll that can still reach the dMSA msDS-ManagedPassword attribute. In that path, we did not observe the kind of authorization check a reader might expect. Instead, the logic checked whether msDS-GroupMSAMembership was empty or non-empty. That explains how a request that seemingly originated from S-1-5-7 could still appear as a successful password fetch.

That observation initially looked promising. If there was an internal password-related path that did not perform the normal authorization check, it was natural to ask whether that path could be abused. We were not able to turn it into a remotely reachable password-read primitive, so this is only a side note, not a claim of a new exploit path. But it is still worth mentioning because it changes how these events should be interpreted.

Microsoft later introduced dMSA-specific events, such as “The KDC successfully fetched the password of a delegated managed service account” and “An attempt to fetch the password of a delegated managed service account failed.” The naming is better, but the underlying interpretation issue remains (Figure 3).

Up to this point, our discussion has mostly been about the dMSA itself: How the account receives the Kerberos material it needs, how the DC computes it, and how that flow is enforced.

But dMSA was designed for migration, and that means the dMSA’s own identity is often only part of the story. In many deployments, the superseded account is the identity that already holds the meaningful privileges.

Using the dMSA and inheriting the superseded identity are not the same thing, and one does not necessarily imply the other. A service might be able to authenticate as the dMSA and still not receive the superseded identity’s effective authorization context. What matters is not only whether the dMSA can be used, but also whether it is being used through the intended flow and recognized by the DC and KDC as the valid successor of the old account.

This is one of the clearest differences from the older gMSA mental model: With gMSA, once an authorized system could use the account, it effectively had the value of that identity; with dMSA, however, that is not always enough. In many environments, the more important question is whether using the dMSA also causes the system to grant the value that made the migration meaningful in the first place.

Ouroboros is an account takeover and persistence primitive built around the same dMSA model we just described. Read Andrew Schwartz’s companion Huntress write-up to learn more about the full chain; we will not repeat the exploitation steps here. The broader point addressed in this post is where that chain fits into the security design of dMSA.

It fits exactly at the boundary between using the dMSA and inheriting the superseded identity. In the intended model, that separation is a core part of what gives dMSA its security value.

Ouroboros shows how that separation can break down in practice. Control of the dMSA can be turned into a state in which operating as the dMSA is enough to inherit the superseded account’s effective privileges. In practical terms, the dMSA becomes not only the account being used, but also the mechanism that preserves its own successor status.

The interesting question is no longer only whether an attacker can obtain dMSA authentication material. The more important question is whether the logic around that material can be shaped so that control of the dMSA also carries the successor relationship that gives the account its real value in the first place.

Moving from password retrieval to controlled issuance does not eliminate the security problem; it moves it. With dMSA, secret retrieval is only part of the security boundary. The logic that decides when the account can be used, and when it inherits the value of the identity behind it, matter just as much.

dMSA looks like a meaningful security improvement, and it solves a real operational problem. Moving away from normal password retrieval and toward a DC-controlled Kerberos flow is a sensible change in the managed service account model.

But that also means the security boundary has changed. The important question is no longer only whether a managed password can be read from the directory, it is also whether the system correctly controls when the account can be used, and when it is allowed to inherit the value of the identity it replaced.

dMSA should not be understood as simply “gMSA, but harder to read from LDAP.” Microsoft appears to have introduced a broader model here, and the right way to evaluate it is to study that model directly: How the DC issues authentication material, how the authorization path is enforced, and how successor state is recognized.

dMSA should still be used. But it should be used with a precise understanding of the boundary it is meant to provide, because that boundary is broader than it first appears.