Introduction

In the first two parts of this series, we explored the why and how of using Group Managed Service Accounts (gMSAs) with Veeam Backup & Replication (VBR). If you missed them, check out:

• Part 1 – Why Use gMSAs with VBR
• Part 2 – How to Configure gMSAs with VBR

This third and final installment dives into security implications, introduces Dedicated Managed Service Accounts (dMSAs), explains the threat of Kerberoasting, and previews what's new with gMSA in Windows Server 2025.

1. Security Considerations: gMSAs in the Real World

a) Overprivileged Accounts

Avoid assigning excessive permissions like Domain Admin to gMSAs.

Best Practices:

• Apply least privilege
• Use role-specific gMSAs (e.g. Exchange, SQL, File-Servers, but NOT DCs! - see below)
• Audit regularly

b) Password Retrieval Abuse

Only authorized systems can retrieve gMSA passwords. Compromised systems pose a risk.

Mitigation:

• Harden GIP and other retrieval systems
  • no other services on the GIP
  • restrict network access (e.g. switch-ACLs in segmented networks or Windows firewall)
  • don’t use domain admins here
  • patch GIP regularly (or even better: automatically)
• Monitor retrieval events
  • enable event logging for security events
  • use SIEM if available
• Isolate and protect endpoints

c) Kerberoasting Risk

Kerberoasting is a technique where attackers request service tickets for accounts with SPNs and crack them offline.

Why It Matters:

• gMSAs/dMSAs with SPNs are targets.
• Common in SQL/IIS setups.

Mitigation:

• Avoid unnecessary SPNs.
• Use strong passwords (gMSAs do this automatically).
• Monitor Kerberos activity.

Creating gMSA without an SPN:

When you create a gMSA using PowerShell, you do not need to specify an SPN unless the account is going to be used for a service that requires Kerberos authentication (e.g., IIS, SQL Server, etc.).
Example: Creating a gMSA without an SPN

New-ADServiceAccount -Name VBRgMSA -DNSHostName vbr.domain.local -PrincipalsAllowedToRetrieveManagedPassword "VBRServer$"

This command:

• Creates a gMSA named VBRgMSA
• Assigns it to the computer VBRServer
• Does not register an SPN, which means it’s not exposed to Kerberoasting attacks via service tickets

Learn more about Kerberoasting: In-depth analysis by Sean Metcalf

d) Recovery Limitations

Veeam Explorers don’t support gMSAs for recovery tasks.

Workaround:

• Use a separate recovery account with limited permissions just for your restore operations
• Run Veeam Explorers on dedicated workstations or jump hosts to isolate their operation
• Document fallback procedures
   

2. What About dMSAs?

Windows Server 2025 introduces a new type of managed service account called the Delegated Managed Service Account (dMSA), which builds on the concepts of gMSAs but adds tighter control and machine-bound authentication. These are currently not supported by Veeam, so this is just meant as an addendum to the gMSA store.

Key Features

• Machine-Bound Authentication - dMSAs are tied to specific machine identities in Active Directory. Only authorized computers can use the account, reducing the risk of credential theft.
• Credential Guard Integration - dMSAs can leverage Credential Guard (CG) to bind authentication to the device and protect secrets in memory
• Passwordless Migration - When migrating from a legacy service account to a dMSA, the original password is disabled. Authentication is redirected to the Local Security Authority (LSA), which uses the dMSA's randomized secret stored on the Domain Controller
• Randomized Secrets - dMSAs use a cryptographic secret derived from the machine account credential. This secret is periodically rotated and cannot be retrieved from the machine — only the Domain Controller holds it
• Delegated Management - Admins can delegate dMSA creation and management to specific Organizational Units (OUs), enabling least privilege and decentralization of service account control

https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/delegated-managed-service-accounts/delegated-managed-service-accounts-overview

⚠️ Security Concerns

Despite its promise, dMSA in Windows Server 2025 has been impacted by critical vulnerabilities:

Golden dMSA Attack

• Exploits flaws in the ManagedPasswordId structure, which has only 1,024 predictable combinations.
• Allows attackers with elevated privileges to brute-force dMSA passwords and gain persistent access across the AD forest. 
• Bypasses protections like Credential Guard and creates a long-term backdoor.

https://www.semperis.com/press-release/research-uncovers-critical-flaw-windows-server-2025-exposing-managed-service-accounts-golden-dmsa-attack/
https://threatlabsnews.xcitium.com/blog/golden-dmsa-attack-one-flaw-in-windows-server-2025-threatens-entire-active-directory-forests/

BadSuccessor Vulnerability

• Allows attackers to manipulate dMSA attributes (msDS-DelegatedMSAState, msDS-ManagedAccountPrecededByLink) to inherit privileges from high-value accounts.
• Can be executed by users with CreateChild or WriteDACL permissions on an OU.

https://www.covertswarm.com/post/bad-successor-technical-deep-dive

3. What else is new in Windows Server 2025?

a) Improved gMSA Management

• GUI lifecycle tools
• Password retrieval visibility
• Azure AD integration

b) Cross-Domain gMSA Support

Simplifies service account management across domains.

4. Final Thoughts

gMSAs offer strong security and automation, but understanding their limitations is key to building a resilient Veeam environment.

Kerberoasting is a real threat. Whether using gMSAs or dMSAs, proper configuration and monitoring are essential.