Partager via

Résoudre les problèmes liés aux gMSA pour les conteneurs Windows

  • Article

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

Problèmes connus

Le nom d’hôte du conteneur doit correspondre au nom gMSA pour Windows Server 2016 et Windows 10, versions 1709 et 1803

Si vous exécutez Windows Server 2016, version 1709 ou 1803, le nom d’hôte de votre conteneur doit correspondre au nom de votre compte SAM gMSA.

Lorsque le nom d’hôte ne correspond pas au nom gMSA, les demandes d’authentification NTLM entrantes et la traduction nom/SID (utilisée par de nombreuses bibliothèques, comme le fournisseur de rôle d’appartenance ASP.NET) échouent. Kerberos continuera à fonctionner normalement même si le nom d’hôte et le nom gMSA ne correspondent pas.

Cette limitation a été corrigée dans Windows Server 2019, où le conteneur utilisera désormais toujours son nom gMSA sur le réseau, quel que soit le nom d’hôte attribué.

Vous ne pouvez pas utiliser des gMSA avec les conteneurs isolés Hyper-V sur les versions Windows 10 1703, 1709 et 1803.

L’initialisation de conteneur se bloque ou échoue lorsque vous essayez d’utiliser un compte gMSA avec un conteneur isolé Hyper-V sur Windows 10 et Windows Server versions 1703, 1709 et 1803.

Ce bogue a été résolu dans Windows Server 2019 et Windows 10, version 1809. Vous pouvez également exécuter Hyper-V conteneurs isolés avec des gMSA sur Windows Server 2016 et Windows 10, version 1607.

Instructions générales pour la résolution des problèmes

Si vous rencontrez des erreurs lors de l’exécution d’un conteneur avec un compte gMSA, les instructions suivantes pourraient vous aider à identifier la cause sous-jacente.

Hôtes joints à un domaine : assurez-vous que l’hôte peut utiliser le gMSA

  1. Vérifiez que l’hôte est joint à un domaine et qu’il peut atteindre le contrôleur de domaine.

  2. Installez les outils AD PowerShell depuis RSAT et exécutez Test-ADServiceAccount pour voir si l’ordinateur a accès à récupérer le gMSA. Si l’applet de commande retourne False, l’ordinateur n’a pas accès au mot de passe gMSA.

    # 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

  3. Si Test-ADServiceAccount retourne faux, vérifiez que l’hôte appartient à un groupe de sécurité qui peut accéder au mot de passe gMSA.

    # Get the current computer's group membership
Get-ADComputer $env:computername | Get-ADPrincipalGroupMembership | Select-Object DistinguishedName

# Get the groups allowed to retrieve the gMSA password
# Change "WebApp01" for your own gMSA name
(Get-ADServiceAccount WebApp01 -Properties PrincipalsAllowedToRetrieveManagedPassword).PrincipalsAllowedToRetrieveManagedPassword

  4. Si votre hôte appartient à un groupe de sécurité autorisé à récupérer le mot de passe gMSA mais échoue toujours Test-ADServiceAccount, vous devrez peut-être redémarrer votre ordinateur pour obtenir un nouveau ticket reflétant ses appartenances de groupe actuelles.

Hôtes non joints à un domaine : vérifiez que l’hôte est configuré pour récupérer le compte gMSA

Vérifiez qu’un plug-in pour l’utilisation de gMSA avec un hôte de conteneur non joint à un domaine est correctement installé sur l’hôte. Windows n’inclut pas de plug-in intégré et vous oblige à fournir un plug-in qui implémente l’interface ICcgDomainAuthCredentials. Les détails de l’installation seront spécifiques au plug-in.

Vérifier le fichier de spécifications d'identifiants

  1. Exécutez Get-CredentialSpec à partir du module PowerShell CredentialSpec pour localiser toutes les spécifications d’informations d’identification sur l’ordinateur. Les spécifications d’informations d’identification doivent être stockées dans le répertoire « CredentialSpecs » sous le répertoire racine Docker. Vous trouverez le répertoire racine Docker en exécutant informations Docker -f « {{. DockerRootDir}} ".

  2. Ouvrez le fichier CredentialSpec et vérifiez que les champs suivants sont renseignés correctement :

    1. Pour les hôtes de conteneur joints à un domaine :

      • Sid: SID de votre domaine
      • MachineAccountName: nom du compte SAM gMSA (n’incluez pas de nom de domaine complet ou de signe dollar)
      • DnsTreeName : nom de domaine complet de votre forêt Active Directory
      • dnsName: nom de domaine complet du domaine auquel appartient gMSA
      • NetBiosName: nom NETBIOS du domaine auquel appartient gMSA
      • GroupManagedServiceAccounts/Name: nom de compte SAM gMSA (n’incluez pas de nom de domaine complet ou de signe dollar)
      • GroupManagedServiceAccounts/Scope : une entrée pour le FQDN du domaine et une pour NETBIOS

      Votre entrée doit ressembler à l’exemple suivant d’une spécification d’informations d’identification complète :

      {
    "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"
            }
        ]
    }
}

    2. Pour les hôtes non joints à un domaine : En plus de tous les champs d’hôte de conteneur non joints à un domaine, vérifiez que la section « HostAccountConfig » est présente et que les champs ci-dessous sont définis correctement.

      • PortableCcgVersion: cette valeur doit être définie sur « 1 ».
      • PluginGUID : le CLSID COM pour votre 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.

      Votre entrée doit ressembler à l’exemple suivant d’une spécification d’informations d’identification complète :

      {
    "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>"
        }
    }
}

  3. Vérifiez que le chemin d’accès au fichier de spécifications des identifiants est correct pour votre solution d’orchestration. Si vous utilisez Docker, vérifiez que la commande d’exécution du conteneur inclut --security-opt="credentialspec=file://NAME.json", où «NAME.json» est remplacé par la sortie du nom par Get-CredentialSpec. Le nom est un nom de fichier plat, par rapport au dossier CredentialSpecs sous le répertoire racine Docker.

Vérifier la configuration réseau

Vérifier la configuration du pare-feu

Si vous utilisez une stratégie de pare-feu stricte sur le conteneur ou le réseau hôte, il peut bloquer les connexions requises au contrôleur de domaine Active Directory ou au serveur DNS.

Protocole et port Objectif
TCP et UDP 53 DNS
TCP et UDP 88 Kerberos
TCP 139 NetLogon
TCP et UDP 389 LDAP
TCP 636 LDAP SSL

Vous devrez peut-être autoriser l’accès à des ports supplémentaires en fonction du type de trafic envoyé par votre conteneur à un contrôleur de domaine. Consultez les exigences relatives aux ports Active Directory et Active Directory Domain Services pour une liste complète des ports utilisés par Active Directory.

Vérifier la configuration DNS de l’hôte de conteneur

Si vous utilisez gMSA avec un hôte de conteneur joint à un domaine, DNS doit être configuré automatiquement sur l’hôte afin qu’il puisse résoudre correctement et établir une connexion au domaine. Si vous utilisez gMSA avec un hôte non joint à un domaine, cette configuration ne sera pas automatiquement définie. Vous devez vérifier que le réseau hôte est configuré afin qu’il puisse résoudre le domaine. Vous pouvez vérifier que le domaine peut être résolu à partir de l’hôte à l’aide de :

nltest /sc_verify:contoso.com

Vérifier le conteneur

  1. Si vous exécutez une version de Windows antérieure à Windows Server 2019 ou Windows 10, version 1809, votre nom d’hôte de conteneur doit correspondre au nom gMSA. Vérifiez que le paramètre --hostname correspond au nom court gMSA (aucun composant de domaine ; par exemple, « webapp01 » au lieu de « webapp01.contoso.com »).

  2. Vérifiez la configuration de mise en réseau du conteneur pour vérifier que le conteneur peut résoudre et accéder à un contrôleur de domaine pour le domaine de gMSA. Les serveurs DNS mal configurés dans le conteneur sont un coupable commun des problèmes d’identité.

  3. Vérifiez si le conteneur a une connexion valide au domaine en exécutant l’applet de commande suivante dans le conteneur (à l’aide de docker exec ou d’un équivalent) :

    nltest /sc_verify:contoso.com

    La vérification d’approbation doit retourner NERR_SUCCESS si le gMSA est disponible et que la connectivité réseau permet au conteneur de communiquer avec le domaine. En cas d’échec, vérifiez la configuration réseau de l’hôte et du conteneur. Les deux doivent être en mesure de communiquer avec le contrôleur de domaine.

  4. Vérifiez si le conteneur peut obtenir un ticket d’octroi de ticket Kerberos valide (TGT) :

    klist get <myapp>

    Cette commande doit renvoyer « Un ticket à krbtgt a été récupéré avec succès » et répertorier le contrôleur de domaine utilisé pour récupérer le ticket. Si vous êtes en mesure d’obtenir un TGT mais que nltest de l’étape précédente échoue, cela peut indiquer que le compte gMSA est mal configuré. Pour plus d'informations, consultez et vérifiez le compte gMSA.

    Si vous ne pouvez pas obtenir un TGT à l’intérieur du conteneur, cela peut indiquer des problèmes de connectivité DNS ou réseau. Vérifiez que le conteneur peut résoudre un contrôleur de domaine à l’aide du nom DNS de domaine et que le contrôleur de domaine est routable à partir du conteneur.

  5. Vérifiez que votre application est configurée pour utiliser le gMSA. Le compte d’utilisateur à l’intérieur du conteneur ne change pas lorsque vous utilisez un compte gMSA. Au lieu de cela, le compte système utilise le compte gMSA lorsqu’il communique avec d’autres ressources réseau. Cela signifie que votre application doit s’exécuter en tant que service réseau ou système local pour tirer parti de l’identité gMSA.

    Conseil / Astuce

    Si vous exécutez whoami ou utilisez un autre outil pour identifier votre contexte utilisateur actuel dans le conteneur, vous ne verrez pas le nom gMSA lui-même. Cela est dû au fait que vous vous connectez toujours au conteneur en tant qu’utilisateur local au lieu d’une identité de domaine. Le compte gMSA est utilisé par le compte d’ordinateur chaque fois qu’il communique avec les ressources réseau, c’est pourquoi votre application doit s’exécuter en tant que service réseau ou système local.

Vérifier le compte gMSA

  1. Si votre conteneur semble être configuré correctement, mais que les utilisateurs ou d'autres services ne peuvent pas s'authentifier automatiquement auprès de votre application conteneurisée, vérifiez les SPN sur votre compte gMSA. Les clients localisent le compte gMSA par le nom sous lequel ils accèdent à votre application. Cela peut signifier que vous aurez besoin de SPN host supplémentaires pour votre compte gMSA si, par exemple, les clients se connectent à votre application via un équilibreur de charge ou un autre nom DNS.

  2. Pour utiliser gMSA avec un hôte de conteneur joint à un domaine, vérifiez que l’hôte gMSA et l’hôte de conteneur appartiennent au même domaine Active Directory. L’hôte de conteneur ne pourra pas récupérer le mot de passe gMSA si le gMSA appartient à un autre domaine.

  3. Vérifiez qu’il n’existe qu’un seul compte dans votre domaine portant le même nom que votre compte gMSA. Les objets gMSA ont des signes de dollar ($) ajoutés à leurs noms de compte SAM. Il est donc possible qu’un gMSA soit nommé « myaccount$ » et qu’un compte d’utilisateur non lié soit nommé « myaccount » dans le même domaine. Cela peut entraîner des problèmes si le contrôleur de domaine ou l’application doit rechercher le gMSA par nom. Vous pouvez rechercher des objets nommés de la même façon dans AD avec la commande suivante :

    # Replace "GMSANAMEHERE" with your gMSA account name (no trailing dollar sign)
Get-ADObject -Filter 'sAMAccountName -like "GMSANAMEHERE*"'

  4. Si vous avez activé la délégation non contrainte sur le compte gMSA, vérifiez que l’attribut UserAccountControl a toujours activé l’indicateur WORKSTATION_TRUST_ACCOUNT. Cet indicateur est requis pour que NETLOGON dans le conteneur communique avec le contrôleur de domaine, comme c’est le cas lorsqu’une application doit résoudre un nom en SID ou inversement. Vous pouvez vérifier si l’indicateur est configuré correctement avec les commandes suivantes :

    $gMSA = Get-ADServiceAccount -Identity 'yourGmsaName' -Properties UserAccountControl
($gMSA.UserAccountControl -band 0x1000) -eq 0x1000

    Si les commandes ci-dessus retournent False, utilisez ce qui suit pour ajouter l’indicateur WORKSTATION_TRUST_ACCOUNT à la propriété UserAccountControl du compte gMSA. Cette commande efface également les indicateurs NORMAL_ACCOUNT, INTERDOMAIN_TRUST_ACCOUNTet SERVER_TRUST_ACCOUNT de la propriété UserAccountControl.

    Set-ADObject -Identity $gMSA -Replace @{ userAccountControl = ($gmsa.userAccountControl -band 0x7FFFC5FF) -bor 0x1000 }

Hôtes de conteneur non joints à un domaine : utilisez les journaux des événements pour identifier les problèmes de configuration

La journalisation des événements pour l’utilisation de gMSA avec des hôtes de conteneur non joints à un domaine peut être utilisée pour identifier les problèmes de configuration. Les événements sont enregistrés dans le fichier journal Microsoft-Windows-Containers-CCG et se trouvent dans l’Observateur d’événements sous Applications and Services Logs\Microsoft\Windows\Containers-GCC\Admin. Si vous exportez ce fichier journal à partir de l’hôte de conteneur pour le lire, vous devez activer la fonctionnalité conteneurs sur l’appareil sur lequel vous essayez de lire le fichier journal et vous devez être sur une version Windows prenant en charge l’utilisation de gMSA avec des hôtes de conteneur non joints à un domaine.

Événements et descriptions

Numéro d’événement Texte de l’événement Description
1 Container Credential Guard a instancié le plugin Cet événement indique que le plug-in spécifié dans la 'Credential Spec' a été installé et a pu être chargé. Aucune action n’est nécessaire.
2 Container Credential Guard a récupéré les informations d’identification gmsa pour %1 à l’aide du plug-in : %2 Il s’agit d’un événement d’information indiquant que les identifiants gMSA ont été récupérés avec succès à partir de l'Active Directory. Aucune action n’est nécessaire.
3 Container Credential Guard n’a pas pu analyser la spécification des informations d’identification. Erreur : %1 Cet événement indique un problème avec la spécification des informations d’identification. Cela peut se produire si le GUID du plug-in est incorrect ou s’il existe d’autres champs mal formés. Consultez guide de résolution des problèmes pour la spécification des informations d’identification pour vérifier la mise en forme et le contenu de la spécification des informations d’identification.
4 Container Credential Guard n’a pas pu instancier le plug-in : %1. Erreur : %2 Cet événement indique que le plug-in n’a pas pu être chargé. Vous devez vérifier que le plug-in a été installé correctement sur l’hôte
6 Container Credential Guard n’a pas pu extraire les informations d’identification du plug-in : %1. Erreur : %2 Cet événement indique que le plug-in chargé mais n’a pas pu récupérer les informations d’identification nécessaires pour récupérer le mot de passe gMSA à partir d’AD. Vous devez vérifier que l’entrée du plug-in est correctement mise en forme dans la spécification des informations d’identification et que l’hôte du conteneur dispose des autorisations nécessaires pour accéder au magasin de secrets utilisé par le plug-in.
7 Container Credential Guard est en train de récupérer à nouveau les informations d’identification à l’aide du plug-in : %1 Il s'agit d'un événement d'information. Cet événement est généré lorsque le mot de passe gMSA a expiré et doit être actualisé à l’aide des informations d’identification extraites par le plug-in.
8 Container Credential Guard n’a pas pu récupérer les informations d’identification gmsa pour %1 à l’aide du plug-in %2. Raison de l’erreur : %3 Cet événement indique que les informations d’identification extraites à l’aide du plug-in n’ont pas pu être utilisées pour extraire les informations d’identification gMSA à partir d’AD. Vous devez vérifier que le compte récupéré à partir du plug-in dispose d’autorisations dans AD pour récupérer les informations d’identification gMSA.