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

В этой статье описано, как включить и использовать групповые управляемые учетные записи служб (gMSA) в Windows Server.

Протоколы аутентификации, поддерживающие взаимную аутентификацию, такие как Kerberos, нельзя использовать, если все экземпляры службы не используют одну и ту же учетную запись. Например, когда клиентский компьютер подключается к службе, использующую балансировку нагрузки или другой метод, где все серверы, как представляется, одинаковы для клиента. Это означает, что каждая служба должна использовать одни и те же пароли или ключи, чтобы подтвердить свою личность. Учетные записи управляемых групп — это тип учетной записи, которую можно использовать с несколькими серверами. GMSA — это учетная запись домена, которая может использоваться для запуска служб на нескольких серверах без необходимости управлять паролем. GMSA обеспечивает автоматическое управление паролями и упрощенное управление именем субъекта-службы, включая делегирование управления другим администраторам.

Note

Отказоустойчивые кластеры не поддерживают GMSAs. Однако службы, которые выполняются поверх службы кластера, могут использовать gMSA или sMSA, если они являются службами Windows, пулом приложений, запланированной задачей или если они изначально поддерживают gMSA или sMSA.

Службы могут выбрать основного субъекта для использования. Каждый основной тип поддерживает разные службы и имеет разные ограничения.

Principals Поддерживаемые службы Управление паролями
Учетная запись компьютера системы Windows Ограничено одним сервером, присоединенным к домену Компьютер управляет
Учетная запись компьютера без Windows системы Любой сервер, присоединенный к домену None
Виртуальная учетная запись Ограничена одним сервером Компьютер управляет
Windows автономная управляемая учетная запись Managed Service Account Ограничено одним сервером, присоединенным к домену Компьютер управляет
Учетная запись пользователя Любой сервер, присоединенный к домену None
Учетная запись управляемой группой службы Любой сервер, присоединенный к домену Windows Server Управляется контроллером домена и извлекается узлом

Учетная запись Windows компьютера, автономная управляемая учетная запись службы (sMSA) Windows или виртуальные учетные записи не могут использоваться в нескольких системах. При использовании виртуальных учетных записей удостоверение также остается локальным для компьютера и не распознается в домене. Если вы настроите одну учетную запись для служб на фермах серверов для совместного использования, необходимо выбрать учетную запись пользователя или учетную запись компьютера, кроме системы Windows. В любом случае эти учетные записи не имеют возможности управления паролями с одной точкой управления. Без управления паролями каждая организация должна обновить ключи для службы в Active Directory (AD) и распространить эти ключи ко всем экземплярам этих служб.

С помощью Windows Server службы и администраторы служб не должны управлять синхронизацией паролей между экземплярами служб при использовании gMSA. Вы создаете gMSA в AD и настраиваете службу, которая поддерживает управляемые учетные записи служб. Использование gMSA распространяется на любой компьютер, который может использовать протокол LDAP для получения учетных данных gMSA. Вы можете создать gMSA с помощью New-ADServiceAccount командлетов, входящих в модуль AD. Следующие службы поддерживают конфигурацию удостоверения службы на хосте.

  • Те же API, что и sMSA, поэтому продукты, поддерживающие sMSA, поддерживают gMSA

  • Службы, использующие Service Control Manager для настройки удостоверения входа

  • Службы, использующие диспетчер служб IIS (Internet Information Services) для пулов приложений для настройки удостоверения

  • Задачи с помощью планировщика задач.

Prerequisites

Для управления gMSAs устройство должно соответствовать следующим требованиям:

Tip

Чтобы контролировать, какие узлы или службы могут использовать gMSA, добавьте учетные записи компьютеров в назначенную группу безопасности (новую или существующую) и назначьте необходимые разрешения этой группе. Аналогичным образом используйте группу безопасности для управления доступом к службам, работающим в gMSAs, обеспечивая наличие всех необходимых разрешений для операций службы и доступа к ресурсам.

Для аутентификации Kerberos в работе с сервисами, использующими gMSAs, необходимо следующее:

  • Убедитесь, что SPN правильно зарегистрированы для каждой службы с помощью группового управляемого служебного аккаунта (gMSA). Это позволяет Kerberos определять и аутентифицировать службу.

  • Убедитесь, что записи DNS настроены правильно для разрешения имен, поскольку Kerberos опирается на них для поиска доменных услуг.

  • Убедитесь, что брандмауэры и политики сети разрешают трафик Kerberos и необходимые коммуникации сервисов.

  • Для параметров времени существования билета Kerberos настройте политики истечения срока действия билета и продления в соответствии с вашими требованиями к безопасности и эксплуатации.

  • Все системы, участвующие в процессе проверки подлинности, должны иметь синхронизированные часы. Kerberos учитывает конфигурацию времени, а несоответствия могут привести к сбоям проверки подлинности.

  • Все системы, которые входят в систему под gMSA или устанавливаются с его использованием, должны поддерживать типы шифрования Kerberos, необходимые для gMSA. Системы, которые не соответствуют этому требованию, не могут войти в систему или установить gMSA.

Если вы управляете AD с компьютера, который не является контроллером домена, установите средства удаленного администрирования сервера (RSAT), чтобы получить доступ к необходимым функциям управления. RSAT предоставляет модуль AD для PowerShell. После установки RSAT откройте PowerShell от имени администратора и запустите Import-Module ActiveDirectory , чтобы включить командлеты управления AD. Это позволяет администраторам удаленно и безопасно управлять AD, минимизируя нагрузку на контроллеры домена.

Создание gMSA

Чтобы создать gMSA с помощью PowerShell, выполните следующие действия в окне PowerShell с повышенными привилегиями:

Important

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

  1. Создайте корневой ключ KDS, если он не существует, следуя инструкциям в руководстве по созданию корневого ключа KDS служб распространения ключей. Если ключ уже существует, пропустите этот шаг.

  2. Чтобы создать gMSA, выполните следующую команду. Замените <gMSAName> нужным именем gMSA и <domain> именем домена. Замените <SecurityGroup> именем группы безопасности или учетных записей компьютеров, у которых должен быть доступ для получения пароля gMSA.

    New-ADServiceAccount -Name <gMSAName> -DNSHostName <gMSAName>.<domain> -PrincipalsAllowedToRetrieveManagedPassword <SecurityGroup>

    Чтобы создать gMSA только для исходящей проверки подлинности, выполните следующую команду. Замените <Days> числовым значением. Если значение не указано, значение по умолчанию равно 30 дням.

    New-ADServiceAccount -Name <gMSAName> -DNSHostName <gMSAName>.<domain> -RestrictToOutboundAuthenticationOnly -ManagedPasswordIntervalInDays <Days> -PrincipalsAllowedToRetrieveManagedPassword <SecurityGroup>

    Important

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

  3. Выполните следующую команду, чтобы проверить, имеет ли целевое устройство доступ для получения пароля gMSA.

    Test-ADServiceAccount -Identity <gMSAName>

Членство в соответствующей группе безопасности или наличие необходимых делегированных разрешений для создания msDS-GroupManagedServiceAccount объектов требуется для выполнения этой процедуры. Хотя члены операторов учетных записей могут управлять определенными объектами пользователей и групп в AD, у них нет прав на создание gMSAs по умолчанию, если эти разрешения не делегированы им. Подробные сведения об использовании соответствующих учетных записей и членства в группах см. в разделе Active Directory группы безопасности.

Вы также можете обновить свойства gMSA с помощью командлета Set-ADServiceAccount . Например, чтобы обновить отображаемое имя компьютера, выполните следующую команду, заменив <gMSAName> и <NewDisplayName> на ваши значения.

Set-ADServiceAccount -Identity "<gMSAName>" -DisplayName "<NewDisplayName>"

Подробные сведения о настройке других свойств для gMSA см. в разделе Set-ADServiceAccount.

Проверка изменений в gMSA

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

Выполните следующую команду, заменив <gMSAName> на имя созданной вами gMSA.

Get-ADServiceAccount -Identity "<gMSAName>" | Select-Object *

Добавьте узлы, являющиеся участниками, в группу безопасности

Note

  • Управление, ориентированное на группу (Add-ADGroupMember / Remove-ADGroupMember): используйте эти командлеты, если вы хотите управлять членством в определенной группе. Они лучше всего подходят для эффективного добавления или удаления нескольких пользователей, компьютеров или других объектов в группу или из группы.

  • Управление, ориентированное на субъекта (Add-ADPrincipalGroupMembership / Remove-ADPrincipalGroupMembership): выберите эти командлеты, когда ваша цель — управлять членством определенного пользователя или компьютера в нескольких группах. Они позволяют добавлять или удалять субъект из нескольких групп в одной операции, что упрощает обновление принадлежности групп для отдельных учетных записей.

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

Чтобы использовать оснастку Пользователи и компьютеры Active Directory (ADUC), см. Добавление учетной записи компьютера в группу и Управление учетными записями пользователей в Пользователи и компьютеры Active Directory.

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

Удаление узлов-участников из группы безопасности

Сведения об использовании оснастки ADUC см. в разделе "Удаление учетной записи компьютера " и "Удаление учетной записи пользователя".

Установка gMSA в системе

После создания gMSA и добавления входящих в группу хостов в группу безопасности необходимо установить gMSA на каждом хост-компьютере, на котором выполняется служба. Чтобы установить gMSA, откройте окно PowerShell с повышенными привилегиями и выполните следующую команду, заменив <gMSAName> на своё значение:

Install-ADServiceAccount -Identity <gMSAName>

Дополнительные сведения о командлете Install-ADServiceAccount см. в разделе Install-ADServiceAccount.

Удалите gMSA из вашей системы

Хотя вы не можете удалить gMSAs в ADUC, вы можете вручную удалить gMSA, найдя его в контейнере управляемых учетных записей служб и удалив его, как и любой другой объект AD. Однако следует помнить, что это не выполняет те же операции очистки, которые Uninstall-ADServiceAccount выполняет в PowerShell.

Чтобы удалить gMSA, откройте окно PowerShell с повышенными привилегиями и выполните следующие действия.

  1. Для удаления одной учетной записи gMSA из вашей среды, выполните следующую команду, заменив <gMSAName> на нужное значение.

    Uninstall-ADServiceAccount -Identity <gMSAName>

  2. Чтобы удалить несколько gMSAs из среды, выполните следующую команду, заменив <gMSA#$> на ваши значения:

    $gMSANames = @("gMSA1$", "gMSA2$", "gMSA3$")

foreach ($gMSAs in $gMSANames) {
  Uninstall-ADServiceAccount -Identity $gMSAs
}

Дополнительные сведения о командлете Uninstall-ADServiceAccount см. в разделе Uninstall-ADServiceAccount.

См. также

  • Last updated on