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 :
- L’utilisation des concepts de gMSA pour limiter la portée d’utilisation via Credential Guard pour lier l’authentification machine.
- 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 par la machine et automatiquement tournants, les mots de passe ne sont toujours pas liés à la machine 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 :
- La politique CG peut être configurée pour protéger l’identité des machines.
- Un administrateur commence et termine la migration du compte de service.
- Le compte de service actualise le serveur de distribution de tickets (TGT).
- Le compte de service ajoute l’identité de la machine pour permettre les principes.
- 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. Il est recommandé de maintenir un service dans l’état de démarrage pendant quatre durées de vie des tickets (28 jours). Retardez la migration si vos DC sont partitionnés ou si la réplication est interrompue lors de l’intégration.
- Soyez attentif aux sites où les retards de réplication sont plus longs que le temps de renouvellement des tickets par défaut de 10 heures. L’attribut groupMSAMembership est vérifié et mis à jour à chaque renouvellement de ticket, et chaque fois que le compte de service original se connecte pendant l’état « début de migration », ce qui ajoute le compte machine au groupMSAMembership du 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.
Avertissement
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 le cas, les machines qui ne prennent pas en charge les dMSA échoueront à l’authentification avec le compte de service existant une fois que le compte devient désactivé pendant 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.
Remarque
Les attributs numériques définis pour le compte indiquent que :
- 1 - La migration du compte a commencé.
- 2 - La migration du compte est terminée.
Exécuter Start-ADServiceAccountMigration applique les changements suivants :
- Lecture Générique est accordée à toutes les propriétés sur le dMSA
- Le compte de service reçoit la propriété Write dans msDS-groupMSAMembership
- msDS-DelegatedMSAState est remplacé par 1
- msDS-ManagedAccountPrecededByLink est paramétré sur le compte de service
- msDS-SupersededAccountState est remplacé par 1
- msDS-SupersededManagedServiceAccountLink est paramétré sur dMSA
Exécuter Complete-ADServiceAccountMigration applique les changements suivants :
- Le compte de service est retiré de Lecture Générique de toutes les propriétés sur le dMSA
- Le compte de service est retiré de Écriture de la propriété sur l’attribut msDS-GroupMSAMembership
- msDS-DelegatedMSAState est paramétré sur 2
- Les Noms Principaux de Service (SPNs) sont copiés du compte de service au compte dMSA
- msDS-AllowedToDelegateTo est copié le cas échéant
- msDS-AllowedToActOnBehalfOfOtherIdentity le descripteur de sécurité est copié le cas échéant
- La politique d’authentification assignée, msDS-AssignedAuthnPolicy, du compte de service est copiée
- 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 est paramétré sur 2
- Le compte de service est désactivé via le bit de désactivation UAC
- Les SPNs sont retirés du compte
Domaines dMSA
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é. En permettant une transition plus fluide et la coexistence de fonctionnalités dans des environnements mixtes, les domaines permettent de garantir la compatibilité sans compromettre la sécurité.
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é
