Compartir a través de

Solución de problemas de gMSA para contenedores de Windows

  • Artículo

Se aplica a: Windows Server 2022, Windows Server 2019

Problemas conocidos

El nombre de host del contenedor debe coincidir con el nombre de gMSA para Windows Server 2016 y Windows 10, versiones 1709 y 1803

Si ejecutas Windows Server 2016, versión 1709 o 1803, el nombre de host del contenedor debe coincidir con el nombre de cuenta SAM de gMSA.

Cuando el nombre de host no coincida con el nombre de gMSA, se producirá un error en las solicitudes de autenticación NTLM entrante y la traducción de nombre/SID (que usan muchas bibliotecas, como el proveedor de roles de pertenencia a ASP.NET). Kerberos seguirá funcionando con normalidad aunque el nombre de host y el nombre de gMSA no coincidan.

Esta limitación se corrigió en Windows Server 2019, donde el contenedor ahora usará siempre su nombre de gMSA en la red, independientemente del nombre de host asignado.

El uso simultáneo de una gMSA con más de un contenedor conduce a errores intermitentes en Windows Server 2016 y Windows 10, versiones 1709 y 1803

Dado que todos los contenedores deben usar el mismo nombre de host, un segundo problema afecta a las versiones de Windows anteriores a Windows Server 2019 y Windows 10, versión 1809. Cuando se asignan a varios contenedores la misma identidad y nombre de host, se puede producir una condición de carrera cuando dos contenedores se comunican a la vez con el mismo controlador de dominio. Cuando otro contenedor se comunica con el mismo controlador de dominio, cancelará la comunicación con los contenedores anteriores que usen la misma identidad. Esto puede producir errores de autenticación intermitentes y, a veces, se puede observar como un error de confianza al ejecutar nltest /sc_verify:contoso.com dentro del contenedor.

Hemos cambiado el comportamiento en Windows Server 2019 para separar la identidad del contenedor del nombre de la máquina, lo que permite que varios contenedores usen la misma gMSA simultáneamente. Por lo tanto, en Windows Server 2019, puede ejecutar varios contenedores con la misma identidad, ya sea en el mismo host o en varios.

No puedes usar varias gMSA con contenedores aislados de Hyper-V en las versiones 1703, 1709 y 1803 de Windows 10.

La inicialización del contenedor se bloqueará o se producirá un error al intentar usar una gMSA con un contenedor aislado con Hyper-V en Windows 10 y Windows Server, versiones 1703, 1709 y 1803.

Este error se corrigió en Windows Server 2019 y Windows 10, versión 1809. También puedes ejecutar contenedores aislados con Hyper-V con gMSA en Windows Server 2016 y Windows 10, versión 1607.

Guía general para la solución de problemas

Si encuentras errores al ejecutar un contenedor con una gMSA, las instrucciones siguientes pueden ayudarte a detectar la causa.

Hosts unidos a un dominio: asegúrese de que el host puede usar gMSA.

  1. Verifica que el host está unido a un dominio y puede comunicarse con el controlador de dominio.

  2. Instala las herramientas de PowerShell de AD desde RSAT y ejecuta test-ADServiceAccount para ver si el equipo tiene acceso para recuperar las gMSA. Si el cmdlet devuelve False, el equipo no tiene acceso a la contraseña de 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. Si test-ADServiceAccount devuelve False, verifica que el host pertenezca a un grupo de seguridad que tenga acceso a la contraseña de 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. Si el host pertenece a un grupo de seguridad autorizado a recuperar la contraseña de gMSA, pero aún no supera Test-ADServiceAccount, es posible que tengas que reiniciar el equipo para obtener un nuevo vale que refleje tus pertenencias a grupos actuales.

Hosts no unidos a un dominio: asegúrese de que el host está configurado para recuperar la cuenta gMSA.

Compruebe que haya un complemento correctamente instalado en el host para poder usar gMSA con un host de contenedor no unido a un dominio. Windows no incluye un complemento integrado y requiere que proporcione un complemento que implemente la interfaz ICcgDomainAuthCredentials. Los detalles de la instalación serán específicos del complemento.

Comprobación del archivo de especificación de credenciales

  1. Ejecuta Get-CredentialSpec desde el módulo CredentialSpec de PowerShell para buscar todas las especificaciones de credenciales en la máquina. Las especificaciones de credenciales deben almacenarse en el directorio "CredentialSpecs" en el directorio raíz de Docker. Puedes encontrar el directorio raíz de Docker ejecutando docker info -f "{{.DockerRootDir}}" .

  2. Abre el archivo CredentialSpec y asegúrate de que los siguientes campos se han rellenado correctamente:

    1. Para hosts de contenedor unidos a un dominio:

      • Sid: SID del dominio
      • MachineAccountName: Nombre de cuenta SAM de gMSA (no incluyas el nombre de dominio completo ni el signo de dólar)
      • DnsTreeName: FQDN del bosque de Active Directory
      • DnsName: FQDN del dominio al que pertenece la gMSA
      • NetBiosName: Nombre NETBIOS del dominio al que pertenece la gMSA
      • GroupManagedServiceAccounts/Name: Nombre de cuenta SAM de gMSA (no incluyas el nombre de dominio completo ni el signo de dólar)
      • GroupManagedServiceAccounts/Scope: Entrada para el FQDN de dominio y otra para NETBIOS

      La entrada debe ser similar a la del ejemplo siguiente de una especificación de credenciales 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 que no están unidos a un dominio: además de todos los campos de host de contenedores no unidos a ningún dominio, asegúrese de que la sección "HostAccountConfig" está presente y de que los campos siguientes están definidos correctamente.

      • PortableCcgVersion: debe establecerse en "1".
      • PluginGUID: COM CLSID para el complemento ccg.exe. Es único para el complemento que se usa.
      • PluginInput: entrada específica del complemento para recuperar la información de la cuenta de usuario del almacén de secretos.

      La entrada debe ser similar a la del ejemplo siguiente de una especificación de credenciales 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 que la ruta de acceso al archivo de especificación de credenciales es correcta para la solución de orquestación. Si usas Docker, asegúrate de que el comando de ejecución del contenedor incluya --security-opt="credentialspec=file://NAME.json", donde "NAME.json" se reemplaza por el nombre generado por Get-CredentialSpec. El nombre es un nombre de archivo plano, relativo a la carpeta CredentialSpecs en el directorio raíz de Docker.

comprobar la configuración de la red

Comprobación de la configuración del firewall

Si usas una directiva de firewall estricta en el contenedor o en la red host, puede que bloquee las conexiones necesarias al controlador de dominio de Active Directory o al servidor DNS.

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

Es posible que necesites permitir el acceso a puertos adicionales en función del tipo de tráfico que el contenedor envíe a un controlador de dominio. Para obtener una lista completa de los puertos que usa Active Directory, consulta Requisitos de puerto de Active Directory y Active Directory Domain Services.

Comprobación de la configuración de DNS del host de contenedor

Si usa gMSA con un host de contenedor unido a un dominio, DNS se debe configurar automáticamente en el host para que pueda resolverse correctamente y establecer una conexión con el dominio. Si usa gMSA con un host que no está unido a ningún dominio, esta configuración no se establecerá automáticamente. Debe comprobar que la red del host está configurada para que pueda resolver el dominio. Puede comprobar que el dominio se puede resolver desde el host mediante:

nltest /sc_verify:contoso.com

Comprobación del contenedor

  1. Si ejecutas una versión de Windows anterior a Windows Server 2019 o Windows 10, versión 1809, el nombre de host del contenedor debe coincidir con el nombre de la gMSA. Asegúrate de que el parámetro --hostname coincida con el nombre corto de la gMSA (sin el componente de dominio; por ejemplo, "webapp01" en lugar de "webapp01.contoso.com").

  2. Comprueba la configuración de red del contenedor para verificar que el contenedor pueda resolver y acceder a un controlador de dominio para el dominio de la gMSA. Los servidores DNS mal configurados en el contenedor son una causa común de los problemas de identidad.

  3. Para comprobar si el contenedor tiene una conexión válida al dominio, ejecuta el siguiente cmdlet en el contenedor (con docker exec o equivalente):

    nltest /sc_verify:contoso.com

    La verificación de confianza debe devolver NERR_SUCCESS si la gMSA está disponible y la conectividad de red permite que el contenedor se comunique con el dominio. Si se produce un error, verifica la configuración de red del host y del contenedor. Ambos deben poder comunicarse con el controlador de dominio.

  4. Comprueba si el contenedor puede obtener un servicio de concesión de vales (TGT) de Kerberos válido:

    klist get <myapp>

    Este comando debe devolver "Un vale para krbtgt se ha recuperado correctamente" y mostrar el controlador de dominio usado para recuperar el vale. Si puedes obtener un TGT, pero nltest del paso anterior genera un error, esto puede indicar que la cuenta gMSA está mal configurada. Para obtener más información, consulta Comprobación de la cuenta gMSA.

    Si no puedes obtener un TGT dentro del contenedor, esto puede indicar problemas de conectividad de red o DNS. Asegúrate de que el contenedor pueda resolver un controlador de dominio con el nombre DNS del dominio, y que el controlador de dominio se puede enrutar desde el contenedor.

  5. Asegúrate de que la aplicación esté configurada para usar la gMSA. La cuenta de usuario dentro del contenedor no cambia cuando se usa una gMSA. En su lugar, la cuenta del sistema usa la gMSA cuando se comunica con otros recursos de red. Es decir, la aplicación tendrá que ejecutarse como servicio de red o sistema local para aprovechar la identidad de la gMSA.

    Sugerencia

    Si ejecutas whoami o usas otra herramienta para identificar el contexto de usuario actual en el contenedor, no verás el nombre mismo de la gMSA. Esto se debe a que siempre inicias sesión en el contenedor como usuario local en lugar de con una identidad de dominio. La cuenta de equipo usa la gMSA cada vez que se comunica con recursos de red, por lo que la aplicación debe ejecutarse como servicio de red o sistema local.

Comprobación de la cuenta gMSA

  1. Si el contenedor parece estar configurado correctamente, pero los usuarios u otros servicios no pueden autenticarse automáticamente en la aplicación en contenedores, comprueba los SPN de la cuenta gMSA. Los clientes encontrarán la cuenta gMSA por el nombre por el que llegan a tu aplicación. Esto puede significar que necesitarán SPN host adicionales para tu gMSA si, por ejemplo, los clientes se conectan a tu aplicación a través de un equilibrador de carga u otro nombre DNS.

  2. Para usar gMSA con un host de contenedor unido a un dominio, asegúrese de que gMSA y el host de contenedor pertenecen al mismo dominio de Active Directory. El host de contenedor no podrá recuperar la contraseña de la gMSA si la gMSA pertenece a otro dominio.

  3. Asegúrate de que solo haya una cuenta en el dominio con el mismo nombre que tu gMSA. Los objetos gMSA tienen signos de dólar ($) anexados a sus nombres de cuenta SAM, por lo que es posible que una gMSA tenga el nombre "micuenta$" y que una cuenta de usuario no relacionada se denomine "micuenta" en el mismo dominio. Esto puede generar problemas si el controlador de dominio o la aplicación tienen que buscar la gMSA por el nombre. Puedes usar el siguiente comando para buscar objetos con el nombre similar en AD:

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

  4. Si has habilitado la delegación sin restricciones en la cuenta gMSA, asegúrate de que el atributo UserAccountControl tenga habilitada la marca WORKSTATION_TRUST_ACCOUNT. Esta marca es necesaria para que NETLOGON en el contenedor se comunique con el controlador de dominio, como sucede cuando una aplicación tiene que resolver un nombre en un SID o viceversa. Puedes comprobar si la marca está configurada correctamente con los siguientes comandos:

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

    Si los comandos anteriores devuelven False, usa lo siguiente para agregar la marca de WORKSTATION_TRUST_ACCOUNT a la propiedad UserAccountControl de la cuenta gMSA. Este comando también borrará las marcas NORMAL_ACCOUNT, INTERDOMAIN_TRUST_ACCOUNT y SERVER_TRUST_ACCOUNT de la propiedad UserAccountControl.

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

Hosts de contenedor que no están unidos a ningún dominio: use registros de eventos para identificar problemas de configuración.

El registro de eventos para usar gMSA con hosts de contenedor que no están unidos a ningún dominio se puede usar para identificar problemas de configuración. Los eventos se registran en el archivo de registro Microsoft-Windows-Containers-CCG y se pueden encontrar en Visor de eventos en Applications and Services Logs\Microsoft\Windows\Containers-CCG\Admin. Si exporta este archivo de registro desde el host de contenedor para leerlo, debe tener habilitada la característica de contenedores en el dispositivo donde está intentando leer el archivo de registro y debe usar una versión de Windows que admita el uso de gMSA con hosts de contenedor que no están unidos a ningún dominio.

Eventos y descripciones

Número de evento Texto del evento Descripción
1 Container Credential Guard creó una instancia del complemento. Este evento indica que el complemento indicado en la especificación de credenciales se instaló y se pudo cargar. No se requiere ninguna acción.
2 Container Credential Guard capturó las credenciales de gMSA para %1 mediante el complemento %2. Se trata de un evento informativo que indica que las credenciales de gMSA se capturaron correctamente de AD. No se requiere ninguna acción.
3 Container Credential Guard no pudo analizar la especificación de credenciales. Error: %1 Este evento indica un problema con la especificación de credenciales. Puede deberse a que el GUID del complemento sea incorrecto o a que haya otros campos con formato incorrecto. Revise la guía de solución de problemas para la especificación de credenciales para comprobar el formato y el contenido de la especificación de credenciales.
4 Container Credential Guard no pudo crear una instancia del complemento: %1. Error: %2 Este evento indica que no se pudo cargar el complemento. Debe comprobar que el complemento se instaló correctamente en el host.
6 Container Credential Guard no pudo capturar las credenciales del complemento: %1. Error: %2 Este evento indica que el complemento se cargó, pero no se pudieron recuperar las credenciales necesarias para capturar la contraseña de gMSA de AD. Debe comprobar que la entrada al complemento tiene el formato correcto en la especificación de credenciales y que el host de contenedor tiene los permisos necesarios para acceder al almacén de secretos usado por el complemento.
7 Container Credential Guard está capturando de nuevo las credenciales mediante el complemento: %1. Se trata de un evento informativo. Este evento se genera cuando la contraseña de gMSA ha expirado y debe actualizarse con las credenciales que ha capturado el complemento.
8 Container Credential Guard no pudo capturar las credenciales de gMSA para %1 mediante el complemento %2. Motivo del error: %3 Este evento indica que las credenciales capturadas mediante el complemento no se pudieron usar para capturar las credenciales de gMSA de AD. Debe comprobar que la cuenta que se captura del complemento tiene permisos en AD para recuperar las credenciales de gMSA.