Delegated managed service accounts
Microsoft's edit ·
Microsoft's commit message in MicrosoftDocs/windowsserverdocs · commit b5de0ac · +91 −0 lines · also on GitHub
The file is new at this commit, or was moved here from another path: every line shows as added.
1
+---
2
+title: Delegated Managed Service Accounts overview in Windows Server Insider Preview
3
+description: Learn about delegated Managed Service Accounts (DMSA) that authenticate specific machine identities mapped in Active Directory (AD) along with Credential Guard (CG) to ensure device credentials isolation in Windows Server Insiders Preview.
4
+ms.topic: conceptual
5
+ms.author: alalve
6
+author: mariamgewida
7
+ms.date: 02/14/2024
8
+---
9
+
10
+# Delegated Managed Service Accounts overview
11
+
12
+> [!IMPORTANT]
13
+> Windows Server Insider builds are in PREVIEW. This information relates to a prerelease product that may be substantially modified before it's released. Microsoft makes no warranties, expressed or implied, with respect to the information provided here.
14
+
15
+A new account type known as delegated Managed Service Account (dMSA) is introduced in Windows Server Insiders Preview that allows migration from a traditional service account to a machine account with managed and fully randomized keys, while disabling original service account passwords. Authentication for dMSA is linked to the device identity, which means that only specified machine identities mapped in AD can access the account. Using dMSA helps to prevent harvesting credentials using a compromised account (kerberoasting), which is a common issue with traditional service accounts.
16
+
17
+## dMSA and gMSA comparison
18
+
19
+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:
20
+
21
+- Utilizing gMSA concepts to limit scope of usage using [Credential Guard](/windows/security/identity-protection/credential-guard) (CG) to bind machine authentication.
22
+- 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.
23
+- Although gMSAs are secured with machine generate and autorotated passwords, the passwords are still not machine bound and can be stolen.
24
+
25
+## Functionality of dMSA
26
+
27
+dMSA allows users to create them as a standalone account, or to replace an existing standard service account. When a dMSA supersedes an existing account, authentication to that existing account using its password will be blocked. The request is redirected to the [Local Security Authority](/windows/win32/secauthn/lsa-authentication) (LSA) to authenticate using dMSA, which has access to everything the previous account could access in AD.
28
+
29
+During migration, dMSA automatically learns the devices on which the service account to be used which is then used to move from all existing service accounts.
30
+
31
+dMSA uses a randomized secret (derived from the machine account credential) that is held by the Domain Controller (DC) to encrypt tickets. The secret can be further protected by enabling CG. While the secrets used by dMSA are updated periodically on an epoch like a gMSA, the key difference is that dMSA's secret can't be retrieved or found anywhere other than on the DC.
32
+
33
+## Migration flow for dMSA
34
+
35
+A quick concept of the migration flow process for a dMSA involves the following steps:
36
+
37
+1. The CG policy can be configured to protect the machines identity.
38
+1. An administrator starts and completes migration of the service account.
39
+1. The service account refreshes the Ticket Granting Server (TGT).
40
+1. The service account adds the machine identity to allow principles.
41
+1. The original service account becomes disabled.
42
+
43
+Take note of the following when migrating dMSAs:
44
+
45
+- You can't migrate from a managed service account or a gMSA to a dMSA.
46
+- 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.
47
+- 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.
48
+ - 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.
49
+- Migration requires access to a Read-Write Domain Controller (RWDC) to query and modify the SD.
50
+- 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).
51
+
52
+> [!WARNING]
53
+> 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.
54
+
55
+## Account attributes for dMSA
56
+
57
+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.
58
+
59
+> [!NOTE]
60
+> The numerical attributes set for the account indicates that:
61
+>
62
+> - **1** - Account migration has begun.
63
+> - **2** - Account migration has completed.
64
+
65
+Running `Start-ADServiceAccountMigration` performs the following changes:
66
+
67
+- The service account is granted _Generic Read_ to all properties on the dMSA
68
+- The service account is granted _Write_ property to **msDS-groupMSAMembership**
69
+- **msDS-DelegatedMSAState** is changed to 1
70
+- **msDS-ManagedAccountPrecededByLink** is set to the service account
71
+- **msDS-SupersededAccountState** is changed to 1
72
+- **msDS-SupersededManagedServiceAccountLink** is set to the dMSA
73
+
74
+Running `Complete-ADServiceAccountMigration` performs the following changes:
75
+
76
+- The service account is removed from _Generic Read_ to all properties on the dMSA
77
+- The service account is removed from _Write_ property on the **msDS-GroupMSAMembership** attribute
78
+- **msDS-DelegatedMSAState** is set to 2
79
+- The Service Principal Names (SPN) are copied over from the service account to the dMSA account
80
+- **msDS-AllowedToDelegateTo** is copied over if applicable
81
+- **msDS-AllowedToActOnBehalfOfOtherIdentity** the security descriptor is copied over if applicable
82
+- The assigned AuthN policy, **msDS-AssignedAuthnPolicy**, of the service account are copied over
83
+- dMSA is added to any AuthN policy silos that the service account was a member of
84
+- The trusted "Auth for Delegation" User Account Control (UAC) bit is copied over if it was set on the service account
85
+- **msDS-SupersededServiceAccountState** is set to 2
86
+- The service account is disabled via the UAC disable bit
87
+- The SPN are removed from the account
88
+
89
+## See also
90
+
91
+[Setting up Delegated Managed Service Accounts](delegated-managed-service-accounts-set-up-dmsa.md)
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.