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

Статья
03/18/2023

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

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

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

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

Если имя узла не соответствует имени gMSA, входящие запросы проверки подлинности NTLM и преобразование имени или идентификатора безопасности (используемые многими библиотеками, такими как поставщик ролей членства 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 можно выполнять несколько контейнеров с одним идентификатором на одном или нескольких узлах.

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

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

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

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

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

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

Убедитесь, что основной элемент присоединен к домену и может подключиться к контроллеру домена.
Установите средства PowerShell AD из 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
```

Если команда 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

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

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

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

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

Выполните команду Get-CredentialSpec из модуля CredentialSpec среды PowerShell, чтобы найти все спецификации учетных данных на компьютере. Спецификации учетных данных должны храниться в каталоге CredentialSpecs в корневом каталоге Docker. Корневой каталог Docker можно найти, выполнив команду docker info -f "{{.DockerRootDir}}" .
Откройте файл CredentialSpec и убедитесь, что следующие поля заполнены правильно:
1. Для узлов контейнеров с присоединением к домену:
  - Sid: идентификатор безопасности домена.
  - MachineAccountName: имя учетной записи SAM gMSA (не добавляйте полное доменное имя или знак доллара).
  - DnsTreeName: FQDN леса Active Directory.
  - DnsName: FQDN домена, которому принадлежит gMSA.
  - NetBiosName: имя NETBIOS домена, которому принадлежит gMSA.
  - GroupManagedServiceAccounts/Name: имя учетной записи SAM gMSA (не добавляйте полное доменное имя или знак доллара).
  - 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>"
        }
    }
}
```
Проверьте правильность пути к файлу спецификации учетных данных для решения оркестрации. Если вы используете 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, см. в разделе Связь с контроллерами доменами.

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

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

nltest /sc_verify:contoso.com

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

Если вы используете версию Windows, предшествующую Windows Server 2019 или Windows 10 версии 1809, имя узла контейнера должно совпадать с именем gMSA. Убедитесь, что параметр --hostname соответствует краткому имени gMSA (без компонента домена, например webapp01 вместо webapp01.contoso.com).
Проверьте конфигурацию сетевых подключений контейнеров, чтобы контейнер мог разрешить контроллер домена gMSA и получить к нему доступ. Неправильно настроенные DNS-серверы в контейнере являются распространенной причиной проблем с удостоверениями.
Убедитесь, что контейнер имеет допустимое подключение к домену, выполнив следующий командлет в контейнере (выполнив docker exec или эквивалентную команду):
```
nltest /sc_verify:contoso.com
```
Проверка доверия должна возвращать NERR_SUCCESS, если gMSA доступна, а сетевое подключение позволяет контейнеру взаимодействовать с доменом. В случае сбоя проверьте конфигурацию сети узла и контейнера. Они оба должны иметь возможность обмениваться данными с контроллером домена.
Проверьте, может ли контейнер получить действительный билет на получение билетов Kerberos (TGT):
```
klist get <myapp>
```
Эта команда должна отобразить сообщение "Билет для krbtgt успешно получен" и список контроллеров домена, используемых для получения билета. Если вы можете получить TGT, но nltest из предыдущего шага завершается сбоем, это может означать, что учетная запись gMSA неправильно настроена. Дополнительные сведения см. в разделе Проверка учетной записи gMSA.

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

Совет

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

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

Если кажется, что контейнер настроен правильно, но пользователям или другим службам не удается автоматически пройти проверку подлинности в контейнерном приложении, проверьте имена субъектов-служб в учетной записи gMSA. Клиенты будут находить учетную запись gMSA по имени, с помощью которого они получают доступ к приложению. Это может означать, что вам потребуются дополнительные имена субъектов-служб hostдля gMSA, если, например, клиенты подключаются к приложению через подсистему балансировки нагрузки или другое DNS-имя.
Чтобы использовать gMSA с узлом контейнеров с присоединением к домену, убедитесь, что gMSA и узел контейнера принадлежат одному домену Active Directory. Узел контейнера не сможет получить пароль gMSA, если gMSA принадлежит другому домену.
Убедитесь, что в домене есть только одна учетная запись с тем же именем, что и у вашей 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*"'
```
Если вы включили неограниченное делегирование для учетной записи gMSA, убедитесь, что для атрибута UserAccountControl по-прежнему активирован флаг WORKSTATION_TRUST_ACCOUNT. Этот флаг необходим для СЕТЕВОГО ВХОДА В СИСТЕМУ, чтобы иметь возможность взаимодействовать с контроллером домена, например, когда приложению требуется разрешить имя в идентификаторе безопасности или наоборот. Выполните следующие команды, чтобы убедиться, что флаг настроен правильно:
```
$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-Windows-Containers-CCG, и их можно просмотреть в средстве "Просмотр событий" в разделе "Приложения и службы" (Logs\Microsoft\Windows\Containers-CCG\Admin). Если вы экспортируете этот файл журнала из узла контейнеров для чтения, вы должны включить компонент контейнеров на устройстве, на котором вы пытаетесь прочитать файл журнала, а также иметь версию Windows, поддерживающую использование gMSA с узлами контейнеров без присоединения к домену.

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

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

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