Gérer les comptes de service géré de groupe

Dans cet article, découvrez comment activer et utiliser des comptes de service administré de groupe (gMSA) dans Windows Server.

Les protocoles d'authentification prenant en charge l'authentification mutuelle, tels que Kerberos, peuvent être utilisés uniquement si toutes les instances des services utilisent le même principal. Par exemple, lorsqu'un ordinateur client se connecte à un service qui utilise l'équilibrage de charge ou une autre méthode où tous les serveurs semblent être le même service pour le client. Cela signifie que chaque service doit utiliser les mêmes mots de passe ou clés pour prouver son identité. Les comptes de service gérés par groupe sont un type de compte pouvant être utilisé avec plusieurs serveurs. Un gMSA est un compte de domaine qui peut être utilisé pour exécuter des services sur plusieurs serveurs sans avoir à gérer le mot de passe. Le gMSA permet une gestion automatique des mots de passe et une gestion simplifiée des noms de principaux services (SPN), y compris la délégation de la gestion à d'autres administrateurs.

Remarque

Les clusters de basculement ne prennent pas en charge les comptes de service administrés de groupe (gMSA, group Managed Service Account). Toutefois, les services qui s'exécutent au-dessus du service de cluster peuvent utiliser un gMSA ou un sMSA s'il s'agit d'un service Windows, d'un pool d'applications, d'une tâche planifiée ou s'ils prennent en charge nativement les gMSA ou sMSA.

Les services peuvent choisir le principal à utiliser. Chaque type de principal prend en charge des services différents et présente des limitations différentes.

Principaux Services pris en charge Gestion des mots de passe
Compte d’ordinateur du système Windows Limité à un serveur joint à un domaine Géré par l'ordinateur
Compte d’ordinateur sans système Windows Tout serveur joint à un domaine Aucun
Compte virtuel Limité à un serveur Géré par l'ordinateur
Compte de Service Géré Autonome Windows Limité à un serveur joint à un domaine Géré par l'ordinateur
Compte d’utilisateur Tout serveur joint à un domaine Aucun
Compte de service administré de groupe N’importe quel serveur joint à un domaine Windows Server Le contrôleur de domaine gère et l'hôte récupère

Un compte d'ordinateur Windows, un compte de service managé autonome (sMSA) Windows ou des comptes virtuels ne peuvent pas être partagés entre plusieurs systèmes. Lorsque vous utilisez des comptes virtuels, l'identité est également locale à la machine et n'est pas reconnue par le domaine. Si vous configurez un compte unique pour les services à partager entre les batteries de serveurs, vous devez choisir un compte d'utilisateur ou un compte d'ordinateur autre qu'un système Windows. D'une manière ou d'une autre, ces comptes n'ont pas la capacité de gérer les mots de passe à partir d'un point de contrôle unique. Sans gestion des mots de passe, chaque organisation doit mettre à jour les clés du service dans Active Directory (AD) et distribuer ces clés à toutes les instances de ces services.

Avec Windows Server, les services et les administrateurs de service n'ont pas besoin de gérer la synchronisation de mot de passe entre les instances de service lors de l'utilisation de gMSA. Vous créez le compte gMSA dans AD, puis configurez le service qui prend en charge les comptes de service géré. L’utilisation du gMSA est limitée à n’importe quel ordinateur capable d’utiliser le protocole LDAP (Lightweight Directory Access Protocol) pour récupérer les informations d’identification de gMSA. Vous pouvez créer un gMSA avec les New-ADServiceAccount applets de commande qui font partie du module AD. Les services suivants prennent en charge la configuration de l'identité du service sur l'hôte.

  • Mêmes API que sMSA, donc les produits qui prennent en charge sMSA prennent en charge gMSA.

  • Services qui utilisent Service Control Manager pour configurer l’identité d’ouverture de session

  • Services qui utilisent le gestionnaire Internet Information Services (IIS) pour les pools d’applications pour configurer l’identité

  • Tâches à l’aide du planificateur de tâches.

Conditions préalables

Pour gérer les gMSA, votre appareil doit répondre aux exigences suivantes :

Conseil / Astuce

Pour contrôler quels hôtes ou services peuvent utiliser un compte gMSA, ajoutez leurs comptes d’ordinateur à un groupe de sécurité désigné (nouveau ou existant) et attribuez les autorisations nécessaires à ce groupe. De même, utilisez un groupe de sécurité pour gérer l’accès aux services exécutés sous gMSA, ce qui garantit que le groupe dispose de toutes les autorisations requises pour l’opération de service et l’accès aux ressources.

Pour que l’authentification Kerberos fonctionne avec des services utilisant des gMSA, les éléments suivants sont requis :

  • Vérifiez que les SPN sont correctement inscrits pour chaque service à l’aide d’un compte gMSA. Cela permet à Kerberos d’identifier et d’authentifier le service.

  • Vérifiez que les enregistrements DNS sont configurés correctement pour la résolution de noms, sur lequel Kerberos s’appuie pour localiser les services de domaine.

  • Assurez-vous que les pare-feu et les stratégies réseau autorisent le trafic Kerberos et les communications de service nécessaires.

  • Pour les paramètres de durée de vie des tickets Kerberos, configurez les stratégies d’expiration et de renouvellement des tickets conformément à vos exigences de sécurité et opérationnelles.

  • Tous les systèmes impliqués dans le processus d’authentification doivent avoir des horloges synchronisées. Kerberos respecte la configuration temporelle et les différences peuvent entraîner des échecs d’authentification.

  • Tous les systèmes qui se connectent ou s’installent à l’aide d’un compte gMSA doivent prendre en charge les types de chiffrement Kerberos requis par gMSA. Les systèmes qui ne répondent pas à cette exigence ne peuvent pas se connecter ni installer gMSA.

Si vous gérez AD à partir d’un ordinateur qui n’est pas un contrôleur de domaine, installez les outils d’administration de serveur distant (RSAT) pour accéder aux fonctionnalités de gestion nécessaires. RSAT fournit le module AD pour PowerShell. Après avoir installé RSAT, ouvrez PowerShell en tant qu’administrateur et exécutez Import-Module ActiveDirectory pour activer les applets de commande de gestion AD. Cela permet aux administrateurs de gérer AD à distance et en toute sécurité, ce qui réduit la charge sur les contrôleurs de domaine.

Créer un gMSA

Pour créer un compte gMSA à l’aide de PowerShell, procédez comme suit dans une fenêtre PowerShell avec élévation de privilèges :

Importante

Les noms des comptes gMSA doivent être uniques au sein d'une forêt et pas seulement d'un domaine. La tentative de création d’un compte gMSA avec un nom en double échoue, même dans différents domaines.

  1. Créez la clé racine KDS, si elle n’existe pas, en suivant les instructions de la section Créer la clé racine KDS des services de distribution de clés. Si une clé existe déjà, ignorez cette étape.

  2. Pour créer un gMSA, exécutez la commande suivante. Remplacez <gMSAName> par votre nom gMSA souhaité et <domain> par le nom de votre domaine. Remplacez <SecurityGroup> par le nom du groupe de sécurité ou des comptes d’ordinateur qui doivent avoir accès pour récupérer le mot de passe de gMSA.

    New-ADServiceAccount -Name <gMSAName> -DNSHostName <gMSAName>.<domain> -PrincipalsAllowedToRetrieveManagedPassword <SecurityGroup>

    Pour créer un gMSA pour l’authentification sortante uniquement, exécutez la commande suivante. Remplacez par <Days> une valeur numérique. Si une valeur n’est pas fournie, elle est définie par défaut sur 30 jours.

    New-ADServiceAccount -Name <gMSAName> -DNSHostName <gMSAName>.<domain> -RestrictToOutboundAuthenticationOnly -ManagedPasswordIntervalInDays <Days> -PrincipalsAllowedToRetrieveManagedPassword <SecurityGroup>

    Importante

    L'intervalle de modification de mot de passe ne peut être défini qu'à la création. Si vous avez besoin de modifier l'intervalle, vous devez créer un nouveau compte gMSA et définir l'intervalle au moment de la création.

  3. Exécutez la commande suivante pour vérifier si l’appareil cible a accès pour récupérer le mot de passe gMSA.

    Test-ADServiceAccount -Identity <gMSAName>

L’appartenance au groupe de sécurité approprié ou l’autorisation déléguée nécessaire pour créer msDS-GroupManagedServiceAccount des objets est nécessaire pour effectuer cette procédure. Bien que les membres des opérateurs de compte puissent gérer certains objets d’utilisateur et de groupe dans AD, ils n’ont pas les droits par défaut pour créer des gMSA, sauf si ces autorisations sont déléguées. Pour plus d'informations sur l'utilisation des comptes appropriés et des adhésions aux groupes, consultez Groupes de sécurité Active Directory.

Vous pouvez également mettre à jour les propriétés gMSA à l’aide de l'applet de commande PowerShell Set-ADServiceAccount. Par exemple, pour mettre à jour le nom d'affichage des ordinateurs, exécutez la commande suivante en remplaçant <gMSAName> et <NewDisplayName> par vos valeurs :

Set-ADServiceAccount -Identity "<gMSAName>" -DisplayName "<NewDisplayName>"

Pour plus d’informations sur la définition d’autres propriétés pour gMSA, consultez Set-ADServiceAccount.

Vérifier les modifications apportées à un compte gMSA

Après avoir apporté des modifications à un compte gMSA, vous pouvez vérifier si le gMSA est correctement mis à jour. Ces modifications incluent l’ajout, la suppression et la désinstallation d’un compte gMSA. Vous pouvez également effectuer cette étape à tout moment lorsque des mises à jour sont apportées aux propriétés gMSA.

Exécutez la commande suivante en remplaçant <gMSAName> par le nom du compte gMSA que vous avez créé :

Get-ADServiceAccount -Identity "<gMSAName>" | Select-Object *

Ajouter des hôtes membres à un groupe de sécurité

Remarque

  • Gestion centrée sur le groupe (Add-ADGroupMember / Remove-ADGroupMember) : utilisez ces applets de commande lorsque vous souhaitez gérer l’appartenance à un groupe spécifique. Ils conviennent mieux à l’ajout ou à la suppression de plusieurs utilisateurs, ordinateurs ou autres objets vers ou à partir d’un seul groupe efficacement.

  • Gestion centrée sur le principal (Add-ADPrincipalGroupMembership / Remove-ADPrincipalGroupMembership) : choisissez ces applets de commande lorsque votre objectif est de gérer l’appartenance d’un utilisateur ou d’un ordinateur spécifique à plusieurs groupes. Ils vous permettent d’ajouter ou de supprimer un principal de plusieurs groupes dans une seule opération, ce qui facilite la mise à jour des affiliations de groupe pour des comptes individuels.

Si vous utilisez des groupes de sécurité pour gérer les hôtes membres, ajoutez le compte d’ordinateur du nouvel hôte membre au groupe de sécurité qui contient les hôtes membres de gMSA. Pour ce faire, vous pouvez utiliser l’une des méthodes suivantes :

Pour utiliser le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory (ADUC), consultez Ajoutez un compte d’ordinateur à un groupe et Gérer les comptes utilisateurs dans Utilisateurs et ordinateurs Active Directory.

Si vous utilisez des comptes d'ordinateur, recherchez les comptes existants et ajoutez le nouveau compte d'ordinateur.

Supprimer des hôtes membres d’un groupe de sécurité

Pour utiliser le composant logiciel enfichable ADUC, consultez Supprimer un compte d’ordinateur et supprimer un compte d’utilisateur.

Installer un gMSA sur votre système

Après avoir créé un compte gMSA et ajouté les hôtes membres au groupe de sécurité, vous devez installer le compte gMSA sur chaque ordinateur hôte sur lequel le service s’exécute. Pour installer un compte gMSA, ouvrez une fenêtre PowerShell avec des privilèges élevés et exécutez la commande suivante en remplaçant <gMSAName> par votre valeur :

Install-ADServiceAccount -Identity <gMSAName>

Pour plus d’informations sur l’applet Install-ADServiceAccount de commande, consultez Install-ADServiceAccount.

Désinstaller un gMSA à partir de votre système

Bien que vous ne puissiez pas désinstaller des gMSA dans ADUC, vous pouvez supprimer manuellement un compte de service administré en le trouvant dans le conteneur Comptes de service gérés et en le supprimant comme n’importe quel autre objet AD. Toutefois, gardez à l’esprit que cela n’effectue pas les mêmes opérations de nettoyage que Uninstall-ADServiceAccount dans PowerShell.

Pour désinstaller un compte gMSA, ouvrez une fenêtre PowerShell avec élévation de privilèges et suivez ces étapes.

  1. Pour supprimer un gMSA unique de votre environnement, exécutez la commande suivante en remplaçant <gMSAName> par votre valeur :

    Uninstall-ADServiceAccount -Identity <gMSAName>

  2. Pour supprimer plusieurs gMSA de votre environnement, exécutez la commande suivante en remplaçant <gMSA#$> par vos valeurs :

    $gMSANames = @("gMSA1$", "gMSA2$", "gMSA3$")

foreach ($gMSAs in $gMSANames) {
  Uninstall-ADServiceAccount -Identity $gMSAs
}

Pour plus d’informations sur l’applet Uninstall-ADServiceAccount de commande, consultez Uninstall-ADServiceAccount.

Voir aussi

  • Last updated on