Compartilhar via

Solucionar problemas de gMSAs para contêineres do Windows

  • Artigo

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 (usada por muitas bibliotecas, como o provedor de função de associação ASP.NET) falharão. Kerberos continuará funcionando normalmente mesmo que o nome do host e o nome gMSA não correspondam.

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

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

Como todos os contêineres são necessários para usar o mesmo nome de host, um segundo problema afeta as versões do Windows antes do Windows Server 2019 e do Windows 10, versão 1809. Quando vários contêineres recebem a mesma identidade e nome de host, uma condição de corrida pode ocorrer quando dois contêineres conversam simultaneamente com o mesmo controlador de domínio. Quando outro contêiner fala com o mesmo controlador de domínio, ele cancela a comunicação com todos os 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.

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, seja no mesmo ou em vários hosts.

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

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

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

Diretrizes gerais de soluçã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 conectados ao domínio: verifique se o host pode usar gMSA

  1. Verifique se o host está conectado ao domínio e se pode alcançar o controlador de domínio.

  2. Instale as Ferramentas do PowerShell do AD do RSAT e execute Test-ADServiceAccount para verificar se o computador tem acesso para recuperar a 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 retornar False, verifique se o host pertence a um grupo de segurança que pode acessar a 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 host pertencer a um grupo de segurança autorizado a recuperar a senha gMSA, mas ainda estiver falhando em Test-ADServiceAccount, talvez seja necessário reiniciar o computador para obter um novo tíquete refletindo 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 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 exige que você forneça um plug-in 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 do 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 seguintes campos estão preenchidos corretamente:

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

      • Sid: o SID do seu domínio
      • MachineAccountName: o Nome da Conta SAM do gMSA (não inclua o nome de domínio completo ou o sinal de dólar)
      • 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 a gMSA pertence
      • GroupManagedServiceAccounts/Name: o nome da conta SAM do gMSA (não inclua elementos do nome de domínio completo nem cifrão)
      • GroupManagedServiceAccounts/Scope: uma entrada para o FQDN de 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: deve ser definido como "1".
      • PluginGUID: o COM CLSID do plug-in ccg.exe. Isso é exclusivo para o plug-in que está sendo usado.
      • PluginInput: entrada específica do plug-in para recuperar as 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 credenciais está correto para sua solução de orquestração. Se você estiver usando Docker, verifique se o comando de execução do contêiner inclui --security-opt="credentialspec=file://NAME.json", em que "NAME.json" é substituído pelo nome de saída do Get-CredentialSpec. O nome é um nome de arquivo simples em relação à 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 na rede de contêineres ou host, ela poderá bloquear as conexões necessárias com o Controlador de Domínio do Active Directory ou o servidor DNS.

Protocolo e porta Propósito
TCP e UDP 53 DNS
TCP e UDP 88 Kerberos
TCP 139 NetLogon
TCP e UDP 389 LDAP
TCP 636 LDAP SSL

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. Confira 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 de DNS do host de contêiner

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

nltest /sc_verify:contoso.com

Verificar o contêiner

  1. Se você estiver executando uma versão do Windows antes do Windows Server 2019 ou do Windows 10, versão 1809, o nome do host do 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 de contêiner para verificar se o contêiner pode resolver e acessar um controlador de domínio para o domínio da gMSA. Servidores DNS configurados incorretamente 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 deverá retornar NERR_SUCCESS se a 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 contêiner pode obter um TGT (Ticket Granting Ticket) válido do Kerberos:

    klist get <myapp>

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

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

  5. Verifique se o aplicativo está configurado para usar o 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 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 o contexto atual do usuário 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. A gMSA é usada pela conta de computador sempre que fala com recursos de rede, razão pela qual seu aplicativo precisa ser executado como Serviço de Rede ou Sistema Local.

Verificar a conta gMSA

  1. Se o contêiner parecer estar configurado corretamente, mas os usuários ou outros serviços não puderem se autenticar automaticamente em seu aplicativo em contêineres, verifique os SPNs em sua conta gMSA. Os clientes localizarão a conta gMSA pelo nome com o qual eles acessarão 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 de contêiner não poderá recuperar a senha gMSA se a gMSA pertencer a um domínio diferente.

  3. Verifique se há apenas uma conta em seu domínio com o mesmo nome que sua gMSA. Os objetos gMSA têm sinais de dólar ($) acrescentados aos nomes da 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 precisar pesquisar a gMSA pelo nome. Você pode pesquisar objetos nomeados da mesma forma no AD 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 irrestrita na conta gMSA, verifique se o atributo UserAccountControl ainda possui a flag WORKSTATION_TRUST_ACCOUNT habilitada. Este flag é necessário para que o NETLOGON no contêiner se comunique com o controlador de domínio, como é o caso quando um aplicativo 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 contêiner que não fazem parte do domínio: use registros de eventos para identificar problemas de configuração

O registro de eventos para o uso de gMSA com hosts de contêiner que não estão no domínio pode ser utilizado para identificar problemas de configuração. Os eventos sã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 leitura, deverá ter o recurso de contêineres habilitado no dispositivo em que você está tentando ler o arquivo de log e deve estar em uma versão do Windows que suporte o uso de gMSA com hosts de contêineres não associados ao domínio.

Eventos e descrições

Número do evento Texto do evento Descrição
1 A Proteção de Credencial de Contêiner criou uma instância do plug-in Esse evento indica que o plug-in especificado na Especificação de Credencial foi instalado e pode ser carregado. Nenhuma ação é necessária.
2 A Proteção de Credencial de Contêiner buscou as credenciais da gmsa para %1 usando o plug-in: %2 Este é um evento informativo que indica que as credenciais gMSA foram recuperadas com sucesso do Active Directory. Nenhuma ação é necessária.
3 Falha do Container Credential Guard ao analisar a especificação de credencial. Erro: %1 Esse evento indica um problema com a especificação de credencial. Isso poderá ocorrer se o GUID do plug-in estiver incorreto ou se houver outros campos malformados. Revise as diretrizes de solução de problemas da especificação de credencial a fim de verificar a formatação e o conteúdo da especificação de credencial.
4 O Container Credential Guard falhou ao instanciar o plug-in: %1. Erro: %2 Esse evento indica que o plug-in não pôde ser carregado. Você deve verificar se o plug-in foi instalado corretamente no host
6 O Container Credential Guard falhou ao buscar credenciais do plug-in: %1. Erro: %2 Esse evento indica que o plug-in foi carregado, mas não pôde recuperar as credenciais necessárias para buscar a senha gMSA do AD. Você deve verificar se a entrada no plug-in está formatada corretamente na especificação de credencial e se o host do contêiner tem as permissões necessárias para acessar o repositório secreto usado pelo plug-in.
7 A Proteção de Credencial de Contêiner falhou ao buscar novamente as credenciais usando o plug-in: %1 Este é um evento informativo. Esse evento é gerado quando a senha gMSA expirou e precisa ser atualizada usando as credenciais buscadas pelo plug-in.
8 O Container Credential Guard não conseguiu buscar credenciais gmsa para %1 usando o plug-in %2. Motivo do erro: %3 Esse evento indica que as credenciais buscadas usando o plug-in não puderam ser usadas para buscar credenciais gMSA do AD. Você deve verificar se a conta que está sendo buscada do plug-in tem permissões no AD para recuperar as credenciais gMSA.