Добавил админа в Protected Users на Windows Server 2025 — и через четыре часа он перестал ходить в домен. Что делать

Типичная история: после аудита по pass-the-hash админские учётки отправили в Protected Users, а через полдня звонок — «рабочий стол открыт, но шары не открываются, оснастка AD просит пароль, ночное задание упало». Разбираю, откуда берутся ровно четыре часа, почему это не баг и не сбой репликации, как за десять минут доказать причину по klist и журналам и как я продлеваю срок жизни билета через Authentication Policy — не выкидывая учётку из группы и не откатывая защиту.

Ровно 240 минут: это не сбой, это константа

Картина всегда одна и та же. Администратор утром зашёл на консоль, поработал, ушёл на обед, вернулся — рабочий стол на месте, окна открыты. А \\pp-fs01\Архив уже не открывается, оснастка «Пользователи и компьютеры» пишет, что домен недоступен, RSAT просит учётные данные, скрипт выгрузки падает с «отказано в доступе». Выход из системы и повторный вход — и всё снова работает ровно четыре часа. Потом опять.

Механика простая, и она описана в документации Microsoft чёрным по белому. Членство в Protected Users жёстко задаёт два параметра, которые обычно берутся из доменной политики Kerberos: «Максимальный срок жизни билета пользователя» и «Максимальный срок жизни для возобновления билета пользователя». Для членов группы оба принудительно равны 240 минутам, и изменить это членством в группе невозможно. Для сравнения: в Default Domain Policy эти значения по умолчанию 10 часов и 7 дней. То есть вы не просто урезали срок билета в 2,5 раза — вы ещё и убили возможность его продлевать.

Дальше вступает вторая часть защиты, ради которой всё и затевалось. Для члена Protected Users Kerberos не кэширует ни пароль в открытом виде, ни долговременные ключи после получения первичного TGT. Значит, когда TGT протух, система физически не может сходить в KDC и взять новый — материала для преаутентификации в памяти нет. Автоматического повторного получения TGT не происходит. Нужен новый интерактивный вход, где пользователь введёт пароль руками.

Почему рабочий стол живой? Сеанс уже создан, локальный токен есть, профиль загружен — локально ничего не ломается. Ломается то, для чего нужен свежий билет: новое обращение к сетевому ресурсу по Kerberos. Сервисные билеты не переживают TGT — KDC не выдаёт их на срок дольше, чем действует сам TGT, — но уже установленные соединения (открытая SMB-сессия, подключённая оснастка) часто держатся до переподключения. Отсюда обманчивая картина «половина работает, половина нет», из-за которой люди неделю ищут проблему в DNS, репликации и антивирусе.

• SMB-шары, к которым в этом сеансе ещё не обращались; уже открытые сессии могут продержаться до первого переподключения
• Оснастки RSAT, ADUC, ADAC, DNS, GPMC — они каждый раз запрашивают новый сервисный билет
• Подключения к SQL Server по Windows-аутентификации, включая linked server
• WinRM, PowerShell Remoting, `Enter-PSSession` — падают с ошибкой доступа
• Задания планировщика и скрипты под доменной админской учёткой — особенно если они ходят к ресурсам по IP-адресу или на NAS без Kerberos: это NTLM
• Всё, что раньше молча падало на NTLM: для членов группы NTLM запрещён на стороне контроллера домена

Две разные защиты, которые все путают

Protected Users работает на двух уровнях, и это ключ к пониманию, что именно у вас сломалось. Первый уровень — клиентский, он включается на той машине, где член группы интерактивно входит. Требование одно: хост под Windows 10/11 или Windows Server 2012 R2 и новее с актуальными обновлениями. Здесь система перестаёт кэшировать открытый пароль для CredSSP (даже если включена политика «Разрешить делегирование учётных данных по умолчанию»), перестаёт кэшировать пароль для WDigest, перестаёт хранить NTOWF для NTLM, не создаёт DES- и RC4-ключи Kerberos и не создаёт кэшированный верификатор входа. Последнее означает, что автономный вход без контроллера домена на этой машине для этого пользователя больше невозможен.

Второй уровень — на контроллере домена. Он включается только при функциональном уровне домена Windows Server 2012 R2 или выше. Здесь для члена группы KDC запрещает NTLM-аутентификацию, запрещает DES и RC4 в преаутентификации Kerberos, запрещает делегирование — и ограниченное, и неограниченное, — и не даёт продлевать TGT сверх первичного четырёхчасового срока. Именно этот уровень даёт наш симптом.

Отсюда практический вывод. Если у вас функциональный уровень домена ниже 2012 R2 (в моей практике до сих пор попадаются домены на уровне 2008 R2, доставшиеся по наследству), группа даст только клиентские защиты, и четырёхчасового срока вы не увидите. И наоборот: подняли DFL при переходе на контроллеры Windows Server 2025 — и группа, которую кто-то заполнил три года назад «на всякий случай», внезапно оживает и начинает кусаться. Я такое видел дважды, и оба раза заказчик был уверен, что «мы ничего не меняли».

И ещё одно, о чём забывают чаще всего: члены группы аутентифицируются только по Kerberos с AES. Если у учётной записи нет AES-ключей — пароль не менялся со времён контроллеров Windows Server 2003 или учётку мигрировали из другого домена, — после добавления в группу она не войдёт никуда. Не через четыре часа, а сразу. Лечится сменой пароля на контроллере Windows Server 2008 или новее: после этого AES-ключи появятся. Microsoft отдельно предупреждает, что у встроенного администратора AES-ключа тоже нет, пока его пароль не сменили на таком контроллере.

• Клиентская часть: Windows 10/11 или Windows Server 2012 R2+, работает независимо от DFL
• Серверная часть: функциональный уровень домена Windows Server 2012 R2 и выше
• Встроенный администратор домена (RID 500) подчиняется ограничениям группы, но всегда исключён из Authentication Policies
• Учётные записи служб и компьютеров в группу добавлять нельзя — локальной защиты они не получают, пароль и сертификат всё равно лежат на хосте
• Тип группы — Domain Global, SID S-1-5-21-<домен>-525; AdminSDHolder эту группу не защищает

Стенд: нотариальная контора «Печать и Право», 13 рабочих мест, два DC на Windows Server 2025

Клиент — нотариальная контора «Печать и Право»: 13 рабочих мест (нотариус, помощники, консультанты, бухгалтер), домен corp.example.local, два контроллера PP-DC01 и PP-DC02 на Windows Server 2025, функциональный уровень домена и леса — Windows Server 2016. Кроме контроллеров — хост Hyper-V с файловым сервером pp-fs01, сервер с базой программы учёта нотариальных действий на MS SQL и 1С для бухгалтерии, плюс NAS для резервных копий. Домен вырос из старого SBS, поэтому часть учёток помнит времена Windows Server 2003. После аудита закрывали базовые вещи: LAPS, отключение WDigest, запрет входа доменных админов на рабочие станции. В том же пакете завели две именованные админские учётки adm.* для наших инженеров, добавили их в Protected Users и оставили одну аварийную учётку вне группы.

Первые сутки прошли спокойно, на второй день посыпалось. Инженер жаловался, что «домен отваливается после обеда», ночное задание Robocopy на NAS в 02:00 упало с кодом 5, а отчётный скрипт, который тянул данные из SQL по Windows-аутентификации, перестал отрабатывать. Причём падало не у всех: помощники и консультанты, чьи учётки в группу не входят, не заметили ничего.

Первым делом я не полез в сеть. Выполнил на проблемной машине klist tgt и увидел ожидаемое: StartTime 09:12, EndTime 13:12, RenewUntil 13:12. Четыре часа, и RenewUntil совпадает с EndTime — продлевать билет некуда. Дальше включил на контроллерах административные журналы аутентификации и получил подтверждение: событие 100 в ProtectedUserFailures-DomainController — отказ NTLM для учётки из группы (задание Robocopy обращалось к NAS по IP-адресу, а это всегда NTLM), и событие 104 — попытка преаутентификации без AES.

Событие 104 оказалось отдельной находкой. Вторая админская учётка была переименованной старой, пароль у неё последний раз меняли в 2011 году, ещё на контроллере эпохи SBS, — AES-ключей у неё просто не было. Заодно в msDS-SupportedEncryptionTypes висело значение 4 (только RC4) — след давней интеграции со сканером. После попадания в Protected Users учётка перестала получать TGT сразу, а не через четыре часа. Сменили пароль на PP-DC01, убрали явный RC4 из атрибута — вход поднялся.

Чем закончилось. Ночное задание Robocopy перевели на gMSA и обращение к NAS по DNS-имени — доменной админской учётке там изначально нечего было делать. Отчётный скрипт перевели на отдельную сервисную учётку с правами только на чтение нужной базы. Для обеих adm.* завёл Authentication Policy с TGT на 600 минут, чтобы инженер мог отработать субботнее окно обслуживания хоста Hyper-V без выхода из системы посреди переноса виртуальной машины. Protected Users никто не снимал: NTLM запрещён, кэша пароля нет. Просрочка билета из аварии превратилась в «раз за смену перезашёл».

• `klist tgt` → EndTime = StartTime + 4:00 и RenewUntil = EndTime — диагноз поставлен
• События 100 и 104 в ProtectedUserFailures-DomainController — подтверждение со стороны KDC
• Учётка без AES-ключей (старый пароль) → мгновенный отказ, а не отвал через четыре часа
• Обращения к ресурсам по IP-адресу — это NTLM, для членов группы они не работают в принципе
• Итог: 2 учётки `adm.*` с политикой на 600 минут, 1 аварийная вне группы, ноль откатов защиты

Диагностика: десять минут и никакой мистики

Начинайте с билетов, а не с журналов. Команда klist tgt на машине пострадавшего показывает срок жизни первичного билета. Если EndTime ровно на четыре часа позже StartTime и RenewUntil совпадает с EndTime — дальше можно не искать. Обычный klist покажет сервисные билеты: их срок не выходит за конец TGT, так что после 240 минут новых билетов не будет, а старые умрут вместе с ним.

klist tgt
klist
klist purge   # только для проверки: после очистки придётся перезайти

Вторым шагом включайте административные журналы. По умолчанию они выключены, лежат в «Журналы приложений и служб → Microsoft → Windows → Authentication» и включаются правым кликом «Включить журнал» или командой wevtutil. Нужны четыре канала: отказы Protected Users на контроллере, успешные выдачи TGT членам группы, клиентский журнал и отказы Authentication Policy.

wevtutil sl Microsoft-Windows-Authentication/ProtectedUserFailures-DomainController /e:true
wevtutil sl Microsoft-Windows-Authentication/ProtectedUserSuccesses-DomainController /e:true
wevtutil sl Microsoft-Windows-Authentication/ProtectedUser-Client /e:true
wevtutil sl Microsoft-Windows-Authentication/AuthenticationPolicyFailures-DomainController /e:true

Параллельно смотрите классику в журнале безопасности на контроллере: 4768 (запрос TGT), 4769 (запрос сервисного билета), 4771 (сбой преаутентификации Kerberos), 4776 (проверка учётных данных NTLM). Успешных 4776 для члена Protected Users быть не должно: если они есть, значит DFL ниже 2012 R2 или вы смотрите не на ту учётку. Неуспешные 4776 при этом вполне возможны — приложение пробует NTLM, контроллер отказывает и пишет рядом событие 100.

И проверьте учётку, прежде чем что-то менять. Главное — дата последней смены пароля: если она старше перехода на контроллеры Windows Server 2008, AES-ключей может не быть. Пустой msDS-SupportedEncryptionTypes означает значения по умолчанию и обычно нормален; явная четвёрка (только RC4) — повод выяснить, откуда она взялась, и убрать.

Get-ADGroupMember -Identity 'Protected Users' |
  Select-Object name, objectClass, distinguishedName

Get-ADUser adm.ivanov -Properties msDS-SupportedEncryptionTypes, PasswordLastSet, msDS-AssignedAuthNPolicy |
  Format-List Name, PasswordLastSet, msDS-SupportedEncryptionTypes, msDS-AssignedAuthNPolicy

• ProtectedUserFailures-DomainController: 100 — отказ NTLM, 104 — DES/RC4 в преаутентификации Kerberos
• ProtectedUserSuccesses-DomainController: 303 — TGT успешно выдан члену группы
• ProtectedUser-Client: 104 — в пакете безопасности нет учётных данных для аутентификации, 304 — пакет не хранит учётные данные члена группы
• Журнал безопасности DC: 4768, 4769, 4771, 4776

Лечение, которое я считаю правильным: Authentication Policy вместо вынимания из группы

Самый частый «фикс», который я вижу у коллег — вынуть учётку из Protected Users и жить дальше. Это откат защиты целиком: возвращается кэширование NTOWF, возвращается NTLM, возвращается делегирование, возвращается кэшированный верификатор. Из-за четырёх часов неудобства вы отдаёте обратно всё, ради чего затевали проект. Так делать не надо.

Правильный инструмент — Authentication Policy. В документации сказано прямо: если в политике срок жизни TGT для пользователя не задан, член Protected Users получает четыре часа на выдачу и продление; если задан — действует значение политики. Все остальные защиты группы остаются на месте. Для настройки срока жизни TGT достаточно DFL Windows Server 2012 R2; Dynamic Access Control и Kerberos armoring нужны только для условий «откуда можно входить» и «к чему можно обращаться».

Синтаксис минимальный, но есть важная деталь: -UserTGTLifetimeMins задаёт срок жизни **непродлеваемого** билета. Билет на 600 минут продлеваться не будет — по истечении срока всё равно нужен новый вход. Вы не возвращаете механизм продления, а выбираете длину окна. Подбирайте значение по длине смены или окна обслуживания, а не «побольше на всякий случай».

И обязательно сначала в режиме аудита. Если при создании политики не указать -Enforce, политика создаётся в режиме аудита: ограничения не применяются, но в журнал Authentication Policy Failures пишутся события о том, что сломалось бы при включении. Пара дней в аудите стоят дешевле, чем выяснять на живых людях, что вы прибили доступ с половины рабочих станций условием UserAllowedToAuthenticateFrom.

# 1. Создаём политику в режиме аудита (-Enforce не указан)
New-ADAuthenticationPolicy -Name 'Admins-TGT-600' `
  -Description 'TGT 10 h for admin accounts' `
  -UserTGTLifetimeMins 600

# 2. Назначаем учётной записи
Set-ADUser -Identity adm.ivanov -AuthenticationPolicy 'Admins-TGT-600'

# 3. Проверяем назначение
Get-ADUser adm.ivanov -Properties msDS-AssignedAuthNPolicy |
  Select-Object Name, msDS-AssignedAuthNPolicy

# 4. После нескольких дней аудита включаем принуждение
Set-ADAuthenticationPolicy -Identity 'Admins-TGT-600' -Enforce $true

# 5. Контроль: какие политики ещё в режиме аудита
Get-ADAuthenticationPolicy -Filter 'Enforce -eq $false' |
  Format-Table Name, Enforce -AutoSize

Отдельная ловушка, на которую я наступал лично: встроенная учётная запись администратора домена с RID 500 всегда исключена из Authentication Policies, даже если назначена через силос. Продлить ей TGT политикой вы не сможете. Если вы зачем-то добавили встроенного администратора в Protected Users, у него будут ровно четыре часа и точка. Именно поэтому встроенный администратор должен быть аварийной учёткой, которая лежит в сейфе, а не рабочим инструментом.

Если нужно ещё и ограничить, с каких машин админская учётка вообще может входить, в политику добавляется условие в формате SDDL. Проще всего собрать его в Active Directory Administrative Center (кнопка «Изменить» у условий входа) и скопировать строку, а в PowerShell передать её в -UserAllowedToAuthenticateFrom. Работает это только при включённой на контроллерах и клиентах поддержке утверждений, составной аутентификации и Kerberos armoring.

# SID группы админских рабочих станций подставьте свой
$sddl = 'O:SYG:SYD:(XA;OICI;CR;;;WD;(Member_of_any {SID(S-1-5-21-<домен>-<RID группы>)}))'
New-ADAuthenticationPolicy -Name 'Admins-Strict' `
  -UserTGTLifetimeMins 600 `
  -UserAllowedToAuthenticateFrom $sddl

• Срок жизни TGT в политике — только DFL 2012 R2, без DAC
• Политика без `-Enforce` работает в режиме аудита, отказы пишутся в AuthenticationPolicyFailures-DomainController
• Силосы (`New-ADAuthenticationPolicySilo`, `Grant-ADAuthenticationPolicySiloAccess`) нужны, когда связываете пользователей, машины и сервисные учётки в изолированный контур; для одной-двух учёток хватит политики, назначенной напрямую
• Встроенный администратор (RID 500) из политик исключён всегда, даже в силосе

Обвязка: RDP, Restricted Admin и что делать со службами

Половина проблем после внедрения Protected Users приходит не от самой группы, а от того, как админы ходят по серверам. Классический сценарий «захожу по RDP на сервер и оттуда управляю доменом» для члена группы работает плохо: делегирование запрещено, CredSSP пароль не кэширует, второй прыжок не получится. Решается это не отключением защиты, а сменой схемы работы.

Первый вариант — Restricted Admin для RDP. На целевом хосте разрешается делегирование неэкспортируемых учётных данных, клиент подключается с ключом /restrictedAdmin. Учётные данные на удалённый хост не передаются вовсе, а к другим ресурсам сеанс ходит под учётной записью самого удалённого компьютера. Для хелпдеска, который подключается к потенциально скомпрометированным машинам, Microsoft рекомендует именно этот режим. Минусы: нужно членство в локальной группе «Администраторы» на целевом хосте, SSO к другим системам под вашей учёткой нет, многопрыжковый RDP не работает.

Второй вариант — Remote Credential Guard, ключ /remoteGuard. Запросы Kerberos перенаправляются обратно на клиентскую машину, учётные данные на удалённый хост не уходят, но SSO к другим системам сохраняется. Ограничения: только Kerberos без отката на NTLM (что как раз стыкуется с Protected Users), только хосты в домене Active Directory, только прямые подключения — через RD Gateway и Connection Broker не работает, составную аутентификацию не поддерживает. Для администратора, который весь день работает со своими серверами с отдельной админской станции, это лучший вариант.

rem На целевом хосте: разрешить делегирование неэкспортируемых учётных данных
reg.exe add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /v DisableRestrictedAdmin /d 0 /t REG_DWORD

rem На клиенте, для конкретного подключения:
mstsc.exe /restrictedAdmin
mstsc.exe /remoteGuard

Третье и самое важное: разберите, где у вас доменные админские учётки используются как сервисные. Задания планировщика с сохранённым паролем, службы, строки подключения приложений, скрипты бэкапа, коннекторы мониторинга. Всё это ломается о запрет NTLM и отсутствие кэша, и никакая Authentication Policy тут не поможет — надо менять учётку. gMSA закрывает большинство таких кейсов и заодно снимает вопрос ротации паролей.

• Групповая политика на клиенте: Конфигурация компьютера → Административные шаблоны → Система → Передача учётных данных → «Ограничить делегирование учётных данных удалённым серверам» со значением Restrict Credential Delegation или Require Remote Credential Guard
• На целевых хостах: та же ветка, параметр «Удалённый узел разрешает делегирование неэкспортируемых учётных данных» → Включено
• Сервисные сценарии — на gMSA: `New-ADServiceAccount` на контроллере, `Install-ADServiceAccount` на сервере, затем перевод задания планировщика или службы на эту учётку

Порядок внедрения без простоев и на что можно забить

Мой порядок действий, отработанный на нескольких доменах. Сначала инвентаризация: где доменные админские учётки используются неинтерактивно. Потом чистка — всё неинтерактивное на gMSA и сервисные учётки. Потом смена паролей у кандидатов, чтобы гарантированно появились AES-ключи. Потом Authentication Policy в режиме аудита. И только после этого — добавление в Protected Users, по одной учётке, с интервалом в рабочий день. Если делать наоборот, вы получите ровно тот сценарий, с которого начиналась статья.

Честно про спорное. Четыре часа — это неудобно, и я понимаю раздражение. Но моя позиция такая: в 90 % случаев претензия к четырём часам маскирует настоящую проблему — админскую учётку используют как рабочую и как сервисную одновременно. Если админ сидит под adm.* весь день, читает почту и правит документы, четыре часа его убивают. Если он переключается на привилегированную учётку под конкретную задачу — он их даже не замечает. Продление TGT политикой я делаю, но считаю это костылём под неудобное окно обслуживания, а не нормой.

Что переоценивают. Страх «мы включим Protected Users и весь домен встанет» преувеличен, если вы не залили в группу разом всех Domain Admins и не забыли про аварийную учётку. Клиентские защиты применяются при следующем входе пользователя, серверные — сразу, но обе абсолютно предсказуемы и полностью документированы. Откат — удаление из группы и повторный вход, никакой перезагрузки контроллеров не требуется.

На что можно не тратить время в первой итерации: силосы аутентификации, условия UserAllowedToAuthenticateFrom и Dynamic Access Control. Это следующий уровень зрелости: условия входа требуют утверждений, Kerberos armoring и выделенных админских станций. В нотариальной конторе на 13 мест, как и в большинстве компаний до 50 рабочих мест, это перебор. Сделайте базу — отдельные админские учётки, Protected Users, LAPS, запрет входа админов на рабочие станции — и самый массовый вектор кражи учётных данных будет закрыт.

• Инвентаризация неинтерактивного использования доменных админских учёток (планировщик, службы, строки подключения)
• Перевод найденного на gMSA и обычные сервисные учётные записи
• Смена паролей будущим членам группы — гарантия наличия AES-ключей
• Проверка `PasswordLastSet` и `msDS-SupportedEncryptionTypes`: старые пароли сменить, явный RC4-only (значение 4) убрать
• Authentication Policy с `-UserTGTLifetimeMins` в режиме аудита, 2–3 дня наблюдения по журналу Authentication Policy Failures
• Добавление в Protected Users по одной учётке, обязательно одна аварийная учётка остаётся вне группы
• Переключение админского RDP на Restricted Admin или Remote Credential Guard

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