Безопасность для начинающих 06. Привилегии администраторов: отдельные записи и LAPS

Бухгалтер открыл вложение из письма, и на его ПК что-то поселилось. Неприятно, но это один компьютер. Хуже, если вечером на него «на минутку» зашёл администратор под admin-lab: злоумышленник получает учётные данные члена Domain Admins, а с ними права на каждом компьютере домена. История вымышленная, но мысль верна: размер ущерба определяет и то, кто и куда входил. В этой статье вы:

• проведёте аудит «кто у нас админ» и сократите состав привилегированных групп;
• разделите повседневную и административную учётные записи, введёте LAPS (уникальный пароль локального администратора на каждом узле) и запретите административной записи вход на рядовые ПК;
• переведёте службы на gMSA (групповые управляемые служебные учётные записи) и замените «всем админа» делегированием.

Что нужно знать заранее

• Windows Server с нуля 03: «Кто чем может», временное членство; 05: OU, делегирование, корзина AD; 06: GPO; 12: LAPS, Protected Users, аудит. Принцип наименьших привилегий: Безопасность для начинающих 01.
• Привилегированная учётная запись — любая, у которой прав больше, чем у обычного пользователя: не только член Domain Admins, но и помощник, сбрасывающий пароли. Кража учётных данных — извлечение данных входа из сеансов вошедших в компьютер учётных записей, чтобы выдать себя за их владельцев.
• Как в Поддержка пользователей 01, специалист работает под повседневной helpdesk1 (ей делегирован сброс паролей в OU=Staff, в Domain Admins она не входит) и административной admin-lab (в Windows Server с нуля 12 она совмещала роли, здесь мы их разделяем). ivanov — обычный сотрудник.

Почему администраторы — главная цель

Microsoft называет защиту привилегированного доступа первым приоритетом: такие учётные записи открывают доступ ко всему, и их слабости эксплуатируют, в частности, вымогатели. Опасно, когда администратор входит в привилегированную запись на незащищённом компьютере или открывает при этом интернет: его учётные данные остаются в сеансе, и их можно украсть. Дальше работает вложенность: Domain Admins по умолчанию входит в локальных администраторов каждого компьютера домена, а Enterprise Admins, Domain Admins и Administrators практически равнозначны, ведь член любой из них способен добавить себя в две другие.

Наименьшие привилегии и уровни доступа

Принцип наименьших привилегий (мера AC-6 каталога NIST SP 800-53) разрешает только тот доступ, который нужен для задач. Из него вытекает, что у владельца привилегированной учётной записи есть отдельная обычная (AC-6(2)); привилегированные записи закрепляют за определёнными людьми или ролями (AC-6(5)); права периодически пересматривают (AC-6(7)); использование привилегированных функций журналируют (AC-6(9)). В малой организации это пять правил:

1. У администратора две учётные записи: повседневная и административная.
2. Идеал Microsoft — группа Domain Admins пуста, права выдают на время операции. В малой сети допускаем одну-две личные административные записи и встроенный Administrator на крайний случай (упрощение, практика автора); Enterprise Admins и Schema Admins пусты.
3. Административная запись не читает почту и не ходит на рядовые ПК.
4. Службы работают под своими учётными записями, а не под административными.
5. Раз в квартал (практика автора) состав групп проверяют, а изменения в них попадают в журнал и оповещение (Безопасность 07).

Правило «учётная запись высокого уровня не входит на системы ниже» берёт начало в модели уровней, которую Microsoft сменила моделью доступа предприятия (enterprise access model): уровень 0 стал плоскостью контроля доступа, уровень 1 разделён на плоскость администрирования и плоскость данных и нагрузок, уровень 2 — на доступ пользователей и приложений. Малой сети хватит трёх слоёв (практика автора): управление идентификацией (контроллеры, Domain Admins), серверы, ПК пользователей. Учётная запись верхнего слоя на нижнем не работает.

Шаг 1. Аудит за 15 минут: кто у нас админ

Выполните в PowerShell с модулем ActiveDirectory. Имена групп в русскоязычной системе переведены, подставьте свои из dsa.msc.

$groups = 'Domain Admins', 'Enterprise Admins', 'Schema Admins',
          'Administrators'
foreach ($g in $groups) {
  "== $g"
  Get-ADGroupMember -Identity $g -Recursive |
    Select-Object Name, SamAccountName, objectClass
}
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly |
  Select-Object Name, LastLogonDate
Search-ADAccount -PasswordNeverExpires -UsersOnly |
  Select-Object Name, Enabled

Порог 90 дней — практика автора. Локальных администраторов проверьте на серверах и нескольких ПК: Get-LocalGroupMember -Group 'Administrators' (на ПК — на самом компьютере). Читайте результат так:

• Domain Admins: одна-две личные административные записи и встроенный Administrator. Помощникам, сотрудникам и службам здесь не место: им нужно делегирование (шаг 6).
• Enterprise Admins, Schema Admins: пусто (допустим встроенный Administrator корневого домена).
• Administrators: не вынимайте из неё Domain Admins и Enterprise Admins, они нужны при аварийном восстановлении леса.
• Локальные администраторы: кроме Domain Admins и локального администратора (его пароль ведёт LAPS) любой участник — вопрос к владельцу.
• «Спящие» записи и записи с бессрочным паролем: у служебных это допустимо, у личных административных нет.

Запись без причины быть в группе уберите после подтверждения владельца, а лишнюю учётную запись отключите (Disable-ADAccount). Удаляйте её не раньше чем через две недели (практика автора) и только при включённой корзине AD (Windows Server 05): откат удаления — восстановление из корзины, остального — Add-ADGroupMember, Enable-ADAccount.

Шаг 2. Две учётные записи и административный хост

Отдельные учётные записи для администрирования и обычной работы советуют и NCSC, и CISA. Повседневная helpdesk1 — почта, браузер, документы, сброс паролей. Административная admin-lab не имеет почтового ящика, не открывает интернет и работает только на административном хосте. Пароли разные и не выводятся друг из друга (Безопасность 02).

Административный хост — компьютер только для администрирования: без почты, браузера и офиса. Принципы: не администрировать доверенную систему с менее доверенного узла, не полагаться на один фактор, защитить компьютер физически и зашифровать диск (BitLocker). Варианты для малой организации:

NCSC (страница 2016 года) считает наиболее рискованным управление прямо с обычного рабочего компьютера, а «бастион из корпоративной сети» — защитой частичной: атакующий с доступом к устройству администратора, вероятно, всё равно доберётся до управления.

Закройте административному хосту выход в интернет брандмауэром, обновления он берёт с WSUS (Windows Server 10). К серверам по RDP подключайтесь в режимах, где пароль не уходит на удалённый узел: Remote Credential Guard (mstsc /remoteGuard; только прямое подключение, не через RD Gateway) или Restricted Admin (mstsc /restrictedAdmin; рекомендован для службы поддержки, но сеанс обращается к другим ресурсам от имени удалённого узла, единого входа нет). Серверы разрешают их политикой «Remote host allows delegation of nonexportable credentials»; откат — «Not configured» и gpupdate /force.

Шаг 3. LAPS и Protected Users

Одинаковый пароль локального администратора на всех узлах — рискованная настройка: украв его на одном компьютере, злоумышленник проходит на все остальные. Windows LAPS (Local Administrator Password Solution) даёт каждому узлу свой пароль и хранит его в AD. Для серверов настройка разобрана в Windows Server 12; для ПК схема та же (схему AD расширяли там же): права на OU Workstations и GPO CMP-LAPS-Workstations, пока только для PC2 (фильтр по компьютеру, как в шаге 4).

$base = (Get-ADDomain).DistinguishedName
Set-LapsADComputerSelfPermission -Identity "OU=Workstations,$base"
# после применения политики на PC2:
Get-LapsADPassword -Identity PC2 -AsPlainText

Встроенный Administrator на Windows 11 обычно отключён (проверьте: Get-LocalUser Administrator), и LAPS в ручном режиме его не включает (режимы учётной записи Windows LAPS). Включите его на PC2 параметром безопасности «Accounts: Administrator account status» либо направьте LAPS на отдельную локальную учётную запись и только затем проверяйте вход с консоли ВМ.

Пока пароль PC2 не прочитан и не проверен входом с консоли ВМ, к шагу 4 не переходите: это ваш запасной путь на ПК. Реальную административную запись добавляйте в Protected Users только после проверки на тестовой (Windows Server 12).

Шаг 4. Запрещаем админским записям вход на рядовые ПК

Если администратор всё же сядет за рядовой ПК, данные его учётной записи не должны там оказаться. Поэтому Domain Admins и Enterprise Admins запрещают вход на рабочих станциях через консоль и RDP. Microsoft описывает запрет для всех рядовых серверов и станций; в малой сети, где администраторы сами ходят на серверы, начните с OU Workstations (практика автора). Запрет сильнее разрешения и вступает в силу при следующем входе: открытый административный сеанс не закрывайте, пока проверка не пройдена. В русском интерфейсе названия прав переведены: ориентируйтесь на путь и константы SeDenyInteractiveLogonRight, SeDenyRemoteInteractiveLogonRight.

Копия. Сохраните политики:

New-Item -ItemType Directory -Force C:\Backup\GPO | Out-Null
Backup-GPO -All -Path C:\Backup\GPO -Comment 'before deny-admins'

Политика. Создайте GPO CMP-Deny-Admins-Workstations (Windows Server 06), пока не привязывая: New-GPO -Name 'CMP-Deny-Admins-Workstations'. В редакторе откройте Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment; в правах «Deny log on locally» и «Deny log on through Remote Desktop Services» добавьте LAB\Domain Admins и LAB\Enterprise Admins кнопкой выбора, а не вручную.

Пилот и привязка. Применение разрешено только PC2, у Authenticated Users оставлено чтение:

$base = (Get-ADDomain).DistinguishedName
Set-GPPermission -Name 'CMP-Deny-Admins-Workstations' `
  -TargetName 'PC2' -TargetType Computer -PermissionLevel GpoApply
Set-GPPermission -Name 'CMP-Deny-Admins-Workstations' `
  -TargetName 'Authenticated Users' -TargetType Group `
  -PermissionLevel GpoRead -Replace
New-GPLink -Name 'CMP-Deny-Admins-Workstations' `
  -Target "OU=Workstations,$base" -LinkEnabled Yes

Проверка применения. На PC2 (от администратора) выполните gpupdate /force и gpresult /r /scope computer: GPO должна быть в списке применённых. Затем выгрузите действующие права и сравните с идентификатором группы:

New-Item -ItemType Directory -Force C:\Temp | Out-Null
secedit /export /mergedpolicy /cfg C:\Temp\ur.inf /areas user_rights
Select-String -Path C:\Temp\ur.inf `
  -Pattern 'SeDenyInteractiveLogonRight|SeDenyRemoteInteractiveLogonRight'
(Get-ADGroup 'Domain Admins').SID.Value
Remove-Item C:\Temp\ur.inf

Пример вывода (формат приблизительный, идентификаторы вымышленные):

SeDenyInteractiveLogonRight = *S-1-5-21-1-2-3-512,*S-1-5-21-1-2-3-519
SeDenyRemoteInteractiveLogonRight = *S-1-5-21-1-2-3-512,*S-1-5-21-1-2-3-519
S-1-5-21-1-2-3-512

Идентификатор Domain Admins из последней строки должен встретиться в обеих строках SeDeny….

Проверка на деле. С консоли ВМ PC2 вход под admin-lab должен быть отклонён, под helpdesk1 и ivanov проходит, а на FS1 admin-lab входит как раньше. Отказ виден в журнале безопасности ПК как неудачный вход (Безопасность 07).

Расширение. Добавляйте остальные ПК партиями (Set-GPPermission … -TargetName '<ПК>' … GpoApply); административный хост (в лаборатории PC1) не добавляйте никогда. Снять фильтр целиком (вернуть Authenticated Users право GpoApply) можно, только когда хост перенесён в отдельный OU без этой политики (например, AdminHosts), а secedit-выгрузка на нём показала, что запрет не применился. Иначе пополняйте фильтр.

Откат. Remove-GPLink -Name 'CMP-Deny-Admins-Workstations' -Target "OU=Workstations,$base", затем gpupdate /force на ПК и новый вход. Поведение после снятия привязки для этих прав в документации не описано, поэтому повторите secedit-выгрузку: идентификаторов Domain Admins и Enterprise Admins в строках SeDeny… быть не должно. Если остались, переведите оба права в Not defined, снова выполните gpupdate /force и войдите заново. Срочно попасть на ПК можно локальным администратором (пароль из LAPS), с консоли ВМ или в безопасном режиме, где Microsoft допускает временно включить локальный Administrator и после ремонта отключить.

Как обслуживать ПК, если администраторы туда не ходят. RDP и вход с консоли под admin-lab на ПК под запретом, а сетевой вход (PowerShell Remoting, консоли MMC) разрешён: шаги второй линии из Поддержка пользователей 02 выполняйте по PowerShell Remoting или через Быструю поддержку. Штатно ПК обслуживает отдельная группа локальных администраторов ПК (не Domain Admins), которую выдаёт групповая политика (практика автора; Microsoft упоминает для этого параметры ограниченных групп в GPO). В лаборатории PC1 — исключение: там и рабочее место petrova, и административный хост; в боевой сети это разные компьютеры.

Предостережения:

• Не добавляйте в запрет встроенную группу Administrators: он действует и на локальных администраторов компьютера, и вы закроете законное администрирование.
• Не привязывайте политику к корню домена, к OU Domain Controllers и (в боевой сети) к OU с административным хостом или jump-сервером. В лаборатории PC1 лежит в Workstations, и его защищает только фильтр: не добавляйте PC1 в Security Filtering.
• Запрет сетевого входа мы не вводим: через него идёт удалённое администрирование (CISA советует для него PowerShell Remoting, Remote Credential Guard или Restricted Admin). Microsoft в полной версии запрещает и его, но тогда нужен иной путь администрирования ПК.

Шаг 5. Служебные учётные записи и gMSA

Служба под учётной записью администратора или обычной записью с вечным паролем — готовая цель. В gMSA пароль создаёт и меняет сам домен, узлы получают его у контроллера, человек его не знает. Подходят службы Windows, пулы приложений IIS и задачи планировщика. Нужны уровни домена и леса не ниже Windows Server 2012 и корневой ключ службы распределения ключей (KDS). Ключ создаёт член Domain Admins или Enterprise Admins один раз на лес, на контроллере; даже с -EffectiveImmediately другие контроллеры смогут им пользоваться только после репликации (по документации до 10 часов).

Add-KdsRootKey -EffectiveImmediately

Прежде чем идти дальше, найдите в журнале KdsSvc (Operational) событие 4004. Затем на DC1:

$base = (Get-ADDomain).DistinguishedName
New-ADGroup -Name 'GG-gMSA-Backup-Hosts' -GroupScope Global `
  -GroupCategory Security -Path "OU=Groups,$base"
Add-ADGroupMember -Identity 'GG-gMSA-Backup-Hosts' `
  -Members (Get-ADComputer -Identity FS1)
New-ADServiceAccount -Name 'gmsa-backup' `
  -DNSHostName 'gmsa-backup.lab.example' `
  -PrincipalsAllowedToRetrieveManagedPassword 'GG-gMSA-Backup-Hosts'

Команды Install- и Test-ADServiceAccount относятся к модулю ActiveDirectory, поэтому на FS1 нужны средства AD DS (компонент RSAT-AD-Tools: Install-WindowsFeature -Name RSAT-AD-Tools -IncludeAllSubFeature; проверьте Get-Module -ListAvailable ActiveDirectory):

Install-ADServiceAccount -Identity 'gmsa-backup'
Test-ADServiceAccount -Identity 'gmsa-backup'

True означает, что учётная запись готова к использованию на этом узле. Если False, проверьте репликацию (repadmin /replsummary) и перезагрузите FS1 (практика автора: членство в группе компьютер подхватывает после перезапуска). Службе укажите имя gMSA (оно заканчивается на $, например LAB\gmsa-backup$) и оставьте поля пароля пустыми: пароль подставит система (практика; сверьтесь с документацией службы). Откат: на FS1 Uninstall-ADServiceAccount -Identity 'gmsa-backup', затем Remove-ADServiceAccount -Identity 'gmsa-backup'; создание ключа KDS откатом не описано, пробуйте на стенде. Если программа gMSA не умеет, остаётся обычная служебная учётная запись (Windows Server 05): длинный случайный пароль в менеджере паролей и право «Deny log on through Remote Desktop Services» (так советуют для служебных записей).

Шаг 6. Делегирование, временный доступ и общий пароль

Делегирование. Помощнику, который сбрасывает пароли, права администратора домена не нужны: используйте группу GG-HelpDesk и делегирование на OU Staff из Windows Server 05. Административные учётные записи под него попадать не должны: в лаборатории admin-lab лежит в контейнере Users, и делегирование на Staff до неё не достаёт; в боевой сети создайте OU Admins (New-ADOrganizationalUnit) и перенесите туда административные записи.

Временный доступ. В идеале постоянное членство в Domain Admins заменяют временным: добавили на время операции, выполнили, убрали, вышли и вошли заново (Windows Server 03). Microsoft советует вести аудит таких действий, по возможности работать вдвоём (один выполняет, другой наблюдает) и оповещать ответственных об изменении состава групп. Автоматизируют это решения PIM и PAM (управление привилегированными учётными записями и доступом). В AD с Windows Server 2016 есть и встроенная возможность задать члену группы срок жизни (-MemberTimeToLive у Add-ADGroupMember), но её включение действует на весь лес и необратимо (спецификация MS-ADTS): без плана и стенда не включайте.

Общий пароль администратора — частый антипаттерн: с одного узла он открывает все. Лечение: найдите, где он используется (локальные Administrator, сетевое оборудование, службы, скрипты); для Windows введите LAPS (шаг 3); для сетевых устройств заведите личные записи через AAA (аутентификация, авторизация и учёт; Cisco с нуля: AAA и RADIUS); пароль «на пожарный случай» храните вне сети, в сейфе, и меняйте после ухода любого, кто его знал (практика автора).

Linux. В Ubuntu учётная запись root по умолчанию отключена: администрируют через sudo под личной учётной записью, что даёт учёт действий. Каждому администратору — личная запись в группе sudo. Состав группы покажет getent group sudo, свои права — sudo -l. Подробнее: Linux для админа Windows 04 и 08.

Состояние на ноябрь 2026 года (проверьте актуальность). Страница Microsoft «Enterprise access model» обновлена 7 мая 2026 года и названа преемником модели уровней; старая справочная страница про уровни перенаправляет на неё. «Securing privileged access» обновлена 20 июня 2024 года. «Implementing Least-Privilege Administrative Models» восходит к материалам 1999 и 2005 годов, но применима, по её пометке, к Windows Server 2016–2025. Страницы о правах «Deny log on…» архивные (обновлены 19 апреля 2017 года, Windows 11 и 10). Страница NCSC о системном администрировании датирована 24 сентября 2016 года. Об изменениях sudo в Ubuntu 25.10 и новее — во врезке Linux 04.

Типичные ошибки и недоразумения

• Администратор «на минутку» зашёл на рядовой ПК под admin-lab. Учётные данные остались в сеансе ПК.
• Запретили вход для группы Administrators. Закрыли заодно локальных администраторов: нужной группой был Domain Admins.
• Политику привязали к корню домена или к OU Domain Controllers, либо сняли фильтр, не переселив PC1. Админы потеряли вход на серверы или на свой рабочий ПК.
• Помощника добавили в Domain Admins «пока не настроим права». Временное решение живёт годами: нужно делегирование.
• Убрали Domain Admins из группы Administrators. Это осложняет аварийное восстановление: вложенность по умолчанию не меняют.
• Общий пароль «временно» разослали всем. Введите LAPS.

Проверьте себя

1. Почему украденная учётная запись члена Domain Admins равна взлому домена? Domain Admins по умолчанию входит в локальных администраторов каждого компьютера домена, а три высшие группы практически равнозначны.
2. Какие две учётные записи нужны специалисту? Повседневная с минимальными правами (helpdesk1) и административная без почты и интернета, только на административном хосте (admin-lab; AC-6(2)).
3. Что запрещают права «Deny log on locally» и «Deny log on through Remote Desktop Services» для Domain Admins и почему не добавляют Administrators? Вход на рядовые ПК через консоль и RDP; запрет действует и на локальных администраторов компьютера и закроет законное администрирование.
4. Почему административный хост нельзя включать в такую политику? Запрет закрыл бы администратору вход на собственный рабочий ПК; хост держат в отдельном OU без политики, без почты и интернета.
5. Чем gMSA лучше обычной служебной учётной записи? Пароль создаёт и меняет домен, человек его не знает и не хранит.

Что дальше

• Безопасность для начинающих 07 — оповещения об изменении привилегированных групп и входах админов.
• Безопасность для начинающих 10 — что делать, если административная учётная запись всё же скомпрометирована.
• Windows Server с нуля 12 — LAPS, Protected Users, аудит и регулярные проверки.
• Linux для админа Windows 04 — права и sudo на Linux-серверах.

Источники

• Securing privileged access — защита привилегированного доступа как первый приоритет, дата обновления страницы
• Enterprise access model — преемник модели уровней, разделение уровней 0, 1 и 2
• Implementing Least-Privilege Administrative Models — вложенность Domain Admins, равнозначность групп, запреты входа, временное членство, работа вдвоём, безопасный режим для локального Administrator, ограниченные группы
• Best practices for securing Active Directory — кража учётных данных, одинаковые локальные пароли, временное членство
• Implementing Secure Administrative Hosts — принципы административного хоста, варианты для малых организаций, BitLocker
• Remote Credential Guard — /remoteGuard, Restricted Admin, ограничение для RD Gateway, рекомендации для службы поддержки
• Deny log on locally (архив, Windows 10) — запрет сильнее разрешения, вступление в силу при следующем входе
• Deny log on through Remote Desktop Services (архив, Windows 10) — запрет RDP, служебные записи
• Manage group Managed Service Accounts — создание, установка и проверка gMSA, требования, событие 4004
• Create a Key Distribution Service (KDS) root key — корневой ключ, время вступления в силу
• MS-ADTS: Privileged Access Management Optional Feature — срок жизни членства, уровень леса 2016, необратимость
• NIST SP 800-53 Rev. 5: Security and Privacy Controls — мера AC-6 и её усиления, релиз 5.2.0
• Systems administration architectures (NCSC) — отдельные учётные записи, выделенные устройства, оценка схем с бастионом (2016)
• #StopRansomware Guide (CISA и партнёры) — раздельные записи, PowerShell Remoting и Restricted Admin, LAPS, администраторы контроллеров
• Ubuntu Server: User management — root отключён по умолчанию, sudo и учёт действий