KomuraSoft LLC
Связаться с нами
Меню

Выбор учётной записи службы Windows — LocalSystem, виртуальные учётные записи и gMSA

· · Windows, Службы Windows, Учётные записи служб, gMSA, LocalSystem, Виртуальные учётные записи, Безопасность, Active Directory, Наименьшие права

«Внутреннюю службу, которую мы пока запускали от LocalSystem, на аудите безопасности отметили как „избыточные права“. На что менять?» «Служба не могла обратиться к общей папке, поэтому мы запускаем её от доменного пользователя. Когда пароль истекает, служба останавливается, поэтому мы сделали его без срока и записали открытым текстом в регламент.» — Среди консультаций вокруг служб Windows заказчиков эти две — классика.

Общее у обеих площадок то, что учётная запись входа службы заморожена как «настройка, которая случайно заработала», а не как проектное решение. Служба Windows всегда работает в контексте безопасности какой-то учётной записи, и эта учётная запись решает всё: что она может делать локально, кем она выглядит с той стороны сети и кто ведёт пароль. Оставьте это по умолчанию — и уязвимость одной службы ведёт напрямую к захвату всей машины, а открытые пароли разлетаются по регламентам и сценариям.

Три вещи, которые решает учётная запись входаСлужба всегда работает в контексте безопасности какой-то учётной записи, и эта учётная запись решает всё, что она может делать локально, кем она выглядит с той стороны сети и кто ведёт парольУчётная запись входа службыЧто она может делать локальноКем она выглядит с той стороны сетиКто ведёт пароль

Рис. 1: Выбор учётной записи входа — проектное решение, которое одновременно фиксирует локальные права, сетевую идентичность и ведение пароля.

Фактически есть шесть выборов — LocalSystem, LocalService, NetworkService, виртуальная учётная запись (NT SERVICE\<имя-службы>), доменный пользователь и gMSA (групповая управляемая учётная запись службы). Рассчитанная на ИТ-сотрудников малых и средних предприятий и разработчиков приложений Windows, эта статья сводит права, сетевую идентичность и ведение пароля этих шести в одну таблицу и кратко излагает поток решений, опираясь на первоисточники Microsoft Learn по состоянию на август 2026 года.

Как строить саму службу (выбор между планировщиком заданий и службой, реализация через .NET Worker Service) разобрано в «Как создавать и эксплуатировать службы Windows». Эта статья сосредоточена на «учётной записи входа» — там, где случается больше всего аварий.

1. Сначала вывод

  • Если сомневаетесь, первый кандидат для службы, которая заканчивается внутри одной машины, — виртуальная учётная запись, а для службы, которая обращается к ресурсу внутри домена с идентичностью конкретной службы, — gMSA. Microsoft также даёт указание использовать управляемую учётную запись (MSA / виртуальную) везде, где возможно.12
  • Не выбирайте LocalSystem потому что «работает». Токен включает SYSTEM и BUILTIN\Administrators и держит сильные права вроде SeDebugPrivilege, поэтому захват почти всё на этой машине теряет. То, что значение по умолчанию sc.exe create — LocalSystem, и есть питательная среда этой аварии.34
  • Разница между LocalService и NetworkService — сетевая идентичность. Локальные права у обеих минимальны, но для удалённой стороны LocalService выглядит анонимно, а NetworkService — как учётная запись компьютера.5
  • **Виртуальная учётная запись (NT SERVICE\<имя-службы>) — современное значение по умолчанию, которое разделяет идентичность по службам, не требуя ведения пароля.** «NT SERVICE\\имя-службы» можно указать прямо в ACL, и учётная запись службы SQL Server по умолчанию — тоже она.[^understand-service-accounts][^sql-service-accounts]
  • Когда LocalSystem, NetworkService или виртуальная учётная запись выходят в сеть, они становятся учётной записью компьютера (DOMAIN\имя-компьютера$). Выдача PC$ в ACL общей папки или SQL Server часто позволяет обойтись без доменного пользователя.36
  • Конфигурация, которая использует доменного пользователя для службы, становится долгом и по эксплуатации паролей, и перед Kerberoasting. SCM входит с сохранённым паролем, поэтому истечение становится отказом запуска, а «никогда не истекает + заметка открытым текстом», которое это обходит, становится подарком злоумышленнику.78
  • gMSA заставляет Active Directory автоматически порождать и чередовать пароль. Требования — домен и корневой ключ KDS, а службу задают как «DOMAIN\имя-учётной-записи$» с пустым полем пароля. Некоторые приложения этого не поддерживают, поэтому нужна предварительная проверка.910
  • Смена учётной записи меняет предпосылки профиля, %TEMP% и DPAPI. Данные, защищённые DPAPI старой учётной записи, новая расшифровать не может.
  • Инвентаризацию текущего состояния можно подтвердить по учётным записям входа списка служб и по событию с кодом 4624 (тип входа 5).11

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

2. Общая картина выборов — шесть учётных записей входа в одной таблице

Сначала один шаг повторения. При запуске службы диспетчер управления службами (SCM) входит как настроенная учётная запись и при успехе создаёт маркер доступа и назначает его процессу службы. Далее каждый доступ к ресурсу — файлам, каналам и подобному — решается сопоставлением этого маркера с ACL.7 Значит, выбор учётной записи входа — проект, который решает содержимое маркера, передаваемого процессу службы. Вот шесть выборов.

Что делает SCM при запуске службыSCM входит как настроенная учётная запись, при успехе создаёт маркер доступа и назначает его процессу службы, и далее доступ к ресурсам решается сопоставлением маркера с ACLДаНетSCMВойти как настроенная учётная записьСоздать маркер доступаНазначить его процессу службыДоступ к файлу или каналуACL разрешает?Доступ успешенДоступ отказан

Рис. 2: Каждый доступ службы к ресурсу решается сопоставлением маркера, который SCM создал при запуске, с ACL.

Учётная запись Локальные права Сетевая идентичность Ведение пароля Типичное применение
LocalSystem Почти без ограничений (SYSTEM+Administrators) Учётная запись компьютера (PC$) Не нужно (пароля нет) Исключительные службы, которые работают как одно целое с ОС
LocalService Минимальные (класс Users) Анонимная Не нужно Локальная обработка без сетевой идентичности
NetworkService Минимальные (класс Users) Учётная запись компьютера (PC$) Не нужно Обработка с малыми правами, где хватает идентичности машины
Виртуальная NT SERVICE\<имя> Минимальные + выдача по отдельности в ACL Учётная запись компьютера (PC$) Не нужно (ведётся автоматически) Значение по умолчанию для деловой службы на одном сервере
Доменный пользователь Только то, что выдали Сам этот пользователь Вручную (истечение, утечка и смена остаются на людях) Последнее средство для приложения, которое не поддерживает gMSA
gMSA Только то, что выдали Сама эта gMSA AD порождает и чередует автоматически Когда доменной среде нужна идентичность конкретной службы

У LocalSystem, LocalService, NetworkService и виртуальной учётной записи вообще нет понятия пароля. Единственные, кто входит с паролем, сохранённым в SCM (= возможны истечение и утечка), — доменный пользователь и локальный пользователь.73

Ниже разбираем эту таблицу по строкам.

3. В чём беда LocalSystem

3.1. Ещё сильнее, чем «Запуск от имени администратора»

LocalSystem (отображаемое имя Local System, NT AUTHORITY\SYSTEM) — предопределённая учётная запись, которую использует SCM, и она держит обширные права на локальном компьютере. В токен входят SID NT AUTHORITY\SYSTEM и BUILTIN\Administrators, и она может обращаться к большинству объектов системы. Далее SeDebugPrivilege, которая может отлаживать другие процессы, и SeTcbPrivilege, которая действует как часть ОС, включены по умолчанию.3

Эта сила синонимична размеру ущерба при захвате. Если у службы, запущенной от LocalSystem, есть одна уязвимость произвольного выполнения кода, злоумышленник одним дыханием доходит до чтения и порчи файлов каждого пользователя на этой машине (у SYSTEM по умолчанию полный контроль на NTFS5), чтения памяти других процессов через SeDebugPrivilege и кражи учётных данных и бокового перемещения оттуда (отправная точка для Pass-the-Hash и подобного). Цепочка кражи учётных данных и бокового перемещения разобрана в «NTLM and Kerberos Explained with Diagrams» и «A Practical Guide to Windows LAPS».

Ущерб при захвате службы LocalSystemЕсли у службы, запущенной от LocalSystem, есть одна уязвимость произвольного выполнения кода, злоумышленник доходит до чтения и порчи файлов каждого пользователя, чтения памяти других процессов и кражи учётных данных с боковым перемещениемОдна уязвимость произвольного выполнения кодаЗлоумышленник получает права SYSTEMЧтение и порча файловЧтение памяти других процессовКража учётных данныхБоковое перемещение на другую машину

Рис. 3: Одна уязвимость в службе LocalSystem позволяет злоумышленнику одним дыханием дойти до захвата всей машины и отправной точки бокового перемещения.

3.2. Почему её всё ещё выбирают

Причина проста: это значение по умолчанию, и отказ в доступе никогда не появляется. Значение по умолчанию, если опустить obj= в sc.exe create, — LocalSystem,4 и многие старые образцы кода и шаблоны установщиков всё ещё предполагают LocalSystem. Потому что в разработке можно оставаться свободным от ошибок прав, есть структура, которая массово производит «заработало — оставим». Собственная документация Microsoft также утверждает, что большинству служб не нужен столь высокий уровень прав и что если он не нужен, следует рассмотреть LocalService или NetworkService.3

Структура, из-за которой LocalSystem продолжают выбиратьЗначение по умолчанию sc.exe create — LocalSystem, и старые образцы и шаблоны тоже предполагают LocalSystem, поэтому в разработке отказ в доступе не появляется и массово производится конфигурация заработало поэтому оставимЗначение по умолчанию sc.exe createСоздана как LocalSystemСтарые образцы и шаблоныНет отказа в доступе в разработкеЗаработало, поэтому оставимСлужбы с избыточными правами производятся массово

Рис. 4: Значение по умолчанию и опыт разработки «без отказа в доступе» массово производят службы, замороженные как LocalSystem.

3.3. Отличие от TrustedInstaller — LocalSystem тоже не безгранична

Называть LocalSystem «самой сильной учётной записью Windows» неточно. Защита ресурсов Windows (WRP) начиная с Windows Vista разрешает изменения важных системных файлов, папок и ключей реестра только TrustedInstaller (службе установщика модулей Windows), и даже SYSTEM или администратор получают отказ в доступе при перезаписи.12 «Вам нужно разрешение от TrustedInstaller» в Проводнике — этот механизм. Наоборот, LocalSystem может достичь почти всего вне области, защищённой WRP, и обычно нет причин давать это деловой службе.

Связь области, защищённой WRP, и TrustedInstallerИзменения важных системных файлов и ключей реестра, которые защищает WRP, разрешены только TrustedInstaller, и даже SYSTEM или администратор получают отказ в доступеМожет менятьОтказ в доступеПочти всё разрешеноTrustedInstallerСистемные файлы, защищённые WRP, и подобноеSYSTEM и администраторыВне области, защищённой WRP

Рис. 5: LocalSystem тоже не безгранична; изменения области, защищённой WRP, разрешены только TrustedInstaller.

3.4. Случаи, когда LocalSystem разумна

Исключительно разумно — служба, чьи нужные права изначально превышают класс администратора — тесная работа с драйвером устройства, управление фундаментом безопасности ОС, управление другими службами или сеансами и подобное. Подходит ПО вроде агента резервного копирования или EDR. Даже тогда стоит подтвердить, что есть путь кода, который действительно использует это право, и рассмотреть, можно ли отделить работу, которой нужно право (как отличить — см. «Когда на Windows действительно требуются права администратора»).

4. LocalService и NetworkService — встроенные учётные записи с наименьшими правами

LocalService (NT AUTHORITY\LOCAL SERVICE, SID: S-1-5-19) и NetworkService (NT AUTHORITY\NETWORK SERVICE, SID: S-1-5-20) — встроенные учётные записи, подготовленные для служб с малыми правами. Обе держат локально только минимальные права и могут мало больше члена группы Users.51

Разница между ними в одном: кем они выглядят с той стороны сети.5

  • LocalService: подключается к удалённой стороне с анонимными учётными данными. Не может обратиться к ресурсу, требующему проверки подлинности.
  • NetworkService: предъявляет удалённой стороне учётные данные компьютера (в доменной среде DOMAIN\имя-компьютера$).

Разделение: LocalService, если «в сеть не выходит или, если выходит, идентичность не нужна», и NetworkService, если «хотите обратиться к ресурсу внутри домена с идентичностью машины».

Разница между LocalService и NetworkServiceЛокальные права у обеих минимальны, но к удалённой стороне LocalService подключается с анонимными учётными данными, а NetworkService предъявляет учётные данные компьютераLocalServiceПодключается с анонимными учётными даннымиРесурс, требующий проверки подлинности, невозможенNetworkServiceПредъявляет учётные данные компьютераВ домене выглядит как PC$

Рис. 6: Локальные права — тот же минимум, но идентичность, видимая с той стороны сети, делится на анонимную или учётную запись компьютера.

Однако у этих двух есть слабость с современной точки зрения. Одну и ту же учётную запись разделяют многие службы. Если пять служб работают от LocalService, то пока ACL по учётной записи, пять могут обращаться к ресурсам друг друга. SQL Server не поддерживает учётную запись Local Service по той же причине: это общая учётная запись, и её нельзя отделить от других служб.1

Общую учётную запись нельзя разделитьЕсли несколько служб разделяют одну LocalService, то пока ACL по учётной записи они могут обращаться к ресурсам друг другаСлужба AТа же LocalServiceСлужба BСлужба CМогут обращаться к ресурсам друг другаПотому что ACL по учётной записи

Рис. 7: Службы, которые разделяют одну учётную запись, нельзя отделить ACL от ресурсов друг друга.

Решить это «остаться с малыми правами, но разделить по службам» — следующая тема, виртуальная учётная запись.

5. Виртуальные учётные записи (NT SERVICE\<имя-службы>) — современное значение по умолчанию

5.1. Можно иметь идентичность на службу без пароля

Виртуальная учётная запись — «управляемая локальная учётная запись», доступная с Windows Server 2008 R2 / Windows 7. У неё три свойства.6

  • Учётная запись ведётся автоматически; ни создание, ни задание пароля не нужны
  • Имя — NT SERVICE\<имя-службы>, и она становится идентичностью, уникальной для каждой службы
  • В доменной среде она может выходить в сеть с учётными данными учётной записи компьютера (DOMAIN\имя-компьютера$)

Иначе говоря, она сохраняет достоинство «нет ведения пароля» у LocalService/NetworkService и снимает недостаток «нельзя разделить, потому что учётная запись общая». Поэтому установка SQL Server по умолчанию использует виртуальную учётную запись вроде NT SERVICE\MSSQLSERVER.1

Что виртуальная учётная запись делает совместимымВиртуальная учётная запись сохраняет достоинство отсутствия ведения пароля у LocalService и NetworkService, снимает недостаток нельзя разделить потому что общая и имеет идентичность, уникальную для каждой службыСохранитьСнятьДостоинство (нет ведения пароля)Виртуальная учётная записьНедостаток (нельзя разделить потому что общая)Идентичность, уникальная для каждой службыНи создание, ни пароль не нужны

Рис. 8: Виртуальная учётная запись сохраняет достоинства встроенных и снимает только недостаток нельзя разделить потому что общая.

5.2. «NT SERVICE\имя-службы» можно писать прямо в ACL

Практическое удобство в том, что в ACL можно добавить только эту службу по имени. «Только эта служба может писать в эту папку данных» реализуется без создания группы и без ведения пароля.

# Change the service's logon account to a virtual account
# The value of obj= is "NT SERVICE\service-name". Do not specify a password
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# Confirm the configuration (check SERVICE_START_NAME)
sc.exe qc MyAppService

# Grant modify rights on the data folder to this service only
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

В графическом интерфейсе в services.msc откройте свойства службы → вкладка «Вход» → введите NT SERVICE\имя-службы в «С учётной записью» и оставьте поля пароля пустыми (для виртуальной учётной записи или MSA не указывать пароль — спецификация SCM). После смены перезапуск службы применяет её.

5.3. Ограничение — вне машины это не «та служба»

Идентичность виртуальной учётной записи локальна для машины и не распознаётся доменом. В сети она сжимается до учётной записи компьютера, как описано далее, поэтому удалённая сторона не может сказать, «какая это служба», и ту же идентичность нельзя разделить между несколькими серверами.10

Идентичность виртуальной учётной записи сжимается вне машиныВиртуальная учётная запись, уникальная для каждой службы внутри машины, в сети тоже сжимается до учётной записи компьютера, и удалённая сторона не может сказать, какая это службаВиртуальная учётная запись AУчётная запись компьютера PC$Виртуальная учётная запись BИдентичность, видимая удалённой сторонеНельзя сказать, какая это служба

Рис. 9: Даже с уникальной идентичностью внутри машины, с той стороны сети каждая служба выглядит как один и тот же PC$.

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

6. Идентичность при выходе в сеть — практика учётной записи компьютера (PC$)

6.1. «Служба не может обратиться к общей папке» — недоразумение

На машине, присоединённой к домену, когда служба, запущенная как LocalSystem, NetworkService или виртуальная учётная запись, обращается к удалённому ресурсу, она проходит проверку подлинности как учётная запись компьютера (DOMAIN\имя-компьютера$).36 Многие консультации в начале «не могла обратиться к общей папке, поэтому сделали доменным пользователем» на деле решаются этим. ACL назначения просто не разрешала PC$.

Удалённый доступ как учётная запись компьютераСлужба LocalSystem, NetworkService или виртуальная на машине, присоединённой к домену, проходит проверку подлинности на удалённой стороне как учётная запись компьютера, и если ACL назначения разрешает PC$, она может обратитьсяДаНетСлужба (LocalSystem, виртуальная учётная запись и подобное)Пройти проверку как PC$ACL назначения разрешает PC$?Доступ к общей папке или БД успешенДоступ отказан

Рис. 10: В доменной среде одной выдачи PC$ в ACL назначения достаточно, чтобы установить удалённый доступ без доменного пользователя.

Выдача на стороне файлового сервера та же, что обычная операция ACL; укажите имя-компьютера$ как имя учётной записи (в диалоге выбора объектов графического интерфейса включите «Компьютеры» в типы объектов).

# On the file-server side: grant a service on APPSV01 modify rights on the shared folder
# You need to grant both share permissions and NTFS permissions
Grant-SmbShareAccess -Name "AppData" -AccountName "CORP\APPSV01$" -AccessRight Change -Force
icacls "D:\Shares\AppData" /grant "CORP\APPSV01$:(OI)(CI)M"

С SQL Server то же: создайте учётную запись компьютера как имя входа, и строка подключения проходит с Integrated Security=true без пароля.

-- On the DB-server side: permit Windows integrated authentication from a service on APPSV01
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

6.2. Знайте пределы подхода PC$

У этого подхода два предела.

  1. Зернистость — на машину. LocalSystem, NetworkService и каждая служба с виртуальной учётной записью на одной машине с удалённой стороны выглядят как один и тот же PC$. На назначении нельзя «разрешить только этой службе», и нельзя проверить, какая служба использовала эту учётную запись.2
  2. Его нельзя использовать в рабочей группе. Учётная запись компьютера — объект Active Directory, поэтому у машины, не присоединённой к домену, её нет. Нужно проектирование, которое явно обрабатывает учётные данные учётной записи назначения.

Когда хотите выйти за предел 1, ответ 2026 года — не доменный пользователь следующей главы… а пропустить эту проблему и перейти к gMSA.

Два предела подхода PC$Проверка подлинности как PC$ имеет зернистость уровня машины, поэтому ни разрешение, ни проверка по службам невозможны, а в рабочей группе самой учётной записи компьютера нет, поэтому использовать нельзяПодход PC$Предел 1: на машинуПредел 2: нет рабочей группыНи разрешения, ни проверки по службамИспользовать явные учётные данныеДальше: gMSA

Рис. 11: Когда хотите выйти за два предела зернистости уровня машины и предпосылки домена, пропустите доменного пользователя и перейдите к gMSA.

7. Проблема использования доменного пользователя для службы

7.1. Структурная проблема пароля

Если назначить службе доменного пользователя (или локального), SCM сохраняет этот пароль и использует его для входа при каждом запуске. SCM не ведёт истечение, поэтому когда пароль истекает, вход не удаётся и служба не запускается.7

Оттуда начинается отрицательная спираль, которую часто видят на местах.

  1. Происходит авария остановки службы из-за истечения
  2. Как предотвращение повтора задают «пароль никогда не истекает»
  3. Процедура смены так и не устанавливается, и тот же пароль пишут открытым текстом в регламенты, сценарии и планировщик заданий нескольких серверов
  4. Даже когда кто-то уходит, пароль не меняют (если смените — не знаете, что остановится)
Отрицательная спираль эксплуатации с доменным пользователемПароль истекает и служба останавливается, «никогда не истекает» задают как предотвращение повтора, открытый пароль распространяется по регламентам и сценариям, и даже когда кто-то уходит, его нельзя сменить1. Истечение останавливает службу2. «Никогда не истекает» задают как предотвращение3. Открытый пароль распространяетсяРегламенты, сценарии, задания4. Даже когда кто-то уходит, сменить нельзя

Рис. 12: Начиная с аварии истечения, «никогда не истекает» и распространение открытого пароля закрепляются.

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

7.2. Kerberoasting — учётная запись службы становится целью

Ещё одна атака, специфичная для учётной записи службы доменного пользователя, — Kerberoasting. Служба, принимающая проверку подлинности Kerberos, регистрирует SPN (имя субъекта-службы) на учётной записи входа. Любой прошедший проверку пользователь домена может запросить билет службы к учётной записи с зарегистрированным SPN, поэтому злоумышленник получает билет и пробует автономный перебор пароля. Пароль из 10–16 символов, который решил человек, этой атаке не выдержит.

Поток KerberoastingБилет службы к учётной записи службы с зарегистрированным SPN может запросить любой прошедший проверку пользователь, поэтому злоумышленник получает билет и пробует автономный перебор пароляПрошедший проверку пользователь доменаЗапросить билет для SPNПолучить билет службыАвтономный переборПримерно 10–16 символов будут взломаны

Рис. 13: Любой прошедший проверку пользователь может запросить билет, и пароль длины, которую решил человек, не выдержит автономный перебор.

Действенный ответ — сделать пароль такой силы, которую человек не угадает и не взломает. Microsoft также перечисляет принуждение к длинному паролю и использование gMSA, чей пароль становится длинным машинно порождённым случайным значением.8 Тот же документ упоминает и броню Kerberos (FAST), но FAST защищает данные предварительной проверки подлинности и устойчивость к подмене KDC; она не мешает прошедшему проверку пользователю запросить билет службы к SPN, поэтому это не замена силе пароля учётной записи службы. Связь SPN и Kerberos и условия, при которых проверка подлинности падает на NTLM, изображены в «NTLM and Kerberos Explained with Diagrams».

7.3. Если всё же используете доменного пользователя

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

  • Сделайте пароль случайно порождённым из 25 символов или больше и нигде кроме средства ведения паролей не пишите (регламенты, сценарии, общая книга Excel)
  • Сделайте её учётной записью, выделенной службе, и разделите по службам (не делите с человеческой учётной записью2)
  • Запретите интерактивный вход и удалённый рабочий стол и разрешите только «Вход в качестве службы»
  • Сведите к минимуму группы, в которые она входит (добавлять в Domain Admins нечего и думать)
  • Установите процедуру периодической смены и занесите места, которые затронет смена, в реестр

Сделать всё это менее безопасно и менее просто, чем перейти на gMSA — это следующая глава.

8. gMSA — оставить ведение пароля Active Directory

8.1. Механизм и эффект

gMSA (групповая управляемая учётная запись службы) — доменная учётная запись, которая оставляет ведение пароля контроллеру домена. Пароль вычисляет контроллер домена из корневого ключа KDS (Key Distribution Service), и только разрешённые узлы его получают.13

Как gMSA ведёт парольКонтроллер домена вычисляет пароль из корневого ключа KDS, только разрешённые узлы получают его и используют для запуска службы, и пароль по умолчанию автоматически чередуется каждые 30 днейКорневой ключ KDSКД вычисляет парольРазрешённый узел получает егоИспользуется для запуска службыАвтоматическая смена каждые 30 дней по умолчанию

Рис. 14: Контроллер домена берёт на себя порождение, раздачу и обновление пароля, и люди могут работать, не зная пароля.

Эффекты ясны.9

  • Случайно порождённый пароль 240 байт: перебор и словарные атаки становятся нереалистичными, и устойчивость к Kerberoasting существенно растёт
  • Автоматическая смена каждые 30 дней по умолчанию: человеку не нужно планировать смену, и службу не нужно останавливать
  • Одну и ту же идентичность можно разделить между несколькими серверами: ферма серверов под балансировкой нагрузки может взаимно проходить проверку подлинности как один и тот же субъект
  • Более простое ведение SPN: регистрацию и ведение SPN тоже можно делегировать и упростить

Люди могут работать, не зная пароля — если принять это как механизм, который для учётной записи службы делает то, что Windows LAPS делает для пароля локального администратора, размещение легче ухватить.

8.2. Требования

У gMSA есть предпосылки.10

  • Доменная среда Active Directory (в рабочей группе невозможно)
  • Функциональные уровни домена и леса Windows Server 2012 или выше
  • Корневой ключ KDS уже создан
  • Имя gMSA уникально в лесу, а не только в домене
  • Интервал смены пароля можно задать только при создании

Создание корневого ключа KDS — разовая задача, но до 10 часов после создания gMSA создать нельзя, потому что ждут репликации на каждый контроллер домена. Это предохранитель, чтобы не случилась авария отказа извлечения пароля, пока репликация не закончилась.14

От создания корневого ключа KDS до создания gMSAПосле создания корневого ключа KDS ждут репликации на каждый контроллер домена, поэтому до 10 часов gMSA создать нельзя; после завершения репликации можно создатьСоздать корневой ключ KDSДо 10 часов ожидания репликацииПредохранитель против аварии отказа извлеченияРепликация на каждый КД завершенаМожно создать gMSA

Рис. 15: Ожидание до 10 часов после создания корневого ключа — время ожидания, чтобы не допустить отказа извлечения, пока репликация не закончилась.

# Run as a domain administrator, on a domain controller (or an administrative
# workstation with the AD PowerShell module)

# Confirm whether a KDS root key exists, and create one if not (once per forest)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # Actually usable after up to 10 hours

8.3. Процедура от создания до настройки

Процедура в четыре этапа: «① создать группу, которой разрешено извлекать → ② создать gMSA → ③ установить на серверы → ④ задать службе».10

Четыре этапа внедрения gMSAВнедрить в четыре этапа: создать группу, которой разрешено извлекать пароль, создать gMSA, установить на каждый сервер и задать как учётную запись входа службы① Создать группу, которой разрешено извлекать② Создать gMSAДобавить PC$ серверов③ Установить на каждый серверПроверить извлечение командой Test④ Задать службе

Рис. 16: От создания группы до задания службе внедрение gMSA идёт в четыре этапа.

# ① Create a security group permitted to retrieve the password,
#    and add the computer accounts of the servers that will run the service
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# Group membership is evaluated at computer logon, so
# restarting the target servers after adding is the reliable approach

# ② Create the gMSA
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# ③ On each server that will run the service, install the gMSA and validate
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True means retrieval is working

# ④ Set it as the service's logon account. Append $ to the name, and do not specify a password
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

При задании из services.msc имя учётной записи тоже вроде CORP\svc-batch$ — добавьте $ в конце и оставьте поля пароля пустыми. Учётную запись семейства MSA нельзя использовать для интерактивного входа.1 Затем выдайте CORP\svc-batch$ в ACL общей папки или SQL Server вместо PC$, и сетевой доступ с идентичностью конкретной службы готов, без пароля.

8.4. Некоторые приложения этого не поддерживают

Как оговорка: не каждое ПО будет работать как gMSA. То, что настраивает идентичность входа через стандартный механизм — служба Windows, пул приложений IIS, задание планировщика — широко поддерживается, но есть ограничения: сам отказоустойчивый кластер gMSA не поддерживает, а приложение, внутри которого требуют пароль, использовать его не может.10 Microsoft также прямо говорит, что поведение как gMSA нужно подтвердить в тестовой среде до промышленной.9

Как отличить, поддерживает ли что-то gMSAПриложение, которое настраивает идентичность входа через стандартный механизм, широко поддерживает gMSA, но отказоустойчивый кластер и приложение, внутри которого требуют пароль, использовать её не могут, поэтому подтвердите в тестовой среде до промышленнойСтандартный механизмТребуют парольЦелевое приложениеКак задаётся вход?gMSA поддерживаетсяСлужба, IIS, заданиеgMSA невозможнаОтказоустойчивый кластерПроверить до промышленной

Рис. 17: Приложение, которое настраивает вход через стандартный механизм, широко поддерживается, но некоторые проекты не поддерживаются, поэтому проверка до промышленной незаменима.

Есть и родственники: sMSA (автономная управляемая учётная запись службы) для одного сервера и dMSA (делегированная управляемая учётная запись службы, введённая в Windows Server 2025, которая привязывается к идентичности устройства, чтобы противостоять краже учётных данных). Для новой постройки берите gMSA как базовую линию и рассматривайте по требованиям.6

9. Сопутствующее проектирование — права входа, профиль, DPAPI и аудит

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

9.1. Право «Вход в качестве службы» (SeServiceLogonRight)

Чтобы запуститься как служба, учётной записи нужно право пользователя «Вход в качестве службы». У LocalSystem, LocalService и NetworkService оно встроено, но любой другой учётной записи (доменному пользователю, gMSA и подобному) нужно явное назначение.15

Если задаёте со вкладки «Вход» графического интерфейса services.msc, оснастка выдаёт это право автоматически. С другой стороны, CreateService / ChangeServiceConfig (API, которые вызывает sc.exe config) не проверяют, есть ли у указанной учётной записи это право. Типичная причина, по которой служба, настроенная сценарием, останавливается при запуске с «служба не запущена из-за ошибки входа», — именно это. Не полагайтесь на побочный эффект средства; явно включите в процедуру развёртывания добавление в «Вход в качестве службы» в локальной политике безопасности (secpol.msc) или настройку через GPO/Intune (в среде, которая настраивает это право групповой политикой, локальная выдача перезаписывается при применении политики, поэтому на это тоже нужно внимание). Наоборот, стандартный ход для учётной записи, выделенной службе, — задать вместе «Запретить локальный вход».

Разница по пути настройки права Вход в качестве службыГрафический интерфейс services.msc выдаёт право автоматически, но API, которую вызывает sc.exe config, право не проверяет, поэтому учётная запись без права останавливает службу с ошибкой входа при запускеДаНетЗадать в services.mscПраво выдаётся автоматическиСлужба может запуститьсяЗадать через sc.exe configПраво не проверяетсяЕсть право?Служба может запуститьсяОстанавливается с ошибкой входаВыдать явно через secpol.msc или GPO

Рис. 18: Графический интерфейс выдаёт право автоматически, но настройка сценарием его не проверяет, поэтому в процедуру нужно включить явную выдачу.

9.2. Профиль, %TEMP% и HKEY_CURRENT_USER меняются

SCM загружает профиль пользователя этой учётной записи при запуске службы.7 Поэтому настоящие %TEMP%, %APPDATA% и HKEY_CURRENT_USER — разное на каждую учётную запись входа, и при смене учётной записи настройки и кэш, сохранённые в профиле старой, выглядят так, будто «пропали».

Ответ проектирования прост: кладите данные службы не под профилем, а на явный путь вроде C:\ProgramData\<имя-приложения> и выдайте этот ACL учётной записи входа. Тогда смена учётной записи не несёт переноса данных.

Зависимость от профиля и ответ размещения данныхНастоящий профиль разный на каждую учётную запись входа, поэтому смена учётной записи делает данные старого профиля похожими на пропавшие, но размещение на явном пути и выдача ACL делают перенос ненужнымОтветСмена учётной записи входаЗагружается другой профильСтарые данные выглядят пропавшимиПоложить под ProgramDataВыдать ACL учётной записи входаНет переноса даже при смене учётной записи

Рис. 19: Избегайте профиля и кладите данные на явный путь — и смена учётной записи больше не несёт переноса данных.

9.3. Данные, защищённые DPAPI, привязаны к учётной записи

Ещё легче пропустить — DPAPI. Данные, зашифрованные DPAPI пользовательского охвата (CryptProtectData или ProtectedData в .NET), в принципе может расшифровать только та же учётная запись, которая их защитила. В момент смены учётной записи сохранённую строку подключения или ключ API уже нельзя прочитать — это DPAPI делает свою работу правильно, но если этого нет в процедуре переноса, это становится инцидентом.

Связь данных, защищённых DPAPI, и смены учётной записиДанные, защищённые DPAPI пользовательского охвата, может расшифровать только та же учётная запись, которая их защитила, поэтому после смены учётной записи входа нужно заново ввести секретыТа же стараяНоваяЗащитить DPAPI старой учётной записьюЗащищённая строка подключения и подобноеКакая учётная запись расшифровывает?Может расшифроватьНе может расшифроватьЗаново ввести секреты

Рис. 20: Данные, защищённые DPAPI, привязаны к учётной записи, которая их защитила, и после смены учётной записи нужно вводить заново.

Ответ — включить в план переноса процедуру «заново ввести секреты после смены учётной записи» (о проектировании, куда их класть, см. «Хранение секретов в Windows-приложениях»). Также конфигурация, которая может закончиться встроенной проверкой подлинности Windows как gMSA или PC$, может устранить само хранение секрета. Правильный порядок — сначала рассмотреть «можно ли обойтись без хранения», а потом «куда хранить».

А если служба хочет обрабатывать «с правами вызывающего пользователя», используют олицетворение, а не делают учётную запись сильнее. Об этом — «Как правильно работать с токенами олицетворения в Windows».

9.4. Аудит — смотрите 4624 тип входа 5

Запуск службы записывается в журнал событий безопасности как событие с кодом 4624 (Учётная запись успешно вошла в систему) с типом входа 5 (Служба: SCM запустила службу). Поле «Virtual Account» в событии показывает, был ли вход от MSA / виртуальной учётной записи, поэтому его можно использовать и для наблюдения за использованием управляемых учётных записей.11

Поток аудита запуска службыЗапуск службы SCM записывается как событие с кодом 4624 тип входа 5, и поле Virtual Account может определить, был ли вход от управляемой учётной записиSCM запускает службуЗаписать событие с кодом 4624Тип входа 5 (Служба)Поле Virtual AccountНаблюдение за управляемыми учётными записями

Рис. 21: Запуск службы записывается как 4624 типа входа 5, и можно даже отслеживать использование управляемых учётных записей.

Для инвентаризации текущего состояния быстрый способ — агрегировать учётные записи входа списка служб.

# Aggregate which services are running as which account
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Inventory non-standard services running as LocalSystem (tell in-house / third-party by the path)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

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

10. Поток решений — решить четырьмя вопросами

Вот содержание до сих пор как процедура выбора. Ответьте на четыре вопроса по порядку.

Поток решений для учётной записи входаРешить учётную запись входа, отвечая по порядку на четыре вопроса о сетевом доступе, присоединении к домену, достаточности идентичности уровня машины и поддержке gMSAНетДаНетДаДаНетДаНетПроверка Windows к узлу?Виртуальная учётная записьLocalSystem если нужноПрисоединена к домену?Защитить сохранённые учётные данныеУровня машины хватает?Виртуальная + PC$Приложение поддерживает gMSA?gMSAПользователь + смягчения

Рис. 22: Ответьте на четыре вопроса по порядку — и какой из шести выборов использовать, решено.

Вопрос 1: Обращается ли эта служба к другой машине в сети (общей папке, БД, API и подобному) с проверкой подлинности Windows?

Если нет, виртуальная учётная запись — значение по умолчанию. Только если нужно особое локальное право, подтвердите эту нужду и затем рассмотрите LocalSystem.

Вопрос 2: (Если обращается) Машина присоединена к домену?

В рабочей группе нельзя использовать ни PC$, ни gMSA. Используйте проектирование, которое явно обрабатывает учётные данные учётной записи назначения (защитите хранилище DPAPI или подобным), или рассмотрите присоединение к домену.

Вопрос 3: (В домене) Хватает ли идентичности уровня машины (PC$)?

Если да, виртуальная учётная запись (или NetworkService) + выдача PC$ в ACL назначения готова. Если нужна идентичность конкретной службы или общая идентичность на нескольких серверах, переходите к вопросу 4.

Вопрос 4: Поддерживает ли приложение gMSA?

Если да (то, что настраивает вход через стандартный механизм — SCM, пул приложений IIS, планировщик заданий — как правило, да), gMSA. Не забудьте проверку поведения в проверочной среде. Если не поддерживается ни при чём, используйте выделенного доменного пользователя после применения каждого смягчения раздела 7.3.

В таблице это так.

Ситуация Рекомендация Примечания
Только локально, обычные права Виртуальная учётная запись Выдать ACL NT SERVICE\<имя>
Только локально, нужно право сверх администратора LocalSystem Сначала проверить нужду в праве
Локальная обработка без сетевой идентичности LocalService Приемлемо, чтобы оставить существующую службу как есть
Обратиться к ресурсу внутри домена с идентичностью машины Виртуальная (или NetworkService) Выдать PC$ в ACL назначения
Обратиться к ресурсу внутри домена с идентичностью конкретной службы gMSA Корневой ключ KDS + подтвердить поддержку
Одна и та же идентичность на нескольких серверах (балансировка и подобное) gMSA С виртуальной учётной записью невозможно
Приложение не поддерживает gMSA + нужна конкретная идентичность Выделенный доменный пользователь Нужны смягчения раздела 7.3
Рабочая группа + нужен удалённый доступ Защитить и хранить явные учётные данные Также рассмотреть пересмотр проекта

11. Итог

  • Учётная запись входа службы — проектное решение, которое одновременно решает локальные права, сетевую идентичность и ведение пароля. Не оставляйте её по умолчанию (LocalSystem).
  • LocalSystem держит маркер SYSTEM+Administrators и сильные права, и ущерб при захвате максимален. Большинству деловых служб это право не нужно.
  • LocalService и NetworkService обе с малыми правами; разница — сетевая идентичность (анонимная или учётная запись компьютера). Однако учётную запись разделяют несколько служб, поэтому их нельзя разделить.
  • Виртуальная учётная запись (NT SERVICE\<имя-службы>) — современное значение по умолчанию, которое может разделить по службам, не требуя ведения пароля. Её можно указать прямо в ACL, и настройка — только смена имени учётной записи входа.
  • LocalSystem, NetworkService и виртуальная учётная запись выходят в сеть как DOMAIN\PC$ в доменной среде. Выдача PC$ в ACL общей папки или SQL Server часто позволяет обойтись без доменного пользователя.
  • Использование доменного пользователя для службы имеет структурные проблемы остановки из-за истечения, распространения открытого пароля и Kerberoasting. Если используете, нужны выделенная учётная запись + длинный случайный пароль + ограничения входа.
  • gMSA — механизм, в котором AD автоматически порождает и чередует пароль; требования — домен, функциональный уровень 2012 или выше и корневой ключ KDS. Задайте службе «DOMAIN\имя$» с пустым полем пароля.
  • При смене учётной записи включите право «Вход в качестве службы», перенос профиля и %TEMP% и повторный ввод данных, защищённых DPAPI, в процедуру переноса. Аудит можно подтвердить событием с кодом 4624 тип входа 5.

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

Похожие статьи

Смежные области консультирования

KomuraSoft LLC занимается проектированием учётной записи входа и ужесточением до наименьших прав для служб Windows и резидентных приложений, переносом существующих служб, построенных в предположении LocalSystem, на виртуальную учётную запись или gMSA, и расследованием отказов из-за отказа в доступе, DPAPI и профиля после смены учётной записи. Начать со стадии «нас отметили на аудите, но мы не знаем, с чего начать» вполне нормально.

Справочные ссылки

  1. Microsoft Learn, Configure Windows service accounts and permissions. О том, что учётная запись службы SQL Server по умолчанию — виртуальная (NT SERVICE\MSSQLSERVER и подобное), что при указании виртуальной или MSA поле пароля оставляют пустым, что MSA — имя с завершающим $ и её нельзя использовать для интерактивного входа, что Local Service — общая учётная запись, поэтому её нельзя отделить и SQL Server её не поддерживает, что использование доменной учётной записи стоит усилий в ручном ведении пароля и SPN и обслуживание может привести к остановке службы, и что службу всегда следует запускать от учётной записи с наименьшими правами. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Microsoft Learn, Securing on-premises service accounts. Приоритет сначала gMSA для локальной службы, затем sMSA если её нельзя использовать, затем учётная запись компьютера и наконец учётная запись пользователя; что при использовании учётной записи компьютера нельзя сказать, какая служба её использует, и нельзя проверить смену; и роли учётной записи службы (опознать, пройти проверку подлинности и запустить службу). ↩ ↩2 ↩3

  3. Microsoft Learn, LocalSystem Account. О том, что LocalSystem держит обширные права на локальном компьютере и токен включает SID NT AUTHORITY\SYSTEM и BUILTIN\Administrators, что у неё нет пароля, что она предъявляет учётные данные компьютера удалённому серверу, список прав включая SE_DEBUG_NAME и SE_TCB_NAME, и что большинству служб этот уровень прав не нужен и следует рассмотреть LocalService/NetworkService. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  4. Microsoft Learn, sc.exe config. О том, что учётную запись входа службы указывают параметром obj=, что значение по умолчанию — LocalSystem, и параметр password= при использовании учётной записи пользователя, отличной от LocalSystem. ↩ ↩2

  5. Microsoft Learn, Local accounts. О том, что у SYSTEM (S-1-5-18) по умолчанию полный контроль на томе NTFS, что NETWORK SERVICE (S-1-5-20) предъявляет учётные данные компьютера удалённому серверу, и что LOCAL SERVICE (S-1-5-19) держит локально минимальные права и предъявляет сети анонимные учётные данные. ↩ ↩2 ↩3 ↩4

  6. Microsoft Learn, Service accounts. О том, что виртуальная учётная запись — автоматически управляемая локальная, которой не нужно ведение пароля, что имя в форме NT SERVICE<SERVICENAME>, что в доменной среде она выходит в сеть с учётными данными учётной записи компьютера (\$), и критерии выбора среди sMSA, gMSA, dMSA и виртуальной учётной записи. ↩ ↩2 ↩3 ↩4

  7. Microsoft Learn, Service User Accounts. О том, что служба работает в контексте безопасности учётной записи пользователя, что SCM входит в учётную запись при запуске и связывает маркер доступа с процессом службы, что SCM загружает профиль пользователя и что SCM не ведёт истечение пароля, поэтому истечение делает вход неудачным и служба не запускается. ↩ ↩2 ↩3 ↩4 ↩5

  8. Microsoft Learn, Protect SMB traffic from interception. Рекомендации включая gMSA как защиту учётной записи службы (длинный машинно порождённый случайный пароль делает взлом перебором или словарём нереалистичным), принуждение к длинному паролю и упоминание брони Kerberos (FAST). ↩ ↩2

  9. Microsoft Learn, Secure group managed service accounts. О том, что пароль gMSA — случайное порождение 240 байт, которое трудно перебрать или атаковать словарём, что ОС Windows меняет пароль каждые 30 дней, поэтому администратору не нужно планировать смену или останавливать службу, развёртывание в ферме серверов и более простое ведение SPN, что если служба не поддерживает gMSA, используют sMSA, а если и это невозможно — стандартную учётную запись пользователя с сильным ведением пароля, и что поведение как gMSA нужно подтвердить в тестовой среде до промышленной. ↩ ↩2 ↩3

  10. Microsoft Learn, Manage group Managed Service Accounts. Предпосылки gMSA (функциональный уровень домена/леса 2012 или выше, создание корневого ключа KDS), что имя gMSA должно быть уникально в лесу, что интервал смены пароля можно задать только при создании, указание группы, которой разрешено извлекать пароль, через -PrincipalsAllowedToRetrieveManagedPassword у New-ADServiceAccount, процедура Install-ADServiceAccount/Test-ADServiceAccount, что идентичность виртуальной учётной записи локальна для машины и доменом не распознаётся, что отказоустойчивый кластер не поддерживает gMSA, и что SCM, пул приложений IIS и планировщик заданий поддерживают настройку входа как gMSA. ↩ ↩2 ↩3 ↩4 ↩5

  11. Microsoft Learn, 4624(S): An account was successfully logged on. О том, что событие 4624 записывается на компьютере, к которому обратились, когда создаётся сеанс входа, что тип входа 5 означает службу (SCM запускает службу), и что поле «Virtual Account» может определить вход от MSA или виртуальной учётной записи и использоваться для наблюдения за управляемыми учётными записями служб. ↩ ↩2

  12. Microsoft Learn, About Windows Resource Protection. О том, что защита ресурсов Windows (WRP) предотвращает замену важных системных файлов, папок и ключей реестра, что полный доступ к ресурсу, защищённому WRP, ограничен TrustedInstaller и изменение можно сделать только через поддерживаемый механизм замены через службу установщика модулей Windows, и что приложение, которое пытается изменить защищённый ресурс, получает отказ в доступе. ↩

  13. Microsoft Learn, Group Managed Service Accounts overview. О том, что gMSA — доменная учётная запись, оставляющая ведение пароля Windows, что контроллер домена вычисляет пароль из общего секрета Key Distribution Service (kdssvc.dll) и узел-член запрашивает у контроллера домена текущий и предыдущий пароли, и что она позволяет взаимную проверку подлинности как один и тот же субъект в ферме серверов. ↩

  14. Microsoft Learn, Create a Key Distribution Service (KDS) root key. О том, что корневой ключ нужен, чтобы контроллер домена начал порождать пароли gMSA, процедура создания через Add-KdsRootKey -EffectiveImmediately, что до 10 часов после создания gMSA создать нельзя, потому что ждут сходимости репликации AD, и что неполная репликация может сделать извлечение пароля неудачным. ↩

  15. Microsoft Learn, Policy CSP - UserRights: LogOnAsService. О том, что право «Вход в качестве службы» позволяет субъекту безопасности входить как служба, что у Local System, Local Service и Network Service это право встроено, что службе, запущенной от любой другой учётной записи, нужно назначить это право, и путь настройки групповой политики. ↩

Похожие статьи

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

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Нужно ли сразу менять службу, которую пока запускают от LocalSystem?
Немедленная смена не всегда правильный ответ. Сначала убедитесь, нужны ли этой службе локальные права класса LocalSystem (сильные права сверх администратора). Если это только чтение и запись файлов и сетевое общение, первый кандидат — виртуальная учётная запись (NT SERVICE\имя-службы). При переносе подтвердите выдачу доступа к нужным папкам и ключам реестра, как обрабатывать данные, зависящие от профиля или DPAPI, и есть ли право «Вход в качестве службы». Подтвердите запуск и основные функции в проверочной среде, затем переключайте промышленную.
Выбрать виртуальную учётную запись или NetworkService?
Для нового выбора рекомендуем виртуальную учётную запись. В сети обе выглядят как учётная запись компьютера (DOMAIN\имя-компьютера$), и у обеих небольшие локальные права. Однако NetworkService разделяют несколько служб, поэтому ACL «разрешить только этой службе» сделать нельзя. У виртуальной учётной записи своя идентичность на каждую службу, и NT SERVICE\имя-службы можно указать прямо в ACL. Недавние продукты Microsoft вроде SQL Server тоже по умолчанию используют виртуальную учётную запись.
Можно ли использовать gMSA в рабочей группе (без домена)?
Нет. gMSA — механизм, в котором контроллер домена Active Directory порождает и ведёт пароль; домен и создание корневого ключа KDS — предпосылки. В рабочей группе базовая линия — закончить локальную обработку виртуальной учётной записью или LocalService/NetworkService. Если нужен доступ к другой машине, нужно другое проектирование, например явно использовать учётные данные учётной записи, подготовленной на стороне назначения. Сетевой доступ как учётная запись компьютера (PC$) тоже действует только в доменной среде.
После смены учётной записи входа службы сохранённые настройки и учётные данные больше не читаются. Почему?
Потому что каждая учётная запись входа привязана к своему профилю пользователя, %TEMP%, HKEY_CURRENT_USER и ключу DPAPI. В частности, данные, защищённые DPAPI пользовательского охвата (CryptProtectData и подобное), в принципе может расшифровать только та же учётная запись, которая их защитила. Файлы, сохранённые под профилем (AppData и подобное), для новой учётной записи — другой путь. Перед сменой учётной записи спланируйте процедуру пересоздания данных, защищённых DPAPI (повторный ввод ключей API и подобное), и перенос файлов под профилем.
Если службе нужен только доступ к общей папке, нужен ли доменный пользователь?
Во многих случаях нет. В доменной среде служба, запущенная как LocalSystem, NetworkService или виртуальная учётная запись, проходит проверку подлинности на удалённой стороне как учётная запись компьютера (DOMAIN\имя-компьютера$). Добавьте этот PC$ в разрешения общего ресурса и NTFS общей папки — и она сможет читать и писать. Если нужен контроль доступа с идентичностью конкретной службы или одна и та же идентичность на нескольких серверах, рассмотрите gMSA, а не доменного пользователя.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.

Связаться с нами

Публичные ссылки

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal
Вернуться в блог