Поделиться через

Устранение неполадок 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 в сети независимо от назначенного имени узла.

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

Так как все контейнеры необходимы для использования одного имени узла, вторая проблема влияет на версии Windows до Windows Server 2019 и Windows 10 версии 1809. Если нескольким контейнерам назначены один и тот же идентификатор и имя хоста, состояние гонки может возникнуть, когда два контейнера одновременно обращаются к тому же контроллеру домена. Когда другой контейнер общается с тем же контроллером домена, он прекратит связь с любыми предыдущими контейнерами, использующими ту же идентичность. Это может привести к периодическим сбоям проверки подлинности и иногда может наблюдаться как сбой доверия при запуске nltest /sc_verify:contoso.com внутри контейнера.

Мы изменили поведение в Windows Server 2019, чтобы отделить идентификацию контейнера от имени компьютера, что дает возможность нескольким контейнерам одновременно использовать одну и ту же gMSA. Поэтому в Windows Server 2019 можно запускать несколько контейнеров с одинаковым удостоверением, будь то на одном или нескольких узлах.

Нельзя использовать 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 возникают ошибки, приведенные ниже инструкции помогут определить первопричину.

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

Протокол и порт Цель
TCP и UDP 53 DNS (Система доменных имён)
TCP и UDP 88 Kerberos
TCP 139 NetLogon
TCP и UDP 389 LDAP
TCP 636 LDAP SSL

Возможно, вам потребуется разрешить доступ к дополнительным портам в зависимости от типа трафика, который контейнер отправляет контроллеру домена. Полный список портов, используемых 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 по имени, по которому они обращаются к приложению. Это может означать, что вам потребуется дополнительная host 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 с узлами контейнеров, не присоединенными к домену.

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

Номер события Текст события Описание
1 Контейнер Credential Guard создает экземпляр подключаемого модуля Это событие указывает, что подключаемый модуль, указанный в спецификации учетных данных, был установлен и может быть загружен. Никаких действий не требуется.
2 Контейнер Credential Guard извлек учетные данные gmsa для %1 с помощью подключаемого модуля: %2 Это информационное событие, указывающее, что учетные данные gMSA успешно извлекались из AD. Никаких действий не требуется.
3 Credential Guard для контейнера не смог проанализировать спецификацию учетных данных. Ошибка: %1 Это событие указывает на проблему с спецификацией учетных данных. Это может произойти, если GUID для подключаемого модуля некорректен или если существуют другие неправильно сформированные поля. Ознакомьтесь с руководством по устранению неполадок спецификации учетных данных, чтобы проверить форматирование и содержимое спецификации учетных данных.
4 Контейнер Credential Guard не удалось создать экземпляр подключаемого модуля: %1. Ошибка: %2 Это событие указывает, что подключаемый модуль не удалось загрузить. Вам следует проверить, что подключаемый модуль установлен правильно на хосте.
6 Защитнику учетных данных контейнера не удалось получить данные учетной записи из подключаемого модуля: %1. Ошибка: %2 Это событие указывает, что подключаемый модуль загружен, но не удалось получить учетные данные, необходимые для получения пароля gMSA из AD. Убедитесь, что входные данные плагина отформатированы правильно в спецификации учетных данных и что узел контейнера имеет необходимые разрешения для доступа к хранилищу секретов, используемому плагином.
7 Контейнер Credential Guard повторно извлекает учетные данные с помощью подключаемого модуля: %1 Это информационное событие. Это событие создается при истечении срока действия пароля gMSA и его необходимо обновить с помощью учетных данных, получаемых подключаемым модулем.
8 Credential Guard контейнера не смог получить учетные данные gmsa для %1, используя плагин %2. Причина ошибки: %3 Это событие указывает, что учетные данные, полученные с помощью подключаемого модуля, не могут использоваться для получения учетных данных gMSA из AD. Убедитесь, что учетная запись, полученная из подключаемого модуля, имеет разрешения в AD для получения учетных данных gMSA.