Безопасность и обновления 12 мин чтения

Миграция Kerberos с RC4 на AES в Active Directory: пошаговое руководство

Microsoft отключает RC4 в Kerberos к июлю 2026 (CVE-2026-20833). Пошаговое руководство: аудит RC4 через Event ID 4768, PowerShell-скрипты, обновление msDS-SupportedEncryptionTypes, настройка GPO, миграция Linux-систем и keytab, устранение CVE-2026-25177.

Editorial Team

Почему Microsoft отключает RC4 в Kerberos и что это значит для вашей инфраструктуры

Итак, если вы ещё не слышали — в январе 2026 года Microsoft начала поэтапное отключение шифрования RC4-HMAC в протоколе Kerberos для контроллеров домена Active Directory. Причина проста и конкретна: уязвимость CVE-2026-20833 (CVSS 5.5), которая позволяет проводить атаки Kerberoasting. Злоумышленник с обычными правами доменного пользователя запрашивает сервисные билеты, зашифрованные слабым RC4, и взламывает пароли сервисных учёток офлайн.

RC4, созданный аж в 1987 году, не использует соль при преобразовании пароля в ключ — из-за этого хеши взламываются в 10–100 раз быстрее, чем AES. К июлю 2026 года RC4 будет полностью отключён на всех контроллерах домена через обязательные обновления Windows.

Если ваша среда не готова — аутентификация Kerberos просто перестанет работать для систем, которые зависят от RC4. Без вариантов.

Параллельно, в марте 2026-го Microsoft закрыла ещё одну серьёзную уязвимость — CVE-2026-25177 (CVSS 8.8), связанную с повышением привилегий в AD DS через дублирование SPN/UPN с помощью Unicode-символов. Обе уязвимости недвусмысленно говорят: безопасность AD требует немедленных действий.

График отключения RC4: три фазы от Microsoft

Microsoft разбила переход на три этапа, чтобы у администраторов было время подготовить инфраструктуру:

ФазаДатаЧто происходит
Фаза 1 — АудитЯнварь 2026Новые события аудита (Event ID 201, 4768, 4769), появляется ключ реестра RC4DefaultDisablementPhase
Фаза 2 — Принудительное включениеАпрель 2026AES-SHA1 становится стандартом по умолчанию, RC4-фоллбэк отключается автоматически
Фаза 3 — Полное отключениеИюль 2026Режим аудита удалён, ключ реестра игнорируется, работает только AES

После июля 2026 года откат к RC4 станет невозможен через стандартные средства. Поэтому настоятельно рекомендую провести аудит и миграцию до апреля — когда начнётся принудительное применение. Честно говоря, лучше не тянуть до последнего момента.

Шаг 1: Аудит использования RC4 в вашем домене

Включение расширенного аудита Kerberos

Первым делом нужно понять, где в вашей среде ещё используется RC4. С обновлениями января 2026-го Microsoft расширила события Event ID 4768 (запрос TGT) и Event ID 4769 (запрос сервисного билета) новыми полями:

  • Ticket Encryption Type — тип шифрования билета
  • Session Encryption Type — тип шифрования сессии
  • msDS-SupportedEncryptionTypes — поддерживаемые типы шифрования учётной записи
  • Available Keys — доступные ключи шифрования

Значение 0x17 в полях Ticket или Session Encryption Type означает использование RC4-HMAC. Именно его мы и ищем.

Быстрая проверка через Event Viewer

На контроллере домена откройте Event Viewer → Windows Logs → Security и отфильтруйте по Event ID 4768. Ищите записи, где Ticket Encryption Type содержит 0x17:

# PowerShell: поиск RC4-билетов в журнале безопасности
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4768
} -MaxEvents 500 | Where-Object {
    $_.Message -match '0x17'
} | Select-Object TimeCreated,
    @{N='Account';E={($_.Properties[0]).Value}},
    @{N='ClientIP';E={($_.Properties[9]).Value}} |
    Format-Table -AutoSize

Автоматизированный аудит скриптами Microsoft

Microsoft выложила два PowerShell-скрипта в репозитории Kerberos-Crypto на GitHub:

  • List-AccountKeys.ps1 — перечисляет доступные ключи шифрования для учётных записей
  • Get-KerbEncryptionUsage.ps1 — анализирует типы шифрования Kerberos с фильтрацией по RC4

Запустите их на каждом контроллере домена:

# Загрузка и запуск скриптов аудита
# Требуется модуль ActiveDirectory
Import-Module ActiveDirectory

# Поиск всех учётных записей с RC4 без AES-ключей
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object {
        $_."msDS-SupportedEncryptionTypes" -eq 0 -or
        $_."msDS-SupportedEncryptionTypes" -eq $null
    } | Select-Object SamAccountName, DistinguishedName |
    Export-Csv -Path "C:\Audit\Accounts_Without_AES.csv" -NoTypeInformation

# Поиск сервисных учётных записей с SPN и RC4
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes |
    Where-Object {
        $_."msDS-SupportedEncryptionTypes" -band 4 -and
        -not ($_."msDS-SupportedEncryptionTypes" -band 24)
    } | Select-Object SamAccountName, ServicePrincipalName,
        @{N='EncTypes';E={$_."msDS-SupportedEncryptionTypes"}} |
    Format-Table -AutoSize

Аудит компьютерных учётных записей

Не забудьте про компьютерные учётные записи. Старые машины на Windows Server 2003 или Windows XP не поддерживают AES (да, такие ещё встречаются в продакшене — видел не раз):

# Поиск устаревших компьютерных учётных записей
Get-ADComputer -Filter * -Properties OperatingSystem, msDS-SupportedEncryptionTypes |
    Where-Object {
        $_.OperatingSystem -match '2003|XP|2000' -or
        $_."msDS-SupportedEncryptionTypes" -eq $null
    } | Select-Object Name, OperatingSystem,
        @{N='EncTypes';E={$_."msDS-SupportedEncryptionTypes"}} |
    Export-Csv -Path "C:\Audit\Legacy_Computers.csv" -NoTypeInformation

Шаг 2: Обновление атрибута msDS-SupportedEncryptionTypes

Для каждой учётной записи, которая ещё сидит на RC4, нужно явно прописать поддержку AES через атрибут msDS-SupportedEncryptionTypes. Вот таблица значений битовой маски:

ЗначениеШифрованиеОписание
0x4RC4-HMACУстаревшее, небезопасное
0x8AES128-CTS-HMAC-SHA1-96Современное
0x10AES256-CTS-HMAC-SHA1-96Современное, рекомендуется
0x18 (24)AES128 + AES256Рекомендуемое значение
0x1C (28)RC4 + AES128 + AES256Переходный период

Массовое обновление учётных записей через PowerShell

# Обновление всех пользователей без явного типа шифрования
# Значение 24 = AES128 + AES256 (без RC4)
Get-ADUser -Filter {msDS-SupportedEncryptionTypes -notlike "*"} |
    Set-ADUser -Replace @{"msDS-SupportedEncryptionTypes" = 24}

# Обновление сервисных учётных записей (безопасный вариант с предпросмотром)
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName, msDS-SupportedEncryptionTypes |
    ForEach-Object {
        Write-Host "Обновление: $($_.SamAccountName) — SPN: $($_.ServicePrincipalName)" -ForegroundColor Yellow
        # Раскомментируйте строку ниже после проверки:
        # Set-ADUser -Identity $_ -Replace @{"msDS-SupportedEncryptionTypes" = 24}
    }

Обязательный сброс паролей

Вот тут внимание — это критически важный момент, который многие пропускают. После обновления атрибута msDS-SupportedEncryptionTypes необходимо сбросить пароль каждой затронутой учётной записи. Почему? Потому что AES-ключи Kerberos генерируются только при смене пароля. Без сброса учётная запись не получит AES-ключи, даже если атрибут формально указывает на поддержку AES.

# Сброс пароля сервисной учётной записи
Set-ADAccountPassword -Identity "svc_sqlserver" -Reset -NewPassword (
    Read-Host "Введите новый пароль" -AsSecureString
)

# Для управляемых учётных записей (gMSA) — пароль управляется автоматически
# Достаточно убедиться, что атрибут msDS-SupportedEncryptionTypes установлен

Шаг 3: Настройка групповой политики (GPO)

Для централизованного управления типами шифрования Kerberos удобнее всего использовать GPO:

  1. Откройте Group Policy Management Console
  2. Создайте или отредактируйте GPO, привязанный к OU с контроллерами домена
  3. Перейдите в Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options
  4. Найдите параметр Network security: Configure encryption types allowed for Kerberos
  5. Установите флажки только для AES128_HMAC_SHA1 и AES256_HMAC_SHA1

Важный нюанс: в переходный период (пока не завершён полный аудит) можно временно оставить RC4 включённым вместе с AES. Снимайте флажок RC4 только после того, как убедитесь, что все учётные записи и устройства поддерживают AES. Иначе рискуете получить массовые блокировки в самый неподходящий момент.

# Проверка применённой политики на контроллере домена
gpresult /r /scope:computer | findstr /i "kerberos"

# Принудительное обновление GPO
gpupdate /force

Шаг 4: Обработка особых случаев

Linux и Unix-системы

Отдельная головная боль — Linux-клиенты, интегрированные с Active Directory. Они часто используют keytab-файлы с RC4. Для миграции:

# На Linux-машине: проверка текущего keytab
klist -kte /etc/krb5.keytab

# Если в списке только arcfour-hmac (RC4), нужно пересоздать keytab
# Пример для SSSD/Samba:
net ads keytab create -U administrator

# Или вручную через ktutil:
ktutil
addent -password -p HTTP/[email protected] -k 1 -e aes256-cts-hmac-sha1-96
wkt /etc/krb5.keytab
quit

NAS-устройства и сетевые аплайансы

Многие NAS-устройства (Synology, QNAP) и сетевые аплайансы по умолчанию используют RC4 для Kerberos-аутентификации в домене. Тут совет простой: проверьте документацию производителя на поддержку AES и обновите прошивку до актуальной версии. Не откладывайте — в некоторых случаях обновление прошивки требует перезагрузку, а это нужно планировать заранее.

Доверительные отношения между доменами (Forest Trusts)

Ещё один момент, о котором легко забыть: межлесные доверительные отношения по умолчанию поддерживают только RC4. Для включения AES:

# Проверка текущих типов шифрования для доверия
Get-ADTrust -Filter * -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, Direction,
        @{N='EncTypes';E={$_."msDS-SupportedEncryptionTypes"}}

# Включение AES для доверительного отношения
Set-ADTrust -Identity "trusted.domain.local" `
    -Replace @{"msDS-SupportedEncryptionTypes" = 24}

Устаревшие системы Windows Server 2003 / XP

Эти системы не поддерживают AES. Тут вариантов немного:

  • Вывести из эксплуатации (лучший вариант, если возможно)
  • Изолировать в отдельный VLAN с минимальным доступом
  • Перенести рабочие нагрузки на современные ОС

Шаг 5: Принудительное отключение RC4 и валидация

Настройка реестра контроллера домена

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

# Установка AES-only на контроллере домена
# Значение 0x18 = только AES128 + AES256
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\KDC" `
    -Name "DefaultDomainSupportedEncTypes" `
    -Value 0x18 -Type DWord

# Для полного набора AES (включая AES-SHA2):
# Значение 0x38 = AES128 + AES256 + AES-SHA2
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\KDC" `
    -Name "DefaultDomainSupportedEncTypes" `
    -Value 0x38 -Type DWord

# Перезапуск службы KDC
Restart-Service -Name "KDC" -Force

Очистка кешированных билетов Kerberos

После применения изменений клиенты могут какое-то время использовать старые кешированные билеты с RC4. Обновите их принудительно:

# На клиентских машинах Windows:
klist purge

# На серверах — очистка всех сессий:
klist -li 0x3e7 purge

Мониторинг после миграции

После отключения RC4 не расслабляйтесь — продолжайте мониторить события 4768 и 4769. Все записи должны показывать типы шифрования 0x11 (AES128) или 0x12 (AES256). Если вдруг появляются ошибки аутентификации — смотрите Event ID 4771 (ошибка предварительной аутентификации Kerberos).

# Мониторинг ошибок Kerberos после миграции
Get-WinEvent -FilterHashtable @{
    LogName = 'Security'
    Id      = 4771
} -MaxEvents 100 | Select-Object TimeCreated,
    @{N='Account';E={($_.Properties[0]).Value}},
    @{N='ErrorCode';E={($_.Properties[4]).Value}},
    @{N='ClientIP';E={($_.Properties[6]).Value}} |
    Format-Table -AutoSize

Шаг 6: Защита от CVE-2026-25177 (повышение привилегий в AD DS)

Параллельно с миграцией RC4 → AES стоит закрыть ещё одну дыру — CVE-2026-25177, выпущенную в мартовском Patch Tuesday 2026. Эта уязвимость с рейтингом CVSS 8.8 позволяет аутентифицированному злоумышленнику получить привилегии уровня SYSTEM через создание дублирующих SPN/UPN с помощью Unicode-символов. Серьёзная штука.

Действия по устранению

  1. Установите мартовские обновления 2026 на все контроллеры домена через WSUS или Windows Update
  2. Проведите аудит SPN на предмет дубликатов:
# Поиск дублирующих SPN в домене
setspn -X

# Расширенный поиск через PowerShell
$spns = Get-ADObject -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName
$allSPNs = $spns | ForEach-Object { $_.ServicePrincipalName } | Sort-Object
$duplicates = $allSPNs | Group-Object | Where-Object { $_.Count -gt 1 }
$duplicates | ForEach-Object {
    Write-Host "Дубликат SPN: $($_.Name) — количество: $($_.Count)" -ForegroundColor Red
}
  1. Настройте мониторинг событий Kerberos (Event ID 4768, 4769, 4771) в SIEM-системе для обнаружения попыток эксплуатации
  2. Примените принцип минимальных привилегий ко всем сервисным учётным записям — это базовая гигиена, которая поможет не только с этой CVE

Чек-лист миграции: от аудита до полного отключения RC4

Чтобы ничего не упустить, держите этот чек-лист под рукой:

  1. ☐ Установлены обновления Windows от января 2026 года на всех контроллерах домена
  2. ☐ Включён аудит событий 4768/4769 с расширенными полями шифрования
  3. ☐ Запущены скрипты List-AccountKeys.ps1 и Get-KerbEncryptionUsage.ps1
  4. ☐ Выявлены все учётные записи с msDS-SupportedEncryptionTypes = 0 или null
  5. ☐ Обновлён атрибут msDS-SupportedEncryptionTypes до значения 24 (AES128+AES256)
  6. ☐ Сброшены пароли всех затронутых сервисных учётных записей
  7. ☐ Обновлены keytab-файлы для Linux/Unix-систем
  8. ☐ Проверены доверительные отношения между доменами/лесами
  9. ☐ Обновлены NAS-устройства и сетевые аплайансы
  10. ☐ Выведены из эксплуатации или изолированы системы Windows Server 2003/XP
  11. ☐ Настроена GPO с разрешением только AES-шифрования
  12. ☐ Установлено значение реестра DefaultDomainSupportedEncTypes = 0x18
  13. ☐ Установлены мартовские обновления 2026 (CVE-2026-25177)
  14. ☐ Настроены SIEM-алерты для мониторинга оставшегося RC4-трафика

Часто задаваемые вопросы

Что произойдёт, если не мигрировать с RC4 до июля 2026?

Всё просто: после июльских обновлений Windows RC4 будет полностью отключён на контроллерах домена без возможности отката. Все учётные записи, устройства и приложения, которые зависят от RC4 для Kerberos-аутентификации, перестанут аутентифицироваться. Это может обернуться массовыми сбоями входа в домен, отказом сервисов и недоступностью сетевых ресурсов. Не самый приятный сценарий, правда?

Как узнать, использует ли моя среда RC4?

Установите январские обновления 2026 на контроллерах домена — они добавляют расширенные поля в события аудита 4768 и 4769. Ищите значение 0x17 в полях Ticket Encryption Type и Session Encryption Type. Также запустите PowerShell-скрипты List-AccountKeys.ps1 и Get-KerbEncryptionUsage.ps1 из репозитория Microsoft Kerberos-Crypto на GitHub — они автоматизируют большую часть работы.

Сломается ли аутентификация Linux-машин после отключения RC4?

Да, если Linux-машины используют keytab-файлы, содержащие только RC4-ключи (arcfour-hmac). Решение: пересоздайте keytab-файлы с AES-ключами командой net ads keytab create или ktutil и убедитесь, что конфигурация /etc/krb5.conf разрешает шифрование AES256 и AES128.

Нужно ли сбрасывать пароли после обновления msDS-SupportedEncryptionTypes?

Да, и это обязательный шаг — не пропускайте его. AES-ключи Kerberos генерируются исключительно при смене пароля учётной записи. Если обновить атрибут msDS-SupportedEncryptionTypes, но не сбросить пароль, AES-ключи не создадутся, и учётка продолжит использовать RC4. Для gMSA (управляемых учётных записей) пароль ротируется автоматически — тут можно не беспокоиться.

Как проверить, что миграция на AES прошла успешно?

Мониторьте события 4768 и 4769 в журнале безопасности контроллеров домена. Все записи должны показывать типы шифрования 0x11 (AES128) или 0x12 (AES256). Если значений 0x17 (RC4) больше нет — миграция завершена успешно. Для финальной проверки запустите Get-KerbEncryptionUsage.ps1.

Об авторе Editorial Team

Our team of expert writers and editors.