Créer des gMSA pour les conteneurs Windows

Article
02/06/2025

S’applique à : Windows Server 2025, Windows Server 2022, Windows Server 2019

Les réseaux Windows utilisent couramment Active Directory (AD) pour faciliter l’authentification et l’autorisation entre les utilisateurs, les ordinateurs et d’autres ressources réseau. Les développeurs d’applications d’entreprise conçoivent souvent leurs applications pour qu’elles soient intégrées à AD et exécutées sur des serveurs joints à un domaine pour tirer parti de l’authentification Windows intégrée, ce qui permet aux utilisateurs et aux autres services de se connecter automatiquement et de manière transparente à l’application avec leurs identités. Cet article explique comment commencer à utiliser des comptes de service managés de groupe Active Directory avec des conteneurs Windows.

Bien que les conteneurs Windows ne puissent pas être joints à un domaine, ils peuvent toujours utiliser des identités de domaine Active Directory pour prendre en charge différents scénarios d’authentification. Pour ce faire, vous pouvez configurer un conteneur Windows pour qu’il s’exécute avec un compte de service géré de groupe (gMSA), qui est un type spécial de compte de service introduit dans Windows Server 2012 et conçu pour permettre à plusieurs ordinateurs de partager une identité sans avoir à connaître son mot de passe. Les conteneurs Windows ne peuvent pas être joints à un domaine, mais de nombreuses applications Windows qui s’exécutent dans des conteneurs Windows ont toujours besoin de l’authentification AD. Pour utiliser l’authentification AD, vous pouvez configurer un conteneur Windows pour qu’il s’exécute avec un compte de service administré de groupe (gMSA).

Lorsque gMSA pour les conteneurs Windows a été introduit initialement, l’hôte de conteneur devait être joint à un domaine, ce qui a entraîné beaucoup de travail supplémentaire pour que les utilisateurs joignent manuellement des nœuds Worker Windows à un domaine. Cette limitation a été résolue pour la prise en charge des conteneurs Windows via gMSA, même lorsque les hôtes de ces conteneurs ne sont pas joints à un domaine. Nous continuerons à prendre en charge la fonctionnalité gMSA d’origine pour utiliser un hôte de conteneur joint à un domaine.

Les améliorations apportées à gMSA lors de l’utilisation d’un hôte de conteneur non joint à un domaine sont les suivantes :

L’exigence de joindre manuellement des nœuds Worker Windows à un domaine est supprimée, car elle a causé beaucoup de surcharge pour les utilisateurs. Pour les scénarios de mise à l’échelle, l’utilisation d’un hôte de conteneur non joint à un domaine simplifie le processus.
Dans les scénarios de mise à jour propagée, les utilisateurs ne doivent plus joindre le nœud à un domaine.
La gestion des comptes d’ordinateur de nœuds worker pour récupérer les mots de passe des comptes de service gMSA est un processus plus simple.
La configuration de gMSA avec Kubernetes est un processus de bout en bout moins compliqué.

Remarque

Pour savoir comment la communauté Kubernetes prend en charge l’utilisation de gMSA avec des conteneurs Windows, consultez configuration de gMSA.

Architecture et améliorations de gMSA

Pour résoudre les limitations de l’implémentation initiale de gMSA pour les conteneurs Windows, la prise en charge de gMSA pour les hôtes de conteneurs non joints à un domaine utilise une identité utilisateur portable au lieu d’un compte d’ordinateur hôte pour récupérer les informations d’identification gMSA. Par conséquent, la jonction manuelle de nœuds Windows Worker à un domaine n’est plus nécessaire, bien que cela soit toujours pris en charge. L’identité/les informations d’identification de l’utilisateur sont stockées dans un magasin de secrets accessible à l’hôte de conteneur (par exemple, en tant que secret Kubernetes) où les utilisateurs authentifiés peuvent le récupérer.

diagramme des comptes de service gérés de groupe version 2

La prise en charge de gMSA pour les hôtes de conteneurs non joints à un domaine offre la possibilité de créer des conteneurs avec gMSA sans joindre le nœud hôte au domaine. À compter de Windows Server 2019, ccg.exe est prise en charge, ce qui permet à un mécanisme de plug-in de récupérer les informations d’identification gMSA à partir d’Active Directory. Vous pouvez utiliser cette identité pour démarrer le conteneur. Pour plus d’informations sur ce mécanisme de plug-in, consultez l’interface ICcgDomainAuthCredentials.

Remarque

Dans Azure Kubernetes Service sur Azure Stack HCI, vous pouvez utiliser le plug-in pour communiquer de ccg.exe à AD, puis récupérer les informations d’identification gMSA. Pour plus d’informations, consultez configurer un compte de service administré de groupe avec AKS sur Azure Stack HCI.

Affichez le diagramme ci-dessous pour suivre les étapes du processus Container Credential Guard :

À l’aide d’un fichier CredSpec en entrée, le processus ccg.exe est démarré sur l’hôte de nœud.
ccg.exe utilise des informations dans le fichier CredSpec pour lancer un plug-in, puis récupérer les informations d’identification du compte dans le magasin secret associé au plug-in.
ccg.exe utilise les informations d’identification du compte récupérés pour récupérer le mot de passe gMSA à partir d’AD.
ccg.exe rend le mot de passe gMSA disponible pour un conteneur qui a demandé des informations d’identification.
Le conteneur s’authentifie auprès du contrôleur de domaine à l’aide du mot de passe gMSA pour obtenir un ticket de Ticket-Granting Kerberos (TGT).
Les applications s’exécutant en tant que service réseau ou système local dans le conteneur peuvent désormais s’authentifier et accéder aux ressources de domaine, telles que gMSA.

diagramme

Conditions préalables

Pour exécuter un conteneur Windows avec un compte de service managé de groupe, vous aurez besoin des éléments suivants :

Domaine Active Directory avec au moins un contrôleur de domaine exécutant Windows Server 2012 ou version ultérieure. Il n’existe aucune exigence de niveau fonctionnel de forêt ou de domaine pour utiliser des gMSA, mais les mots de passe gMSA ne peuvent être distribués que par les contrôleurs de domaine exécutant Windows Server 2012 ou version ultérieure. Pour plus d’informations, consultez Exigences d'Active Directory pour les gMSAs.
Autorisation de créer un compte gMSA. Pour créer un compte gMSA, vous devez être administrateur de domaine ou utiliser un compte qui dispose de l'autorisation Créer des objets msDS-GroupManagedServiceAccount.
Accédez à Internet pour télécharger le module CredentialSpec PowerShell. Si vous travaillez dans un environnement déconnecté, vous pouvez enregistrer le module sur un ordinateur disposant d’un accès Internet et le copier sur votre ordinateur de développement ou hôte de conteneur.

Préparation ponctuelle d’Active Directory

Si vous n’avez pas encore créé un compte gMSA dans votre domaine, vous devez générer la clé racine KDS (Key Distribution Service). Le KDS est responsable de la création, de la rotation et de la distribution du mot de passe gMSA aux hôtes autorisés. Lorsqu’un hôte de conteneur doit utiliser le compte gMSA pour exécuter un conteneur, il contacte le KDS pour récupérer le mot de passe actuel.

Pour vérifier si la clé racine KDS a déjà été créée, exécutez l’applet de commande PowerShell suivante en tant qu’administrateur de domaine sur un contrôleur de domaine ou un membre de domaine avec les outils AD PowerShell installés :

Get-KdsRootKey

Si la commande retourne un identifiant de clé, vous êtes prêt et pouvez passer à la section créer un compte de service géré de groupe. Sinon, continuez à créer la clé racine KDS.

Important

Vous ne devez créer qu’une clé racine KDS par forêt. Si plusieurs clés racines KDS sont créées, cela entraîne l’échec du gMSA après la rotation du mot de passe gMSA.

Dans un environnement de production ou un environnement de test avec plusieurs contrôleurs de domaine, exécutez l’applet de commande suivante dans PowerShell en tant qu’administrateur de domaine pour créer la clé racine KDS.

# For production environments
Add-KdsRootKey -EffectiveImmediately

Bien que la commande implique que la clé soit effective immédiatement, vous devez attendre 10 heures avant que la clé racine KDS soit répliquée et disponible pour être utilisée sur tous les contrôleurs de domaine.

Si vous n’avez qu’un seul contrôleur de domaine dans votre domaine, vous pouvez accélérer le processus en définissant la clé pour qu’elle soit effective il y a 10 heures.

Important

N’utilisez pas cette technique dans un environnement de production.

# For single-DC test environments only
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

Créer un compte de service géré de groupe

Chaque conteneur qui utilise l’authentification Windows intégrée a besoin d’au moins un gMSA. Le compte gMSA principal est utilisé chaque fois que les applications s’exécutant en tant que système ou service réseau accèdent aux ressources sur le réseau. Le nom du gMSA devient le nom du conteneur sur le réseau, quel que soit le nom d’hôte affecté au conteneur. Les conteneurs peuvent également être configurés avec des gMSA supplémentaires, au cas où vous souhaitez exécuter un service ou une application dans le conteneur sous la forme d’une identité différente du compte d’ordinateur conteneur.

Lorsque vous créez un compte gMSA, vous créez également une identité partagée qui peut être utilisée simultanément sur de nombreuses machines différentes. L’accès au mot de passe gMSA est protégé par une liste de contrôle d’accès Active Directory. Nous vous recommandons de créer un groupe de sécurité pour chaque compte gMSA et d’ajouter les hôtes de conteneur appropriés au groupe de sécurité pour limiter l’accès au mot de passe.

Enfin, étant donné que les conteneurs n’inscrivent pas automatiquement de noms de principal de service (SPN), vous devez créer manuellement un SPN hôte pour votre compte gMSA.

En règle générale, l’hôte ou le spN http est inscrit à l’aide du même nom que le compte gMSA, mais vous devrez peut-être utiliser un autre nom de service si les clients accèdent à l’application conteneurisée à partir d’un équilibreur de charge ou d’un nom DNS différent du nom gMSA.

Par exemple, si le compte gMSA est nommé « WebApp01 », mais que vos utilisateurs accèdent au site à mysite.contoso.com, vous devez inscrire un spN http/mysite.contoso.com sur le compte gMSA.

Certaines applications peuvent nécessiter des noms de principal de service supplémentaires pour leurs protocoles uniques. Par exemple, SQL Server nécessite le spN MSSQLSvc/hostname.

Le tableau suivant répertorie les attributs requis pour la création d’un compte gMSA.

propriété gMSA	Valeur requise	Exemple
Nom	Tout nom de compte valide.	`WebApp01`
DnsHostName	Nom de domaine ajouté au nom du compte.	`WebApp01.contoso.com`
ServicePrincipalNames	Définissez au moins le SPN hôte, ajoutez d’autres protocoles si nécessaire.	`'host/WebApp01', 'host/WebApp01.contoso.com'`
PrincipalsAllowedToRetrieveManagedPassword	Le groupe de sécurité contenant vos hôtes de conteneur.	`WebApp01Hosts`

Une fois que vous avez choisi le nom de votre compte gMSA, exécutez les applets de commande suivantes dans PowerShell pour créer le groupe de sécurité et gMSA.

Conseil

Vous devez utiliser un compte qui appartient au groupe de sécurité Domain Admins ou à qui l'autorisation de créer des objets msDS-GroupManagedServiceAccount a été déléguée, pour exécuter les commandes suivantes. L’applet de commande New-ADServiceAccount fait partie des outils PowerShell AD des Outils d'administration de serveur distant.

Nous vous recommandons de créer des comptes gMSA distincts pour vos environnements de développement, de test et de production.

Cas d’usage pour la création d’un compte gMSA pour les hôtes de conteneur joints à un domaine

# Replace 'WebApp01' and 'contoso.com' with your own gMSA and domain names, respectively.

# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat

# Create the security group
New-ADGroup -Name "WebApp01 Authorized Hosts" -SamAccountName "WebApp01Hosts" -GroupScope DomainLocal

# Create the gMSA
New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.contoso.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.contoso.com" -PrincipalsAllowedToRetrieveManagedPassword "WebApp01Hosts"

# Add your container hosts to the security group
Add-ADGroupMember -Identity "WebApp01Hosts" -Members "ContainerHost01$", "ContainerHost02$", "ContainerHost03$"

Cas d’usage pour la création d’un compte gMSA pour les hôtes de conteneur non joints à un domaine

Lorsque vous utilisez gMSA pour les conteneurs avec des hôtes non joints à un domaine, au lieu d’ajouter des hôtes de conteneur au groupe de sécurité WebApp01Hosts, créez et ajoutez un compte d’utilisateur standard.

# Replace 'WebApp01' and 'contoso.com' with your own gMSA and domain names, respectively.

# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat

# Create the security group
New-ADGroup -Name "WebApp01 Authorized Accounts" -SamAccountName "WebApp01Accounts" -GroupScope DomainLocal

# Create the gMSA
New-ADServiceAccount -Name "WebApp01" -DnsHostName "WebApp01.contoso.com" -ServicePrincipalNames "host/WebApp01", "host/WebApp01.contoso.com" -PrincipalsAllowedToRetrieveManagedPassword "WebApp01Accounts"

# Create the standard user account. This account information needs to be stored in a secret store and will be retrieved by the ccg.exe hosted plug-in to retrieve the gMSA password. Replace 'StandardUser01' and 'p@ssw0rd' with a unique username and password. We recommend using a random, long, machine-generated password.
New-ADUser -Name "StandardUser01" -AccountPassword (ConvertTo-SecureString -AsPlainText "p@ssw0rd" -Force) -Enabled 1

# Add your container hosts to the security group
Add-ADGroupMember -Identity "WebApp01Accounts" -Members "StandardUser01"

Préparer votre hôte de conteneur

Cas d’usage pour la préparation de l’hôte de conteneur pour un hôte de conteneur joint à un domaine

Chaque hôte de conteneur qui exécutera un conteneur Windows avec un compte gMSA doit être joint à un domaine et avoir accès pour récupérer le mot de passe gMSA.

Joignez votre ordinateur à votre domaine Active Directory.
Vérifiez que votre hôte appartient au groupe de sécurité qui contrôle l’accès au mot de passe gMSA.
Redémarrez l’ordinateur pour mettre à jour sa nouvelle appartenance au groupe.
Configurez Docker Desktop pour Windows 10 ou Docker pour Windows Server.

(Recommandé) Vérifiez que l’hôte peut utiliser le compte gMSA en exécutant Test-ADServiceAccount. Si la commande retourne false, suivez les instructions de résolution des problèmes .

# To install the AD module on Windows Server, run Install-WindowsFeature RSAT-AD-PowerShell
# To install the AD module on Windows 10 version 1809 or later, run Add-WindowsCapability -Online -Name 'Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0'
# To install the AD module on older versions of Windows 10, see https://aka.ms/rsat

Test-ADServiceAccount WebApp01

Cas d’usage pour la préparation de l’hôte de conteneur pour un hôte de conteneur non joint à un domaine

Lorsque vous utilisez gMSA pour les conteneurs Windows sur des hôtes de conteneur non joints à un domaine, chaque hôte de conteneur doit disposer d’un plug-in pour ccg.exe installé qui sera utilisé pour récupérer le compte d’utilisateur portable et les informations d’identification spécifiés à l’étape précédente. Les plug-ins sont uniques au magasin de secrets utilisé pour protéger les informations d’identification du compte d’utilisateur portable. Par exemple, différents plug-ins seraient nécessaires pour stocker les informations d’identification de compte dans Azure Key Vault et dans un magasin de secrets Kubernetes.

Windows n’offre actuellement pas de plug-in intégré et par défaut. Les instructions d’installation pour les plug-ins seront spécifiques à l’implémentation. Pour plus d’informations sur la création et l’inscription de plug-ins pour ccg.exe, consultez interface ICcgDomainAuthCredentials.

Créer une spécification d’informations d’identification

Un fichier de spécifications d’informations d’identification est un document JSON qui contient des métadonnées sur le ou les comptes gMSA que vous souhaitez utiliser pour un conteneur. En conservant la configuration d’identité distincte de l’image conteneur, vous pouvez modifier le gMSA que le conteneur utilise en échangeant simplement le fichier de spécifications d’informations d’identification, aucune modification du code n’est nécessaire.

Le fichier de spécifications d’informations d’identification est créé à l’aide du module PowerShell credentialSpec sur une machine jointe à un domaine. Une fois que vous avez créé le fichier, vous pouvez le copier vers d’autres hôtes de conteneur ou dans votre orchestrateur de conteneur. Le fichier de spécifications d’informations d’identification ne contient aucun secret, tel que le mot de passe gMSA, car l’hôte du conteneur récupère le gMSA pour le compte du conteneur.

Docker s’attend à trouver le fichier de spécifications d’informations d’identification sous le répertoire CredentialSpecs dans le répertoire de données Docker. Dans une installation par défaut, vous trouverez ce dossier à C:\ProgramData\Docker\CredentialSpecs.

Pour créer un fichier de spécifications d’informations d’identification sur votre hôte de conteneur :

Installer les outils PowerShell RSAT AD
- Pour Windows Server, exécutez Install-WindowsFeature RSAT-AD-PowerShell.
- Pour Windows 10, version 1809 ou ultérieure, exécutez Add-WindowsCapability -Online -Name ' Rsat.ActiveDirectory.DS-LDS.Tools~~~0.0.1.0'.
- Pour les versions antérieures de Windows 10, consultez https://aka.ms/rsat.
Exécutez l’applet de commande suivante pour installer la dernière version du module PowerShell CredentialSpec :
```
Install-Module CredentialSpec
```
Si vous n’avez pas accès à Internet sur votre hôte de conteneur, exécutez Save-Module CredentialSpec sur un ordinateur connecté à Internet et copiez le dossier du module vers C:\Program Files\WindowsPowerShell\Modules ou vers un autre emplacement dans $env:PSModulePath sur l’hôte de conteneur.
Exécutez l’applet de commande suivante pour créer le fichier de spécifications d’informations d’identification :
```
# Replace 'WebApp01' with your own gMSA
New-CredentialSpec -AccountName WebApp01
```
Par défaut, l’applet de commande crée une spécification d’informations d’identification à l’aide du nom gMSA fourni en tant que compte d’ordinateur pour le conteneur. Le fichier sera enregistré dans le répertoire Docker CredentialSpecs à l’aide du domaine gMSA et du nom de compte du nom de fichier.

Si vous souhaitez enregistrer le fichier dans un autre répertoire, utilisez le paramètre -Path :
```
New-CredentialSpec -AccountName WebApp01 -Path "C:\MyFolder\WebApp01_CredSpec.json"
```
Vous pouvez également créer une spécification d’informations d’identification qui inclut des comptes gMSA supplémentaires si vous exécutez un service ou un processus en tant que gMSA secondaire dans le conteneur. Pour ce faire, utilisez le paramètre -AdditionalAccounts :
```
New-CredentialSpec -AccountName WebApp01 -AdditionalAccounts LogAgentSvc, OtherSvc
```
Pour obtenir la liste complète des paramètres pris en charge, exécutez Get-Help New-CredentialSpec -Full.
Vous pouvez afficher une liste de toutes les spécifications d'identification et leur chemin d’accès complet avec l’applet de commande suivante :
```
Get-CredentialSpec
```

Voici un exemple de spécification de justificatifs :

{
    "CmsPlugins": [
        "ActiveDirectory"
    ],
    "DomainJoinConfig": {
        "Sid": "S-1-5-21-702590844-1001920913-2680819671",
        "MachineAccountName": "webapp01",
        "Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
        "DnsTreeName": "contoso.com",
        "DnsName": "contoso.com",
        "NetBiosName": "CONTOSO"
    },
    "ActiveDirectoryConfig": {
        "GroupManagedServiceAccounts": [
            {
                "Name": "webapp01",
                "Scope": "contoso.com"
            },
            {
                "Name": "webapp01",
                "Scope": "CONTOSO"
            }
        ]
    }
}

Configuration supplémentaire des spécifications d’informations d’identification pour le cas d’usage de l’hôte de conteneur non joint à un domaine

Lorsque vous utilisez gMSA avec des hôtes de conteneur non joints à un domaine, des informations sur le plug-in ccg.exe que vous utiliserez doivent être ajoutées à la spécification des informations d’identification. Cette opération est ajoutée à une section de la spécification d’informations d’identification appelée HostAccountConfig. La section HostAccountConfig comporte trois champs qui doivent être renseignés :

PortableCcgVersion: cette valeur doit être définie sur « 1 ».
Plug-inGUID : le CLSID COM pour le plug-in ccg.exe. Ceci est propre au plug-in utilisé.
PluginInput : entrée spécifique au plug-in pour récupérer les informations du compte utilisateur depuis le magasin de secrets.

Voici un exemple de spécification d’informations d’identification avec la section HostAccountConfig ajoutée :

{
    "CmsPlugins": [
        "ActiveDirectory"
    ],
    "DomainJoinConfig": {
        "Sid": "S-1-5-21-702590844-1001920913-2680819671",
        "MachineAccountName": "webapp01",
        "Guid": "56d9b66c-d746-4f87-bd26-26760cfdca2e",
        "DnsTreeName": "contoso.com",
        "DnsName": "contoso.com",
        "NetBiosName": "CONTOSO"
    },
    "ActiveDirectoryConfig": {
        "GroupManagedServiceAccounts": [
            {
                "Name": "webapp01",
                "Scope": "contoso.com"
            },
            {
                "Name": "webapp01",
                "Scope": "CONTOSO"
            }
        ],
        "HostAccountConfig": {
            "PortableCcgVersion": "1",
            "PluginGUID": "{GDMA0342-266A-4D1P-831J-20990E82944F}",
            "PluginInput": "contoso.com:gmsaccg:<password>"
        }
    }
}

Étapes suivantes

Maintenant que vous avez configuré votre compte gMSA, vous pouvez l’utiliser pour :

Si vous rencontrez des problèmes lors de l’installation, consultez notre guide de résolution des problèmes pour connaître les solutions possibles.

Ressources additionnelles

Pour en savoir plus sur les gMSA, consultez la Vue d’ensemble des comptes de service administrés de groupe .

Partager via