Share via

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

  • Article

Important

Les builds Windows Server Insider sont en préversion. Certaines informations portent sur un produit en préversion susceptible d’être substantiellement modifié avant sa publication. Microsoft ne donne aucune garantie, expresse ou implicite, concernant les informations fournies ici.

Un nouveau type de compte appelé compte de service administré délégué (dMSA) est introduit dans Windows Server Insiders Preview, permettant la migration d’un compte de service traditionnel vers un compte de machine avec des clés gérées et entièrement aléatoires, tout en désactivant les mots de passe du compte de service original. 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 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 en utilisant Credential Guard (CG) 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 de son mot de passe sera 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. 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 (SPN) 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 SPN sont retirés du compte

Voir aussi

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