Risolvere i problemi degli account del servizio gestito del gruppo per i contenitori di Windows

Si applica a: Windows Server 2022, Windows Server 2019

Problemi noti

Il nome host del contenitore deve corrispondere al nome dell'account del servizio gestito del gruppo per Windows Server 2016 e Windows 10, versioni 1709 e 1803

Se è in esecuzione Windows Server 2016, versione 1709 o 1803, il nome host del contenitore deve corrispondere al nome dell'account SAM dell'account del servizio gestito del gruppo.

Quando il nome host non corrisponde al nome dell'account del servizio gestito del gruppo, le richieste di autenticazione NTLM in ingresso e la conversione nome/SID (usata da molte librerie, ad esempio il provider di ruoli di appartenenza ASP.NET) avranno esito negativo. Kerberos continuerà a funzionare normalmente anche se il nome host e il nome dell'account del servizio gestito del gruppo non corrispondono.

Questa limitazione è stata risolta in Windows Server 2019, in cui il contenitore userà sempre il nome dell'account del servizio gestito del gruppo sulla rete, indipendentemente dal nome host assegnato.

L'uso di un account del servizio gestito del gruppo con più contenitori simultaneamente genera errori intermittenti in Windows Server 2016 e Windows 10, versioni 1709 e 1803

Poiché tutti i contenitori devono usare lo stesso nome host, un secondo problema riguarda le versioni di Windows precedenti a Windows Server 2019 e Windows 10, versione 1809. Quando a più contenitori vengono assegnati la stessa identità e lo stesso nome host, è possibile che si verifichi una race condition quando due contenitori comunicano simultaneamente con lo stesso controller di dominio. Quando un altro contenitore comunica con lo stesso controller di dominio, la comunicazione con i contenitori precedenti che usano la stessa identità verrà annullata. Questo può causare errori di autenticazione intermittenti e talvolta può essere osservato come un errore di attendibilità quando si esegue nltest /sc_verify:contoso.com all'interno del contenitore.

Questo comportamento in Windows Server 2019 è stato modificato per separare l'identità del contenitore dal nome del computer, consentendo a più contenitori di usare contemporaneamente lo stesso account del servizio gestito del gruppo. Pertanto, in Windows Server 2019, è possibile eseguire più contenitori con la stessa identità, sia nello stesso host che in più host.

Non puoi usare gli account del servizio gestito del gruppo con i contenitori isolati Hyper-V in Windows 10 versioni 1703, 1709 e 1803

L'inizializzazione del contenitore si interrompe o genera un errore quando si tenta di usare un account del servizio gestito del gruppo con un contenitore isolato Hyper-V in Windows 10 e Windows Server versioni 1703, 1709 e 1803.

Questo bug è stato risolto in Windows Server 2019 e Windows 10, versione 1809. Puoi eseguire i contenitori isolati Hyper-V con gli account del servizio gestito del gruppo in Windows Server 2016 e Windows 10, versione 1607.

Guida generale alla risoluzione dei problemi

Se si verificano errori durante l'esecuzione di un contenitore con un account del servizio gestito del gruppo, le istruzioni seguenti possono esserti utili per identificarne la causa principale.

Host aggiunti a un dominio: assicurarsi che l'host possa usare l'account del servizio gestito del gruppo

1. Verifica che l'host sia aggiunto a un dominio e che sia in grado di raggiungere il controller di dominio.

2. Installa gli strumenti di PowerShell per AD da Strumenti di amministrazione remota del server ed esegui Test-ADServiceAccount per verificare se il computer dispone dell'accesso per recuperare l'account del servizio gestito del gruppo. Se il cmdlet restituisce False, il computer non ha accesso alla password dell'account del servizio gestito del gruppo.

   # 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. Se Test-ADServiceAccount restituisce False, verifica che l'host appartenga a un gruppo di sicurezza in grado di accedere alla password dell'account del servizio gestito del gruppo.

   # 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. Se l'host appartiene a un gruppo di sicurezza autorizzato a recuperare la password dell'account del servizio gestito del gruppo, ma Test-ADServiceAccount ha ancora esito negativo, potresti dover riavviare il computer in modo da ottenere un nuovo ticket che rifletta l'appartenenza al gruppo corrente.

Host non aggiunti a un dominio: assicurarsi che l'host sia configurato per recuperare l'account del servizio gestito del gruppo

Verificare che un plug-in per l'uso dell'account del servizio gestito del gruppo con un host contenitore non aggiunto a un dominio sia installato correttamente nell'host. Windows non include un plug-in predefinito e richiede di fornire un plug-in che implementa l'interfaccia ICcgDomainAuthCredentials. I dettagli di installazione saranno specifici del plug-in.

Controllare il file delle specifiche delle credenziali

1. Esegui Get-CredentialSpec dal modulo CredentialSpec di PowerShell, per individuare tutte le specifiche delle credenziali nel computer. Le specifiche delle credenziali devono essere archiviate nella directory "CredentialSpecs" nella directory radice di Docker. Puoi trovare la directory radice di Docker eseguendo docker info -f "{{.DockerRootDir}}" .

2. Apri il file CredentialSpec e assicurati che i campi seguenti siano compilati correttamente:

   1. Per gli host contenitore aggiunti a un dominio:

      • Sid: SID del dominio
      • MachineAccountName: nome dell'account SAM dell'account del servizio gestito del gruppo (non include il nome di dominio completo o il simbolo del dollaro)
      • DnsTreeName: FQDN della foresta di Active Directory
      • DnsName: FQDN del dominio a cui appartiene l'account del servizio gestito del gruppo
      • NetBiosName: nome NETBIOS per il dominio a cui appartiene l'account del servizio gestito del gruppo
      • GroupManagedServiceAccounts/Name: nome dell'account SAM dell'account del servizio gestito del gruppo (non include il nome di dominio completo o il simbolo del dollaro)
      • GroupManagedServiceAccounts/Scope: una voce per FQDN del dominio e una voce per NETBIOS

      L'input dovrebbe essere simile all'esempio seguente di una specifica delle credenziali completa:

      {
          "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. Per gli host non aggiunti a un dominio: Oltre a tutti i campi host contenitore non aggiunti a un dominio, assicurarsi che la sezione "HostAccountConfig" sia presente e che i campi seguenti siano definiti correttamente.

      • PortableCcgVersion: deve essere impostato su "1".
      • PluginGUID: CLSID COM per il plug-in ccg.exe. Questo è univoco per il plug-in usato.
      • PluginInput: input specifico del plug-in per recuperare le informazioni sull'account utente dall'archivio segreti.

      L'input dovrebbe essere simile all'esempio seguente di una specifica delle credenziali completa:

      {
          "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. Verifica che il percorso del file delle specifiche delle credenziali sia corretto per la soluzione di orchestrazione. Se usi Docker, assicurati che il comando di esecuzione del contenitore includa --security-opt="credentialspec=file://NAME.json", dove "NAME.json" viene sostituito con il nome restituito da Get-CredentialSpec. Il nome è un nome file flat, relativo alla cartella CredentialSpecs nella directory radice di Docker.

controllare la configurazione della rete

Verificare la configurazione del firewall

Se usi un criterio di firewall rigoroso nel contenitore o nella rete host, è possibile che le connessioni richieste al Controller di dominio Active Directory o al server DNS siano bloccate.

Potresti dover consentire l'accesso a porte aggiuntive a seconda del tipo di traffico inviato dal contenitore a un controller di dominio. Per un elenco completo delle porte usate da Active Directory, vedi Requisiti relativi alle porte per Active Directory e Active Directory Domain Services.

Controllare la configurazione DNS dell'host del contenitore

Se si usa l'account del servizio gestito del gruppo con un host contenitore aggiunto a un dominio, il DNS deve essere configurato automaticamente nell'host in modo che possa risolvere correttamente e stabilire una connessione al dominio. Se si usa l'account del servizio gestito del gruppo con un host non aggiunto a un dominio, questa configurazione non verrà impostata automaticamente. È necessario verificare che la rete host sia configurata in modo che possa risolvere il dominio. È possibile verificare che il dominio possa essere risolto dall'host usando:

nltest /sc_verify:contoso.com

Controllare il contenitore

1. Se esegui una versione di Windows precedente a Windows Server 2019 o Windows 10, versione 1809, il nome host del contenitore deve corrispondere al nome dell'account del servizio gestito del gruppo. Verifica che il parametro --hostname corrisponda al nome breve dell'account del servizio gestito del gruppo (nessun componente del dominio, ad esempio "webapp01" invece di "webapp01.contoso.com").

2. Controlla la configurazione di rete del contenitore per verificare che il contenitore sia in grado di risolvere e accedere al controller di dominio per il dominio dell'account del servizio gestito del gruppo. I server DNS non configurati correttamente nel contenitore rappresentano una causa comune dei problemi di identità.

3. Verifica che il contenitore disponga di una connessione valida al dominio eseguendo il cmdlet seguente nel contenitore (usando docker exec o un equivalente):

   nltest /sc_verify:contoso.com
   

   La verifica dell'attendibilità deve restituire NERR_SUCCESS se l'account del servizio gestito del gruppo è disponibile e la connettività di rete consente al contenitore di comunicare con il dominio. In caso di errore, verifica la configurazione di rete dell'host e del contenitore. Entrambi devono essere in grado di comunicare con il controller di dominio.

4. Controlla se il contenitore può ottenere un Ticket Granting Ticket (TGT) Kerberos valido:

   klist get <myapp>
   

   Questo comando dovrebbe restituire un messaggio simile a "È stato recuperato un ticket per KRBTGT " ed elencare il controller di dominio usato per recuperare il ticket. Se riesci a ottenere un TGT ma nltest dal passaggio precedente ha esito negativo, è possibile che l'account del servizio gestito del gruppo non sia configurato correttamente. Per altre informazioni, vedi Controllare l'account del servizio gestito del gruppo.

   Se non riesci a ottenere un TGT all'interno del contenitore, potrebbero esserci problemi di connettività di rete o DNS. Verifica che il contenitore sia in grado di risolvere un controller di dominio usando il nome DNS del dominio e che il controller di dominio sia instradabile dal contenitore.

5. Verifica che l'app sia configurata per usare l'account del servizio gestito del gruppo. L'account utente all'interno del contenitore non cambia quando si usa un account del servizio gestito del gruppo. L'account di sistema usa invece l'account del servizio gestito del gruppo quando comunica con altre risorse di rete. L'app deve quindi essere eseguita come Servizio di rete o Sistema locale per sfruttare i vantaggi offerti dall'identità dell'account del servizio gestito del gruppo.

   Suggerimento

   Se esegui whoami o usi un altro strumento per identificare il contesto utente corrente nel contenitore, non visualizzerai l'account del servizio gestito del gruppo. Questo perché si accede sempre al contenitore come utente locale anziché come identità di dominio. L'account del servizio gestito del gruppo viene usato dall'account del computer ogni volta che comunica con le risorse di rete, motivo per cui l'app deve essere eseguita come Servizio di rete o Sistema locale.

Controllare l'account del servizio gestito del gruppo

1. Se il contenitore sembra essere configurato correttamente, ma gli utenti o altri servizi non sono in grado di autenticarsi automaticamente all'app in contenitori, controlla i nomi SPN nell'account del servizio gestito del gruppo. I client troveranno l'account del servizio gestito del gruppo in base al nome di riferimento per raggiungere l'applicazione. Questo potrebbe significare che dovrai usare nomi SPN host aggiuntivi per l'account del servizio gestito del gruppo se, ad esempio, i client si connettono all'app tramite un servizio di bilanciamento del carico o un nome DNS diverso.

2. Per l'uso dell'account del servizio gestito del gruppo con un host contenitore aggiunto a un dominio, assicurarsi che l'account del servizio gestito del gruppo e l'host del contenitore appartengano allo stesso dominio di Active Directory. L'host contenitore non sarà in grado di recuperare la password dell'account del servizio gestito del gruppo se quest'ultimo appartiene a un dominio diverso.

3. Assicurati che nel dominio sia presente un solo account con lo stesso nome dell'account del servizio gestito del gruppo. Gli oggetti dell'account del servizio gestito del gruppo hanno il simbolo del dollaro ($) aggiunto al nome dell'account SAM, è quindi possibile che nello stesso dominio un account del servizio gestito del gruppo venga denominato "accountpersonale$" e che un account utente non correlato venga denominato "accountpersonale". Ciò può causare problemi se il controller di dominio o l'applicazione deve cercare l'account del servizio gestito del gruppo in base al nome. Puoi eseguire ricerche in Active Directory per oggetti denominati in modo analogo con il comando seguente:

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

4. Se hai abilitato la delega non vincolata nell'account del servizio gestito del gruppo, assicurati che nell'attributo UserAccountControl il flag WORKSTATION_TRUST_ACCOUNT sia ancora abilitato. Questo flag è necessario affinché NETLOGON nel contenitore possa comunicare con il controller di dominio, come nel caso in cui un'app debba risolvere un nome in un SID o viceversa. Puoi verificare se il flag è configurato correttamente con i comandi seguenti:

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

   Se i comandi precedenti restituiscono False, usa il comando seguente per aggiungere il flag WORKSTATION_TRUST_ACCOUNT alla proprietà UserAccountControl dell'account del servizio gestito del gruppo. Questo comando eliminerà anche i flag NORMAL_ACCOUNT, INTERDOMAIN_TRUST_ACCOUNT e SERVER_TRUST_ACCOUNT dalla proprietà UserAccountControl.

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

Host contenitore non aggiunti a un dominio: usare i registri eventi per identificare i problemi di configurazione

La registrazione degli eventi per l'uso di account del servizio gestito del gruppo con host contenitore non aggiunti a un dominio può essere usata per identificare i problemi di configurazione. Gli eventi vengono registrati nel file di log Microsoft-Windows-Containers-CCG e sono disponibili nella Visualizzatore eventi in Registri applicazioni e servizi\Microsoft\Windows\Containers-CCG\Amministrazione. Se si esporta questo file di log dall'host contenitore per leggerlo, è necessario che la funzionalità contenitori sia abilitata nel dispositivo in cui si sta tentando di leggere il file di log e che sia in una versione di Windows che supporta l'uso di gMSA con host contenitore non aggiunti a un dominio.

Eventi e descrizioni