Aperçu des comptes de service administrés délégués

Un nouveau type de compte, connu sous le nom de compte de service géré délégué (dMSA), est introduit dans Windows Server 2025 et permet la migration d’un compte de service traditionnel vers un compte machine avec des clés gérées et entièrement randomisées, tout en désactivant les mots de passe des comptes de service d’origine. L’authentification pour dMSA est liée à l’identité de l’appareil, ce qui signifie que seules les identités de machine spécifiées mappées dans Active Directory (AD) peuvent accéder au compte. L’utilisation de dMSA contribue également à empêcher la collecte d’informations d’identification à l’aide d’un compte compromis (kerberoasting), ce qui est un problème courant avec les comptes de service traditionnels.

Comparaison entre dMSA et gMSA

dMSA et gMSA sont deux types de comptes de service gérés utilisés pour exécuter des services et des applications dans Windows Server. Un dMSA est géré par un administrateur et est utilisé pour exécuter un service ou une application sur un serveur spécifique. Un gMSA est géré par AD et est utilisé pour exécuter un service ou une application sur plusieurs serveurs. Les deux offrent une sécurité améliorée et une gestion simplifiée des mots de passe. Les dMSA diffèrent par :

• Utilizing gMSA concepts to limit scope of usage using Credential Guard (CG) to bind machine authentication.
• CG peut être utilisé pour améliorer la sécurité dans dMSA en renouvelant les mots de passe de manière automatique et en liant tous les tickets de compte de service. Les comptes hérités sont ensuite désactivés pour améliorer davantage la sécurité.
• Bien que les gMSA soient sécurisés avec des mots de passe générés et autorotés, les mots de passe ne sont toujours pas liés à l’ordinateur et peuvent être volés.

Fonctionnalité des dMSA

Les dMSA permettent aux utilisateurs de les créer en tant que compte autonome, ou de remplacer un compte de service standard existant. Lorsqu’un dMSA remplace un compte existant, l’authentification à ce compte existant à l’aide du mot de passe correspondant est bloquée. La demande est redirigée vers l’Autorité de sécurité locale (LSA) pour une authentification en utilisant un dMSA, qui a accès à tout ce que le compte précédent pouvait accéder dans AD.

Pendant la migration, le dMSA apprend automatiquement les appareils sur lesquels le compte de service doit être utilisé, puis est utilisé pour passer de tous les comptes de service existants.

Le dMSA utilise un secret aléatoire (dérivé de l’identifiant de compte de machine) qui est détenu par le contrôleur de domaine (DC) pour crypter les tickets. Le secret peut être en outre protégé en activant CG. Bien que les secrets utilisés par dMSA soient mis à jour périodiquement sur un modèle d’époque comme un gMSA, la principale différence est que le secret de dMSA ne peut pas être récupéré ou trouvé ailleurs que sur le DC.

Flux de migration pour les dMSA

Un bref concept du processus de flux de migration pour un dMSA implique les étapes suivantes :

1. La politique CG peut être configurée pour protéger l’identité des machines.
2. Un administrateur commence et termine la migration du compte de service.
3. Le compte de service actualise le serveur de distribution de tickets (TGT).
4. Le compte de service ajoute l’identité de la machine pour permettre les principes.
5. Le compte de service original est alors désactivé.

Remarquez les points suivants lors de la migration d’un dMSA :

• Vous ne pouvez pas migrer d’un compte de service géré ou d’un gMSA vers un dMSA.
• Attendez au moins deux durées de vie des tickets (équivalent à 14 jours) après avoir modifié le descripteur de sécurité (SD) avant de terminer la migration d’un dMSA. Keeping a service in the start state for four ticket lifetimes (28 days) is recommended. Retardez la migration si vos DC sont partitionnés ou si la réplication est interrompue lors de l’intégration.
• 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.
  • Par exemple, deux sites utilisent le même compte de service et chaque cycle de réplication prend plus de 10 heures par durée de vie de ticket. Dans ce scénario, une appartenance au groupe est perdue pendant les cycles de réplication initiaux.
• La migration nécessite un accès à un Contrôleur de Domaine en Lecture-Écriture (RWDC) pour interroger et modifier le SD.
• La délégation non contrainte cesse de fonctionner une fois la migration terminée si l’ancien compte de service l’utilisait. Si vous utilisez un dMSA protégé par CG, la délégation non contrainte cesse de fonctionner. Pour en savoir plus, veuillez consulter Considérations et problèmes connus lors de l’utilisation de Credential Guard.

Warning

Si vous migrez vers un dMSA, toutes les machines utilisant le compte de service doivent être mises à jour pour supporter les dMSA. Si ce n’est pas vrai, les machines qui ne prennent pas en charge l’authentification dMSA échouent avec le compte de service existant une fois le compte désactivé lors de la migration.

Attributs de compte pour les dMSA

Cette section décrit comment les attributs pour les dMSA changent dans le schéma AD. Ces attributs peuvent être consultés en utilisant le snap-in Utilisateurs et ordinateurs Active Directory ou en exécutant ADSI Edit sur le DC.

Note

Les attributs numériques définis pour le compte indiquent :

• 1 - Account migration has begun.
• 2 - Account migration has completed.

Exécuter Start-ADServiceAccountMigration applique les changements suivants :

• The service account is granted Generic Read to all properties on the dMSA
• The service account is granted Write property to msDS-groupMSAMembership
• msDS-DelegatedMSAState is changed to 1
• msDS-ManagedAccountPrecededByLink is set to the service account
• msDS-SupersededAccountState is changed to 1
• msDS-SupersededManagedServiceAccountLink is set to the dMSA

Exécuter Complete-ADServiceAccountMigration applique les changements suivants :

• The service account is removed from Generic Read to all properties on the dMSA
• The service account is removed from Write property on the msDS-GroupMSAMembership attribute
• msDS-DelegatedMSAState is set to 2
• Les Noms Principaux de Service (SPNs) sont copiés du compte de service au compte dMSA
• msDS-AllowedToDelegateTo is copied over if applicable
• msDS-AllowedToActOnBehalfOfOtherIdentity the security descriptor is copied over if applicable
• The assigned AuthN policy, msDS-AssignedAuthnPolicy, of the service account are copied over
• dMSA est ajouté à tous les silos de politique d’authentification dont le compte de service était membre
• Le bit de contrôle d’accès utilisateur (UAC) "Auth pour délégation" de confiance est copié s’il était défini sur le compte de service
• msDS-SupersededServiceAccountState is set to 2
• Le compte de service est désactivé via le bit de désactivation UAC
• Les SPNs sont retirés du compte

dMSA realms

Les domaines servent de regroupements logiques qui définissent des limites d’authentification, souvent utilisées lors de l’intégration de différentes versions d’AD sur plusieurs domaines ou forêts. Ils sont particulièrement importants dans les environnements à domaine mixte où certains domaines peuvent ne pas prendre totalement en charge toutes les fonctionnalités de dMSA. En spécifiant des domaines, dMSA peut garantir une communication et un flux d’authentification appropriés entre les domaines.

Les administrateurs peuvent utiliser des domaines afin de spécifier quels domaines ou composants d'annuaire peuvent authentifier le compte dMSA et y accéder. Cela garantit que même les domaines enfants plus anciens, qui peuvent ne pas prendre en charge les fonctionnalités dMSA en mode natif, peuvent interagir avec les comptes tout en maintenant les limites de sécurité. Les domaines facilitent la coexistence transparente des transitions et des fonctionnalités dans des environnements mixtes, garantissant ainsi la compatibilité entre les domaines tout en conservant une sécurité forte lorsqu’ils sont activés.

Par exemple, si vous avez un domaine principal appelé corp.contoso.com qui s'exécute sur Windows Server 2025 et un domaine enfant plus ancien appelé legacy.corp.contoso.com sous Windows Server 2022, vous pouvez spécifier le domaine en tant que legacy.corp.contoso.com.

Pour modifier ce paramètre de stratégie de groupe pour votre environnement, accédez au chemin d’accès suivant :

Configuration ordinateur\Modèles d’administration\Système\Kerberos\Activer les ouvertures de session de compte de service managé délégué

See also

Configuration des comptes de service administrés délégués