Problembehandlung bei gMSAs für Windows-Container

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

Bekannte Probleme

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

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

Wenn der Hostname nicht mit dem gMSA-Namen übereinstimmt, treten bei eingehenden NTLM-Authentifizierungsanforderungen und bei der Name/SID-Übersetzung (die von vielen Bibliotheken, z. B. dem Anbieter von ASP.NET-Mitgliedschaftsrollen, verwendet wird) Fehler auf. Kerberos funktioniert weiterhin normal, auch wenn der Hostname und der gMSA-Name nicht übereinstimmen.

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

Die gleichzeitige Verwendung eines gMSA mit mehr als einem Container führt zu zeitweiligen Ausfällen unter Windows Server 2016 und Windows 10, Versionen 1709 und 1803.

Da alle Container denselben Hostnamen verwenden müssen, betrifft ein zweites Problem Versionen von Windows vor Windows Server 2019 und Windows 10, Version 1809. Wenn mehreren Containern dieselbe Identität und derselbe Hostname zugewiesen werden, kann eine Racebedingung auftreten, wenn zwei Container gleichzeitig mit demselben Domänencontroller kommunizieren. Wenn ein anderer Container mit demselben Domänencontroller kommuniziert, bricht er die Kommunikation mit allen vorherigen Containern mit derselben Identität ab. Dies kann zu zeitweiligen Authentifizierungsfehlern führen und gelegentlich 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 gleichzeitig dasselbe gMSA verwenden können. Daher können Sie in Windows Server 2019 mehrere Container mit derselben Identität ausführen, egal ob auf demselben oder auf mehreren Hosts.

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

Die Containerinitialisierung reagiert nicht mehr oder weist einen Fehler auf, wenn Sie versuchen, ein gMSA mit einem isolierten Hyper-V-Container unter Windows 10 und den 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.

Anleitung zur allgemeinen Problembehandlung

Wenn Sie bei der Ausführung eines Containers mit einem gMSA Fehler auftreten, können Ihnen die folgenden Anweisungen helfen, die Ursache zu ermitteln.

Hosts in einer Domäne: Stellen Sie sicher, dass der Host das gMSA verwenden kann

1. Überprüfen Sie, ob der Host mit der Domäne verknüpft ist und den Domänencontroller erreichen kann.

2. Installieren Sie die AD PowerShell-Tools von RSAT, und führen Sie Test-ADServiceAccount aus, um zu prüfen, ob der Computer über den Zugriff zum Abrufen des gMSAs verfügt. Wenn das Cmdlet False zurü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
   

3. Wenn Test-ADServiceAccount den Wert False zurü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
   

4. 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.

Hosts, die sich nicht in einer Domäne befinden: 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 nicht in die Domäne beigetretenen Containerhost ordnungsgemäß auf dem Host installiert ist. Windows enthält kein integriertes Plug-In und erfordert, dass Sie ein Plug-In bereitstellen, das die ICcgDomainAuthCredentials-Schnittstelle implementiert. Die Installationsdetails sind plug-in-spezifisch.

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

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

2. Öffnen Sie die CredentialSpec-Datei, und stellen Sie sicher, dass die folgenden Felder ordnungsgemäß ausgefüllt sind:

   1. Für Containerhosts in einer Domäne:

      • Sid: die SID Ihrer Domäne
      • MachineAccountName: Der gMSA SAM-Kontoname (enthält nicht den vollständigen Domänennamen oder das Dollarzeichen).
      • DnsTreeName: Der FQDN Ihrer Active Directory-Gesamtstruktur.
      • DnsName: Der FQDN der Domäne, zu der das gMSA gehört.
      • NetBiosName: NETBIOS-Name für die Domäne, zu der das gMSA gehört.
      • GroupManagedServiceAccounts/Name: Der gMSA SAM-Kontoname (enthält nicht den vollständigen Domänennamen oder das Dollarzeichen).
      • 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"
                  }
              ]
          }
      }
      

   2. Für Hosts, die sich nicht einer Domäne befinden: Stellen Sie zusätzlich zu allen nicht in einer Domäne eingebundenen Containerhostfeldern sicher, dass der Abschnitt „HostAccountConfig2 vorhanden ist und dass die folgenden Felder ordnungsgemäß definiert sind.

      • PortableCcgVersion: Dieses Feld sollte auf „1“ festgelegt werden.
      • PluginGUID: Die COM-CLSID für Ihr ccg.exe-Plug-In. Diese ist für das verwendete Plug-In eindeutig.
      • PluginInput: Plug-In-spezifische Eingabe zum Abrufen der Benutzerkontoinformationen aus dem Geheimnisspeicher.

      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"
                  }
              ],
              "HostAccountConfig": {
                  "PortableCcgVersion": "1",
                  "PluginGUID": "{GDMA0342-266A-4D1P-831J-20990E82944F}",
                  "PluginInput": "contoso.com:gmsaccg:<password>"
              }
          }
      }
      

3. Ü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 Befehl zum Ausführen des Containers --security-opt="credentialspec=file://NAME.json" enthält, wobei „NAME.json“ durch den Namen ersetzt wird, der durch Get-CredentialSpec ausgegeben wird. Der Name ist ein Flatfilename, relativ zum CredentialSpecs-Ordner unter dem Docker-Stammverzeichnis.

Überprüfen Sie die Netzwerkkonfiguration.

Überprüfen der Firewallkonfiguration

Wenn Sie eine strikte Firewallrichtlinie für das Container- oder Hostnetzwerk verwenden, blockiert diese möglicherweise erforderliche Verbindungen zum Active Directory-Domänencontroller oder DNS-Server.

Je nach Art des Datenverkehrs, den Ihr Container an einen Domänencontroller sendet, müssen Sie möglicherweise den Zugriff auf zusätzliche Ports erlauben. 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 eine Domäne eingebundenen Host verwenden, wird diese Konfiguration nicht automatisch festgelegt. Sie sollten überprüfen, ob das Hostnetzwerk konfiguriert ist, damit es die Domäne auflösen kann. Sie können überprüfen, ob die Domäne vom Host aus aufgelöst werden kann, indem Sie:

nltest /sc_verify:contoso.com

Überprüfen des Containers

1. 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 Parameter --hostname mit dem gMSA-Kurznamen übereinstimmt (keine Domänenkomponente, z. B. „webapp01“ anstelle von „webapp01.contoso.com“).

2. Überprüfen Sie die Containernetzwerkkonfiguration, um sicherzustellen, dass der Container einen Domänencontroller für die Domäne des gMSAs auflösen und auf ihn zugreifen kann. DNS-Server mit fehlerhafter Konfiguration im Container sind ein häufiger Verursacher von Identitätsproblemen.

3. Überprüfen Sie, ob der Container über eine gültige Verbindung zur Domäne verfügt, indem Sie das folgende Cmdlet im Container ausführen (unter Verwendung von docker exec oder einem äquivalenten Cmdlet):

   nltest /sc_verify:contoso.com
   

   Die Überprüfung der Vertrauenswürdigkeit sollte NERR_SUCCESS zurückgeben, wenn das gMSA verfügbar ist und die Netzwerkverbindungen es dem Container gestatten, mit der Domäne zu kommunizieren. Wenn dies nicht der Fall ist, überprüfen Sie die Netzwerkkonfiguration des Hosts und Containers. Beide müssen mit dem Domänencontroller kommunizieren können.

4. Überprüfen Sie, ob der Container ein gültiges Kerberos-TGT (Ticket-Granting Ticket) 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 bei nltest aus dem vorherigen Schritt ein Fehler auftritt, kann dies ein Hinweis darauf sein, dass das gMSA-Konto falsch konfiguriert ist. Weitere Informationen finden Sie unter Überprüfen des gMSA-Kontos.

   Wenn Sie innerhalb des Containers kein TGT abrufen können, kann dies auf DNS- oder Netzwerkverbindungsprobleme hinweisen. Stellen Sie sicher, dass der Container einen Domänencontroller unter Verwendung des DNS-Namens der Domäne auflösen kann und dass der Domänencontroller über den Container routingfähig ist.

5. Stellen Sie sicher, dass Ihre App für die Verwendung des gMSAs konfiguriert ist. Das Benutzerkonto innerhalb des Containers ändert sich nicht, wenn Sie ein gMSA verwenden. Vielmehr verwendet das Systemkonto das gMSA, wenn es mit anderen Netzwerkressourcen kommuniziert. Das bedeutet, dass Ihre Anwendung 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 und nicht als Domänenidentität am Container anmelden. Das gMSA wird vom Computerkonto immer dann verwendet, wenn es mit Netzwerkressourcen kommuniziert, weshalb Ihre Anwendung als Netzwerkdienst oder lokales System ausgeführt werden muss.

Überprüfen des gMSA-Kontos

1. Wenn Ihr Container ordnungsgemäß konfiguriert zu sein scheint, aber Benutzer 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 unter dem Namen, unter dem sie Ihre Anwendung erreichen. Dies kann bedeuten, dass Sie zusätzliche host-SPNs für Ihr gMSA benötigen, wenn sich z. B. Clients über einen Lastenausgleich oder einen anderen DNS-Namen mit Ihrer App verbinden.

2. Stellen Sie für die Verwendung von gMSA mit einem in die Domäne eingebundenen Containerhost sicher, dass das gMSA und der Containerhost zur gleichen Active Directory-Domäne gehören. Der Containerhost ist nicht in der Lage, das gMSA-Kennwort abzurufen, wenn das gMSA zu einer anderen Domäne gehört.

3. Stellen Sie sicher, dass es in Ihrer Domäne nur ein Konto mit demselben Namen wie Ihr gMSA gibt. An gMSA-Objekte ist ein Dollarzeichen ($) an ihren SAM-Kontonamen angefügt, sodass es möglich ist, dass ein gMSA den Namen „myaccount$“ und ein nicht verwandtes Benutzerkonto in derselben Domäne den Namen „myaccount“ erhält. Dies kann Probleme verursachen, wenn der Domänencontroller oder die Anwendung das gMSA anhand des Namens suchen muss. Mit dem folgenden Befehl können Sie AD nach ähnlich benannten Objekten durchsuchen:

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

4. Wenn Sie die uneingeschränkte Delegierung für das gMSA-Konto aktiviert haben, stellen Sie sicher, dass für das UserAccountControl-Attribut immer noch das WORKSTATION_TRUST_ACCOUNT-Flag aktiviert ist. Dieses Flag ist erforderlich, damit NETLOGON im Container mit dem Domänencontroller kommunizieren kann, wie es der Fall ist, wenn eine App einen Namen in eine SID auflösen muss oder umgekehrt. Sie können mit den folgenden Befehlen überprüfen, ob das Flag 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 Folgendes, um der UserAccountControl-Eigenschaft des gMSA-Kontos das Flag WORKSTATION_TRUST_ACCOUNT hinzuzufügen. Dieser Befehl löscht auch die Flags NORMAL_ACCOUNT, INTERDOMAIN_TRUST_ACCOUNT und SERVER_TRUST_ACCOUNT aus der UserAccountControl-Eigenschaft.

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

Nicht in die Domäne eingebundene Containerhosts: Verwenden sie Ereignisprotokolle, um Konfigurationsprobleme zu identifizieren

Die Ereignisprotokollierung für die Verwendung von gMSA mit nicht in die Domäne eingebundenen Containerhosts kann verwendet werden, um Konfigurationsprobleme zu identifizieren. Ereignisse werden in der Protokolldatei Microsoft-Windows-Containers-CCG protokolliert und befinden sich 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 die Container-Funktion auf dem Gerät aktiviert haben, auf dem Sie die Protokolldatei lesen möchten, und Sie müssen über eine Windows-Version verfügen, die die Verwendung von gMSA mit nicht in die Domäne eingebundenen Containerhosts unterstützt.

Ereignisse und Beschreibungen