Устранение неполадок групповых управляемых учетных записей служб для контейнеров WindowsTroubleshoot gMSAs for Windows containers

Известные проблемыKnown issues

Имя узла контейнера должно соответствовать имени gMSA для Windows Server 2016 и Windows 10 версий 1709 и 1803Container hostname must match the gMSA name for Windows Server 2016 and Windows 10, versions 1709 and 1803

Если вы используете Windows Server 2016 версии 1709 или 1803, имя узла контейнера должно соответствовать имени учетной записи SAM gMSA.If you're running Windows Server 2016, version 1709 or 1803, the hostname of your container must match your gMSA SAM Account Name.

Если имя узла не соответствует имени gMSA, входящие запросы проверки подлинности NTLM и преобразование имени или идентификатора безопасности (используемые многими библиотеками, такими как поставщик ролей членства ASP.NET) завершатся ошибкой.When the hostname doesn't match the gMSA name, inbound NTLM authentication requests and name/SID translation (used by many libraries, like the ASP.NET membership role provider) will fail. Kerberos продолжит работать в обычном режиме, даже если имена узлов и gMSA не совпадают.Kerberos will continue to function normally even if the hostname and gMSA name don't match.

Это ограничение было исправлено в Windows Server 2019, где контейнер теперь всегда будет использовать имя gMSA в сети независимо от назначенного имени узла.This limitation was fixed in Windows Server 2019, where the container will now always use its gMSA name on the network regardless of the assigned hostname.

Использование gMSA с более чем одним контейнером одновременно приводит к периодическим сбоям в работе Windows Server 2016 и Windows 10 версий 1709 и 1803.Using a gMSA with more than one container simultaneously leads to intermittent failures on Windows Server 2016 and Windows 10, versions 1709 and 1803

Так как все контейнеры должны использовать одно и то же имя узла, вторая проблема затрагивает версии Windows, предшествующие Windows Server 2019 и Windows 10 версии 1809.Because all containers are required to use the same hostname, a second issue affects versions of Windows prior to Windows Server 2019 and Windows 10, version 1809. Если нескольким контейнерам назначено одно и то же удостоверение и имя узла, может возникнуть состояние гонки, если два контейнера одновременно обращаются к одному и тому же контроллеру домена.When multiple containers are assigned the same identity and hostname, a race condition may occur when two containers talk to the same domain controller simultaneously. Когда другой контейнер взаимодействует с одним и тем же контроллером домена, он отменит связь с любыми из предыдущих контейнеров, использующих то же удостоверение.When another container talks to the same domain controller, it will cancel communication with any prior containers using the same identity. Это может привести к периодическим ошибкам проверки подлинности. При выполнении nltest /sc_verify:contoso.com внутри контейнера иногда может наблюдаться ошибка доверия.This can lead to intermittent authentication failures and can sometimes be observed as a trust failure when you run nltest /sc_verify:contoso.com inside the container.

Мы изменили поведение Windows Server 2019, чтобы отделить удостоверение контейнера от имени компьютера, позволяя нескольким контейнерам одновременно использовать одну и ту же gMSA.We changed the behavior in Windows Server 2019 to separate the container identity from the machine name, allowing multiple containers to use the same gMSA simultaneously.

Нельзя использовать gMSA с изолированными контейнерами Hyper-V в Windows 10 версий 1703, 1709 и 1803.You can't use gMSAs with Hyper-V isolated containers on Windows 10 versions 1703, 1709, and 1803

При попытке использовать gMSA с изолированным контейнером Hyper-V в Windows 10 и Windows Server версий 1703, 1709 и 1803 инициализация контейнера зависает или завершается сбоем.Container initialization will hang or fail when you try to use a gMSA with a Hyper-V isolated container on Windows 10 and Windows Server versions 1703, 1709, and 1803.

Эта ошибка была исправлена в Windows Server 2019 и Windows 10 версии 1809.This bug was fixed in Windows Server 2019 and Windows 10, version 1809. Вы также можете запускать изолированные контейнеры Hyper-V с помощью gMSA в Windows Server 2016 и Windows 10 версии 1607.You can also run Hyper-V isolated containers with gMSAs on Windows Server 2016 and Windows 10, version 1607.

Общие рекомендации по устранению неполадокGeneral troubleshooting guidance

Если при запуске контейнера с помощью gMSA возникают ошибки, приведенные ниже инструкции могут помочь определить основную причину.If you're encountering errors when running a container with a gMSA, the following instructions may help you identify the root cause.

Использование gMSA в узлеMake sure the host can use the gMSA

  1. Убедитесь, что основной элемент присоединен к домену и может подключиться к контроллеру домена.Verify the host is domain joined and can reach the domain controller.

  2. Установите средства PowerShell AD из RSAT и выполните команду Test-ADServiceAccount, чтобы узнать, есть ли у компьютера доступ для получения gMSA.Install the AD PowerShell Tools from RSAT and run Test-ADServiceAccount to see if the computer has access to retrieve the gMSA. Если командлет возвращает значение False, компьютер не имеет доступа к паролю gMSA.If the cmdlet returns False, the computer does not have access to the gMSA password.

    # 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. Если команда Test-ADServiceAccount возвращает значение False, убедитесь, что основной элемент принадлежит группе безопасности, которая может получить доступ к паролю gMSA.If Test-ADServiceAccount returns False, verify the host belongs to a security group that can access the gMSA password.

    # 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. Если основной элемент принадлежит группе безопасности, авторизованной для получения пароля gMSA, но по-прежнему происходит сбой Test-ADServiceAccount, может потребоваться перезагрузить запрос, чтобы получить новый билет, отражающий текущие членства в группах.If your host belongs to a security group authorized to retrieve the gMSA password but is still failing Test-ADServiceAccount, you may need to restart your computer to obtain a new ticket reflecting its current group memberships.

Проверка файла спецификации учетных данныхCheck the Credential Spec file

  1. Выполните команду Get-CredentialSpec из модуля CredentialSpec среды PowerShell, чтобы найти все спецификации учетных данных на компьютере.Run Get-CredentialSpec from the CredentialSpec PowerShell module to locate all credential specs on the machine. Спецификации учетных данных должны храниться в каталоге CredentialSpecs в корневом каталоге Docker.The credential specs must be stored in the "CredentialSpecs" directory under the Docker root directory. Корневой каталог Docker можно найти, выполнив команду docker info -f "{{.DockerRootDir}}" .You can find the Docker root directory by running docker info -f "{{.DockerRootDir}}".

  2. Откройте файл CredentialSpec и убедитесь, что следующие поля заполнены правильно:Open the CredentialSpec file and make sure the following fields are filled out correctly:

    • Sid: идентификатор безопасности учетной записи gMSA.Sid: the SID of your gMSA account
    • MachineAccountName: имя учетной записи SAM gMSA (не добавляйте полное доменное имя или знак доллара).MachineAccountName: the gMSA SAM Account Name (don't include full domain name or dollar sign)
    • DnsTreeName: FQDN леса Active Directory.DnsTreeName: the FQDN of your Active Directory forest
    • DnsName: FQDN домена, которому принадлежит gMSA.DnsName: the FQDN of the domain to which the gMSA belongs
    • NetBiosName: имя NETBIOS домена, которому принадлежит gMSA.NetBiosName: NETBIOS name for the domain to which the gMSA belongs
    • GroupManagedServiceAccounts/Name: имя учетной записи SAM gMSA (не добавляйте полное доменное имя или знак доллара).GroupManagedServiceAccounts/Name: the gMSA SAM account name (do not include full domain name or dollar sign)
    • GroupManagedServiceAccounts/Scope: одна запись для FQDN домена и одна — для NETBIOS.GroupManagedServiceAccounts/Scope: one entry for the domain FQDN and one for the NETBIOS

    Ваши введенные данные должны выглядеть как в следующем примере полной спецификации учетных данных:Your input should look like the following example of a complete credential spec:

    {
        "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"
                }
            ]
        }
    }
    
  3. Проверьте правильность пути к файлу спецификации учетных данных для решения оркестрации.Verify the path to the credential spec file is correct for your orchestration solution. Если вы используете Docker, убедитесь, что команда запуска контейнера содержит --security-opt="credentialspec=file://NAME.json", где NAME.json заменяется именем, полученным с помощью команды Get-CredentialSpec.If you're using Docker, make sure the container run command includes --security-opt="credentialspec=file://NAME.json", where "NAME.json" is replaced with the name output by Get-CredentialSpec. Имя представляет собой имя неструктурированного файла, которое относится к папке CredentialSpecs в корневом каталоге Docker.The name is a flat file name, relative to the CredentialSpecs folder under the Docker root directory.

Проверка конфигурации брандмауэраCheck the firewall configuration

Если вы используете строгую политику брандмауэра в сети контейнера или узла, она может блокировать необходимые подключения к контроллеру домена Active Directory или DNS-серверу.If you're using a strict firewall policy on the container or host network, it may block required connections to the Active Directory Domain Controller or DNS server.

Протокол и портProtocol and port ОписаниеPurpose
TCP и UDP 53TCP and UDP 53 Служба доменных имен (DNS)DNS
TCP и UDP 88TCP and UDP 88 KerberosKerberos
TCP 139TCP 139 NetLogonNetLogon
TCP и UDP 389TCP and UDP 389 LDAPLDAP
TCP 636TCP 636 LDAP SSLLDAP SSL

Вам может потребоваться разрешить доступ к дополнительным портам в зависимости от типа трафика, отправляемого контейнером в контроллер домена.You may need to allow access to additional ports depending on the type of traffic your container sends to a domain controller. Полный список портов, используемых в Active Directory, см. в разделе Связь с контроллерами доменами.See Active Directory and Active Directory Domain Services port requirements for a full list of ports used by Active Directory.

Проверка контейнераCheck the container

  1. Если вы используете версию Windows, предшествующую Windows Server 2019 или Windows 10 версии 1809, имя узла контейнера должно совпадать с именем gMSA.If you're running a version of Windows prior to Windows Server 2019 or Windows 10, version 1809, your container hostname must match the gMSA name. Убедитесь, что параметр --hostname соответствует краткому имени gMSA (без компонента домена, например webapp01 вместо webapp01.contoso.com).Ensure the --hostname parameter matches the gMSA short name (no domain component; for example, "webapp01" instead of "webapp01.contoso.com").

  2. Проверьте конфигурацию сетевых подключений контейнеров, чтобы контейнер мог разрешить контроллер домена gMSA и получить к нему доступ.Check the container networking configuration to verify the container can resolve and access a domain controller for the gMSA's domain. Неправильно настроенные DNS-серверы в контейнере являются распространенной причиной проблем с удостоверениями.Misconfigured DNS servers in the container are a common culprit of identity issues.

  3. Убедитесь, что контейнер имеет допустимое подключение к домену, выполнив следующий командлет в контейнере (выполнив docker exec или эквивалентную команду):Check if the container has a valid connection to the domain by running the following cmdlet in the container (using docker exec or an equivalent):

    nltest /sc_verify:contoso.com
    

    Проверка доверия должна возвращать NERR_SUCCESS, если gMSA доступна, а сетевое подключение позволяет контейнеру взаимодействовать с доменом.The trust verification should return NERR_SUCCESS if the gMSA is available and network connectivity allows the container to talk to the domain. В случае сбоя проверьте конфигурацию сети узла и контейнера.If it fails, verify the network configuration of the host and container. Они оба должны иметь возможность обмениваться данными с контроллером домена.Both need to be able to communicate with the domain controller.

  4. Проверьте, может ли контейнер получить действительный билет на получение билетов Kerberos (TGT):Check if the container can obtain a valid Kerberos Ticket Granting Ticket (TGT):

    klist get krbtgt
    

    Эта команда должна отобразить сообщение "Билет для krbtgt успешно получен" и список контроллеров домена, используемых для получения билета.This command should return "A ticket to krbtgt has been retrieved successfully" and list the domain controller used to retrieve the ticket. Если вы можете получить TGT, но nltest из предыдущего шага завершается сбоем, это может означать, что учетная запись gMSA неправильно настроена.If you're able to obtain a TGT but nltest from the previous step fails, this may be an indication that the gMSA account is misconfigured. Дополнительные сведения см. в разделе Проверка учетной записи gMSA.See check the gMSA account for more information.

    Если вы не можете получить TGT в контейнере, это может означать наличие проблем с подключением DNS или сетевым подключением.If you cannot obtain a TGT inside the container, this may indicate DNS or network connectivity issues. Убедитесь, что контейнер может разрешить контроллер домена с помощью DNS-имени домена и что контроллер домена поддерживает маршрутизацию из контейнера.Ensure the container can resolve a domain controller using the domain DNS name and that the domain controller is routable from the container.

  5. Убедитесь, что приложение настроено для использования gMSA.Ensure your app is configured to use the gMSA. Учетная запись пользователя в контейнере не изменяется при использовании gMSA.The user account inside the container doesn't change when you use a gMSA. Вместо этого системная учетная запись использует gMSA, когда она обращается к другим сетевым ресурсам.Rather, the System account uses the gMSA when it talks to other network resources. Это означает, что для использования удостоверения gMSA приложение должно быть запущено как сетевая служба или локальная система.This means your app will need to run as Network Service or Local System to leverage the gMSA identity.

    Совет

    Если вы запускаете whoami или используете другое средство для идентификации текущего контекста пользователя в контейнере, имя gMSA не отображается.If you run whoami or use another tool to identify your current user context in the container, you won't see the gMSA name itself. Это связано с тем, что вы всегда входите в контейнер в качестве локального пользователя, а не с помощью удостоверения домена.This is because you always sign in to the container as a local user instead of a domain identity. gMSA используется учетной записью компьютера при каждом обращении к сетевым ресурсам, поэтому приложение должно работать как сетевая служба или локальная система.The gMSA is used by the computer account whenever it talks to network resources, which is why your app needs to run as Network Service or Local System.

Проверка учетной записи gMSACheck the gMSA account

  1. Если кажется, что контейнер настроен правильно, но пользователям или другим службам не удается автоматически пройти проверку подлинности в контейнерном приложении, проверьте имена субъектов-служб в учетной записи gMSA.If your container seems to be configured correctly but users or other services are unable to automatically authenticate to your containerized app, check the SPNs on your gMSA account. Клиенты будут находить учетную запись gMSA по имени, с помощью которого они получают доступ к приложению.Clients will locate the gMSA account by the name at which they reach your application. Это может означать, что вам потребуются дополнительные имена субъектов-служб hostдля gMSA, если, например, клиенты подключаются к приложению через подсистему балансировки нагрузки или другое DNS-имя.This may mean that you'll need additional host SPNs for your gMSA if, for example, clients connect to your app via a load balancer or a different DNS name.

  2. Убедитесь, что gMSA и узел контейнера принадлежат одному и тому же домену Active Directory.Ensure the gMSA and container host belong to the same Active Directory domain. Узел контейнера не сможет получить пароль gMSA, если gMSA принадлежит другому домену.The container host will not be able to retrieve the gMSA password if the gMSA belongs to a different domain.

  3. Убедитесь, что в домене есть только одна учетная запись с тем же именем, что и у вашей gMSA.Ensure there is only one account in your domain with the same name as your gMSA. Объекты gMSA содержат знаки доллара ($), добавленные к именам учетных записей SAM, поэтому gMSA может иметь имя myaccount$, а несвязанная учетная запись пользователя — myaccount в том же домене.gMSA objects have dollar signs ($) appended to their SAM account names, so it's possible for a gMSA to be named "myaccount$" and an unrelated user account to be named "myaccount" in the same domain. Это может вызвать проблемы, если контроллер домена или приложение должны искать gMSA по имени.This can cause issues if the domain controller or application has to look up the gMSA by name. В AD можно выполнить поиск объектов с похожими именами с помощью следующей команды:You can search AD for similarly named objects with the following command:

    # Replace "GMSANAMEHERE" with your gMSA account name (no trailing dollar sign)
    Get-ADObject -Filter 'sAMAccountName -like "GMSANAMEHERE*"'
    
  4. Если вы включили неограниченное делегирование для учетной записи gMSA, убедитесь, что для атрибута UserAccountControl по-прежнему активирован флаг WORKSTATION_TRUST_ACCOUNT.If you've enabled unconstrained delegation on the gMSA account, ensure that the UserAccountControl attribute still has the WORKSTATION_TRUST_ACCOUNT flag enabled. Этот флаг необходим для СЕТЕВОГО ВХОДА В СИСТЕМУ, чтобы иметь возможность взаимодействовать с контроллером домена, например, когда приложению требуется разрешить имя в идентификаторе безопасности или наоборот.This flag is required for NETLOGON in the container to communicate with the domain controller, as is the case when an app has to resolve a name to a SID or vice versa. Выполните следующие команды, чтобы убедиться, что флаг настроен правильно:You can check if the flag is configured correctly with the following commands:

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

    Если приведенные выше команды возвращают значение False, выполните указанную ниже команду, чтобы добавить флаг WORKSTATION_TRUST_ACCOUNT в свойство UserAccountControl учетной записи gMSA.If the above commands return False, use the following to add the WORKSTATION_TRUST_ACCOUNT flag to the gMSA account's UserAccountControl property. Эта команда также снимет флаги NORMAL_ACCOUNT, INTERDOMAIN_TRUST_ACCOUNT и SERVER_TRUST_ACCOUNT в свойстве UserAccountControl.This command will also clear the NORMAL_ACCOUNT, INTERDOMAIN_TRUST_ACCOUNT, and SERVER_TRUST_ACCOUNT flags from the UserAccountControl property.

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