Устранение неполадок при работе с gMSAs в контейнерах Windows

Область применения: Windows Server 2025, Windows Server 2022, Windows Server 2019

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

Имя узла контейнера должно соответствовать имени gMSA для Windows Server 2016 и Windows 10, версий 1709 и 1803

Если вы используете Windows Server 2016 версии 1709 или 1803, имя узла контейнера должно соответствовать имени учетной записи SAM gMSA.

Если имя узла не совпадает с именем gMSA, запросы на входящую NTLM-аутентификацию и преобразование имен и SID (используемое многими библиотеками, такими как поставщик ролей членства в ASP.NET), потерпят неудачу. Kerberos продолжит работать обычно, даже если имя узла и имя gMSA не совпадают.

Это ограничение было исправлено в Windows Server 2019, где контейнер теперь всегда будет использовать его имя gMSA в сети независимо от назначенного имени узла.

Нельзя использовать gMSAs с изолированными контейнерами Hyper-V в Windows 10 версии 1703, 1709 и 1803

Инициализация контейнера зависнет или ошибется при попытке использовать изолированный контейнер Hyper-V с gMSA в Windows 10 и Windows Server версий 1703, 1709 и 1803.

Эта ошибка исправлена в Windows Server 2019 и Windows 10 версии 1809. Вы также можете запускать изолированные контейнеры Hyper-V с gMSAs в Windows Server 2016 и Windows 10 версии 1607.

Использование gMSA с несколькими контейнерами одновременно приводит к периодическим сбоям в Windows Server 2019 и выше, если указан параметр имени узла

Все контейнеры используют учетную запись gMSA, когда нескольким контейнерам назначено одно удостоверение. При использовании параметра --hostname указывается имя учетной записи gmsa, и состояние гонки может возникнуть, когда два контейнера одновременно обращаются к одному и тому же контроллеру домена. Когда другой контейнер взаимодействует с тем же контроллером домена, он отменит обмен данными с любыми предыдущими контейнерами с использованием того же удостоверения.

Это может привести к периодическим сбоям проверки подлинности и иногда может наблюдаться как сбой доверия при запуске nltest /sc_verify:contoso.com внутри контейнера. Чтобы избежать этой проблемы в контейнере Docker, если --hostname указан параметр, он должен быть всегда уникальным при запуске контейнера одновременно с учетной записью gmsa. Например, если учетная запись gmsa имеет значение "webapp01.contoso.com", а если два контейнера работают одновременно, оба контейнера могут иметь --hostname параметр со значениями "webapp01", "webapp02" соответственно.

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

Если при запуске контейнера с gMSA возникают ошибки, приведенные ниже инструкции помогут определить первопричину.

Присоединенные к домену узлы: убедитесь, что узел имеет возможность использовать gMSA

1. Убедитесь, что хост присоединен к домену и имеет доступ к контроллеру домена.

2. Установите AD PowerShell Tools из RSAT и запустите Test-ADServiceAccount, чтобы проверить, имеет ли компьютер доступ для получения gMSA. Если командлет возвращает False, компьютер не имеет доступа к паролю 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. Если Test-ADServiceAccount возвращает False, убедитесь, что хост принадлежит к группе безопасности, имеющей доступ к паролю 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. Если ваш хост входит в группу безопасности, уполномоченную на получение пароля gMSA, но до сих пор не проходит Test-ADServiceAccount, возможно, потребуется перезапустить ваш компьютер, чтобы получить новый тикет, отражающий его текущее членство в группах.

Хосты, не присоединенные к домену: убедитесь, что хост настроен на получение учетной записи gMSA.

Убедитесь, что плагин для работы gMSA с узлом контейнера, не присоединенном к домену, правильно установлен на узле. Windows не включает встроенный подключаемый модуль и требует, чтобы вы предоставили подключаемый модуль, реализующий интерфейс ICcgDomainAuthCredentials. Сведения об установке будут зависят от подключаемого модуля.

Проверьте файл спецификации учетных данных

1. Запустите Get-CredentialSpec из модуля CredentialSpec PowerShell, чтобы найти все спецификации учетных данных на компьютере. Спецификации учетных данных должны храниться в каталоге CredentialSpecs в корневом каталоге Docker. Корневой каталог Docker можно найти, выполнив команду docker info -f "{{.DockerRootDir}}".

2. Откройте файл CredentialSpec и убедитесь, что следующие поля заполнены правильно:

   1. Для контейнерных хостов, присоединенных к домену:

      • Sid: SID вашего домена
      • MachineAccountName: имя учетной записи SAM gMSA (не включайте полное доменное имя или знак доллара).
      • DnsTreeName: полное доменное имя леса Active Directory
      • DnsName: полное доменное имя домена, к которому принадлежит gMSA
      • NetBiosName: имя NETBIOS для домена, к которому принадлежит gMSA
      • GroupManagedServiceAccounts/Name: имя учетной записи gMSA SAM (не включайте полное доменное имя или знак доллара).
      • GroupManagedServiceAccounts/Scope: одна запись для FQDN домена и одна для NETBIOS

      Ваши входные данные должны выглядеть как следующий пример полного спецификатора учетных данных:

      {
          "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. Для узлов, не присоединенных к домену: помимо всех полей узла контейнера, не присоединенных к домену, убедитесь, что "HostAccountConfig" присутствует и что указанные ниже поля определены правильно.

      • PortableCcgVersion: это значение должно иметь значение "1".
      • PluginGUID: COM CLSID для плагина ccg.exe. Это уникально для используемого подключаемого модуля.
      • PluginInput: входные данные плагина для получения сведений об учетной записи пользователя из секретного хранилища.

      Ваши входные данные должны выглядеть как следующий пример полного спецификатора учетных данных:

      {
          "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. Проверьте, что путь к файлу спецификации учетных данных правильный для вашей системы управления оркестрацией. Если вы используете Docker, убедитесь, что команда запуска контейнера включает --security-opt="credentialspec=file://NAME.json", где "NAME.json" заменяется именем, полученным от Get-CredentialSpec. Имя — это простое имя файла, относительно папки CredentialSpecs в корневом каталоге Docker.

Проверка конфигурации сети

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

Если вы используете строгую политику брандмауэра в контейнере или сети узла, он может заблокировать необходимые подключения к контроллеру домена Active Directory или DNS-серверу.

Возможно, вам потребуется разрешить доступ к дополнительным портам в зависимости от типа трафика, который контейнер отправляет контроллеру домена. Полный список портов, используемых Active Directory и Службы доменов Active Directory, см. в разделе Требования к портам Active Directory и Службы доменов Active Directory.

Проверка конфигурации DNS узла контейнера

Если вы используете gMSA с узлом контейнера, присоединенным к домену, DNS должен быть автоматически настроен на узле, чтобы он смог правильно разрешить и установить подключение к домену. Если вы используете gMSA с узлом, не присоединенным к домену, эта конфигурация не будет автоматически задана. Убедитесь, что сеть узла настроена, чтобы она может разрешить домен. Вы можете проверить, что домен можно разрешить с сервера следующим образом:

nltest /sc_verify:contoso.com

Проверка контейнера

1. Если вы используете версию Windows до Windows Server 2019 или Windows 10 версии 1809, имя узла контейнера должно соответствовать имени gMSA. Убедитесь, что параметр --hostname соответствует короткому имени gMSA (без доменного компонента; например, "webapp01" вместо "webapp01.contoso.com").

2. Проверьте конфигурацию сети контейнера, чтобы убедиться, что контейнер может разрешить и получить доступ к контроллеру домена для домена gMSA. Неправильно настроенные DNS-серверы в контейнере часто являются причиной проблем с идентификацией.

3. Проверьте, имеет ли контейнер допустимое подключение к домену, выполнив следующий командлет в контейнере (с помощью docker exec или эквивалентного):

   nltest /sc_verify:contoso.com
   

   Проверка доверия должна возвращать NERR_SUCCESS, если gMSA доступна, а сетевое подключение позволяет контейнеру взаимодействовать с доменом. Если задача завершается с ошибкой, проверьте сетевую конфигурацию узла и контейнера. Оба должны иметь возможность взаимодействовать с контроллером домена.

4. Проверьте, может ли контейнер получить действительный билет Kerberos (TGT):

   klist get <myapp>
   

   Эта команда должна возвращать сообщение "Билет krbtgt успешно получен" и перечислить контроллер домена, использованный для получения билета. Если вы можете получить TGT, но nltest из предыдущего шага завершается ошибкой, это может означать, что учетная запись gMSA настроена неправильно. См. и проверьте учетную запись gMSA для получения дополнительной информации.

   Если вы не можете получить TGT внутри контейнера, это может указывать на проблемы с DNS или сетевым подключением. Убедитесь, что контейнер может определить и разрешить контроллер домена с использованием DNS-имени домена, и что контроллер домена доступен для маршрутизации из контейнера.

5. Убедитесь, что ваше приложение настроено для работы с gMSA. Учетная запись пользователя внутри контейнера не изменяется при использовании gMSA. Скорее, системная учетная запись использует gMSA при переговорах с другими сетевыми ресурсами. Чтобы использовать удостоверение gMSA, вашему приложению потребуется работать как служба сети или локальная система.

   Совет

   Если вы запускаете whoami или используете другое средство для идентификации текущего контекста пользователя в контейнере, имя gMSA не отображается. Это связано с тем, что вы всегда входите в контейнер как локальный пользователь, а не как учетная запись домена. GMSA используется учетной записью компьютера всякий раз, когда она взаимодействует с сетевыми ресурсами, поэтому ваше приложение должно выполняться как сетевая служба или локальная система.

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

1. Если ваш контейнер настроен правильно, но пользователи или другие службы не могут автоматически аутентифицироваться в вашем контейнере, проверьте имена субъектов службы в учетной записи gMSA. Клиенты будут находить учетную запись gMSA по имени, по которому они обращаются к приложению. Это может означать, что вам потребуются дополнительные уникальные имена служб (SPNs) для gMSA, например, если клиенты подключаются к вашему приложению через систему балансировки нагрузки или другое DNS-имя.

2. Для использования gMSA с узлом контейнера, присоединенным к домену, убедитесь, что узел gMSA и контейнер принадлежат тому же домену Active Directory. Хост контейнера не сможет получить пароль gMSA, если gMSA принадлежит другому домену.

3. Убедитесь, что в домене есть только одна учетная запись с тем же именем, что и gMSA. Объекты gMSA имеют знаки доллара ($), добавленные к именам учетных записей SAM, поэтому в том же домене возможно существование gMSA с именем "myaccount$" и несвязанной учетной записи пользователя с именем "myaccount". Это может привести к проблемам, если контроллер домена или приложение должен искать gMSA по имени. Вы можете найти в AD похожие именованные объекты с помощью следующей команды:

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

4. Если вы включили неограниченное делегирование в учетной записи gMSA, убедитесь, что атрибут UserAccountControl по-прежнему имеет установленный флаг WORKSTATION_TRUST_ACCOUNT. Этот флаг необходим для NETLOGON в контейнере для связи с контроллером домена, как в случае, когда приложению нужно преобразовать имя в идентификатор безопасности (SID) или наоборот. Вы можете проверить правильность настройки флага с помощью следующих команд:

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

   Если приведенные выше команды возвращают False, используйте следующую команду, чтобы добавить флаг WORKSTATION_TRUST_ACCOUNT в свойство UserAccountControl учетной записи gMSA. Эта команда также очищает флаги NORMAL_ACCOUNT, INTERDOMAIN_TRUST_ACCOUNTи SERVER_TRUST_ACCOUNT из свойства UserAccountControl.

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

Узлы контейнеров, не присоединенных к домену: используйте журналы событий для выявления проблем конфигурации

Ведение журнала событий для использования gMSA с узлами контейнеров, не присоединенными к домену, можно использовать для выявления проблем конфигурации. События регистрируются в файле журнала Microsoft-WindowsContainers-CCG и находятся в средстве просмотра событий в разделе "Приложения и службы Logs\Microsoft\Windows\Containers-CCG\Admin". Если вы экспортируете этот файл журнала из узла контейнера для чтения, необходимо включить функцию контейнеров на устройстве, где вы пытаетесь считывать файл журнала, и вы должны находиться в версии Windows, поддерживающей использование gMSA с узлами контейнеров, не присоединенными к домену.

События и описания