Учётные записи служб Windows: LocalSystem, виртуальные учётные записи и gMSA

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

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

flowchart TB
    accTitle: Три вещи, которые задаёт учётная запись службы
    accDescr: Служба всегда работает в контексте безопасности какой-то учётной записи, и эта учётная запись определяет, что служба может делать локально, кем она выглядит с удалённой стороны и кто управляет паролем
    acct["Учётная запись службы"] --> local["Что можно делать локально"]
    acct --> net["Кем служба выглядит в сети"]
    acct --> pwd["Кто управляет паролем"]

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

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

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

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

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

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

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 19, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

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

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

flowchart TB
    accTitle: Что делает SCM при запуске службы
    accDescr: SCM входит под настроенной учётной записью, при успехе создаёт токен доступа и назначает его процессу службы, дальше доступ к ресурсам решается сопоставлением токена с ACL
    scm["SCM"] --> logon["Вход под настроенной учётной записью"]
    logon --> token["Создать токен доступа"]
    token --> proc["Назначить процессу службы"]
    proc --> access["Доступ к файлу или каналу"]
    access --> check{"ACL разрешает?"}
    check -->|Да| ok["Доступ разрешён"]
    check -->|Нет| deny["Отказано в доступе"]

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

У LocalSystem, LocalService, NetworkService и виртуальной учётной записи самого понятия пароля нет. С паролем, сохранённым в SCM (а значит, с риском истечения и утечки), входят только доменный и локальный пользователь.⁷³

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

3. В чём проблема LocalSystem

3.1. Сильнее, чем «запуск от имени администратора»

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

Эта сила равна масштабу ущерба при компрометации. Если у службы, запущенной от LocalSystem, есть одна уязвимость произвольного выполнения кода, злоумышленник сразу доходит до чтения и порчи файлов всех пользователей на этой машине (у SYSTEM по умолчанию полный контроль на NTFS⁵), чтения памяти других процессов через SeDebugPrivilege и кражи учётных данных с последующим латеральным перемещением (отправная точка для Pass-the-Hash и подобных атак). Цепочка кражи учётных данных и латерального перемещения разобрана в «NTLM и Kerberos на схемах — почему проверка подлинности „падает“ на NTLM» и «Практическое руководство по Windows LAPS».

flowchart TB
    accTitle: Ущерб при компрометации службы LocalSystem
    accDescr: Если у службы, запущенной от LocalSystem, есть одна уязвимость произвольного выполнения кода, злоумышленник доходит до чтения и порчи файлов всех пользователей, чтения памяти других процессов и кражи учётных данных с латеральным перемещением
    vuln["Одна уязвимость произвольного выполнения кода"] --> sys["Злоумышленник получает права SYSTEM"]
    sys --> files["Чтение и порча файлов"]
    sys --> mem["Чтение памяти других процессов"]
    sys --> cred["Кража учётных данных"]
    cred --> lateral["Латеральное перемещение на другую машину"]

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

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

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

flowchart TB
    accTitle: Почему LocalSystem продолжают выбирать
    accDescr: Значение по умолчанию sc.exe create — LocalSystem, старые образцы и шаблоны тоже предполагают LocalSystem, поэтому в разработке отказа в доступе нет и массово остаётся схема заработало поэтому оставим
    def["Значение по умолчанию sc.exe create"] --> lsys["Создана как LocalSystem"]
    old["Старые образцы и шаблоны"] --> lsys
    lsys --> noerr["В разработке нет отказа в доступе"]
    noerr --> asis["Заработало, поэтому оставим"]
    asis --> mass["Массово появляются службы с избыточными правами"]

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

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

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

flowchart TB
    accTitle: Область защиты WRP и TrustedInstaller
    accDescr: Изменения важных системных файлов и ключей реестра, которые защищает WRP, разрешены только TrustedInstaller, и даже SYSTEM или администратор получают отказ в доступе
    ti["TrustedInstaller"] -->|Можно менять| wrp["Системные файлы под WRP и т. п."]
    sysadm["SYSTEM и администраторы"] -->|Отказ в доступе| wrp
    sysadm -->|Почти всё можно| other["Вне области защиты 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.⁵¹

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

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

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

flowchart TB
    accTitle: Разница между LocalService и NetworkService
    accDescr: Локальные права у обеих минимальны, но к удалённой стороне LocalService подключается с анонимными учётными данными, а NetworkService предъявляет учётные данные компьютера
    ls["LocalService"] --> anon["Подключение с анонимными учётными данными"]
    anon -.-> ng["Ресурс с проверкой подлинности недоступен"]
    ns["NetworkService"] --> comp["Предъявляет учётные данные компьютера"]
    comp -.-> pc["В домене выглядит как PC$"]

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

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

flowchart TB
    accTitle: Общую учётную запись нельзя изолировать
    accDescr: Если несколько служб делят одну LocalService, то пока ACL задан на учётную запись, они могут ходить в ресурсы друг друга
    sva["Служба A"] --> acct["Та же LocalService"]
    svb["Служба B"] --> acct
    svc["Служба C"] --> acct
    acct --> mutual["Могут ходить в ресурсы друг друга"]
    mutual -.-> reason["Потому что ACL задан на учётную запись"]

Рис. 7: Службы на одной учётной записи ACL не изолирует друг от друга.

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

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

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

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

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

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

flowchart TB
    accTitle: Что совмещает виртуальная учётная запись
    accDescr: Виртуальная учётная запись сохраняет плюс LocalService и NetworkService — паролем управлять не нужно, снимает минус нельзя изолировать из-за общей учётки и даёт идентичность, уникальную для каждой службы
    merit["Плюс (паролем управлять не нужно)"] -->|Сохраняет| va["Виртуальная учётная запись"]
    demerit["Минус (общая учётка, изоляции нет)"] -->|Снимает| va
    va --> ident["Идентичность на каждую службу"]
    va --> auto["Ни создавать, ни задавать пароль не нужно"]

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

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

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

# Сменить учётную запись службы на виртуальную
# Значение obj= — «NT SERVICE\имя-службы». Пароль не указывают
sc.exe config MyAppService obj= "NT SERVICE\MyAppService"

# Проверить конфигурацию (смотреть SERVICE_START_NAME)
sc.exe qc MyAppService

# Выдать этой службе право изменения только на папку данных
icacls "C:\ProgramData\MyApp" /grant "NT SERVICE\MyAppService:(OI)(CI)M"

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

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

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

flowchart TB
    accTitle: Вне машины идентичность виртуальной учётной записи сводится к PC$
    accDescr: Виртуальная учётная запись, уникальная для каждой службы внутри машины, в сети сводится к учётной записи компьютера, и удалённая сторона не видит, какая это служба
    vaa["Виртуальная учётная запись A"] --> pc["Учётная запись компьютера PC$"]
    vab["Виртуальная учётная запись B"] --> pc
    pc --> remote["Идентичность, которую видит удалённая сторона"]
    remote -.-> nodist["Не видно, какая это служба"]

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

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

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

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

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

flowchart TB
    accTitle: Удалённый доступ от имени учётной записи компьютера
    accDescr: Служба LocalSystem, NetworkService или виртуальная на машине в домене проходит проверку подлинности на удалённой стороне как учётная запись компьютера, и если ACL назначения разрешает PC$, доступ есть
    svc["Служба (LocalSystem, виртуальная учётная запись и т. п.)"] --> auth["Проверка подлинности как PC$"]
    auth --> acl{"ACL назначения разрешает PC$?"}
    acl -->|Да| ok["Доступ к общей папке или БД есть"]
    acl -->|Нет| ng["Отказано в доступе"]

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

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

# На стороне файлового сервера: службе на APPSV01 — право изменения общей папки
# Нужны и разрешения общего ресурса, и разрешения NTFS
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 без пароля.

-- На стороне сервера БД: разрешить Windows-проверку подлинности службе на APPSV01
CREATE LOGIN [CORP\APPSV01$] FROM WINDOWS;

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

У этой схемы два предела.

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

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

flowchart TB
    accTitle: Два предела схемы PC$
    accDescr: Проверка подлинности как PC$ имеет гранулярность уровня машины, поэтому ни разрешение, ни аудит по службам невозможны, а в рабочей группе самой учётной записи компьютера нет, поэтому схема неприменима
    pcs["Схема PC$"] --> lim1["Предел 1 (гранулярность на машину)"]
    pcs --> lim2["Предел 2 (не работает в рабочей группе)"]
    lim1 -.-> noaudit["Нет разрешения и аудита по службам"]
    lim2 -.-> nocred["Явные учётные данные в проекте"]
    lim1 --> gmsa["Если мало — к gMSA"]

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

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

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

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

Отсюда начинается порочный круг, который часто видят на местах.

1. Служба встаёт из‑за истечения пароля
2. Чтобы не повторилось, ставят «пароль не истекает»
3. Процедуры смены нет, один и тот же пароль открытым текстом уходит в инструкции, скрипты и планировщик заданий на нескольких серверах
4. Сотрудник уволился — пароль не меняют (если сменить, непонятно, что встанет)

flowchart TB
    accTitle: Порочный круг эксплуатации с доменным пользователем
    accDescr: Пароль истекает и служба останавливается, чтобы не повторилось ставят бессрочный, открытый пароль расползается по инструкциям и скриптам, и даже после увольнения его нельзя сменить
    expire["1. Истечение останавливает службу"] --> forever["2. Чтобы не повторилось, делают бессрочным"]
    forever --> spread["3. Открытый пароль расползается"]
    spread -.-> where["Инструкции, скрипты, задания"]
    spread --> stuck["4. После увольнения сменить нельзя"]

Рис. 12: С инцидента истечения закрепляются бессрочный пароль и его расползание открытым текстом.

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

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

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

flowchart TB
    accTitle: Как идёт Kerberoasting
    accDescr: Билет службы к учётной записи службы с зарегистрированным SPN может запросить любой прошедший проверку пользователь, поэтому злоумышленник получает билет и пробует автономный перебор пароля
    atk["Прошедший проверку пользователь домена"] --> req["Запрос билета на SPN"]
    req --> tkt["Получить билет службы"]
    tkt --> brute["Автономный перебор"]
    brute --> weak["Примерно 10–16 символов вскрываются"]

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

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

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

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

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

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

8. gMSA: управление паролем отдаёт Active Directory

8.1. Как устроено и что даёт

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

flowchart TB
    accTitle: Как gMSA управляет паролем
    accDescr: Контроллер домена вычисляет пароль из корневого ключа KDS, только разрешённые узлы получают его и используют для запуска службы, пароль по умолчанию автоматически ротируется каждые 30 дней
    kds["Корневой ключ KDS"] --> dc["DC вычисляет пароль"]
    dc --> host["Разрешённый узел получает его"]
    host --> svc["Используется для запуска службы"]
    dc -.-> rot["Авторотация каждые 30 дней по умолчанию"]

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

Эффект прямой.⁹

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

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

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

У gMSA есть предварительные условия.¹⁰

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

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

flowchart TB
    accTitle: От создания корневого ключа KDS до создания gMSA
    accDescr: После создания корневого ключа KDS ждут репликации на все контроллеры домена, поэтому до 10 часов gMSA создать нельзя; после завершения репликации создать можно
    add["Создать корневой ключ KDS"] --> wait["Ожидание репликации до 10 часов"]
    wait -.-> why["Предохранитель против отказа извлечения"]
    wait --> done["Репликация на все DC завершена"]
    done --> ok["Можно создать gMSA"]

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

# Выполнять как администратор домена, на контроллере домена
# (или на управленческой станции с модулем AD PowerShell)

# Проверить, есть ли корневой ключ KDS, и создать, если нет (один раз на лес)
Get-KdsRootKey
Add-KdsRootKey -EffectiveImmediately   # Реально заработает максимум через 10 часов

8.3. От создания до настройки

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

flowchart TB
    accTitle: Четыре этапа внедрения gMSA
    accDescr: Внедрить в четыре этапа: создать группу, которой разрешено извлекать пароль, создать gMSA, установить на каждый сервер и задать как учётную запись службы
    st1["① Создать группу с правом извлечения"] --> st2["② Создать gMSA"]
    st1 -.-> add["Добавить PC$ серверов"]
    st2 --> st3["③ Установить на каждый сервер"]
    st3 -.-> test["Проверить извлечение командой Test"]
    st3 --> st4["④ Задать службе"]

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

# ① Создать группу безопасности с правом извлекать пароль
#    и добавить учётные записи компьютеров серверов, где будет служба
New-ADGroup -Name "GG-SvcBatchHosts" -GroupScope Global
Add-ADGroupMember -Identity "GG-SvcBatchHosts" -Members "APPSV01$", "APPSV02$"
# Членство в группе оценивается при входе компьютера,
# поэтому после добавления надёжнее перезапустить целевые серверы

# ② Создать gMSA
New-ADServiceAccount -Name "svc-batch" `
    -DNSHostName "svc-batch.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG-SvcBatchHosts"

# ③ На каждом сервере, где будет служба, установить gMSA и проверить
Install-ADServiceAccount -Identity "svc-batch"
Test-ADServiceAccount -Identity "svc-batch"   # True — извлечение работает

# ④ Задать как учётную запись службы. В конце имени — $, пароль не указывают
sc.exe config MyBatchService obj= "CORP\svc-batch$"
Restart-Service MyBatchService

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

8.4. Есть приложения без поддержки

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

flowchart TB
    accTitle: Как понять, есть ли поддержка gMSA
    accDescr: Приложение, которое настраивает идентичность входа через стандартный механизм, широко поддерживает gMSA, но отказоустойчивая кластеризация и приложение, которое внутри требует пароль, использовать её не могут, поэтому проверьте в тестовой среде до продакшена
    app["Целевое приложение"] --> how{"Как задаётся вход?"}
    how -->|Стандартный механизм| okapp["gMSA поддерживается"]
    okapp -.-> ex1["Служба, IIS, задание"]
    how -->|Требуют пароль| ngapp["gMSA нельзя"]
    ngapp -.-> ex2["Отказоустойчивый кластер"]
    okapp --> test["Проверить до продакшена"]

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

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

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

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

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

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

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

flowchart TB
    accTitle: Разница путей настройки права Вход в качестве службы
    accDescr: Графический интерфейс services.msc выдаёт право автоматически, но API, которую вызывает sc.exe config, право не проверяет, поэтому учётная запись без права останавливает службу с ошибкой входа при запуске
    gui["Задать в services.msc"] --> auto["Право выдаётся автоматически"]
    auto --> okgui["Служба может запуститься"]
    cli["Задать через sc.exe config"] --> noval["Право не проверяется"]
    noval --> has{"Есть право?"}
    has -->|Да| okcli["Служба может запуститься"]
    has -->|Нет| stop["Останавливается с ошибкой входа"]
    stop -.-> fix["Выдать явно через secpol.msc или GPO"]

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

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

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

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

flowchart TB
    accTitle: Зависимость от профиля и как размещать данные
    accDescr: Реальный профиль у каждой учётной записи свой, поэтому после смены данные старого профиля выглядят пропавшими, но размещение на явном пути и выдача ACL делают перенос ненужным
    sw["Смена учётной записи службы"] --> newprof["Загружается другой профиль"]
    newprof --> lost["Старые данные выглядят пропавшими"]
    lost -.->|Ответ| fix["Положить под ProgramData"]
    fix --> acl["Выдать ACL учётной записи службы"]
    acl --> nomig["Перенос не нужен даже при смене учётной записи"]

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

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

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

flowchart TB
    accTitle: Данные под DPAPI и смена учётной записи
    accDescr: Данные, защищённые DPAPI в области пользователя, расшифровывает только та же учётная запись, которая их защитила, поэтому после смены учётной записи службы секреты нужно ввести заново
    protect["Защитить DPAPI старой учётной записью"] --> data["Защищённая строка подключения и т. п."]
    data --> who{"Какая учётная запись расшифровывает?"}
    who -->|Та же старая| okdec["Расшифровать можно"]
    who -->|Новая| ngdec["Расшифровать нельзя"]
    ngdec --> re["Ввести секреты заново"]

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

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

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

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

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

flowchart TB
    accTitle: Как аудировать запуск службы
    accDescr: Запуск службы SCM записывается как событие 4624 с типом входа 5, и поле Virtual Account показывает, был ли вход от управляемой учётной записи
    start["SCM запускает службу"] --> ev["Записать событие 4624"]
    ev --> type5["Тип входа 5 (Service)"]
    type5 --> vafield["Поле Virtual Account"]
    vafield --> watch["Наблюдение за управляемыми учётными записями"]

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

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

# Сгруппировать, какие службы от какой учётной записи запущены
Get-CimInstance Win32_Service |
    Group-Object StartName |
    Sort-Object Count -Descending |
    Select-Object Count, Name

# Найти нестандартные службы от LocalSystem (свои / сторонние — по пути)
Get-CimInstance Win32_Service |
    Where-Object { $_.StartName -eq 'LocalSystem' -and $_.PathName -notlike '*\Windows\*' } |
    Select-Object Name, DisplayName, PathName

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

10. Схема выбора: четыре вопроса

Сводим сказанное в процедуру выбора. Ответьте на четыре вопроса по порядку.

flowchart TB
    accTitle: Схема выбора учётной записи службы
    accDescr: Выбрать учётную запись службы, отвечая по порядку на четыре вопроса о сетевом доступе, членстве в домене, достаточности идентичности уровня машины и поддержке gMSA
    q1{"Windows-вход на другую машину?"} -->|Нет| va["Виртуальная учётная запись"]
    va -.-> sys["LocalSystem, если привилегия обязательна"]
    q1 -->|Да| q2{"В домене?"}
    q2 -->|Нет| cred["Хранить учётные данные защищённо"]
    q2 -->|Да| q3{"Хватает уровня машины?"}
    q3 -->|Да| pcacl["Виртуальная + разрешение PC$"]
    q3 -->|Нет| q4{"Приложение поддерживает gMSA?"}
    q4 -->|Да| gmsa["gMSA"]
    q4 -->|Нет| du["Отдельный пользователь + смягчения"]

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

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

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

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

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

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

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

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

Если да (то, что настраивает вход через стандартный механизм — SCM, пул приложений IIS, планировщик заданий — как правило, да), 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.

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

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

• Как создавать и эксплуатировать службы Windows — от выбора между планировщиком заданий и службами до превращения BackgroundService в службу Windows
• Когда на Windows действительно нужны права администратора — UAC, защищённые области и как это увидеть на этапе проектирования
• Как правильно работать с токенами олицетворения в Windows — заимствование прав на уровне потока и безопасный откат
• NTLM и Kerberos на схемах — почему проверка подлинности «падает» на NTLM
• Практическое руководство по Windows LAPS — убрать общий пароль локального администратора со всех ПК
• Хранение секретов в Windows-приложениях — не оставлять настройки открытым текстом, использовать DPAPI

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

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

• Разработка приложений для Windows
• Расследование ошибок и анализ причин
• Технические консультации и ревью проектирования
• Связаться с нами

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

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

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

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

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

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

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

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

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

Службу пока запускают от 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, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.