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

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

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

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

• Использование концепций gMSA для ограничения области использования с помощью Credential Guard для привязки проверки подлинности компьютера.
• 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. Рекомендуется сохранить службу в состоянии начала в течение четырех времен существования билета (28 дней). Отложите миграцию, если контроллеры домена секционированы или репликация нарушены во время подключения.
• Обратите внимание на сайты, в которых задержки репликации превышают время продления билета по умолчанию в течение 10 часов. Атрибут groupMSAMembership проверяется и обновляется при каждом продлении билета, а при каждом входе в исходную учетную запись службы во время состояния "начать миграцию", которая добавляет учетную запись компьютера в группу GROUPMSAMembership dMSA.
  • Например, два сайта используют одну и ту же учетную запись службы, и каждый цикл репликации занимает более 10 часов в течение всего времени существования билета. В этом сценарии членство в группе теряется во время начальных циклов репликации.
• Миграция требует доступа к контроллеру домена чтения и записи (RWDC) для запроса и изменения SD.
• Без ограничений делегирование перестает работать после завершения миграции, если старая учетная запись службы использовала ее. Если вы используете dMSA, защищенную CG, не ограничено делегирование перестает работать. Дополнительные сведения см. в статье "Рекомендации и известные проблемы при использовании Credential Guard".

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

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

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

• Учетная запись службы предоставляется универсальному чтению для всех свойств dMSA.
• Учетная запись службы предоставляется свойству Write в msDS-groupMSAMembership
• msDS-DelegatedMSAState изменяется на 1
• msDS-ManagedAccountPrecededByLink имеет учетную запись службы.
• msDS-SupersededAccountState изменяется на 1
• msDS-SupersededManagedServiceAccountLink имеет значение dMSA

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

• Учетная запись службы удаляется из универсального чтения ко всем свойствам dMSA
• Учетная запись службы удаляется из свойства Write в атрибуте msDS-GroupMSAMembership
• MsDS-DelegatedMSAState имеет значение 2
• Имена субъектов-служб копируются из учетной записи службы в учетную запись dMSA.
• msDS-AllowedToDelegateTo копируется, если применимо
• msDS-AllowedToActOnBehalfOfOtherIdentity дескриптор безопасности копируется при необходимости.
• Назначенная политика AuthN, msDS-AssignedAuthnPolicy, учетной записи службы копируются поверх
• DMSA добавляется в любые серверы политики AuthN, в которые учетная запись службы была членом
• Доверенный бит контроля учетных записей проверки подлинности для делегирования (UAC) копируется, если он был установлен в учетной записи службы.
• msDS-SupersededServiceAccountState имеет значение 2
• Учетная запись службы отключена с помощью бита отключения UAC
• Имена субъектов-служб удаляются из учетной записи

области dMSA

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

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

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

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

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

См. также

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