Rozwiązywanie problemów z kontami gMSA dla kontenerów systemu Windows

Dotyczy: Windows Server 2025, Windows Server 2022, Windows Server 2019

Znane problemy

Nazwa hosta kontenera musi być zgodna z nazwą gMSA dla systemów Windows Server 2016 i Windows 10 w wersjach 1709 i 1803

Jeśli korzystasz z systemu Windows Server 2016 w wersji 1709 lub 1803, nazwa hosta kontenera musi być zgodna z nazwą konta SAM usługi gMSA.

Jeśli nazwa hosta nie jest zgodna z nazwą gMSA, przychodzące żądania uwierzytelniania NTLM i tłumaczenie nazwy/identyfikatora SID (używane przez wiele bibliotek, takich jak dostawca roli członkostwa ASP.NET) zakończy się niepowodzeniem. Protokół Kerberos będzie nadal działać normalnie, nawet jeśli nazwa hosta i nazwa gMSA nie są zgodne.

To ograniczenie zostało naprawione w systemie Windows Server 2019, gdzie kontener będzie teraz zawsze używać jego nazwy gMSA w sieci niezależnie od przypisanej nazwy hosta.

Używanie grupowego zarządzanego konta usługi (gMSA) z więcej niż jednym kontenerem jednocześnie prowadzi do sporadycznych błędów w systemach Windows Server 2016 i Windows 10 w wersjach 1709 i 1803

Ponieważ wszystkie kontenery są wymagane do używania tej samej nazwy hosta, drugi problem dotyczy wersji systemu Windows wcześniejszych niż Windows Server 2019 i Windows 10 w wersji 1809. Gdy wiele kontenerów ma przypisaną tę samą tożsamość i nazwę hosta, może wystąpić warunek wyścigu, gdy dwa kontenery komunikują się jednocześnie z tym samym kontrolerem domeny. Gdy inny kontener komunikuje się z tym samym kontrolerem domeny, anuluje komunikację z wszelkimi poprzednimi kontenerami przy użyciu tej samej tożsamości. Może to prowadzić do sporadycznych błędów uwierzytelniania i czasami może być obserwowany jako błąd zaufania podczas uruchamiania nltest /sc_verify:contoso.com wewnątrz kontenera.

Zmieniliśmy zachowanie w systemie Windows Server 2019, aby oddzielić tożsamość kontenera od nazwy komputera, co umożliwia jednoczesne użycie tego samego zarządzanego konta usług grupowych (gMSA) przez wiele kontenerów. W związku z tym w systemie Windows Server 2019 można uruchomić wiele kontenerów z tą samą tożsamością, zarówno na tych samych hostach, jak i na wielu hostach.

Nie można używać gMSAs z kontenerami izolowanymi Hyper-V w systemie Windows 10 w wersji 1703, 1709 i 1803

Inicjowanie kontenera zawiesza się lub kończy się niepowodzeniem, gdy spróbujesz użyć grupowego konta usługi zarządzanej (gMSA) z izolowanym kontenerem Hyper-V w systemach Windows 10 i Windows Server w wersji 1703, 1709 i 1803.

Ta usterka została usunięta w systemach Windows Server 2019 i Windows 10 w wersji 1809. Można również uruchamiać kontenery izolowane Hyper-V z użyciem gMSAs na systemach Windows Server 2016 oraz Windows 10, wersja 1607.

Ogólne wskazówki dotyczące rozwiązywania problemów

Jeśli występują błędy podczas uruchamiania kontenera z gMSA, poniższe instrukcje mogą pomóc w zidentyfikowaniu głównej przyczyny.

Hosty przyłączone do domeny: upewnij się, że host może korzystać z gMSA

1. Sprawdź, czy host jest przyłączony do domeny i może uzyskać dostęp do kontrolera domeny.

2. Zainstaluj narzędzia AD PowerShell z pakietu RSAT i uruchom Test-ADServiceAccount, aby sprawdzić, czy komputer ma dostęp do korzystania z konta zarządzanego usługą. Jeśli polecenie cmdlet zwróci false, komputer nie ma dostępu do hasła 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. Jeśli Test-ADServiceAccount zwraca wartość False, sprawdź, czy host należy do grupy zabezpieczeń, która może uzyskać dostęp do hasła 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. Jeśli host należy do grupy zabezpieczeń autoryzowanej do pobrania hasła gMSA, ale nadal nie przechodzi Test-ADServiceAccount, może być konieczne ponowne uruchomienie komputera w celu uzyskania nowego biletu odzwierciedlającego jego członkostwa w bieżących grupach.

Hosty nieprzyłączone do domeny: upewnij się, że host jest skonfigurowany do pobierania konta gMSA

Sprawdź, czy wtyczka do używania usługi gMSA z hostem kontenera nieprzyłączonego do domeny jest poprawnie zainstalowana na hoście. System Windows nie zawiera wbudowanej wtyczki i wymaga dostarczenia wtyczki, która implementuje interfejs ICcgDomainAuthCredentials. Szczegóły instalacji będą specyficzne dla wtyczki.

Sprawdź plik specyfikacji poświadczeń

1. Uruchom Get-CredentialSpec z modułu CredentialSpec programu PowerShell, aby zlokalizować wszystkie specyfikacje poświadczeń na maszynie. Specyfikacje poświadczeń muszą być przechowywane w katalogu "CredentialSpecs" w katalogu głównym platformy Docker. Katalog główny platformy Docker można znaleźć, wykonując docker info -f "{{.DockerRootDir}}".

2. Otwórz plik CredentialSpec i upewnij się, że następujące pola zostały wypełnione poprawnie:

   1. Dla hostów kontenerów przyłączonych do domeny:

      • SID: identyfikator SID Twojej domeny
      • MachineAccountName: nazwa konta SAM grupowego zarządzanego przez usługę (nie uwzględniaj pełnej nazwy domeny ani znaku dolara)
      • DnsTreeName: nazwa FQDN lasu usługi Active Directory
      • dnsName: nazwa FQDN domeny, do której należy gMSA
      • NetBiosName: nazwa NETBIOS domeny, do której należy gMSA
      • GroupManagedServiceAccounts/Name: nazwa konta SAM dla kont usługi gMSA (nie dołączaj pełnej nazwy domeny lub znaku dolara)
      • GroupManagedServiceAccounts/Scope: jeden wpis dla nazwy FQDN domeny i jeden dla NETBIOS

      Dane wejściowe powinny wyglądać podobnie do poniższego przykładu pełnej specyfikacji poświadczeń:

      {
          "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. Dla hostów nieprzyłączonych do domeny: Oprócz wszystkich pól hosta kontenera nieprzyłączonych do domeny upewnij się, że sekcja "HostAccountConfig" jest obecna i że poniższe pola są poprawnie zdefiniowane.

      • PortableCcgVersion: wartość powinna być ustawiona na "1".
      • PluginGUID: COM CLSID dla wtyczki ccg.exe. Jest to unikatowe dla używanej wtyczki.
      • PluginInput: specyficzne dla wtyczki dane wejściowe służące do pobierania informacji o koncie użytkownika z magazynu sekretów.

      Twój wkład powinien wyglądać podobny do poniższego przykładu kompletnej specyfikacji poświadczenia.

      {
          "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. Sprawdź, czy ścieżka do pliku specyfikacji poświadczeń jest poprawna dla rozwiązania orkiestracji. Jeśli używasz platformy Docker, upewnij się, że polecenie uruchamiania kontenera zawiera --security-opt="credentialspec=file://NAME.json", gdzie element "NAME.json" jest zastępowany nazwą wyjściową przez Get-CredentialSpec. Nazwa jest nazwą prostego pliku w folderze CredentialSpecs w katalogu głównym Docker.

Sprawdzanie konfiguracji sieci

Sprawdź konfigurację zapory

Jeśli stosujesz rygorystyczną politykę zapory w kontenerze lub sieci hosta, może to blokować wymagane połączenia z kontrolerem domeny Active Directory lub serwerem DNS.

Protokół i port	Cel
TCP i UDP 53	DNS
TCP i UDP 88	Kerberos
TCP 139	NetLogon
TCP i UDP 389	LDAP
TCP 636	LDAP SSL

Może być konieczne zezwolenie na dostęp do dodatkowych portów w zależności od typu ruchu wysyłanego przez kontener do kontrolera domeny. Zobacz wymagania dotyczące portów dla Active Directory i Active Directory Domain Services, aby uzyskać pełną listę portów używanych przez Active Directory.

Sprawdzanie konfiguracji DNS hosta kontenera

Jeśli używasz usługi gMSA z hostem kontenera przyłączonym do domeny, system DNS powinien zostać automatycznie skonfigurowany na hoście, aby mógł prawidłowo rozpoznać i nawiązać połączenie z domeną. Jeśli używasz konta gMSA z hostem nieprzyłączonym do domeny, ta konfiguracja nie zostanie ustawiona automatycznie. Należy sprawdzić, czy sieć hostów jest skonfigurowana, aby mogła rozpoznać domenę. Możesz sprawdzić, czy domenę można rozwiązać na hoście przy użyciu:

nltest /sc_verify:contoso.com

Sprawdzanie kontenera

1. Jeśli korzystasz z systemu Windows w wersji wcześniejszej niż Windows Server 2019 lub Windows 10 w wersji 1809, nazwa hosta kontenera musi być zgodna z nazwą gMSA. Upewnij się, że parametr --hostname jest zgodny z krótką nazwą gMSA (brak składnika domeny, na przykład "webapp01" zamiast "webapp01.contoso.com").

2. Sprawdź konfigurację sieci kontenera, aby sprawdzić, czy kontener może rozpoznać i uzyskać dostęp do kontrolera domeny dla domeny gMSA. Błędnie skonfigurowane serwery DNS w kontenerze są typowymi winowajcami problemów z tożsamością.

3. Sprawdź, czy kontener ma prawidłowe połączenie z domeną, uruchamiając następujące polecenie cmdlet w kontenerze (przy użyciu docker exec lub odpowiednika):

   nltest /sc_verify:contoso.com
   

   Weryfikacja zaufania powinna zwrócić NERR_SUCCESS, jeśli usługa gMSA jest dostępna, a łączność sieciowa umożliwia kontenerowi rozmowę z domeną. Jeśli nie powiedzie się, sprawdź konfigurację sieci hosta i kontenera. Oba muszą być w stanie komunikować się z kontrolerem domeny.

4. Sprawdź, czy kontener może uzyskać ważny bilet przyznający bilety Kerberos (TGT):

   klist get <myapp>
   

   To polecenie powinno zwrócić komunikat "Bilet do krbtgt został pomyślnie pobrany" i wyświetlić kontroler domeny użyty do pobrania biletu. Jeśli możesz uzyskać bilet TGT, ale nltest z poprzedniego kroku zakończy się niepowodzeniem, może to oznaczać, że konto usługi gMSA jest nieprawidłowo skonfigurowane. Zobacz , a następnie sprawdź konto gMSA, aby uzyskać więcej informacji.

   Jeśli nie możesz uzyskać biletu TGT wewnątrz kontenera, może to wskazywać na problemy z usługą DNS lub łącznością sieciową. Upewnij się, że kontener może rozwiązać kontroler domeny przy użyciu nazwy DNS domeny i że kontroler domeny jest osiągalny dla kontenera.

5. Upewnij się, że aplikacja jest skonfigurowana do używaniagMSA. Konto użytkownika w kontenerze nie zmienia się podczas korzystania z zarządzanego konta usługi grupowej. Zamiast tego konto systemowe używa konta gMSA, gdy komunikuje się z innymi zasobami sieciowymi. Oznacza to, że aplikacja będzie musiała działać jako usługa sieciowa lub system lokalny, aby korzystać z tożsamości gMSA.

   Napiwek

   Jeśli uruchomisz whoami lub użyjesz innego narzędzia, aby zidentyfikować bieżący kontekst użytkownika w kontenerze, nie zobaczysz samej nazwy gMSA. Jest to spowodowane tym, że zawsze logujesz się do kontenera jako użytkownik lokalny zamiast tożsamości domeny. gMSA jest używane przez konto komputera za każdym razem, gdy komunikuje się z zasobami sieciowymi, dlatego aplikacja musi działać jako Usługa sieciowa lub System lokalny.

Sprawdzanie konta usługi gMSA

1. Jeśli kontener wydaje się być poprawnie skonfigurowany, ale użytkownicy lub inne usługi nie mogą automatycznie uwierzytelniać się w konteneryzowanej aplikacji, sprawdź nazwy SPN na koncie gMSA. Klienci zlokalizują konto usługi gMSA po nazwie, za pomocą której uzyskują dostęp do twojej aplikacji. Może to oznaczać, że będziesz potrzebować dodatkowych host nazw SPN dla gMSA, jeśli na przykład klienci łączą się z Twoją aplikacją za pośrednictwem równoważnika obciążenia lub innej nazwy DNS.

2. W przypadku korzystania z usługi gMSA z przyłączonym do domeny hostem kontenera upewnij się, że host gMSA i kontenera należą do tej samej domeny usługi Active Directory. Host kontenera nie będzie mógł pobrać hasła gMSA, jeśli gMSA należy do innej domeny.

3. Upewnij się, że w domenie istnieje tylko jedno konto o tej samej nazwie co Twoje gMSA. Obiekty gMSA mają znaki dolara ($) dołączane do nazw kont SAM, więc istnieje możliwość, aby konto zarządzane przez grupę miało nazwę "myaccount$" i niepowiązane konto użytkownika o nazwie "myaccount" w tej samej domenie. Może to spowodować problemy, jeśli kontroler domeny lub aplikacja musi wyszukać gMSA według nazwy. Za pomocą następującego polecenia możesz wyszukać w usłudze AD obiekty o podobnych nazwach:

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

4. Jeśli włączono delegowanie bez ograniczeń na koncie gMSA, upewnij się, że atrybut UserAccountControl nadal ma włączoną flagę WORKSTATION_TRUST_ACCOUNT. Ta flaga jest wymagana, aby NETLOGON w kontenerze mógł komunikować się z kontrolerem domeny, na przykład wtedy, gdy aplikacja musi zamienić nazwę na SID lub odwrotnie. Możesz sprawdzić, czy flaga jest poprawnie skonfigurowana za pomocą następujących poleceń:

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

   Jeśli powyższe polecenia zwracają False, użyj poniższej instrukcji, aby dodać flagę WORKSTATION_TRUST_ACCOUNT do właściwości UserAccountControl konta gMSA. To polecenie spowoduje również wyczyszczenie flag NORMAL_ACCOUNT, INTERDOMAIN_TRUST_ACCOUNTi SERVER_TRUST_ACCOUNT z właściwości UserAccountControl.

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

Hosty kontenerów nieprzyłączonych do domeny: identyfikowanie problemów z konfiguracją przy użyciu dzienników zdarzeń

Rejestrowanie zdarzeń na potrzeby korzystania z usługi gMSA z hostami kontenerów nieprzyłączonych do domeny może służyć do identyfikowania problemów z konfiguracją. Zdarzenia są rejestrowane w pliku dziennika Microsoft-Windows-Containers-CCG i można je znaleźć w Podglądzie zdarzeń w obszarze Dzienniki aplikacji i usług\Microsoft\Windows\Containers-CCG\Admin. Jeśli eksportujesz ten plik dziennika z hosta kontenera, aby go odczytać, musisz mieć włączoną funkcję kontenerów na urządzeniu, na którym próbujesz odczytać plik dziennika, i musisz korzystać z wersji systemu Windows, która obsługuje używanie gMSA z hostami kontenerów nieprzyłączonymi do domeny.

Zdarzenia i opisy

Numer zdarzenia	Tekst zdarzenia	Opis
1	Funkcja Container Credential Guard zainicjowała wtyczkę	To zdarzenie wskazuje, że wtyczka określona w specyfikacji poświadczeń została zainstalowana i może zostać załadowana. Nie jest wymagana żadna akcja.
2	Funkcja Container Credential Guard pobrała poświadczenia gmsa dla %1 przy użyciu wtyczki: %2	Jest to zdarzenie informacyjne wskazujące, że poświadczenia gMSA zostały pomyślnie pobrane z Active Directory. Nie jest wymagana żadna akcja.
3	Usługa Container Credential Guard nie może przeanalizować specyfikacji poświadczeń. Błąd: %1	To zdarzenie wskazuje problem ze specyfikacją poświadczeń. Może się tak zdarzyć, jeśli identyfikator GUID dla wtyczki jest niepoprawny lub jeśli istnieją inne źle sformułowane pola. Przejrzyj wskazówki dotyczące rozwiązywania problemów związanych ze specyfikacją poświadczeń, aby sprawdzić jej formatowanie i zawartość.
4	Nie można utworzyć wystąpienia wtyczki Container Credential Guard: %1. Błąd: %2	To zdarzenie oznacza, że nie można załadować wtyczki. Należy sprawdzić, czy wtyczka została poprawnie zainstalowana na hoście
6	Usługa Container Credential Guard nie może pobrać poświadczeń z wtyczki: %1. Błąd: %2	To zdarzenie wskazuje, że wtyczka załadowana, ale nie może pobrać poświadczeń wymaganych do pobrania hasła gMSA z usługi AD. Należy sprawdzić, czy dane wejściowe do wtyczki są poprawnie sformatowane w specyfikacji poświadczeń i czy host kontenera ma niezbędne uprawnienia dostępu do magazynu tajemnic używanego przez wtyczkę.
7	Funkcja Container Credential Guard odświeża poświadczenia używając wtyczki: %1	Jest to zdarzenie informacyjne. To zdarzenie jest generowane, gdy hasło gMSA wygasło i musi zostać odświeżone przy użyciu poświadczeń pobranych przez wtyczkę.
8	Usługa Container Credential Guard nie może pobrać poświadczeń gMSA dla %1 przy użyciu wtyczki %2. Przyczyna błędu: %3	To zdarzenie wskazuje, że poświadczenia pobrane przy użyciu wtyczki nie mogą być używane do pobierania poświadczeń gMSA z usługi AD. Należy sprawdzić, czy konto pobierane z wtyczki ma uprawnienia w AD, aby pobrać poświadczenia gMSA.