Короткий ответ

Учётка из Domain Admins / Enterprise Admins / встроенных привилегированных групп не должна открывать почту, браузер и Office на WS-042. Модель: daily-drive (ivanov) без админ-групп и privileged (ivanov-adm) только для AD/серверов, вход на jump-хост, не на пользовательский ПК. На рабочих станциях запретите интерактивный вход Domain Admins (User Rights / Authentication Policy). Это не «неудобство», а отрез от кражи TGT/хеша с заражённого ПК.

Не кладите DA в локальные Administrators всех ПК «чтобы всегда зайти». Для аварий — LAPS и консоль, см. локальный админ. Не отключайте Defender на jump «чтобы быстрее».

Симптомы и как отличить

  • 4624 Type 2/10 на WS-042 с учёткой, у которой 4672 Special privileges (SeDebug, SeTcb и т.д.).
  • Outlook/Teams под CONTOSO\admin.
  • Один человек, одна учётка, член Domain Admins.
  • RDP с дома под DA на белый IP — ещё и периметр.
КартинаИное
Helpdesk в локальных админах без DAлишние права, всё равно сужать
gMSA для службынорма, не daily-drive
Схема tier0/1/2 Microsoftцель этой статьи упрощённо
Только LAPS без разделения DAнедостаточно

Возможные причины

  1. Исторически «админ один, учётка одна».
  2. Совместимость старых MMC, «не работает без DA».
  3. Нет jump-сервера, админят с ноутбука.
  4. GPO не запрещает DA логон на Workstations OU.
  5. Сервисные задачи под DA вместо gMSA.
  6. Поставщик ПО требует DA для клиента на ПК.

Диагностика

На DC01 / SIEM выборка 4624+4672 по OU станций. На WS-042:

Get-WinEvent -FilterHashtable @{ LogName = 'Security'; Id = 4672 } -MaxEvents 20
Get-LocalGroupMember Administrators

Кто в Domain Admins:

Get-ADGroupMember 'Domain Admins' -Recursive | Select-Object SamAccountName, objectClass

Интерактивные входы DA на станциях (пример фильтрацией 4624 — смотрите TargetUserName из списка DA). Включите аудит входов, если его нет.

Проверьте Scheduled Tasks / службы:

Get-ScheduledTask | ForEach-Object {
  $i = $_ | Get-ScheduledTaskInfo
  [pscustomobject]@{ Task = $_.TaskName; User = $_.Principal.UserId }
} | Where-Object User -match 'admin'
Get-CimInstance Win32_Service | Where-Object StartName -match 'admin' | Select-Object Name, StartName

Решение

Сценарий A. Создать privileged-учётку

  1. ivanov — только пользовательские группы.
  2. ivanov-adm — в группе роли (не сразу Domain Admins; лучше делегирование / более узкая группа). Если DA неизбежен — только эта учётка, не daily.
  3. Разные пароли, лучше MFA/smartcard на privileged.
  4. Запрет почты: не профилировать ivanov-adm на Exchange без нужды, не входить в Outlook.

Сценарий B. Запрет логона DA на рабочих станциях

GPO на OU Workstations: User Rights Assignment → Deny log on locally / Deny log on through Remote Desktop Services для Domain Admins, Enterprise Admins, Schema Admins (осторожно: не повесьте Deny на OU, где сидят jump и DC).

Проверьте, что администраторы имеют jump в другой OU.

Сценарий C. Jump / PAW

Выделенный сервер или hardened Windows 11: нет почты, нет веба кроме документации, RDP/WinRM только с admin-сети, WinRM HTTPS, PowerShell logging. С jump — MMC/ADUC к DC01. С WS-042 privileged RDP запрещён.

Сценарий D. Службы под DA

Переведите на gMSA или dedicated svc-учётку с минимальными правами. DA как Log On As Service — дефект.

В contoso.example разделение учёток без jump быстро вырождается: privileged пароль снова вводят на WS-042. Заведите OU Admin-Jump, не линкуйте на неё Deny logon для Domain Admins. На DC01 смотрите 4672 с рабочих станций как KPI: цель — ноль за неделю. Почта и браузер под ivanov-adm — регресс, даже если MFA есть. Службы и планировщик на серверах переведите с DA на gMSA в том же проекте, иначе «учётки разделили, PAC всё ещё DA». Документируйте break-glass DA в сейфе, не в общей Wiki.

Как проверить, что проблема устранена

  • Get-ADGroupMember 'Domain Admins' без ежедневных имён.
  • На WS-042 нет 4672 для DA за рабочий день.
  • Вход ivanov-adm на jump работает, на WS-042 — отказ.
  • Почта открывается только под ivanov.
  • Задачи планировщика не под DA.

Функциональный тест: сброс пароля пользователя с jump под privileged-ID.

Если не помогло

  • Приложение вендора «только под DA»: требуйте документированные права, контейнер/RDS jump, не DA на каждом ПК.
  • Пользователи-совместители IT в DA «на всякий случай» — вычистить.
  • Cached logon DA на ноутбуке — запрет логона + смена пароля DA + отзыв сессий.
  • Fine-grained: Authentication Policy Silos (если готовы к сложности) — опционально поверх GPO.

Профилактика

  • Регламент: две учётки, recertification DA ежеквартально.
  • Алерт 4672 на Workstations OU.
  • Онбординг админа: сначала daily, потом privileged, не наоборот.
  • Не использовать DA для навигации в интернет, даже «проверить сайт вендора».
  • Tiering по возможности: DA только на DC/jump tier0.

FAQ

Protected Users для DA?

Имеет смысл для privileged: меньше NTLM/delegation. Проверьте совместимость со старыми приложениями до массового включения.

Можно ли один человек — одна учётка, если MFA?

MFA не отменяет кражу сессии на заражённом ПК после входа. Разделение остаётся.

Local Admin на ПК vs DA

Локальный админ своего ПК ≠ DA леса. Для IT-ПК лучше отдельная local/LAPS, не DA.

Schema Admin на каждый день?

Нет. Пустая группа или break-glass, не daily.

Runas / UAC из-под daily

runas privileged с пользовательского ПК всё равно кладёт секреты на небезопасный хост. Цель — не вводить privileged пароль на WS-042.

Нужен ли отдельный лес?

Для крупного enterprise — модель ESAE/tier. Для SMB часто хватает двух учёток + jump + deny logon. Не имитируйте пустой «красный лес» без процессов.