Active Directory

Служба Windows, IIS application pool, задача планировщика и кластерный ресурс должны иметь собственную идентичность. Она получает доступ к файлам, SQL, очередям и API, поэтому её нельзя считать обычным пользователем, которому «просто запретили вход». У service account есть секрет, привилегии, след в аудит-логах, владелец и жизненный цикл.

Один компонент — одна учётная запись — один ответственный. Такое разделение делает аудит полезным: по событию входа видно конкретный сервис, а ротация секрета затрагивает известный круг зависимостей. Общая svc_apps на все приложения создаёт неустранимую неоднозначность и огромный blast radius.

[IIS payroll] -- gmsa-payroll$ --> [SQL payroll]
[Backup job ] -- gmsa-backup$ --> [backup share]
[Legacy app ] -- svc-legacy --> [один API]

Не так: все стрелки --> domaindministrator

Get-ADUser -Filter 'Name -like "svc-*"' -Properties Description,PasswordLastSet |
 Select SamAccountName,Enabled,PasswordLastSet,Description

Учётка с SPN участвует в Kerberos: аутентифицированный пользователь домена может запросить service ticket для её сервиса. Билет зашифрован ключом сервисной учётки и может подбираться офлайн. Поэтому флаг Password never expires особенно опасен: атакующий получает неограниченное время, а пароль нередко придуман человеком и повторён.

Длинный пароль полезен, но не заменяет ротацию и минимальные права. Если скомпрометированная учётка имеет доступ к SQL, backup share или локальным администраторам, ticket становится не просто криптографическим артефактом, а маршрутом к следующему tier.

user -- TGS-REQ HTTP/app.contoso.com --> KDC
KDC -- ticket encrypted by gmsa-app$ key --> user
user -- offline password guessing --> service privileges

Get-ADUser -LDAPFilter "(servicePrincipalName=*)" `
 -Properties ServicePrincipalName,PasswordLastSet,PasswordNeverExpires |
 Select SamAccountName,PasswordLastSet,PasswordNeverExpires,ServicePrincipalName

Обычный доменный user нужен legacy-программам, но его пароль приходится хранить, вводить и менять. sMSA передаёт ротацию Active Directory, однако привязан к одному компьютеру. gMSA расширяет модель:

• один managed account разрешён группе компьютеров
• подходит для фермы IIS
• нескольких worker nodes или кластера

legacy app -> user + vault
single Windows service -> sMSA
WEB01 + WEB02 + WEB03 -> gMSA -> common service

Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword |
 Select Name,PrincipalsAllowedToRetrieveManagedPassword

KDS root key — корень, с помощью которого контроллеры домена согласованно вычисляют пароли gMSA. Его создают один раз на домен. Ключу нужно время, чтобы реплицироваться на все DC; создание за минуту до миграции — распространённая причина ночного отказа.

В лаборатории часто используют немедленную effective date. В production этот shortcut маскирует реальное требование:

• каждый DC
• который может обслужить запрос
• должен обладать согласованным ключевым материалом

KDS root key
 |--> DC01 calculates gmsa-web$ password
 |--> DC02 calculates same password
 +--> authorised WEB01 retrieves it

Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(10)
Get-KdsRootKey | Format-List *

Группа компьютеров — правильная точка управления доступом к managed password. Новый узел добавляют в группу, ждут репликацию, устанавливают service account, проверяют его. Так именование и процедура onboarding становятся одинаковыми для десятков узлов.

Общий principal не означает общие неограниченные права. gMSA для фронтенда не должна быть gMSA для backup или SQL Agent. Доступ к данным всё равно выражают ACL, SQL roles и локальными группами на уровне конкретной функции.

GG_gMSA_Web_Hosts
 | |
 WEB01 WEB02
 \ /
 gmsa-web$ --> SQL role: execute only

New-ADGroup -Name GG_gMSA_Web_Hosts -GroupScope Global
New-ADServiceAccount -Name gmsa-web -DNSHostName gmsa-web.contoso.com `
 -PrincipalsAllowedToRetrieveManagedPassword GG_gMSA_Web_Hosts
# On each host: Install-ADServiceAccount gmsa-web; Test-ADServiceAccount gmsa-web

SPN связывает имя сервиса с account, чей ключ KDC использует для ticket. DNS alias балансировщика, порт нестандартного SQL и имя виртуального сервиса должны быть отражены осмысленно. Дубликат SPN создаёт неоднозначность; неверный SPN приводит к ошибке Kerberos или fallback на NTLM.

SPN — часть проектной документации: имя клиента, DNS record, владелец service account, способ проверки должны быть записаны вместе. Перед миграцией имени сначала выясняют текущего владельца и затем меняют зависимые точки контролируемо.

client -> HTTP/app.contoso.com -> KDC
KDC finds unique SPN -> gmsa-web$ key -> ticket
duplicate SPN -> ambiguity / failed authentication

setspn -X
setspn -L CONTOSO\gmsa-web$
setspn -S HTTP/app.contoso.com CONTOSO\gmsa-web$

Не каждое приложение поддерживает managed service account. Старый агент может принимать только username/password; Linux workload потребует keytab или иной модели; облачный сервис — workload identity, federated credential или сертификат. Нельзя подменять архитектурный анализ попыткой заставить продукт принять gMSA.

Если нужен обычный user, его секрет хранится в vault/PAM, меняется автоматизированно и проверяется в пилоте. Запрет интерактивного входа, отдельная учётка на приложение и ограниченные ACL остаются обязательны.

Supports managed password?
 | yes -> gMSA
 | no -> certificate / managed identity / keytab?
 | no -> unique user + vault + rotation

Get-ADUser svc-legacy -Properties LogonWorkstations,PasswordNeverExpires |
 Format-List SamAccountName,LogonWorkstations,PasswordNeverExpires

Сервису почти никогда не требуется Domain Admin. Обычно достаточно права Log on as a service, конкретной SQL role, Modify на одном каталоге либо membership в локальной группе одного класса серверов. Каждое лишнее право расширяет последствия компрометации.

Ограничения logon нужно проектировать вместе с приложением: отказ в interactive/RDP не должен случайно запретить service logon. Политики тестируют отдельно от production, а доступы пересматривают при смене владельца или функциональности.

gmsa-report$
 +-- Log on as a service: REPORT01
 +-- SQL: db_datareader in Reporting
 +-- share: Modify on \fs
eports
 `-- NOT Domain Admin / NOT all servers

Get-ADPrincipalGroupMembership gmsa-report$ |
 Select Name,GroupScope
whoami /priv

Без реестра service accounts даже хороший первоначальный дизайн деградирует. Для каждой записи нужны владелец, бизнес-функция, account type, разрешённые хосты, SPN, права, дата последнего review и процедура аварийного отключения. Этот реестр связывают с CMDB и change management.

Ротация — это проверяемый процесс: сервис получает новый секрет, старые connections не маскируют проблему, мониторинг видит ошибку, а владелец подтверждает функцию. Для gMSA ротацию выполняет AD, но совместимость и доступ к password retrieval всё равно проверяются.

Inventory -> owner -> least privilege -> rotation -> review
 ^   |
 +--------------- decommission ----------------+

Get-ADServiceAccount -Filter * -Properties Created,Description |
 Select Name,Created,Description | Export-Csv .\gmsa-inventory.csv -NoTypeInformation