Solucionar problemas de gMSAs para contêineres do Windows

Aplica-se a: Windows Server 2025, Windows Server 2022, Windows Server 2019

Problemas conhecidos

O nome do host do contêiner deve corresponder ao nome gMSA para Windows Server 2016 e Windows 10, versões 1709 e 1803

Se você estiver executando o Windows Server 2016, versão 1709 ou 1803, o nome do host do contêiner deverá corresponder ao Nome da Conta SAM gMSA.

Quando o nome do host não corresponder ao nome gMSA, as solicitações de autenticação NTLM de entrada e a conversão de nome/SID (usadas por muitas bibliotecas, como o provedor de função de associação ASP.NET) falharão. Kerberos continuará a funcionar normalmente mesmo se o nome do host e o nome gMSA não corresponderem.

Essa limitação foi corrigida no Windows Server 2019, onde o contêiner agora sempre usará seu nome gMSA na rede, independentemente do nome de host atribuído.

Não é possível usar gMSAs com contentores isolados Hyper-V no Windows 10 versões 1703, 1709 e 1803

A inicialização do contêiner travará ou falhará quando você tentar usar um gMSA com um contêiner isolado Hyper-V no Windows 10 e no Windows Server versões 1703, 1709 e 1803.

Este bug foi corrigido no Windows Server 2019 e Windows 10, versão 1809. Você também pode executar contêineres isolados Hyper-V com gMSAs no Windows Server 2016 e no Windows 10, versão 1607.

Usar um gMSA com mais de um container simultaneamente leva a falhas intermitentes no Windows Server 2019 e versões superiores se o parâmetro hostname for especificado

Todos os contêineres usam a conta gMSA quando vários contêineres recebem a mesma identidade. Com o parâmetro --hostname, o nome da conta gmsa é especificado e uma condição de disputa pode ocorrer quando dois contentores comunicam com o mesmo controlador de domínio simultaneamente. Quando outro contêiner fala com o mesmo controlador de domínio, ele cancela a comunicação com quaisquer contêineres anteriores usando a mesma identidade.

Isso pode levar a falhas de autenticação intermitentes e, às vezes, pode ser observado como uma falha de confiança quando você executa nltest /sc_verify:contoso.com dentro do contêiner. Para evitar esse problema no contêiner do docker, se o --hostname parâmetro for especificado, ele deverá ser sempre exclusivo ao executar o contêiner simultaneamente com a conta gmsa. Por exemplo, se a conta gmsa for "webapp01.contoso.com" e dois contêineres estiverem a ser executados simultaneamente, ambos os contêineres podem ter o parâmetro --hostname com os valores "webapp01" e "webapp02", respetivamente.

Orientações gerais para resolução de problemas

Se você estiver encontrando erros ao executar um contêiner com um gMSA, as instruções a seguir podem ajudá-lo a identificar a causa raiz.

Hosts ligados ao domínio: certifique-se de que o host pode usar o gMSA

1. Verifique se o host ingressou no domínio e pode acessar o controlador de domínio.

2. Instale as Ferramentas do AD PowerShell a partir do RSAT e execute Test-ADServiceAccount para ver se o computador tem acesso para recuperar o gMSA. Se o cmdlet retornar False, o computador não terá acesso à senha 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. Se Test-ADServiceAccount devolver False, verifique se o host pertence a um grupo de segurança que tenha acesso à senha 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. Se o seu servidor pertencer a um grupo de segurança autorizado a recuperar a palavra-passe gMSA, mas ainda assim falhar no teste Test-ADServiceAccount, poderá ter de reiniciar o computador para obter um novo ticket que reflita as suas atuais associações de grupo.

Hosts não associados ao domínio: verifique se o host está configurado para recuperar a conta gMSA

Verifique se um plug-in para usar gMSA com um host de contêiner não associado ao domínio está instalado corretamente no host. O Windows não inclui um plug-in interno e requer que você forneça um plug-in que implemente o interface ICcgDomainAuthCredentials. Os detalhes da instalação serão específicos do plug-in.

Verifique o arquivo de especificação de credencial

1. Execute Get-CredentialSpec a partir do módulo CredentialSpec PowerShell para localizar todas as especificações de credenciais na máquina. As especificações de credenciais devem ser armazenadas no diretório "CredentialSpecs" no diretório raiz do Docker. Você pode encontrar o diretório raiz do Docker executando docker info -f "{{. DockerRootDir}}".

2. Abra o arquivo CredentialSpec e verifique se os seguintes campos estão preenchidos corretamente:

   1. Para hosts de contêiner associados ao domínio:

      • Sid: o SID do seu domínio
      • MachineAccountName: o nome de conta SAM do gMSA (não inclua o nome de domínio completo ou cifrão)
      • DnsTreeName: o FQDN da floresta do Active Directory
      • DnsName: o FQDN do domínio ao qual o gMSA pertence
      • NetBiosName: Nome NETBIOS para o domínio ao qual o gMSA pertence
      • GroupManagedServiceAccounts/Name: o nome da conta SAM do gMSA (não inclua o nome de domínio completo nem o sinal de dólar)
      • GroupManagedServiceAccounts/Scope: uma entrada para o FQDN do domínio e outra para o NETBIOS

      A sua entrada deve assemelhar-se ao seguinte exemplo de uma especificação de credencial 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. Para hosts não associados ao domínio: Além de todos os campos de host de contentor não associados ao domínio, verifique se a seção "HostAccountConfig" está presente e se os campos abaixo estão definidos corretamente.

      • PortableCcgVersion: Deve ser definido como "1".
      • PluginGUID: O COM CLSID para o seu plug-in ccg.exe. Isso é exclusivo do plug-in que está sendo usado.
      • PluginInput: Entrada específica do plug-in para recuperar a informação da conta do utilizador do repositório secreto.

      A sua entrada deve assemelhar-se ao seguinte exemplo de uma especificação de credencial 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. Verifique se o caminho para o arquivo de especificação de credenciais está correto para sua solução de orquestração. Se estiver a usar o Docker, certifique-se de que o comando de execução do container inclui --security-opt="credentialspec=file://NAME.json", onde "NAME.json" é substituído pelo nome de saída pelo Get-CredentialSpec. O nome é um nome de arquivo simples, relativo à pasta CredentialSpecs no diretório raiz do Docker.

Verifique a configuração da rede

Verifique a configuração do firewall

Se você estiver usando uma diretiva de firewall rígida no contêiner ou na rede host, ela poderá bloquear as conexões necessárias com o Controlador de Domínio Ative Directory ou o servidor DNS.

Talvez seja necessário permitir o acesso a portas adicionais, dependendo do tipo de tráfego que seu contêiner envia para um controlador de domínio. Consulte os requisitos de porta do Active Directory e dos Serviços de Domínio do Active Directory para obter uma lista completa das portas usadas pelo Active Directory.

Verifique a configuração DNS do host do contêiner

Se você estiver usando o gMSA com um host de contêiner associado ao domínio, o DNS deverá ser configurado automaticamente no host para que ele possa resolver e estabelecer uma conexão com o domínio corretamente. Se estiver a usar o gMSA com um host que não está associado ao domínio, esta configuração não será definida automaticamente. Você deve verificar se a rede host está configurada para que possa resolver o domínio. Você pode verificar se o domínio pode ser resolvido a partir do host usando:

nltest /sc_verify:contoso.com

Verifique o recipiente

1. Se você estiver executando uma versão do Windows anterior ao Windows Server 2019 ou ao Windows 10, versão 1809, seu nome de host de contêiner deverá corresponder ao nome gMSA. Verifique se o parâmetro --hostname corresponde ao nome curto gMSA (sem componente de domínio; por exemplo, "webapp01" em vez de "webapp01.contoso.com").

2. Verifique a configuração de rede do contêiner para verificar se o contêiner pode resolver e acessar um controlador de domínio para o domínio do gMSA. Servidores DNS mal configurados no contêiner são um culpado comum de problemas de identidade.

3. Verifique se o contêiner tem uma conexão válida com o domínio executando o seguinte cmdlet no contêiner (usando docker exec ou equivalente):

   nltest /sc_verify:contoso.com
   

   A verificação de confiança deve retornar NERR_SUCCESS se o gMSA estiver disponível e a conectividade de rede permitir que o contêiner fale com o domínio. Se falhar, verifique a configuração de rede do host e do contêiner. Ambos precisam ser capazes de se comunicar com o controlador de domínio.

4. Verifique se o contentor consegue obter um Ticket Granting Ticket (TGT) Kerberos válido:

   klist get <myapp>
   

   Este comando deve retornar "Um ticket para krbtgt foi recuperado com sucesso" e listar o controlador de domínio usado para recuperar o ticket. Se você conseguir obter um TGT, mas nltest da etapa anterior falhar, isso pode ser uma indicação de que a conta gMSA está configurada incorretamente. Consulte e verifique a conta gMSA para obter mais informações.

   Se não for possível obter um TGT dentro do contêiner, isso pode indicar problemas de DNS ou conectividade de rede. Verifique se o contêiner pode resolver um controlador de domínio usando o nome DNS do domínio e se o controlador de domínio é roteável a partir do contêiner.

5. Verifique se a sua aplicação está configurada para usar o gMSA. A conta de usuário dentro do contêiner não muda quando você usa um gMSA. Em vez disso, a conta System usa o gMSA quando fala com outros recursos de rede. Isso significa que seu aplicativo precisará ser executado como Serviço de Rede ou Sistema Local para aproveitar a identidade gMSA.

   Dica

   Se você executar whoami ou usar outra ferramenta para identificar seu contexto de usuário atual no contêiner, não verá o nome gMSA em si. Isso ocorre porque você sempre entra no contêiner como um usuário local em vez de uma identidade de domínio. O gMSA é usado pela conta do computador sempre que ele fala com recursos de rede, e é por isso que seu aplicativo precisa ser executado como Serviço de Rede ou Sistema Local.

Verifique a conta gMSA

1. Se o contêiner parecer estar configurado corretamente, mas os usuários ou outros serviços não conseguirem se autenticar automaticamente no aplicativo em contêiner, verifique os SPNs na sua conta gMSA. Os clientes localizarão a conta gMSA pelo nome no qual chegarão ao seu aplicativo. Isso pode significar que você precisará de SPNs de host adicionais para seu gMSA se, por exemplo, os clientes se conectarem ao seu aplicativo por meio de um balanceador de carga ou um nome DNS diferente.

2. Para usar o gMSA com um host de contêiner associado ao domínio, verifique se o gMSA e o host de contêiner pertencem ao mesmo domínio do Ative Directory. O host do contêiner não poderá recuperar a senha do gMSA se o gMSA pertencer a um domínio diferente.

3. Certifique-se de que existe apenas uma conta no seu domínio com o mesmo nome que o seu gMSA. Os objetos gMSA têm cifrões ($) anexados aos seus nomes de conta SAM, portanto, é possível que um gMSA seja chamado de "myaccount$" e uma conta de usuário não relacionada seja chamada de "myaccount" no mesmo domínio. Isso pode causar problemas se o controlador de domínio ou aplicativo tiver que procurar o gMSA pelo nome. Pode procurar no AD objetos com nomes semelhantes com o seguinte comando:

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

4. Se você habilitou a delegação sem restrições na conta gMSA, verifique se o atributo UserAccountControl ainda tem o sinalizador WORKSTATION_TRUST_ACCOUNT habilitado. Esta bandeira é necessária para o NETLOGON no container para que comunique com o controlador de domínio, tal como no caso em que uma aplicação precisa resolver um nome em um SID ou vice-versa. Você pode verificar se o sinalizador está configurado corretamente com os seguintes comandos:

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

   Se os comandos acima retornarem False, use o seguinte para adicionar o sinalizador WORKSTATION_TRUST_ACCOUNT à propriedade UserAccountControl da conta gMSA. Esse comando também limpará os sinalizadores NORMAL_ACCOUNT, INTERDOMAIN_TRUST_ACCOUNTe SERVER_TRUST_ACCOUNT da propriedade UserAccountControl.

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

Hosts de contentores não associados ao domínio: utilize logs de eventos para identificar problemas de configuração

O log de eventos para usar o gMSA com hosts de contêiner não associados ao domínio pode ser usado para identificar problemas de configuração. Os eventos são registados no ficheiro de log Microsoft-Windows-Containers-CCG e podem ser encontrados no Visualizador de Eventos em Registos de Aplicações e Serviços\Microsoft\Windows\Containers-CCG\Admin. Se exportar este ficheiro de log do anfitrião do contentor para o ler, deve ter o recurso de contentores ativado no dispositivo onde está a tentar ler o ficheiro de log e deve estar numa versão do Windows que suporte o uso do gMSA com anfitriões de contentores não ligados ao domínio.

Eventos e Descrições