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

Новый тип учетной записи, известный как делегированная управляемая учетная запись службы (dMSA), представлен в Windows Server 2025, который позволяет переносить традиционную учетную запись службы на учетную запись компьютера с управляемыми и полностью случайными ключами, отключая исходные пароли учетных записей службы. Проверка подлинности для dMSA связана с удостоверением устройства, что означает, что доступ к учетной записи может получить только указанные удостоверения компьютера, сопоставленные в Active Directory (AD). Использование DMSA помогает предотвратить сбор учетных данных с помощью скомпрометированных учетных записей (kerberoasting), что является распространенной проблемой с традиционными учетными записями служб.

Сравнение dMSA и gMSA

DMSAs и gMSAs — это два типа управляемых учетных записей служб, которые используются для запуска служб и приложений в Windows Server. DMSA управляется администратором и используется для запуска службы или приложения на определенном сервере. GMSA управляется AD и используется для запуска службы или приложения на нескольких серверах. Оба предложения обеспечивают улучшенную безопасность и упрощенное управление паролями. DMSA отличается по следующим значениям:

• Utilizing gMSA concepts to limit scope of usage using Credential Guard (CG) to bind machine authentication.
• CG можно использовать для повышения безопасности в dMSA путем автоматического смены паролей и привязки всех билетов учетной записи службы. Устаревшие учетные записи затем отключены для дальнейшего повышения безопасности.
• Несмотря на то, что gMSAs защищены с помощью созданных и автоматически созданных паролей, пароли по-прежнему не привязаны к компьютеру и могут быть украдены.

Функциональные возможности dMSA

dMSA позволяет пользователям создавать их как автономную учетную запись или заменять существующую стандартную учетную запись службы. При замене существующей учетной записи dMSA проверка подлинности на существующую учетную запись с помощью пароля блокируется. Запрос перенаправляется в локальный центр безопасности (LSA), чтобы пройти проверку подлинности с помощью dMSA, которая имеет доступ ко всем предыдущим учетным записям, к которым можно получить доступ в AD.

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

dMSA использует случайный секрет (производный от учетных данных учетной записи компьютера), который хранится контроллером домена (DC) для шифрования билетов. Секрет можно дополнительно защитить, включив CG. Хотя секреты, используемые dMSA, периодически обновляются в эпоху, например gMSA, ключевое отличие заключается в том, что секрет dMSA не может быть получен или найден где-либо, кроме контроллера домена.

Поток миграции для dMSA

Быстрая концепция процесса потока миграции для dMSA включает следующие действия.

1. Политику CG можно настроить для защиты удостоверения компьютеров.
2. Администратор запускает и завершает миграцию учетной записи службы.
3. Учетная запись службы обновляет сервер предоставления билетов (TGT).
4. Учетная запись службы добавляет удостоверение компьютера для разрешения принципов.
5. Исходная учетная запись службы становится отключенной.

Обратите внимание на следующие моменты при переносе DMSAs:

• Невозможно выполнить миграцию из управляемой учетной записи службы или gMSA в dMSA.
• Подождите по крайней мере два времени существования билета (эквивалентно 14 дням) после изменения дескриптора безопасности (SD) перед завершением миграции dMSA. Keeping a service in the start state for four ticket lifetimes (28 days) is recommended. Отложите миграцию, если контроллеры домена секционированы или репликация нарушены во время подключения.
• Pay attention to sites where replication delays are longer than the default ticket renewal time of 10 hours. The groupMSAMembership attribute is checked and updated at every ticket renewal, and every time the original service account logs on during the "start migration" state, which adds the machine account to the groupMSAMembership of the dMSA.
  • Например, два сайта используют одну и ту же учетную запись службы, и каждый цикл репликации занимает более 10 часов в течение всего времени существования билета. В этом сценарии членство в группе теряется во время начальных циклов репликации.
• Миграция требует доступа к контроллеру домена чтения и записи (RWDC) для запроса и изменения SD.
• Без ограничений делегирование перестает работать после завершения миграции, если старая учетная запись службы использовала ее. Если вы используете dMSA, защищенную CG, не ограничено делегирование перестает работать. Дополнительные сведения см. в статье "Рекомендации и известные проблемы при использовании Credential Guard".

Warning

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

Атрибуты учетной записи для dMSA

В этом разделе описывается, как атрибуты для изменений dMSA в схеме AD. Эти атрибуты можно просматривать с помощью оснастки Пользователи и компьютеры Active Directory или запуска редактирования ADSI в контроллере домена.

Note

Числовые атрибуты, заданные для учетной записи, указывают:

• 1 - Account migration has begun.
• 2 - Account migration has completed.

При выполнении Start-ADServiceAccountMigration выполняются следующие изменения:

• The service account is granted Generic Read to all properties on the dMSA
• The service account is granted Write property to msDS-groupMSAMembership
• msDS-DelegatedMSAState is changed to 1
• msDS-ManagedAccountPrecededByLink is set to the service account
• msDS-SupersededAccountState is changed to 1
• msDS-SupersededManagedServiceAccountLink is set to the dMSA

При выполнении Complete-ADServiceAccountMigration выполняются следующие изменения:

• The service account is removed from Generic Read to all properties on the dMSA
• The service account is removed from Write property on the msDS-GroupMSAMembership attribute
• msDS-DelegatedMSAState is set to 2
• Имена субъектов-служб копируются из учетной записи службы в учетную запись dMSA.
• msDS-AllowedToDelegateTo is copied over if applicable
• msDS-AllowedToActOnBehalfOfOtherIdentity the security descriptor is copied over if applicable
• The assigned AuthN policy, msDS-AssignedAuthnPolicy, of the service account are copied over
• DMSA добавляется в любые серверы политики AuthN, в которые учетная запись службы была членом
• Доверенный бит контроля учетных записей проверки подлинности для делегирования (UAC) копируется, если он был установлен в учетной записи службы.
• msDS-SupersededServiceAccountState is set to 2
• Учетная запись службы отключена с помощью бита отключения UAC
• Имена субъектов-служб удаляются из учетной записи

dMSA realms

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

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

Например, если у вас есть основной домен под управлением corp.contoso.com Windows Server 2025 и более старый дочерний домен под управлением legacy.corp.contoso.com Windows Server 2022, можно указать область как legacy.corp.contoso.com.

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

Конфигурация компьютера\Административные шаблоны\System\Kerberos\Включение делегированного входа управляемой учетной записи службы

See also

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