Problembehandlung bei gMSAs für Windows-Container

Artikel
02/06/2025

Gilt für: Windows Server 2025, Windows Server 2022, Windows Server 2019

Bekannte Probleme

Containerhostname muss mit dem gMSA-Namen für Windows Server 2016 und Windows 10, Version 1709 und 1803 übereinstimmen

Wenn Sie Windows Server 2016, Version 1709 oder 1803, ausführen, muss der Hostname Ihres Containers ihrem gMSA SAM-Kontonamen entsprechen.

Wenn der Hostname nicht mit dem gMSA-Namen übereinstimmt, schlagen eingehende NTLM-Authentifizierungsanforderungen und die Namens-/SID-Übersetzung (die von vielen Bibliotheken verwendet wird, wie der ASP.NET Mitgliedschaftsrollenanbieter) fehl. Kerberos funktioniert weiterhin normal, auch wenn der Hostname und der gMSA-Name nicht übereinstimmen.

Diese Einschränkung wurde in Windows Server 2019 behoben, bei der der Container nun unabhängig vom zugewiesenen Hostnamen immer den gMSA-Namen im Netzwerk verwendet.

Die Gleichzeitige Verwendung eines gMSA mit mehreren Containern führt zu zeitweiligen Fehlern unter Windows Server 2016 und Windows 10, Version 1709 und 1803

Da alle Container denselben Hostnamen verwenden müssen, wirkt sich ein zweites Problem auf Windows-Versionen vor Windows Server 2019 und Windows 10, Version 1809, aus. Wenn mehreren Containern dieselbe Identität und derselbe Hostname zugewiesen werden, kann eine Race-Condition auftreten, wenn zwei Container gleichzeitig mit demselben Domänencontroller kommunizieren. Wenn ein anderer Container mit demselben Domänencontroller kommuniziert, wird die Kommunikation mit allen vorherigen Containern mit derselben Identität abgebrochen. Dies kann zu zeitweiligen Authentifizierungsfehlern führen und kann manchmal als Vertrauensfehler beobachtet werden, wenn Sie nltest /sc_verify:contoso.com innerhalb des Containers ausführen.

Wir haben das Verhalten in Windows Server 2019 geändert, um die Containeridentität vom Computernamen zu trennen, sodass mehrere Container dieselbe gMSA gleichzeitig verwenden können. Daher können Sie in Windows Server 2019 mehrere Container mit derselben Identität ausführen, unabhängig davon, ob auf demselben oder mehreren Hosts.

Sie können gMSAs nicht mit isolierten Hyper-V-Containern unter Windows 10, Versionen 1703, 1709 und 1803, verwenden.

Die Containerinitialisierung hängt oder schlägt fehl, wenn Sie versuchen, einen gMSA mit einem Hyper-V isolierten Container unter Windows 10 und Windows Server, Versionen 1703, 1709 und 1803 zu verwenden.

Dieser Fehler wurde in Windows Server 2019 und Windows 10, Version 1809, behoben. Sie können auch isolierte Hyper-V-Container mit gMSAs unter Windows Server 2016 und Windows 10, Version 1607, ausführen.

Allgemeine Anleitung zur Problembehandlung

Wenn beim Ausführen eines Containers mit einem gMSA Fehler auftreten, können Sie anhand der folgenden Anweisungen die Ursache ermitteln.

In die Domäne eingebundene Hosts: Stellen Sie sicher, dass der Host die gMSA verwenden kann

Überprüfen Sie, ob der Host einer Domäne beigetreten ist und den Domänencontroller erreichen kann.

Installieren Sie die AD PowerShell-Tools aus RSAT, und führen Sie Test-ADServiceAccount aus, um festzustellen, ob der Computer Zugriff auf das Abrufen der gMSA hat. Wenn das Cmdlet Falsezurückgibt, hat der Computer keinen Zugriff auf das gMSA-Kennwort.

# 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

Wenn Test-ADServiceAccountFalsezurückgibt, überprüfen Sie, ob der Host zu einer Sicherheitsgruppe gehört, die auf das gMSA-Kennwort zugreifen kann.

# 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

Wenn Ihr Host zu einer Sicherheitsgruppe gehört, die berechtigt ist, das gMSA-Kennwort abzurufen, aber bei Test-ADServiceAccount weiterhin ein Fehler auftritt, müssen Sie möglicherweise Ihren Computer neu starten, um ein neues Ticket zu erhalten, das die aktuelle Gruppenmitgliedschaft widerspiegelt.

Nicht domänenverbundene Hosts: Stellen Sie sicher, dass der Host zum Abrufen des gMSA-Kontos konfiguriert ist.

Stellen Sie sicher, dass ein Plug-In für die Verwendung von gMSA mit einem Containerhost, der nicht in die Domäne eingebunden ist, ordnungsgemäß auf dem Host installiert ist. Windows enthält kein integriertes Plug-In und erfordert, dass Sie ein Plug-In bereitstellen, das die ICcgDomainAuthCredentials-Schnittstelleimplementiert. Installationsdetails sind plug-insspezifisch.

Überprüfen der Datei für die Spezifikation der Anmeldeinformationen

Führen Sie Get-CredentialSpec des PowerShell-Moduls „CredentialSpec“ aus, um alle Spezifikationen der Anmeldeinformationen auf dem Computer zu ermitteln. Die Anmeldeinformationsspezifikationen müssen im Verzeichnis "CredentialSpecs" unter dem Docker-Stammverzeichnis gespeichert werden. Sie finden das Docker-Stammverzeichnis, indem Sie docker info -f "{{.DockerRootDir}}"ausführen.

Öffnen Sie die Datei "CredentialSpec", und stellen Sie sicher, dass die folgenden Felder richtig ausgefüllt sind:

Für in die Domäne eingebundene Container-Hosts:
- Sid: die SID Ihrer Domäne
- MachineAccountName: der gMSA SAM-Kontoname (geben Sie keinen vollständigen Domänennamen oder Dollarzeichen an)
- DnsTreeName: der FQDN Ihrer Active Directory-Gesamtstruktur
- DnsName-: der FQDN der Domäne, zu der die gMSA gehört
- NetBiosName: NETBIOS-Name für die Domäne, zu der die gMSA gehört
- GroupManagedServiceAccounts/Name: der gMSA SAM-Kontoname (nicht den vollständigen Domänennamen oder das Dollarzeichen enthalten)
- GroupManagedServiceAccounts/Scope: ein Eintrag für den Domänen-FQDN und ein Eintrag für NETBIOS
Ihre Eingabe sollte wie das folgende Beispiel einer vollständigen Spezifikation für die Anmeldeinformationen aussehen:
```
{
    "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"
            }
        ]
    }
}
```

Für nicht domänenverbundene Hosts: Stellen Sie zusätzlich zu allen Nicht-domänenverbundenen Containerhostfeldern sicher, dass der Abschnitt "HostAccountConfig" vorhanden ist und die folgenden Felder ordnungsgemäß definiert sind.

PortableCcgVersion: Dies sollte auf "1" festgelegt werden.
PluginGUID: Die COM-CLSID für Ihr ccg.exe-Plug-In. Dies ist einzigartig für das verwendete Plug-In.
PluginInput: Plug-In-spezifische Eingabe zum Abrufen der Benutzerkontoinformationen aus dem Geheimnisspeicher.

Ihre Eingabe sollte wie im folgenden Beispiel einer vollständigen Anmeldedaten-Spezifikation aussehen.

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

Überprüfen Sie, ob der Pfad zur Spezifikationsdatei für die Anmeldeinformationen für Ihre Orchestrierungslösung richtig ist. Wenn Sie Docker verwenden, stellen Sie sicher, dass der Containerausführungsbefehl --security-opt="credentialspec=file://NAME.json"enthält, wobei "NAME.json" durch die Namensausgabe durch Get-CredentialSpecersetzt wird. Der Name ist ein flacher Dateiname, relativ zum Ordner "CredentialSpecs" unter dem Docker-Stammverzeichnis.

Überprüfen der Netzwerkkonfiguration

Überprüfen der Firewallkonfiguration

Wenn Sie eine strenge Firewallrichtlinie für den Container oder das Hostnetzwerk verwenden, kann dies erforderliche Verbindungen mit dem Active Directory-Domänencontroller oder DNS-Server blockieren.

Protokoll und Port	Zweck
TCP und UDP 53	DNS
TCP und UDP 88	Kerberos
TCP 139	NetLogon
TCP und UDP 389	LDAP
TCP 636	LDAP SSL

Möglicherweise müssen Sie den Zugriff auf zusätzliche Ports zulassen, abhängig vom Typ des Datenverkehrs, den Ihr Container an einen Domänencontroller sendet. Eine vollständige Liste der von Active Directory verwendeten Ports finden Sie unter Active Directory- und Active Directory Domain Services-Portanforderungen.

Überprüfen der DNS-Konfiguration des Containerhosts

Wenn Sie gMSA mit einem Containerhost in einer Domäne verwenden, sollte DNS automatisch auf dem Host konfiguriert werden, damit es ordnungsgemäß auflösen und eine Verbindung mit der Domäne herstellen kann. Wenn Sie gMSA mit einem nicht in die Domäne eingebundenen Host verwenden, wird diese Konfiguration nicht automatisch festgelegt. Überprüfen Sie, ob das Hostnetzwerk konfiguriert ist, damit es die Domäne auflösen kann. Sie können überprüfen, ob die Domäne vom Host aufgelöst werden kann, indem Sie Folgendes verwenden:

nltest /sc_verify:contoso.com

Überprüfen des Containers

Wenn Sie eine Version von Windows vor Windows Server 2019 oder Windows 10, Version 1809, ausführen, muss Ihr Containerhostname mit dem gMSA-Namen übereinstimmen. Stellen Sie sicher, dass der --hostname-Parameter dem gMSA-Kurznamen entspricht (keine Domänenkomponente; z. B. "webapp01" anstelle von "webapp01.contoso.com").
Überprüfen Sie die Containernetzwerkkonfiguration, um sicherzustellen, dass der Container den Domänencontroller der gMSA-Domäne auflösen und darauf zugreifen kann. Falsch konfigurierte DNS-Server im Container sind eine häufige Ursache von Identitätsproblemen.
Überprüfen Sie, ob der Container über eine gültige Verbindung mit der Domäne verfügt, indem Sie das folgende Cmdlet im Container ausführen (mit docker exec oder einer entsprechung):
```
nltest /sc_verify:contoso.com
```
Die Vertrauensüberprüfung sollte NERR_SUCCESS zurückgeben, wenn die gMSA verfügbar ist und die Netzwerkkonnektivität dem Container ermöglicht, mit der Domäne zu sprechen. Wenn ein Fehler auftritt, überprüfen Sie die Netzwerkkonfiguration des Hosts und Containers. Beide müssen mit dem Domänencontroller kommunizieren können.
Überprüfen Sie, ob der Container ein gültiges Kerberos-Ticketgewährungsticket (TGT) abrufen kann:
```
klist get <myapp>
```
Dieser Befehl sollte "Ein Ticket für krbtgt wurde erfolgreich abgerufen" zurückgeben und den Domänencontroller auflisten, der zum Abrufen des Tickets verwendet wurde. Wenn Sie ein TGT abrufen können, aber nltest aus dem vorherigen Schritt fehlschlägt, kann dies ein Hinweis darauf sein, dass das gMSA-Konto falsch konfiguriert ist. Siehe , überprüfen Sie das gMSA-Konto für weitere Informationen.

Wenn Sie keine TGT innerhalb des Containers abrufen können, kann dies auf DNS- oder Netzwerkkonnektivitätsprobleme hinweisen. Stellen Sie sicher, dass der Container einen Domänencontroller mithilfe des Domänen-DNS-Namens auflösen kann und dass der Domänencontroller vom Container routingfähig ist.
Stellen Sie sicher, dass Ihre App für die Verwendung des gMSA konfiguriert ist. Das Benutzerkonto im Container ändert sich nicht, wenn Sie eine gMSA verwenden. Vielmehr verwendet das Systemkonto die gMSA, wenn es mit anderen Netzwerkressourcen kommuniziert. Dies bedeutet, dass Ihre App als Netzwerkdienst oder lokales System ausgeführt werden muss, um die gMSA-Identität zu nutzen.

Tipp

Wenn Sie whoami ausführen oder ein anderes Tool verwenden, um Ihren aktuellen Benutzerkontext im Container zu identifizieren, wird der gMSA-Name selbst nicht angezeigt. Dies liegt daran, dass Sie sich immer als lokaler Benutzer anstelle einer Domänenidentität beim Container anmelden. Die gMSA wird vom Computerkonto verwendet, wenn sie mit Netzwerkressourcen spricht. Deshalb muss Ihre App als Netzwerkdienst oder lokales System ausgeführt werden.

Überprüfen des gMSA-Kontos

Wenn Ihr Container ordnungsgemäß konfiguriert zu sein scheint, aber Benutzende oder andere Dienste nicht in der Lage sind, sich automatisch bei Ihrer Container-App zu authentifizieren, überprüfen Sie die SPNs für Ihr gMSA-Konto. Clients finden das gMSA-Konto anhand des Namens, unter dem sie Ihre Anwendung erreichen. Dies kann bedeuten, dass Sie zusätzliche host SPNs für Ihre gMSA benötigen, wenn Clients beispielsweise über einen Lastenausgleich oder einen anderen DNS-Namen eine Verbindung mit Ihrer App herstellen.
Stellen Sie für die Verwendung von gMSA mit einem in eine Domäne eingebundenen Containerhost sicher, dass der gMSA- und Containerhost derselben Active Directory-Domäne angehören. Der Containerhost kann das gMSA-Kennwort nicht abrufen, wenn die gMSA zu einer anderen Domäne gehört.
Stellen Sie sicher, dass nur ein Konto in Ihrer Domäne mit demselben Namen wie Ihre gMSA vorhanden ist. gMSA-Objekte haben Dollarzeichen ($) an ihre SAM-Kontonamen angefügt, sodass es möglich ist, dass ein gMSA den Namen "myaccount$" und ein nicht verwandtes Benutzerkonto mit dem Namen "myaccount" in derselben Domäne hat. Dies kann zu Problemen führen, wenn der Domänencontroller oder die Anwendung die gMSA anhand des Namens nachschlagen muss. Sie können AD nach ähnlich benannten Objekten mit dem folgenden Befehl durchsuchen:
```
# Replace "GMSANAMEHERE" with your gMSA account name (no trailing dollar sign)
Get-ADObject -Filter 'sAMAccountName -like "GMSANAMEHERE*"'
```
Wenn Sie die nicht eingeschränkte Delegierung für das gMSA-Konto aktiviert haben, stellen Sie sicher, dass das attribut "UserAccountControl" weiterhin das WORKSTATION_TRUST_ACCOUNT Flag aktiviert hat. Dieses Flag ist für NETLOGON im Container erforderlich, um mit dem Domänencontroller zu kommunizieren, wie dies der Fall ist, wenn eine App einen Namen in eine SID auflösen muss oder umgekehrt. Sie können überprüfen, ob das Flag mit den folgenden Befehlen ordnungsgemäß konfiguriert ist:
```
$gMSA = Get-ADServiceAccount -Identity 'yourGmsaName' -Properties UserAccountControl
($gMSA.UserAccountControl -band 0x1000) -eq 0x1000
```
Wenn die obigen Befehle False zurückgeben, verwenden Sie folgenden Befehl, um der UserAccountControl-Eigenschaft des gMSA-Kontos das Flag WORKSTATION_TRUST_ACCOUNT hinzuzufügen. Mit diesem Befehl werden auch die NORMAL_ACCOUNT, INTERDOMAIN_TRUST_ACCOUNTund SERVER_TRUST_ACCOUNT Flags aus der UserAccountControl -Eigenschaft gelöscht.
```
Set-ADObject -Identity $gMSA -Replace @{ userAccountControl = ($gmsa.userAccountControl -band 0x7FFFC5FF) -bor 0x1000 }
```

Nicht in die Domäne eingebundene Containerhosts: Verwenden von Ereignisprotokollen zum Identifizieren von Konfigurationsproblemen

Die Ereignisprotokollierung für die Verwendung von gMSA mit nicht domänenverbundenen Containerhosts kann verwendet werden, um Konfigurationsprobleme zu identifizieren. Ereignisse werden in der Protokolldatei "Microsoft-Windows-Containers-CCG" protokolliert und finden Sie in der Ereignisanzeige unter "Anwendungs- und Dienstprotokolle\Microsoft\Windows\Containers-CCG\Admin". Wenn Sie diese Protokolldatei aus dem Containerhost exportieren, um sie zu lesen, müssen Sie das Containerfeature auf dem Gerät aktiviert haben, auf dem Sie versuchen, die Protokolldatei zu lesen, und Sie müssen sich in einer Windows-Version befinden, die die Verwendung von gMSA mit nicht domänenverbundenen Containerhosts unterstützt.

Ereignisse und Beschreibungen

Ereignisnummer	Ereignistext	Beschreibung
1	Container Credential Guard instanziierte das Plug-In	Dieses Ereignis gibt an, dass das in der Anmeldeinformationsspezifikation angegebene Plug-In installiert und geladen werden konnte. Es ist keine Aktion erforderlich.
2	Container Credential Guard hat gMSA-Anmeldeinformationen für %1 mithilfe des Plug-Ins abgerufen: %2	Dies ist ein Informationsereignis, das angibt, dass gMSA-Anmeldeinformationen erfolgreich aus AD abgerufen wurden. Es ist keine Aktion erforderlich.
3	Container Credential Guard konnte die Anmeldeinformationsspezifikation nicht analysieren. Fehler: %1	Dieses Ereignis weist auf ein Problem mit der Anmeldeinformationsspezifikation hin. Dies kann auftreten, wenn die GUID für das Plug-In falsch ist oder andere falsch formatierte Felder vorhanden sind. Lesen Sie die Anleitung zur Problembehandlung für die Spezifikation der Anmeldedaten, um die Formatierung und den Inhalt der Spezifikation zu überprüfen.
4	Container Credential Guard konnte das Plug-In nicht instanziieren: %1. Fehler: %2	Dieses Ereignis gibt an, dass das Plug-In nicht geladen werden konnte. Überprüfen Sie, ob das Plug-In korrekt auf dem Host installiert wurde.
6	Container Credential Guard konnte keine Anmeldeinformationen aus dem Plug-In abrufen: %1. Fehler: %2	Dieses Ereignis gibt an, dass das Plug-In geladen wurde, aber keine Anmeldeinformationen abrufen konnten, die zum Abrufen des gMSA-Kennworts von AD erforderlich sind. Sie sollten überprüfen, ob die Eingabe an das Plug-In in der Spezifikation der Anmeldeinformationen korrekt formatiert ist und dass der Containerhost über die erforderlichen Berechtigungen für den Zugriff auf den geheimen Speicher verfügt, der vom Plug-In verwendet wird.
7	Container Credential Guard ruft die Anmeldeinformationen mithilfe des Plug-Ins erneut ab: %1	Dies ist ein Informationsereignis. Dieses Ereignis wird generiert, wenn das gMSA-Kennwort abgelaufen ist und mithilfe der vom Plug-In abgerufenen Anmeldeinformationen aktualisiert werden muss.
8	Container Credential Guard konnte die GMSA-Anmeldeinformationen für %1 mithilfe des Plugins %2nicht abrufen. Fehlerursache: %3	Dieses Ereignis gibt an, dass die mit dem Plug-In abgerufenen Anmeldeinformationen nicht zum Abrufen von gMSA-Anmeldeinformationen aus AD verwendet werden konnten. Sie sollten überprüfen, ob das Konto, das aus dem Plug-In abgerufen wird, über Berechtigungen in AD verfügt, um die gMSA-Anmeldeinformationen abzurufen.

Freigeben über