RC4 вышел из чата. Сервисные аккаунты остались

В апреле 2026 Kerberos в Windows перестаёт по умолчанию прикрывать старые сервисные учётки RC4. И тут внезапно выясняется, что главный вопрос не «как включить AES», а «кто вообще помнит, какие аккаунты у нас сервисные».

Microsoft в описании изменений по CVE-2026-20833 пишет, что обновления Windows, выпущенные с 14 апреля 2026 года, меняют поведение Kerberos KDC: если явная конфигурация не задана, контроллеры домена в enforcement-режиме будут исходить из поддержки AES. RC4-HMAC больше не работает как удобный неявный fallback. В апреле ещё остаётся ручной откат, в июле – уже без этого люфта.

⚠️ Где ломается логика

Проблема не в том, чтобы выставить msDS-SupportedEncryptionTypes. Это одна команда PowerShell.

Проблема – сначала найти всё, что нужно исправить.

В зрелом AD-лесу сервисных аккаунтов могут быть сотни. Часть создана вручную. Часть – скриптами, которые писал человек из прошлой эпохи. Часть – установщиками enterprise-приложений, которые сами создали учётку и не спросили, надо ли оставить записку будущим поколениям.

ldapsearch или PowerShell выдадут список объектов. Но список не ответит на главные вопросы:

·         какой аккаунт обслуживает какой сервис;

·         кто его создал;

·         почему у него именно такие флаги;

·         что отвалится, если атрибут поменять.

После enforcement один старый флаг – и сервис, который тихо работал пять лет, встречает вас ошибкой уровня KRB_AP_ERR_ETYPE_NOSUPP. Очень вежливо. Очень бесполезно.

🔍 Почему резервка не спасает

Резервная копия здесь не главный инструмент. Это не пожар в дата-центре и не потерянный контроллер домена. Это состояние конкретных атрибутов у конкретных объектов.

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

Снимок состояния каталога и сравнение объекта «было / стало» в таких историях полезнее, чем героический разбор логов в три ночи. Особенно когда речь идёт не только про Kerberos, но и про импортозамещение, миграции, синхронизации и переносы объектов между каталогами.

Это хорошо видно и по соседнему миру: Help Net Security разбирает Samba 4.24.0 как релиз с Kerberos hardening и переходом к AES-default для доменной криптографии. Тренд понятный: старые неявные допущения вокруг RC4 постепенно закрываются. А вместе с ними всплывает качество инвентаризации каталога.

После переноса часть атрибутов может потеряться тихо. Сервисные учётки могут остаться на месте, но уже не в том состоянии. Формально каталог работает. Практически – вы начинаете админскую археологию.

Апрельский дедлайн Kerberos – хороший повод проверить не только поддержку AES. Он задаёт более неприятный вопрос: насколько хорошо вы вообще видите состояние своего каталога.

Скрипт отработал без ошибок. Каталог – нет

Скрипт массового обновления атрибутов отработал идеально: лог чистый, ошибок нет.

Через час выясняется – у 400 пользователей сломалась связка UPN‑sAMAccountName.

Причина – логическая ошибка в условии.
Тест на 10 объектах её просто не поймал.

Дальше обычно три сценария.

Первый – откат из резервной копии.
Но копию сделали 18 часов назад. За это время уже:

– создали новые аккаунты;
– поменяли пароли;
– выдали права.

Откат чинит одно и ломает другое.

Второй – писать обратный скрипт.
Работает, если ты точно помнишь, что именно перезаписалось, и уверен, что обратная логика не добьёт оставшееся.

Обычно это уже режим «админской археологии».

Третий – взять снимок состояния до запуска и вернуть только нужные атрибуты у нужных объектов.

Проблема в том, что третий путь работает только если снимок был сделан заранее.

Не «когда всё поехало», а до того, как нажали Enter.

Массовое изменение без снимка перед изменением – это не автоматизация.

Это ставка на то, что скрипт идеален.

Обычно – нет.

Очередная история про контроллеры домена и ребутлуп после обновления хорошо показывает старую проблему.

Когда каталог ложится, все вспоминают про резервки. Когда каталог подняли, внезапно выясняется, что резервка не умеет ответить на главный вопрос: что из свежих изменений мы сейчас потеряли.

Учётки, членства, атрибуты, результаты массовых правок, последствия миграции – всё это очень легко откатывается вместе с аварией.

В итоге сервис вроде живой, а дальше начинается админская археология.

Поэтому для каталога мало просто уметь подняться из копии. Нужно ещё уметь нормально разруливать логические потери без отката всего подряд.

Потому что «всё поднялось» и «всё починилось» – это, как известно, две разные стадии одного и того же инцидента.