Risoluzione dei problemi degli account di servizio gestiti di gruppo per i contenitori Windows
Si applica a: Windows Server 2025, Windows Server 2022, Windows Server 2019
Problemi noti
Il nome host del contenitore deve corrispondere al nome gMSA per Windows Server 2016 e Windows 10, versioni 1709 e 1803
Se si esegue Windows Server 2016, versione 1709 o 1803, l'hostname del contenitore deve corrispondere al nome dell'account SAM gMSA.
Quando il nome host non corrisponde al nome gMSA, le richieste di autenticazione NTLM in ingresso e la traduzione nome/SID (utilizzata da molte librerie, come il provider di ruoli di appartenenza ASP.NET) avranno esito negativo. Kerberos continuerà a funzionare normalmente anche se il nome host e il nome gMSA non dovessero corrispondere.
Questa limitazione è stata risolta in Windows Server 2019, in cui il contenitore userà sempre il nome gMSA nella rete indipendentemente dal nome host assegnato.
L'uso di un gMSA con più contenitori contemporaneamente porta a errori intermittenti in Windows Server 2016 e Windows 10, versioni 1709 e 1803
Poiché tutti i contenitori sono necessari per 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 viene assegnata la stessa identità e lo stesso nome host, può verificarsi una condizione di competizione quando due contenitori comunicano contemporaneamente con lo stesso controller di dominio. Quando un altro contenitore comunica con lo stesso controller di dominio, annulla la comunicazione con tutti i contenitori precedenti che usano la stessa identità. Ciò 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.
Abbiamo modificato il comportamento in Windows Server 2019 per separare l'identità del contenitore dal nome del computer, consentendo a più contenitori di utilizzare contemporaneamente lo stesso account del servizio gestito del gruppo (gMSA). Pertanto, in Windows Server 2019, è possibile eseguire più contenitori con la stessa identità, indipendentemente dallo stesso host o da più host.
Non è possibile usare gMSAs con Hyper-V contenitori isolati su Windows 10 versioni 1703, 1709 e 1803
L'inizializzazione del contenitore potrebbe bloccarsi o fallire quando si tenta di utilizzare un account del servizio gestito del gruppo (gMSA) con un contenitore isolato Hyper-V su Windows 10 e Windows Server versioni 1703, 1709 e 1803.
Questo bug è stato risolto in Windows Server 2019 e Windows 10 versione 1809. È anche possibile eseguire contenitori isolati Hyper-V con gMSA (group Managed Service Account) su Windows Server 2016 e Windows 10, versione 1607.
Linee guida generali per la 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 aiutarvi a individuare la causa principale.
Host aggiunti a un dominio: assicurarsi che l'host possa utilizzare l'account gMSA (account del servizio gestito di gruppo)
Verificare che l'host sia associato al dominio e possa raggiungere il controller di dominio.
Installare gli strumenti di PowerShell di AD da RSAT ed eseguire Test-ADServiceAccount per verificare se il computer ha accesso per recuperare il gMSA. Se il cmdlet restituisce False, il computer non ha accesso alla password 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
Se Test-ADServiceAccount restituisce False, verificate che l'host appartenga a un gruppo di sicurezza che possa accedere alla password dell'account del servizio gestito di 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
Se l'host appartiene a un gruppo di sicurezza autorizzato a recuperare la password dell'account del servizio gestito del gruppo ma ha ancora esito negativo Test-ADServiceAccount, potrebbe essere necessario riavviare il computer per ottenere un nuovo ticket che riflette le appartenenze ai gruppi correnti.
Host non aggiunti a un dominio: verificare che l'host sia configurato per recuperare l'account gMSA
Verificare che un plug-in per l'utilizzo di gMSA con un host di contenitori non associato a un dominio sia stato installato correttamente sull'host. Windows non include un plug-in predefinito e richiede di fornire un plug-in che implementi l'interfaccia ICcgDomainAuthCredentials. I dettagli di installazione saranno specifici del plug-in.
Controllare il file delle specifiche delle credenziali
Eseguire Get-CredentialSpec dal modulo PowerShell CredentialSpec per individuare tutte le specifiche delle credenziali nel computer. Le specifiche delle credenziali devono essere archiviate nella directory "CredentialSpecs" nella directory radice di Docker. È possibile trovare la directory radice di Docker eseguendo docker info -f "{{.DockerRootDir}}".
Aprire il file CredentialSpec e assicurarsi che i campi seguenti siano compilati correttamente:
Per gli host contenitore aggiunti a un dominio:
- Sid: SID del dominio
- MachineAccountName: nome Account SAM gMSA (non includere il nome di dominio completo o il segno di dollaro)
- DnsTreeName: il nome di dominio completo della foresta Active Directory
- DnsName: il nome di dominio completo del dominio a cui appartiene il gMSA (account del servizio gestito del gruppo)
- NetBiosName: nome NETBIOS per il dominio a cui appartiene il gMSA
- GroupManagedServiceAccounts/Name: il nome dell'account SAM gMSA (non includere il nome di dominio completo o il simbolo del dollaro)
- GroupManagedServiceAccounts/Scope: una voce per il nome di dominio completo e una per NETBIOS
L'input dovrebbe essere simile all'esempio seguente di una specifica di 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" } ] } }
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: Il CLSID COM per il plug-in ccg.exe. Questo è univoco per il plug-in utilizzato.
- PluginInput: input specifico del plug-in per recuperare le informazioni sull'account utente dall'archivio segreto.
L'input dovrebbe essere simile all'esempio seguente di una specifica di 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>" } } }
Verificare che il percorso del file delle specifiche di credenziali sia corretto per la soluzione di orchestrazione. Se si usa Docker, assicurarsi che il comando 'run' del contenitore includa
--security-opt="credentialspec=file://NAME.json"
, dove "NAME.json" viene sostituito con il nome prodotto dal comando Get-CredentialSpec. Il nome è un nome di file semplice, relativo alla cartella CredentialSpecs nella directory principale di Docker.
Controllare la configurazione di rete
Controllare la configurazione del firewall
Se si usano criteri firewall rigorosi nel contenitore o nella rete host, è possibile che blocchi le connessioni necessarie al controller di dominio Active Directory o al server DNS.
Protocollo e porta | Scopo |
---|---|
TCP e UDP 53 | DNS |
TCP e UDP 88 | Kerberos |
TCP 139 | NetLogon |
TCP e UDP 389 | LDAP |
TCP 636 | LDAP SSL |
Potrebbe essere necessario 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, consultare i requisiti delle porte di Active Directory e dei Servizi di dominio Active Directory ai riferimenti e.
Controllare la configurazione DNS dell'host del contenitore
Se si utilizza un account del servizio gestito del gruppo (gMSA) con un host contenitore unito al dominio, il DNS dovrebbe essere configurato automaticamente sull'host affinché possa risolvere correttamente e stabilire una connessione al dominio. Se si usa gMSA (account del servizio gestito del gruppo) con un host non unito al 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
Se si esegue una versione di Windows precedente a Windows Server 2019 o Windows 10, versione 1809, l'hostname del contenitore deve corrispondere al nome gMSA. Assicurarsi che il parametro
--hostname
corrisponda al nome breve gMSA (nessun componente di dominio, ad esempio "webapp01" anziché "webapp01.contoso.com").Controllare la configurazione di rete del contenitore per verificare che il contenitore possa risolvere e raggiungere un controller di dominio del dominio gMSA. I server DNS configurati in modo errato nel contenitore sono una causa comune dei problemi di identità.
Controllare se il contenitore dispone 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 il gMSA (Group Managed Service Account) è disponibile e la connettività di rete consente al contenitore di comunicare con il dominio. In caso di errore, verificare la configurazione di rete dell'host e del contenitore. Entrambi devono essere in grado di comunicare con il controller di dominio.Controllare se il contenitore può ottenere un ticket di concessione Kerberos valido.
klist get <myapp>
Questo comando deve restituire "Un ticket per krbtgt è stato recuperato correttamente" ed elencare il controller di dominio usato per recuperare il ticket. Se è possibile ottenere un TGT, ma
nltest
dal passaggio precedente non riesce, potrebbe essere un'indicazione che l'account gMSA non è configurato correttamente. Vedere e controllare l'account del servizio gestito del gruppo per ulteriori informazioni.Se non è possibile ottenere un TGT all'interno del contenitore, questo potrebbe indicare problemi di connettività di rete o DNS. Assicurarsi che il contenitore possa risolvere un controller di dominio usando il nome DNS di dominio e che il controller di dominio sia instradabile dal contenitore.
Assicurati 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 gMSA (account del servizio gestito del gruppo). Piuttosto, l'account di sistema utilizza il gMSA quando comunica con altre risorse di rete. Ciò significa che l'app dovrà essere eseguita come "Network Service" o "Local System" per sfruttare l'identità del gMSA.
Consiglio
Se si esegue
whoami
o si usa un altro strumento per identificare il contesto utente corrente nel contenitore, non verrà visualizzato il nome del gMSA. Ciò è dovuto al fatto che si accede sempre al contenitore come utente locale anziché come identità di dominio. L'gMSA viene utilizzato dall'account 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 gMSA (account del servizio gestito di gruppo)
Se il container sembra essere configurato correttamente, ma gli utenti o altri servizi non sono in grado di eseguire automaticamente l'autenticazione alla tua app containerizzata, controlla i nomi SPN nel tuo account gMSA. I clienti individuano l'account gMSA (account del servizio gestito del gruppo) in base al nome con cui raggiungono l'applicazione. Questo può significare che potrebbero essere necessari ulteriori SPN
host
per il tuo gMSA se, ad esempio, i client si connettono alla tua app tramite un servizio di bilanciamento del carico o un nome DNS diverso.Per usare il gMSA con un host contenitore unito al dominio, verificare che il gMSA e l'host contenitore appartengano allo stesso dominio di Active Directory. L'host contenitore non sarà in grado di recuperare la password del gMSA se il gMSA appartiene a un dominio diverso.
Assicurati che nel tuo dominio ci sia un solo account con lo stesso nome del gMSA. Gli oggetti gMSA hanno segni di dollaro ($) aggiunti ai loro nomi di account SAM, quindi è possibile che un gMSA sia chiamato "myaccount$" e un account utente non correlato sia chiamato "myaccount" nello stesso dominio. Ciò può causare problemi se il controller di dominio o l'applicazione deve cercare il gMSA (account del servizio gestito del gruppo) in base al nome. È possibile cercare oggetti denominati in modo analogo in AD con il comando seguente:
# Replace "GMSANAMEHERE" with your gMSA account name (no trailing dollar sign) Get-ADObject -Filter 'sAMAccountName -like "GMSANAMEHERE*"'
Se hai abilitato la delega senza vincoli sull'account gMSA, assicurati che l'attributo UserAccountControl abbia ancora il flag
WORKSTATION_TRUST_ACCOUNT
abilitato. Questo flag è obbligatorio per NETLOGON nel contenitore per consentire la comunicazione con il controller di dominio, come nel caso in cui un'app deve risolvere un nome in un SID o viceversa. È possibile 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
, utilizzare quanto segue per aggiungere il flagWORKSTATION_TRUST_ACCOUNT
alla proprietà UserAccountControl dell'account gMSA. Questo comando cancella anche i flagNORMAL_ACCOUNT
,INTERDOMAIN_TRUST_ACCOUNT
eSERVER_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'utilizzo di gMSA con host di contenitori non uniti a un dominio può essere utilizzata per identificare i problemi di configurazione. Gli eventi vengono registrati nel file di log di Microsoft-Windows-Containers-CCG e sono disponibili nel Visualizzatore eventi in Registri applicazioni e servizi\Microsoft\Windows\Containers-CCG\Admin. Se si esporta questo file di log dall'host del contenitore per leggerlo, è necessario abilitare la funzionalità contenitori sul dispositivo su cui si sta tentando di leggere il file di log, e bisogna trovarsi su una versione di Windows che supporti l'uso di gMSA con host contenitore non aggiunti a un dominio.
Eventi e descrizioni
Il numero dell'evento | Testo evento | Descrizione |
---|---|---|
1 | Container Credential Guard ha istanziato il plug-in | Questo evento indica che il plug-in specificato nella specifica di credenziali è stato installato e può essere caricato. Nessuna azione necessaria. |
2 | Container Credential Guard ha recuperato le credenziali gmsa per %1 tramite plug-in: %2 | Si tratta di un evento informativo che indica che le credenziali gMSA sono state recuperate correttamente da Active Directory. Nessuna azione necessaria. |
3 | Container Credential Guard non è riuscito ad analizzare la specifica delle credenziali. Errore: %1 | Questo evento indica un problema con la specifica delle credenziali. Questo problema può verificarsi se il GUID per il plug-in non è corretto o se sono presenti altri campi in formato non valido. Si prega di esaminare le indicazioni sulla risoluzione dei problemi per la specifica delle credenziali al fine di verificare la formattazione e il contenuto della specifica delle credenziali. |
4 | Container Credential Guard non è riuscito a instanziare il plug-in: %1. Errore: %2 | Questo evento indica che non è stato possibile caricare il plug-in. È necessario verificare che il plug-in sia stato installato correttamente nell'host |
6 | Container Credential Guard non è riuscito a recuperare le credenziali dal plug-in: %1. Errore: %2 | Questo evento indica che il plug-in è stato caricato, ma non è stato in grado di ottenere le credenziali necessarie per recuperare la password gMSA da Active Directory. È necessario verificare che l'input per il plug-in sia formattato correttamente nella specifica delle credenziali e che l'host contenitore disponga delle autorizzazioni necessarie per accedere all'archivio segreto usato dal plug-in. |
7 | Container Credential Guard recupera le credenziali usando il plug-in: %1 | Si tratta di un evento informativo. Questo evento viene generato quando la password del gMSA (Group Managed Service Account) è scaduta e deve essere rinnovata utilizzando le credenziali recuperate dal plug-in. |
8 | Container Credential Guard non è riuscito a recuperare le credenziali gmsa per %1 usando il plug-in %2. Motivo dell'errore: %3 | Questo evento indica che le credenziali recuperate usando il plug-in non hanno potuto essere usate per recuperare le credenziali dell'account del servizio gestito del gruppo (gMSA) da AD. È necessario verificare che l'account recuperato dal plug-in disponga delle autorizzazioni in Active Directory (AD) per recuperare le credenziali gMSA. |