Delegated managed service accounts
Microsoft's edit ·
Microsoft's commit message in MicrosoftDocs/windowsserverdocs · commit bc5b3e3 · +9 −8 lines · also on GitHub
⋯ 2 unchanged lines
33
description: Learn about delegated Managed Service Accounts (DMSA) that authenticate specific machine identities mapped in Active Directory along with Credential Guard to ensure device credentials isolation in Windows Server 2025.
44
ms.topic: concept-article
55
ms.author: alalve
6
−author: mariamgewida
7
−ms.date: 10/25/2024
6
+author: xelu86
7
+ms.contributor: mariamgewida
8
+ms.date: 05/30/2025
89
---
910
1011
# Delegated Managed Service Accounts overview
⋯ 4 unchanged lines
1516
1617
dMSAs and gMSAs are two types of managed service accounts that are used to run services and applications in Windows Server. A dMSA is managed by an administrator and is used to run a service or application on a specific server. A gMSA is managed by AD and is used to run a service or application on multiple servers. Both offer improved security and simplified password management. dMSA differs by:
1718
18
−- Utilizing gMSA concepts to limit scope of usage using [Credential Guard](/windows/security/identity-protection/credential-guard) to bind machine authentication.
19
+- Utilizing gMSA concepts to limit scope of usage using [Credential Guard](/windows/security/identity-protection/credential-guard) (CG) to bind machine authentication.
1920
- CG can be used to enhance security in dMSA by automatically rotating passwords and binding all service account tickets. Legacy accounts are then disabled to further improve security.
20
−- Although gMSAs are secured with machine generate and autorotated passwords, the passwords are still not machine bound and can be stolen.
21
+- Although gMSAs are secured with machine generated and autorotated passwords, the passwords are still not machine bound and can be stolen.
2122
2223
## Functionality of dMSA
2324
⋯ 17 unchanged lines
4142
4243
- You can't migrate from a managed service account or a gMSA to a dMSA.
4344
- Wait at least two ticket lifetimes (equivalent to 14 days) after modifying the Security Descriptor (SD) before completing the dMSA migration. Keeping a service in the **start** state for four ticket lifetimes (28 days) is recommended. Delay the migration if your DCs are partitioned or replication is broken during onboarding.
44
−- Pay attention to sites where replication delays are longer than the default ticket renewal time of **10 hours**. The **groupMSAMembership** attribute is checked and updated at every ticket renewal, and every time the original service account logs on during the “start migration” state, which adds the machine account to the **groupMSAMembership** of the dMSA.
45
+- Pay attention to sites where replication delays are longer than the default ticket renewal time of **10 hours**. The **groupMSAMembership** attribute is checked and updated at every ticket renewal, and every time the original service account logs on during the "start migration" state, which adds the machine account to the **groupMSAMembership** of the dMSA.
4546
- Example, two sites utilize the same service account and each replication cycle takes more than 10 hours per ticket lifetime. In this scenario, a group membership is lost during the initial replication cycles.
4647
- Migration requires access to a Read-Write Domain Controller (RWDC) to query and modify the SD.
4748
- Unconstrained delegation stops working once the migration is complete if the old service account was using it. If you're using a dMSA protected by CG, unconstrained delegation stops working. To learn more, see [Considerations and known issues when using Credential Guard](/windows/security/identity-protection/credential-guard/considerations-known-issues).
4849
4950
> [!WARNING]
50
−> If you're going to migrate to a dMSA, all machines using the service account need to be updated to support dMSA. If this is not true, machines that don't support dMSA will fail authentication with the existing service account once the account becomes disabled during migration.
51
+> If you're going to migrate to a dMSA, all machines using the service account need to be updated to support dMSA. If this isn't true, machines that don't support dMSA fails authentication with the existing service account once the account becomes disabled during migration.
5152
5253
## Account attributes for dMSA
5354
5455
This section describes how the attributes for dMSA changes in the AD schema. These attributes can be viewed using the **Active Directory Users and Computers** snap-in or running **ADSI Edit** on the DC.
5556
5657
> [!NOTE]
57
−> The numerical attributes set for the account indicates that:
58
+> The numerical attributes set for the account indicate:
5859
>
5960
> - **1** - Account migration has begun.
6061
> - **2** - Account migration has completed.
⋯ 26 unchanged lines
8788
8889
Realms serve as logical groupings that define authentication boundaries, commonly used when integrating different versions of AD across domains or forests. They're especially important in mixed domain environments where some domains may not fully support all features of dMSA. By specifying realms, dMSA can ensure proper communication and authentication flow between domains.
8990
90
−Administrators can use realms to specify which domains or directory components can authenticate and access the dMSA account. This ensures that even older child domains, which may not natively support dMSA features, can interact with the accounts while maintaining security boundaries. By enabling a smoother transition and coexistence of features across mixed environments, realms help ensure compatibility without compromising security.
91
+Administrators can use realms to specify which domains or directory components can authenticate and access the dMSA account. This ensures that even older child domains, which may not natively support dMSA features, can interact with the accounts while maintaining security boundaries. Realms facilitate seamless transitions and feature coexistence in mixed environments, ensuring compatibility between domains while maintaining strong security when enabled.
9192
9293
For example, if you have a primary domain called `corp.contoso.com` running on Windows Server 2025 and an older child domain called `legacy.corp.contoso.com` running Windows Server 2022, you can specify the realm as `legacy.corp.contoso.com`.
9394
⋯ 9 unchanged lines
Microsoft's Markdown source from MicrosoftDocs/windowsserverdocs, © Microsoft Corporation, under CC BY 4.0. Changed lines with up to 3 unchanged lines around each; ChangeIntel kept this copy 10 Oct 08:22 UTC. The commit date is when the source changed, which can be hours or days before Learn published it.