Inside dMSA on AD 2025: How It Works, How to Monitor It, Why It Matters

Active Directory Domain Services (ADDS) service accounts are special accounts used by applications or services to interact with network resources. Traditionally, these were often standard user accounts with static passwords, leading to security risks. Later, Microsoft introduced Managed Service Accounts (MSA) and group Managed Service Accounts (gMSA) to automate password management and improve security for service accounts. In Windows Server 2025, a new feature called Delegated Managed Service Accounts (dMSA) was introduced as an evolution of this concept.

Note: The dMSA security enhancement can mitigate attacks like Kerberoasting

MSA vs gMSA vs dMSA

Before touching dMSA, let’s understand how it compares to earlier (and exiting) managed service account types:

Standalone MSA (Managed Service Account)

Introduced in Windows Server 2008 R2, an MSA is a domain account tied to a single host. ADDS automatically manages its password, eliminating manual updates. However, an MSA can only be used on one computer, and you must configure that specific host as the account’s owner. MSAs simplify password management for services on single servers but cannot be shared across multiple systems.

gMSA (Group Managed Service Account)

Introduced in Windows Server 2012, a gMSA extends MSAs by allowing multiple hosts to use the same account. ADDS stores a long, randomly generated password for the gMSA, and any authorized host can retrieve the current password to run services. This makes gMSAs ideal for load balanced services or clusters. The password is auto rotated by ADDS and fetched as needed by hosts in the

Also, the PrincipalsAllowedToRetrieveManagedPassword list gMSAs can reduce the burden of password management and improve security, but their credentials, while auto managed, are not machine bound, and any authorized host can retrieve the plaintext password from ADDS.

Note: PrincipalsAllowedToRetrieveManagedPassword is an attribute that lists which computers or groups are allowed to retrieve the gMSA secret

dMSA (Delegated Managed Service Account)

A dMSA is a new managed service account in Windows Server 2025 that builds on gMSA concepts while introducing tighter binding to specific machines. Like a gMSA, a dMSA’s password is automatically managed and rotated by ADDS. Also, unknown to human users. However, a dMSA is machine bound and only specific machine identities in ADDS are allowed to use or authenticate as the account.

A dMSA is a machine bound, automatically managed service account designed to replace legacy objects without requiring manual reconfiguration of all services. The primary goal of dMSA is to enhance security and simplify credential management for services, especially during transitions from older accounts.

dMSA authentication is linked to a device’s identity, and the cryptographic secrets for the account are kept such that they cannot be retrieved in plaintext from ADDS by an admin or host, and the secret exists only on the domain controller. It is derived in part from the machine’s own credentials. This means even if a host is authorized to use a dMSA, it doesn’t get a reusable password hash. It receives a Kerberos ticket or key uniquely tied to that machine. In essence, dMSAs combine the benefits of gMSAs with an extra layer of security. Also, binding the service account to specific servers and the Kerberos LSA can mitigate credential theft and reuse attacks (like Kerberoasting).

Note: Tools that can exploit dMSA can be Rubeus, PowerView, DSInternals, and others. 

In a nutshell. A gMSA is managed by ADDS and can run on multiple servers, whereas a dMSA is intended to run on a specific server and is managed by an administrator, but with ADDS handling the credentials behind the scenes. Both gMSA and dMSA have rotating, random passwords. Still, dMSAs ensure that those credentials are not directly exposed to or retrievable by the server. The authentication is handled via the device’s identity and the Local Security Authority, not by the service supplying a password.

Note: In practice, a dMSA often starts as a replacement for an existing user based service account. The dMSA takes over the identity and permissions of that legacy account through a migration process, but with far stronger protections on the credentials.

---

How dMSAs Work?

Machine Bound Authentication

Once a service uses a dMSA, only a specified machine can use that account’s identity. The Kerberos authentication for dMSA is linked to the computer’s own credentials. Under the hood, the KDC maintains a random secret key for the dMSA derived from the machine account credentials and stores it so it can’t be retrieved from ADDS like a standard password hash.

When a service on an authorized host tries to authenticate as the dMSA, the authentication request is redirected to the host’s Local Security Authority (LSA), which works with the KDC to use the machine bound secret for Kerberos tickets. The host doesn’t have the dMSA password at all. It obtains Kerberos service tickets or TGTs for the dMSA identity that cannot be used on other machines.

This design potentially prevents an attacker from stealing the service account’s credentials and using them elsewhere. Even if a ticket were captured, it would be encrypted with a key tied to the specific host.

While gMSA uses randomized auto rotating passwords, the passwords are still not machine bound and can be stolen. In contrast, dMSA can leverage Credential Guard and machine binding, so the secret can’t be retrieved or found anywhere other than on the Domain Controller.

This dramatically reduces the risk of credential theft attacks such as Kerberoasting, where attackers traditionally request service tickets for service accounts with SPNs and then brute force the tickets offline to recover weak passwords. With dMSA, the Kerberos TGT and service tickets are encrypted using strong, random secrets frequently changed and not stored on services in plaintext, refusing the traditional Kerberoast vector.

Seamless Migration from Legacy Accounts

One of the features of dMSA is the ability to migrate an existing service account without breaking the service. This is achieved through a migration process where the dMSA supersedes the old account. During migration, ADDS links the two accounts and temporarily grants the new dMSA all the access the old account had, so it can effectively step into its shoes.

Once migration is completed, any authentication attempt using the old account’s credentials is intercepted, the old account’s password login is disabled, and authentication requests are redirected to the LSA to use the dMSA credentials instead.

From the service’s perspective, it might still be configured with the legacy account, but ADDS is now treating that principal as an alias of the dMSA. This means the service can continue running under what appears to be the old account, but behind the scenes, it uses the dMSA’s machine bound secret.

This design improves security without immediately reconfiguring potentially numerous services or scheduled tasks. Once the migration is finalized, the original account becomes disabled. During migration, all of its key attributes are copied to the dMSA account so that the dMSA has the same identity footprint in the domain.

Credential Management

dMSAs use ADDS to automatically manage the account’s secret/password. No manual password resets are needed or even possible. In fact, it explicitly notes that you cannot force a password reset for a dMSA.

The system regularly rotates the dMSA’s password. When rotation happens, the new secret is again stored so that only the DCs know it. The authorized machines will transparently start using the latest secret for Kerberos operations because administrators cannot handle the credentials directly, which reduces the chance of mismanagement or exposure.

Integration with Credential Guard

Windows Credential Guard can be used with dMSA for even stronger security. Credential Guard is a Windows security feature that isolates secrets in a secure execution environment, making them harder to extract even if the OS is compromised. In the context of dMSA, Microsoft indicates that enabling Credential Guard on the server can further protect the dMSA’s Kerberos tickets and keys in memory.

When Credential Guard is enabled, the dMSA’s secret keys used for ticket encryption are protected so that even if malware runs on the server, it’s significantly challenging to scrape those keys. This makes dMSAs particularly appealing for high-value services you remove the static password and shield the transient credentials.

Scope of Use (Single vs Multi Server)

By design, a single dMSA can be used on one or multiple machines, but only if those machines are explicitly authorized. In practice, dMSA is expected to be used in scenarios where a service account was historically used on one server.

However, suppose the same legacy account was used on multiple servers. In that case, you cannot migrate all instances into one dMSA if that implies a shared identity. Microsoft clarifies that you must create one dMSA per legacy account. You cannot merge multiple separate service accounts into a single dMSA.

Once dMSA can be authorized for various hosts, if the scenario requires the same account on multiple servers. During migration, the system will learn all the host machines where the old account is in use and add them to the dMSA’s allowed host list. Thus, a dMSA can support a farm of servers running the same service account, but it remains one account in ADDS, just like the original. This still adheres to the machine-bound principle.

New Attributes

Under the hood, dMSAs introduced attributes in the AD schema to handle this linking and state management. Notably:

• msDS-DelegatedMSAState indicates the state of a dMSA in the migration lifecycle (0 = none/unknown, 1 = migration in progress, 2 = migration completed, 3 = standalone dMSA that isn’t tied to a legacy account)

• msDS-ManagedAccountPreczededByLink set on the dMSA to store the distinguished name (DN) of the superseded original account, if any

• msDS-SupersededManagedServiceAccountLink Set on the original account to link back to the new dMSA that superseded it

• msDS-SupersededAccountState a flag on the original account indicating it’s in the process of being superseded or has been superseded

• Additionally, the msDS-GroupMSAMembership attribute on the dMSA stores the list of security principals (machine accounts) authorized to retrieve the dMSA’s credentials, i.e., the allowed host list. This attribute is analogous to how gMSA stores its authorized hosts, and in PowerShell, it’s managed via the PrincipalsAllowedToRetrieveManagedPassword property.

ADDS temporarily grants the original service account the right to write to the dMSA’s msDS-GroupMSAMembership attribute during migration. When the migration is in the Start phase, as the legacy service account continues to log on, it automatically adds those machine accounts to the dMSA’s allowed list.

In other words, ADDS lets the old account invite the machines it’s running on into the new account’s host set. This automation migration involves discovering where the service is used.

The environment should be left in this state through at least a few Kerberos ticket lifetimes (several days) to catch all machines, especially in large or distributed environments. When Complete-ADServiceAccountMigration is run, AD finalizes the cut-over.

Then, remove those special permissions, flips msDS-DelegatedMSAState to 2 (Completed), copies any remaining SPNs or delegation settings to the dMSA, and disables the old account.

---

dMSA Functionality and Creations

To set a dMSA, you’ll use PowerShell and then manually configure the key attributes that distinguish it from a normal gMSA:

• msDS-ManagedAccountPrecededByLink

• msDS-DelegatedMSAState

There is no direct PowerShell cmdlet for dMSAs yet as of Windows Server 2025 preview, so you’ll need to do a mix of standard gMSA creation and attribute modification via ADSI or Set-ADObject.

Note: As of Windows Server 2025, the Active Directory Users and Computers (ADUC) console does not yet have a native GUI path for creating a dMSA directly.

A general Action in dMSA

In a short demo we transitioning a legacy user based service account (pLABService) to a password managed, minimal permissions dMSA (dMSA-xLAB).

Creates the dMSA identity

The command: “New-ADServiceAccount -CreateDelegatedServiceAccount -KerberosEncryptionType AES256 -Name dMSA-xLAB -DNSHostName dMSA-xLAB.contoso.com”

• -KerberosEncryptionType AES256: Enables strong encryption, mitigating downgrade attacks.
• -DNSHostName: This acts as a pseudo SPN identity for Kerberos tickets, which is used in TGS requests.

Security impact

• You eliminate password-based credentials.
• You isolate the service identity from both users and machines.

Links the dMSA with an existing legacy account

Start-ADServiceAccountMigration -Identity dMSA-xLAB -SupersededAccount “CN=pLABService,OU=ServiceAccounts,DC=purplex,DC=lab”

What it does:

• ADDS starts issuing tickets referencing the new dMSA without breaking old trust paths.
• The dMSA becomes the Kerberos target while preserving any SPNs, ACLs, or service dependencies attached to the old account
• The dMSA has taken over Kerberos ticket resolution
• The legacy account (pLABService) is now shadowed and can be phased out
• Migration in progress, the dMSA is active and in a linked state
• Superseded legacy account successfully attached
• Strong Kerberos ticket encryption is enforced

Security implications:

• Maintains backward compatibility during migration
• Ensures that ticket requests now resolve to the more secure dMSA
• Prevents attackers from exploiting legacy accounts with static passwords during migration
• Supports phased rollouts where you can test without downtime

The original account is still:

• Enabled
• With the same password
• Potentially still being used by older services

Risk:

• Attackers with access to credentials object (pLABService) can continue to authenticate unless you explicitly disable the account or strip it down
• It creates an identity overlap where two accounts can serve the same SPN/role.

Mitigation:

• Immediately disable pLABService or set a strong random password and remove Logon as a service right.
• Monitor authentication logs for continued usage of the old account.

Views that computers are allowed to request the dMSA’s password from AD

This is critical because only these computers can install the account via: Install-ADServiceAccount -Identity dMSA-xLAB

Security perspective:

• This is your “trusted hosts” list
• If a rogue or compromised host is added here, it could extract the dMSA’s password material (like any gMSA)
• You must audit and restrict this list tightly

A Potential dMSA Misconfig

PrincipalsAllowedToRetrieveManagedPassword Misconfig

If you allow dMSA-xLAB to be retrieved by overly permissive entities (“Domain Computers”, a wildcard group, or too many servers): Get-ADServiceAccount -Identity dMSA-xLAB -Properties PrincipalsAllowedToRetrieveManagedPassword

Risk:

• Any machine in the domain can pull the password hash using Install-ADServiceAccount, potentially allowing offline cracking
• Attackers with local admin rights on one compromised host can extract the dMSA key and pivot into services

Mitigation:

• Always use tight scoping (specific hostnames or security groups).
• Audit this list regularly: Get-ADServiceAccount -Identity dMSA-xLAB -Properties PrincipalsAllowedToRetrieveManagedPassword

DNSHostName spoofing / SPN confusion

If DNSHostName doesn’t match the real DNS/SPN structure of your services: New-ADServiceAccount -DNSHostName dMSA-xLAB.contoso.com

Risk:

• Kerberos authentication might fail silently, causing fallback to NTLM, opening the door to NTLM relay or downgrade attacks.
• A misaligned SPN can allow an attacker to register the same SPN elsewhere if not protected, enabling Kerberoasting.

Mitigation:

• Ensure DNSHostName matches a real SPN registered to a trusted host.
• Use setspn.exe -L dMSA-xLAB to validate.

Lack of monitoring during the transition phase

While Start-ADServiceAccountMigration If your services are active, they might run inconsistently with the old credentials or the new dMSA identity.

Risk:

• Hard to detect whether the services switched properly
• If log sources are outdated, SIEMs may not clearly show which identity is currently in use

Mitigation:

• Monitor Kerberos TGS requests with Event ID 4769 and look for dMSA-xLAB$ vs pLABService
• Build correlation logic in your SIEM to trace the transition

dMSA creation via full script – optional

# Parameters
$AccountName = "dMSA-Service1"
$DnsHostName = "$AccountName.purplex.lab"
$OuPath = "OU=ServiceAccounts,DC=purplex,DC=lab"
$ComputerName = "DC1"

# Load AD module
if (-not (Get-Module -ListAvailable -Name ActiveDirectory)) {
Write-Error "Active Directory module not found. Install RSAT: Active Directory."
return
}
Import-Module ActiveDirectory

# Step 1: Validate computer exists
try {
$Computer = Get-ADComputer -Identity $ComputerName -ErrorAction Stop
Write-Host "Computer object '$ComputerName' found."
}
catch {
Write-Error "Computer $ComputerName not found in AD."
return
}

# Step 2: Validate OU exists
try {
$null = Get-ADOrganizationalUnit -Identity $OuPath -ErrorAction Stop
Write-Host "OU path '$OuPath' found."
}
catch {
Write-Error "OU path '$OuPath' does not exist. Create it or update the script."
return
}

# Step 3: Ensure KDS Root Key exists
if (-not (Get-KdsRootKey)) {
Write-Warning "KDS Root Key not found. Creating one for immediate use..."
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10)) | Out-Null
Start-Sleep -Seconds 10
Write-Host "KDS Root Key created."
} else {
Write-Host "KDS Root Key already exists."
}

# Step 4: Create dMSA
try {
New-ADServiceAccount -Name $AccountName `
-DNSHostName $DnsHostName `
-KerberosEncryptionType AES256 `
-Path $OuPath `
-PrincipalsAllowedToRetrieveManagedPassword $Computer
Write-Host "dMSA '$AccountName' created successfully."
}
catch {
Write-Error "Failed to create dMSA: $_"
return
}

# Step 5: Confirm object type is dMSA (not gMSA)
$objectClass = (Get-ADServiceAccount -Identity $AccountName).ObjectClass
if ($objectClass -ne "msDS-ManagedServiceAccount") {
Write-Warning "Warning: '$AccountName' is not a delegated MSA. Detected type: $objectClass"
} else {
Write-Host "dMSA '$AccountName' is confirmed as msDS-ManagedServiceAccount"
}

# Step 6: Check who can retrieve the password
$retrievers = (Get-ADServiceAccount -Identity $AccountName -Properties PrincipalsAllowedToRetrieveManagedPassword).PrincipalsAllowedToRetrieveManagedPassword
if ($retrievers) {
Write-Host "Password retrievers:"
$retrievers | Select-Object Name
} else {
Write-Warning "No computer is currently authorized to retrieve this dMSA's password."
}

# Optional Step: Output install/test command for client machine
Write-Host "`nOn the '$ComputerName' machine, run the following:"
Write-Host "Install-ADServiceAccount -Identity '$AccountName'"
Write-Host "Test-ADServiceAccount -Identity '$AccountName'"

Once the dMSA is created, you should run validations to ensure it is configured correctly.

# Parameters
$AccountName = "dMSA-Service1"
$ComputerName = "DC1"
$OuPath = "OU=ServiceAccounts,DC=purplex,DC=lab"

# Load AD module
Import-Module ActiveDirectory

# 1. Validate dMSA exists and is the correct object class
$dmsa = Get-ADServiceAccount -Identity $AccountName -Properties *
if ($dmsa) {
Write-Host "`n[+] dMSA '$AccountName' exists in AD."
if ($dmsa.ObjectClass -eq "msDS-ManagedServiceAccount") {
Write-Host "[+] ObjectClass is correct: msDS-ManagedServiceAccount"
} else {
Write-Warning "[-] '$AccountName' is not a dMSA. It is a $($dmsa.ObjectClass)"
}
} else {
Write-Error "[-] dMSA '$AccountName' not found in Active Directory."
return
}

# 2. Validate OU exists
try {
$null = Get-ADOrganizationalUnit -Identity $OuPath -ErrorAction Stop
Write-Host "[+] OU path '$OuPath' exists."
}
catch {
Write-Error "[-] OU path '$OuPath' not found."
}

# 3. Validate PrincipalsAllowedToRetrieveManagedPassword
$retrievers = $dmsa.PrincipalsAllowedToRetrieveManagedPassword
if ($retrievers -and $retrievers.Count -gt 0) {
Write-Host "[+] Computers allowed to retrieve dMSA password:"
$retrievers | Select-Object Name
} else {
Write-Warning "[-] No computer is authorized to retrieve this dMSA password."
}

# 4. Check KDS Root Key
if (Get-KdsRootKey) {
Write-Host "[+] KDS Root Key exists."
} else {
Write-Warning "[-] No KDS Root Key found. Password rollout may fail."
}

# 5. Check if dMSA is installed and testable locally (only run if this is the target machine)
try {
if (Test-ADServiceAccount -Identity $AccountName) {
Write-Host "[+] dMSA is installed and working on this machine."
} else {
Write-Warning "[-] dMSA is not testable on this machine. Run Install-ADServiceAccount first."
}
}
catch {
Write-Warning "[-] Unable to validate dMSA on this machine: $_"
}

# 6. Check if dMSA has SPNs (for Kerberos services)
if ($dmsa.ServicePrincipalName -and $dmsa.ServicePrincipalName.Count -gt 0) {
Write-Host "[+] dMSA has SPNs configured:"
$dmsa.ServicePrincipalName
} else {
Write-Host "[*] dMSA has no SPNs configured. This is fine unless it's used for a Kerberos service."
}

dMSAs Behind the Scenes

Account Creation

• A dMSA is created as an msDS-GroupManagedServiceAccount object in AD.
• It has a userAccountControl flag set for service usage (UF_MNS_LOGON_ACCOUNT).

Attribute Configuration

Key attributes:

• msDS-ManagedAccountPrecededByLink pointing to a legacy or privileged account
• msDS-DelegatedMSAState tells DCs the migration state
• servicePrincipalName optional, enables service binding

Authentication Behavior

When a service authenticates with a dMSA:

• If migration is complete, KDC builds the PAC based on the predecessor account.
• The Kerberos ticket includes SIDs and group memberships from the linked identity, not just the dMSA’s own

Note: This is key to migration and the root of the BadSuccessor attack.

---

Security Gaps and Potential Abuse

Like any technical feature, dMSA comes with potential risks if not controlled. In fact, a critical vulnerability was discovered in this new feature that can be exploited to completely compromise Active Directory under certain conditions. Understanding this and other abuse scenarios is essential to securing your environment.

The “BadSuccessor” Vulnerability

Shortly after dMSA was introduced, security researchers uncovered a design flaw in the default configuration that could enable a devastating privilege escalation. Dubbed “BadSuccessor,” this attack shows how an attacker with limited permissions can leverage dMSAs to gain full domain privileges.

If an attacker can set the msDS-ManagedAccountPrecededByLink on a dMSA to point to ‘CN=Administrator,CN=Users,domain, and set msDS-DelegatedMSAState’ to 2 (the completed state), the KDC will assume a legitimate migration happened.

The next time the attacker requests a TGT for their dMSA, the KDC will issue a ticket that says, This account (dMSA) is effectively Administrator, including membership in Domain Admins and every other group the Administrator had

The attacker controlling dMSA now has the privileges of the superseded account without ever needing to know its password or directly modify that account. This is a stunning escalation: from the perspective of other services and DCs, dMSA is now a domain admin because the Kerberos PAC says so.

Abuse of Allowed Principles

If an attacker already has a local admin on a server authorized for some dMSA, they could impersonate that dMSA account on that machine, for example, by extracting a token or forging a service ticket to access resources that dMSA has access to.

This is similar to how compromising a host using a gMSA can lead to lateral movement, the difference being that dMSA tickets won’t work on other machines. However, the attacker could use the compromised host to act as the service and possibly access whatever that service account could. Thus, standard protections still apply.

Weak Delegation Configurations

If an organization attempted to delegate the ability to create a dMSAs to a lower tier without fully understanding the implications, it might inadvertently give too much power.

For example, if a security group has write access to the msDS-GroupMSAMembership attribute on all gMSA/dMSA objects, which could be leveraged to add unauthorized hosts. However, since dMSA secrets aren’t retrievable like gMSA passwords, adding a host might not immediately leak a credential, and it would allow that host to obtain Kerberos tickets as the dMSA, though.

Persistence via dMSA

A sophisticated attacker who has already obtained Domain Admin might create a dMSA and intentionally link it to a high-priv account as a backdoor, then remove their other traces.

If admins are not watching (monitoring/auditing) a dMSA, the attacker can use that dMSA to regain privileges even after their original domain admin access is revoked.

Auditing for unexpected dMSAs and linkages is vital for initial compromise and persistence mechanisms.

During dMSA Migration

During the dMSA migration phase, after executing Start-ADServiceAccountMigration but before Complete-ADServiceAccountMigration, both the legacy service account and the new dMSA remain valid for Kerberos authentication.

This introduces a temporary state in which:

• Kerberos TGS tickets can still be requested for the old account’s SPNs.
• The legacy account retains its SID, access tokens, group memberships, and delegation settings even though it is intended to be retired.
• The dMSA is gradually enrolled on target machines via msDS-GroupMSAMembership and begins to function in parallel without invalidating the old account.

Why This Is a Risk? If the legacy account’s NTLM hash or Kerberos TGT was compromised before migration, an attacker can continue authenticating using Pass the Hash or Overpass the Hash techniques. Since the account is still active and trusted by services, the attacker’s access is not invalidated until the final Complete-ADServiceAccountMigration step. Also, the organization might falsely assume improved security, while in reality, both accounts are usable, and one may be fully compromised.

---

Post validation

Object Type Validation: Ensure it was created as an msDS-ManagedServiceAccount, not a gMSA:

Get-ADServiceAccount -Identity "dMSA-Service1" | Select-Object Name,ObjectClass

Validate the OU existence

Get-ADOrganizationalUnit -Identity "OU=ServiceAccounts,DC=purplex,DC=lab"

Check which computers are allowed to retrieve the dMSA password

(Get-ADServiceAccount -Identity "dMSA-Service1" -Properties PrincipalsAllowedToRetrieveManagedPassword).PrincipalsAllowedToRetrieveManagedPassword

Test dMSA on the bound computer

Test-ADServiceAccount -Identity "dMSA-Service1"

Check if dMSA-Service1 has any SPNs (for Kerberos use)

(Get-ADServiceAccount -Identity "dMSA-Service1" -Properties ServicePrincipalName).ServicePrincipalName

Note: While the SPNs check was run, there was no result. Why is that? That’s normal unless the dMSA is used for Kerberos based services like IIS / SQL. If it’s just for scheduled tasks or local services, SPNs aren’t needed. Still, dMSA is exploitable even if no SPN is configured, because SPNs are required for Kerberos service ticket requests 

Once a dMSA is created, installed, and validated, you should move from setup to hardening, operational readiness, and monitoring. Here are a few commands that you can start with

Restrict dMSA Permissions

• Avoid granting unnecessary group memberships
• Don’t give Domain Admin, Local Admin, or Logon rights unless required
  • Review permissions with:
    Get-ADServiceAccount -Identity dMSA-Service1 -Properties MemberOf

Audit and Monitor Usage

The very first step of monitoring dMSA

• Event ID 4769: Kerberos TGS request
• Event ID 4624: Logon events (Type 5/6 for service logon)

Review ACLs on the dMSA Object

Ensure no unauthorized users or systems have GenericWrite, WriteDACL, or WriteProperty permissions:

Get-Acl "AD:\CN=dMSA-Service1,OU=ServiceAccounts,DC=purplex,DC=lab" | Format-List

Prevent Interactive Logon

By default, dMSAs can’t log on interactively, and you should confirm with the command:

(Get-ADServiceAccount -Identity dMSA-Service1 -Properties userAccountControl).userAccountControl

Note: userAccountControl = 4096 maps to 0x1000 = ADS_UF_WORKSTATION_TRUST_ACCOUNT

Now that dMSA is installed, validated, and checked from general security commands, it is time to check how it can be exploited via pure PowerShell and other tools.

Monitoring and MDI

Service Creation Detection on DCs with Parsed Metadata

Creation & Configuration of the dMSA

What to look for:

• Attribute changes on CN=dMSA-xLAB
• Addition of msDS-ManagedAccountPrecedent
• Changes to PrincipalsAllowedToRetrieveManagedPassword

Refernces

Attacking Group Managed Service Accounts (gMSA)

BadSuccessor: Abusing dMSA to Escalate Privileges in Active Directory