Solucionar problemas das gMSAs para contêineres do Windows

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

Problemas conhecidos

O nome do host do contêiner deve corresponder à gMSA do 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 seu contêiner deverá corresponder ao nome de conta do seu SAM da gMSA.

Quando o nome do host não corresponde ao nome da 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. O Kerberos continuará a funcionar normalmente mesmo que o nome do host e da gMSA não correspondam.

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

Usar uma gMSA com mais de um contêiner leva simultaneamente a falhas intermitentes no Windows Server 2016 e Windows 10, versões 1709 e 1803

Como todos os contêineres são necessários para usar o mesmo nome do host, um segundo problema afeta versões do Windows anteriores ao Windows Server 2019 e ao Windows 10, versão 1809. Quando vários contêineres são atribuídos à mesma identidade e nome do host, uma condição de corrida pode ocorrer quando dois contêineres falam com o mesmo controlador de domínio simultaneamente. Quando outro contêiner se comunica com o mesmo controlador de domínio, ele cancelará a comunicação com os contêineres anteriores usando a mesma identidade. Isso pode levar a falhas intermitentes de autenticação e, às vezes, pode ser observado como uma falha de confiança quando você executa nltest /sc_verify:contoso.com dentro do contêiner.

Alteramos o comportamento no Windows Server 2019 para separar a identidade do contêiner do nome do computador, permitindo que vários contêineres usem o mesmo gMSA simultaneamente. Portanto, no Windows Server 2019, você pode executar vários contêineres com a mesma identidade, tanto no mesmo quanto em vários hosts.

Você não pode usar as gMSAs com contêineres isolados do Hyper-V nas versões 1703, 1709 e 1803 do Windows 10

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

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

Diretrizes para a solução de problemas gerais

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

Hosts conectados ao domínio: verifique se o host pode usar a gMSA

1. Verifique se o host está ingressado no domínio e pode acessar o controlador de domínio.

2. Instale as Ferramentas do PowerShell para Active Directory no RSAT e execute Test-ADServiceAccount para ver se o computador tem acesso para recuperar a gMSA. Se o cmdlet retornar False, o computador não terá acesso à senha da 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 o Test-ADServiceAccount retornar False, verifique se o host pertence a um grupo de segurança que pode acessar a senha da 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 host pertencer a um grupo de segurança autorizado a recuperar a senha da gMSA, mas ainda estiver apresentando falhas no Test-ADServiceAccount, talvez seja necessário reiniciar o computador para obter um novo tíquete que reflete suas associações de grupo atuais.

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

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

Verificar o arquivo de especificação de credencial

1. Execute Get-CredentialSpec no módulo CredentialSpec PowerShell para localizar todas as especificações de credencial no computador. As especificações de credencial 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 campos a seguir estão preenchidos corretamente:

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

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

      Sua entrada deve ser semelhante ao exemplo a seguir 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 conectados ao domínio: além de todos os campos do host de contêiner não conectado ao domínio, verifique se a seção "HostAccountConfig" está presente e se os campos abaixo estão definidos corretamente.

      • PortableCcgVersion: recomendamos definir como "1".
      • PluginGUID: o COM CLSID do plug-in ccg.exe. Ele é exclusivo para o plug-in que está sendo usado.
      • PluginInput: entrada específica do plug-in usada para recuperar informações da conta de usuário do repositório de segredos.

      Sua entrada deve ser semelhante ao exemplo a seguir 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 credencial está correto para sua solução de orquestração. Se você estiver usando o Docker, verifique se o comando de execução do contêiner inclui --security-opt="credentialspec=file://NAME.json", em que “NAME. JSON” é substituído pela saída do nome por Get-CredentialSpec. O nome é um nome de arquivo simples, relativo à pasta CredentialSpecs no diretório raiz do Docker.

Verificar a configuração de rede

Verificar a configuração do firewall

Se você estiver usando uma política de firewall estrita no contêiner ou na rede do host, ele poderá bloquear as conexões necessárias para o controlador de Domínio do Active 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 Requisitos de porta do Active Directory e do Active Directory Domain Services para obter uma lista completa de portas usadas pelo Active Directory.

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

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

nltest /sc_verify:contoso.com

Verificar o contêiner

1. Se você estiver executando uma versão do Windows anterior ao Windows Server 2019 ou ao Windows 10, versão 1809, o nome do host do contêiner deverá corresponder à gMSA. Verifique se o parâmetro --hostname corresponde ao nome curto da gMSA (nenhum componente do 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 da gMSA. Os servidores DNS mal configurados no contêiner são um culpado comum dos 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 um equivalente):

   nltest /sc_verify:contoso.com
   

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

4. Verifique se o contêiner pode obter um tíquete de concessão de tíquete Kerberos (TGT) válido:

   klist get <myapp>
   

   Esse comando deve retornar a mensagem “Um tíquete para krbtgt foi recuperado com êxito” e listar o controlador do domínio usado para recuperar o tíquete. Se você conseguir obter um TGT, mas o nltest da etapa anterior falhar, isso pode ser uma indicação de que a conta gMSA está configurada incorretamente. Consulte Verificar a conta gMSA para obter mais informações.

   Se você não puder obter um TGT dentro do contêiner, isso poderá indicar problemas de conectividade de DNS ou 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 pode ser roteado a partir do contêiner.

5. Verifique se seu aplicativo está configurado para usar a gMSA. A conta de usuário dentro do contêiner não é alterada quando você usa uma gMSA. Em vez disso, a conta do sistema usa a gMSA quando conversa com outros recursos de rede. Isso significa que seu aplicativo precisará ser executado como Serviço de Rede ou Sistema Local para usar a identidade da gMSA.

   Dica

   Se você executar whoami ou usar outra ferramenta para identificar o contexto do usuário atual no contêiner, você não verá o nome da 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. A gMSA é usada pela conta de computador sempre que se comunica com os recursos de rede e, por esta razão, seu aplicativo precisa ser executado como um Serviço de Rede ou Sistema Local.

Verificar a conta da gMSA

1. Se o seu contêiner parece estar configurado corretamente, mas os usuários ou outros serviços não podem se autenticar automaticamente em seu aplicativo em contêiner, verifique os SPNs em sua conta da gMSA. Os clientes localizarão a conta gMSA pelo nome com o qual eles encontram seu aplicativo. Isso pode significar que você precisará de SPNs de host adicionais para sua 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 a gMSA com um host de contêiner conectado ao domínio, cerifique se a gMSA e o host do contêiner pertencem ao mesmo domínio do Active Directory. O host do contêiner não poderá recuperar a senha da gMSA se ela pertencer a um domínio diferente.

3. Verifique se há apenas uma conta em seu domínio com o mesmo nome que a sua gMSA. Os objetos da gMSA têm cifrões ($) anexados aos nomes de sua conta SAM, portanto, é possível que uma gMSA seja nomeada “myaccount $” e uma conta de usuário não relacionada seja nomeada “myaccount” no mesmo domínio. Isso pode causar problemas se o controlador de domínio ou o aplicativo tiver que procurar a gMSA por nome. Você pode pesquisar no AD para encontrar objetos nomeados de forma semelhante com o seguinte comando:

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

4. Se você tiver habilitado a delegação irrestrita na conta gMSA, verifique se o atributo UserAccountControl ainda tem o sinalizador WORKSTATION_TRUST_ACCOUNT habilitado. Esse sinalizador é necessário para que o NETLOGON no contêiner se comunique com o controlador de domínio, como é o caso quando um aplicativo tem que resolver um nome para 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 contêiner não conectado ao domínio: use logs de eventos para identificar problemas de configuração

O registro de eventos para o uso da gMSA com hosts de contêiner não conectado ao domínio pode ser usado para identificar problemas de configuração. Os eventos estão registrados no arquivo de log Microsoft-Windows-Containers-CCG e podem ser encontrados no Visualizador de Eventos em Logs de Aplicativos e Serviços\Microsoft\Windows\Containers-CCG\Admin. Se você exportar esse arquivo de log do host do contêiner para lê-lo, será preciso ter o recurso de contêineres habilitado no dispositivo no qual está tentando ler o arquivo de log e estar usando uma versão do Windows que dá suporte ao uso da gMSA com hosts de contêiner não conectado ao domínio.

Eventos e descrições