Partager via

Premiers pas avec les comptes de service gérés par groupe

Dans cet article, découvrez comment activer et utiliser les comptes de service gérés par 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 sur le service de cluster peuvent utiliser un compte gMSA ou un compte de service administré autonome (sMSA, standalone Managed Service Account) s'il s'agit d'un service Windows, d'un pool d'applications, d'une tâche planifiée ou s'ils prennent nativement en charge les comptes 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 None
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 None
Compte de service administré de groupe Tout serveur Windows Server relié à un domaine Le contrôleur de domaine gère et l'hôte récupère

Un compte d'ordinateur Windows, un compte de service géré autonome Windows (sMSA) 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 à partager par les services de la batterie de serveurs, vous devrez choisir un compte d'utilisateur ou un compte d'ordinateur en dehors d'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 et distribuer ces clés à toutes les instances de ces services.

Avec Windows Server, les services et les administrateurs de services n’ont pas besoin de gérer la synchronisation des mots de passe entre les instances de service lorsqu’ils utilisent des gMSA. Vous créez le gMSA dans Active Directory, puis configurez le service qui prend en charge les comptes de service managés. L’utilisation de gMSA est limitée à n’importe quel ordinateur capable d’utiliser LDAP pour récupérer les informations d’identification de gMSA. Vous pouvez créer un gMSA à l'aide des cmdlets New-ADServiceAccount qui font partie du module Active Directory. 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é de connexion

  • Services qui utilisent le gestionnaire IIS pour les pools d'applications afin de configurer l'identité

  • Les tâches qui utilisent le Planificateur de tâches

Prérequis

Le tableau suivant répertorie la configuration requise du système d'exploitation pour que l'authentification Kerberos puisse fonctionner avec les services utilisant des comptes gMSA. Les conditions requises pour Active Directory sont répertoriées à la suite de ce tableau.

Une architecture 64 bits est requise pour exécuter les commandes Windows PowerShell utilisées pour administrer les gMSA.

Système d’exploitation

Élément Exigence
Hôte d'application cliente Client Kerberos conforme aux RFC
Contrôleurs de domaine du domaine du compte d'utilisateur KDC conforme aux RFC
Hôtes membres du service partagé
Contrôleurs de domaine du domaine de l'hôte membre KDC conforme aux RFC
Contrôleurs de domaine du domaine du compte gMSA Contrôleurs de domaine Windows Server 2012 disponibles pour que l'hôte puisse récupérer le mot de passe
Hôte de service principal Serveur d'application Kerberos conforme aux RFC
Contrôleurs de domaine du domaine du compte de service principal KDC conforme aux RFC
Windows PowerShell pour Active Directory Les outils de l'administrateur du serveur distant des services de domaine Active Directory

Services de domaine Active Directory

Les comptes de service gérés par groupe doivent remplir les conditions suivantes dans les services de domaine Active Directory (AD DS).

  • Le niveau fonctionnel du domaine et de la forêt Active Directory doit être Windows Server 2012 ou une version ultérieure. Pour en savoir plus sur la mise à jour du schéma, veuillez consulter la section Comment élever les niveaux fonctionnels de domaine et de forêt d’Active Directory.

  • Si vous gérez l'autorisation de l'hôte de service à utiliser gMSA par groupe, alors groupe de sécurité nouveau ou existant.

  • Si vous gérez le contrôle d'accès au service par groupe, alors groupe de sécurité nouveau ou existant.

  • La clé racine des services de distribution de clés (KDS) pour Active Directory doit être créée dans le domaine. Le résultat de sa création peut être vérifié dans le journal des opérations du service KDS, Event ID 4004 Pour en savoir plus sur la création de la clé racine KDS (kdssvc.dll), reportez-vous à la section Créer la clé racine KDS des services de distribution de clés.

Déployer une nouvelle batterie de serveurs

Le processus de création et de gestion d'une batterie de serveurs à l'aide de la fonctionnalité gMSA implique généralement les tâches suivantes.

  • Déploiement d'une nouvelle batterie de serveurs

  • Ajout d'hôtes membres à une batterie de serveurs existante

  • Désaffectation d'hôtes membres d'une batterie de serveurs existante

  • Désaffectation d'une batterie de serveurs existante

  • Suppression d'un hôte membre compromis d'une batterie de serveurs, le cas échéant.

Lorsque l'administrateur du service déploie une nouvelle batterie de serveurs, il doit déterminer les informations suivantes.

  • Le service prend en charge l'utilisation des gMSA

  • Le service nécessite des connexions authentifiées entrantes ou sortantes.

  • Les noms de comptes d'ordinateur des hôtes membres du service utilisant la fonctionnalité gMSA

  • Le nom NetBIOS du service

  • Le nom d'hôte DNS du service

  • Les noms de principal du service (SPN) pour le service

  • L'intervalle de changement de mot de passe (30 jours par défaut)

Créer des comptes de service gérés par groupe

Vous pouvez créer un gMSA uniquement si le schéma de la forêt est Windows Server 2012 ou une version ultérieure. Vous devez également déployer la clé racine KDS pour Active Directory, et avoir au moins un contrôleur de domaine Windows Server 2012 ou plus récent dans le domaine où vous souhaitez créer un gMSA.

Important

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

Vous devez au minimum appartenir au groupe Domain Admins, ou avoir la capacité de créer des objets msDS-GroupManagedServiceAccount pour réaliser les procédures suivantes.

Pour créer un gMSA à l'aide de PowerShell, procédez comme suit.

  1. Dans le contrôleur de domaine Windows Server 2012, exécutez Windows PowerShell à partir de la barre des tâches.

  2. À l'invite de commandes de Windows PowerShell, tapez les commandes suivantes et appuyez sur Entrée : (Le module Active Directory se charge automatiquement.)

    New-ADServiceAccount [-Name] <string> -DNSHostName <string> [-KerberosEncryptionType <ADKerberosEncryptionType>] [-ManagedPasswordIntervalInDays <Nullable[Int32]>] [-PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal[]>] [-SamAccountName <string>] [-ServicePrincipalNames <string[]>]

    Remarque

    Une valeur pour le paramètre -Name est toujours requise (que vous spécifiez -Name ou non), les paramètres -DNSHostName, -RestrictToSingleComputer et -RestrictToOutboundAuthentication étant des exigences secondaires pour les trois scénarios de déploiement.

    Paramètre String Exemple
    Nom Nom du compte BatterieIT1
    DNSHostName Nom d'hôte DNS du service BatterieIT1.contoso.com
    KerberosEncryptionType Tout type de chiffrement pris en charge par les serveurs hôtes None, RC4, AES128, AES256
    ManagedPasswordIntervalInDays Intervalle de modification de mot de passe exprimé en jours (la valeur par défaut est 30 jours) 90
    PrincipalsAllowedToRetrieveManagedPassword Comptes d'ordinateur des hôtes membres ou groupe de sécurité auquel appartiennent les hôtes membres HôtesBatterieIT
    SamAccountName Nom NetBIOS du service s'il est différent de Name BatterieIT1
    ServicePrincipalNames Noms de principal du service (SPN) pour le service http/ITFarm1.contoso.com/contoso.com, http/ITFarm1.contoso.com/contoso, http/ITFarm1/contoso.com, http/ITFarm1/contoso, MSSQLSvc/ITFarm1.contoso.com:1433, MSSQLSvc/ITFarm1.contoso.com:INST01

    Important

    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.

    Par exemple, utilisez la commande suivante pour créer un nouveau gMSA appelé ITFarm1 pour le groupe. La gMSA permet au service d'utiliser les types de chiffrement Kerberos RC4, AES128 et AES256. Le service est autorisé à utiliser les SPN http/ITFarm1.contoso.com/contoso.com, http/ITFarm1.contoso.com/contoso, http/ITFarm1/contoso.com et http/ITFarm1/contoso.

    Entrez la commande sur une seule ligne, même si elle tient ici sur plusieurs lignes du fait de contraintes de mise en forme.

     New-ADServiceAccount ITFarm1 -DNSHostName ITFarm1.contoso.com -PrincipalsAllowedToRetrieveManagedPassword ITFarmHosts$ -KerberosEncryptionType RC4, AES128, AES256 -ServicePrincipalNames http/ITFarm1.contoso.com/contoso.com, http/ITFarm1.contoso.com/contoso, http/ITFarm1/contoso.com, http/ITFarm1/contoso

Vous devez au minimum appartenir au groupe Admins du domaine ou Opérateurs de compte, ou avoir la capacité de créer des objets msDS-GroupManagedServiceAccount pour réaliser les procédures suivantes. Pour plus d’informations sur l’utilisation des comptes et appartenances à des groupes appropriés, voir Groupes de sécurité Active Directory.

Pour créer un gMSA pour l'authentification sortante uniquement à l'aide de PowerShell, procédez comme suit.

  1. Dans le contrôleur de domaine Windows Server 2012, exécutez Windows PowerShell à partir de la barre des tâches.

  2. À l'invite de commande du module Windows PowerShell Active Directory, utilisez la commande suivante.

    New-ADServiceAccount [-Name] <string> -RestrictToOutboundAuthenticationOnly [-ManagedPasswordIntervalInDays <Nullable[Int32]>] [-PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal[]>]

    L’exemple crée un gMSA en utilisant les paramètres dans le tableau suivant.

    Paramètre String Exemple
    Nom Nom du compte BatterieIT1
    ManagedPasswordIntervalInDays Intervalle de modification de mot de passe exprimé en jours (la valeur par défaut est 30 jours) 75
    PrincipalsAllowedToRetrieveManagedPassword Comptes d'ordinateur des hôtes membres ou groupe de sécurité auquel appartiennent les hôtes membres HôtesBatterieIT

    Important

    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.

    La commande d’exemple utilise ces paramètres comme suit.

    New-ADServiceAccount ITFarm1 -RestrictToOutboundAuthenticationOnly - PrincipalsAllowedToRetrieveManagedPassword ITFarmHosts$

Configurer le service d'application d'identité

Pour configurer les services dans Windows Server, consultez les articles suivants :

D'autres services peuvent prendre en charge la fonctionnalité gMSA. Reportez-vous à la documentation produit spécifique pour plus d'informations sur la configuration de ces services.

Ajouter des hôtes membres à une batterie de serveurs existante

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é (auquel appartiennent les hôtes membres du compte gMSA) en utilisant l'une des méthodes suivantes.

Vous devez au minimum appartenir au groupe Admins du domaine ou avoir la capacité d'ajouter des membres à l'objet de groupe de sécurité pour réaliser ces procédures.

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

L’appartenance à Domain Admins, Account Operators ou la capacité à gérer des objets msDS-GroupManagedServiceAccount, est le minimum requis pour compléter cette procédure. Pour plus d’informations sur l’utilisation des comptes et appartenances à des groupes appropriés, voir Groupes locaux et de domaine par défaut.

Ajouter des hôtes membres à l'aide de PowerShell

  1. Dans le contrôleur de domaine Windows Server 2012, exécutez Windows PowerShell à partir de la barre des tâches.

  2. À l'invite de commandes du module Active Directory pour Windows PowerShell, tapez les commandes suivantes et appuyez sur Entrée :

    Get-ADServiceAccount [-Identity] <string> -Properties PrincipalsAllowedToRetrieveManagedPassword

  3. À l'invite de commandes du module Active Directory pour Windows PowerShell, tapez les commandes suivantes et appuyez sur Entrée :

    Set-ADServiceAccount [-Identity] <string> -PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal[]>

L'exemple suivant ajoute un membre à une batterie de serveurs en utilisant les paramètres du tableau.

Paramètre String Exemple
Nom Nom du compte BatterieIT1
PrincipalsAllowedToRetrieveManagedPassword Comptes d'ordinateur des hôtes membres ou groupe de sécurité auquel appartiennent les hôtes membres Hôte1, Hôte2, Hôte3

L'exemple suivant permet d'obtenir les membres actuels de la ferme ITFarm1.

Get-ADServiceAccount [-Identity] ITFarm1 -Properties PrincipalsAllowedToRetrieveManagedPassword

L'exemple suivant ajoute des hôtes membres à une batterie de serveurs existante ITFarm1.

Set-ADServiceAccount [-Identity] ITFarm1 -PrincipalsAllowedToRetrieveManagedPassword Host1$,Host2$,Host3$

Mettre à jour les propriétés du gMSA

Vous devez au minimum appartenir au groupe Admins du domaine ou Opérateurs de compte, ou avoir la capacité d'écrire dans des objets msDS-GroupManagedServiceAccount pour réaliser ces procédures.

Ouvrez le module Active Directory pour Windows PowerShell et définissez n'importe quelle propriété à l'aide de la cmdlet Set-ADServiceAccount

Pour plus d’informations sur la définition de ces propriétés, voir Set-ADServiceAccount dans la Bibliothèque TechNet ou tapez Get-Help Set-ADServiceAccount à l’invite de commandes du module Active Directory pour Windows PowerShell et appuyez sur ENTRÉE.

Retirer les hôtes membres d’une batterie de serveurs existante

Vous devez au minimum appartenir au groupe Admins du domaine ou avoir la capacité de supprimer des membres de l'objet de groupe de sécurité pour réaliser ces procédures.

Si vous utilisez des groupes de sécurité pour gérer les hôtes membres, supprimez le compte d’ordinateur de l’hôte membre déclassé du groupe de sécurité auquel les hôtes membres du gMSA appartiennent, en utilisant l’une des méthodes suivantes.

Si la liste des comptes d'ordinateur est affichée, récupérez les comptes existants, puis ajoutez tous les comptes sauf le compte d'ordinateur supprimé.

L’appartenance à Domain Admins, Account Operators ou la capacité à gérer des objets msDS-GroupManagedServiceAccount, est le minimum requis pour compléter cette procédure. Pour plus d’informations sur l’utilisation des comptes et appartenances à des groupes appropriés, voir Groupes locaux et de domaine par défaut.

Supprimer des hôtes membres à l'aide de PowerShell

  1. Dans le contrôleur de domaine Windows Server 2012, exécutez Windows PowerShell à partir de la barre des tâches.

  2. À l'invite de commandes du module Active Directory pour Windows PowerShell, tapez les commandes suivantes et appuyez sur Entrée :

    Get-ADServiceAccount [-Identity] <string> -Properties PrincipalsAllowedToRetrieveManagedPassword

  3. À l'invite de commandes du module Active Directory pour Windows PowerShell, tapez les commandes suivantes et appuyez sur Entrée :

    Set-ADServiceAccount [-Identity] <string> -PrincipalsAllowedToRetrieveManagedPassword <ADPrincipal[]>

L’exemple retire un membre d’une batterie de serveurs en utilisant les paramètres dans le tableau suivant.

Paramètre String Exemple
Nom Nom du compte BatterieIT1
PrincipalsAllowedToRetrieveManagedPassword Comptes d'ordinateur des hôtes membres ou groupe de sécurité auquel appartiennent les hôtes membres Host1, Host3

L'exemple suivant permet d'obtenir les membres actuels de la ferme ITFarm1.

Get-ADServiceAccount [-Identity] ITFarm1 -Properties PrincipalsAllowedToRetrieveManagedPassword

L'exemple suivant supprime les hôtes membres d'une batterie de serveurs existante ITFarm1.

Set-ADServiceAccount [-Identity] ITFarm1 -PrincipalsAllowedToRetrieveManagedPassword Host1$,Host3$

Supprimer le gMSA du système

Supprimez les informations d’identification gMSA mises en cache de l’hôte membre en utilisant Uninstall-ADServiceAccount ou l’API NetRemoveServiceAccount sur le système hôte.

Vous devez au minimum appartenir au groupe Administrateurs ou à un groupe équivalent pour réaliser ces procédures.

Supprimer le gMSA en utilisant PowerShell

  1. Dans le contrôleur de domaine Windows Server 2012, exécutez Windows PowerShell à partir de la barre des tâches.

  2. À l'invite de commandes du module Active Directory pour Windows PowerShell, tapez les commandes suivantes et appuyez sur Entrée :

    Uninstall-ADServiceAccount <ADServiceAccount>

    L'exemple suivant désinstalle un compte de service géré Active Directory d'un ordinateur.

    Uninstall-ADServiceAccount ITFarm1

Pour plus d’informations sur la cmdlet Uninstall-ADServiceAccount, à l’invite de commande du module Active Directory pour Windows PowerShell, tapez Get-Help Uninstall-ADServiceAccount, puis appuyez sur ENTRÉE, ou consultez les informations sur TechNet à Uninstall-ADServiceAccount.

Contenu connexe