Ужесточение NTLMv1 SSO с октября 2026: ищем PEAP-MSCHAPv2 в Wi-Fi и VPN, пока сотрудники не остались без сети

Сломается не весь NTLM, а только автоматический вход (SSO) в Wi-Fi, Ethernet и VPN через MS-CHAPv2 на Windows 11 24H2 и новее и Windows Server 2025 без Credential Guard. Найти такие подключения можно по событиям 4024 и 4025 журнала NTLM/Operational. Ниже: как это сделать, что чинить в первую очередь и как не оставить людей без сети.

Что именно меняется в октябре 2026 и при чём тут MS-CHAPv2

Начну с главной путаницы, из-за которой мне звонят уже вторую неделю. Это не «Microsoft отключила NTLM». Это узкое изменение: Windows перестаёт по умолчанию выдавать производные от NTLMv1 учётные данные для единого входа (SSO) в сценариях на базе MS-CHAPv2. Если вы работаете с доменом и групповыми политиками, а Wi-Fi и VPN в вашей компании живут на PEAP-MSCHAPv2 или EAP-MSCHAPv2, то это именно ваша история. Сначала стоит понять, что вообще происходит с аутентификацией в Active Directory, а уже потом лечить симптомы.

Что говорит бюллетень Microsoft KB5066470. Затронуты Windows 11 версий 24H2, 25H2 и 26H2 и Windows Server 2025. Параметр лежит в реестре: ветка HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\msv1_0, значение BlockNtlmv1SSO типа REG_DWORD. Значение 0 — режим аудита: запрос разрешён, в журнал пишется предупреждение. Значение 1 — режим блокировки: запрос блокируется, в журнал пишется ошибка. Перезагрузка для смены значения не нужна.

Дата, ради которой все и нервничают, — 13 октября 2026 года. До обновления отсутствующее значение BlockNtlmv1SSO означало аудит (0). После обновления отсутствующее значение означает блокировку (1). Само обновление значение не создаёт и не меняет, оно так и остаётся пустым. Бюллетень называет обновления KB5127648 для Windows 11 и KB5126646 для Windows Server 2025, вышедшие 13 октября 2026 года, и отдельно напоминает, что Microsoft раскатывает выпуски постепенно, поэтому разные машины получат обновление в разное время. Сегодня 17 октября, так что у части ваших компьютеров переключение, скорее всего, уже случилось. Номер KB сверяйте с тем, что реально установлено у вас: на машинах с более поздним накопительным обновлением изменение тоже есть.

Теперь о том, чего это изменение не делает, потому что именно здесь живёт больше всего мифов. Ручной ввод логина и пароля продолжает работать: блокируется только SSO, то есть автоматическая подстановка учётных данных текущего пользователя. Протокол NTLM целиком не отключается, файловые шары, принтеры и 1С по NTLM продолжают ходить так же, как ходили. Если у вас есть вопрос про тотальный отказ от NTLM в домене, это отдельная большая работа, и я разбирал её в статье про переход с NTLM на Kerberos. Здесь же речь о двух вещах: Wi-Fi и VPN.

• Затронуто: SSO по MS-CHAPv2 (PEAP-MSCHAPv2, EAP-MSCHAPv2) для Wi-Fi, Ethernet и VPN
• Не затронуто: ручной ввод пароля, остальные сценарии NTLM, устройства с включённым Credential Guard
• Параметр: BlockNtlmv1SSO, REG_DWORD, 0 — аудит, 1 — блокировка, перезагрузка не нужна
• Дата: обновление от 13 октября 2026 (KB5127648 / KB5126646) включает блокировку, если значение в реестре не задано явно

Кого заденет: при чём тут Credential Guard и почему часть машин «уже сломана»

Изменение работает только на устройствах, где Credential Guard отключён. Это важная деталь, и она ломает логику «у нас же всё новое». Начиная с Windows 11 22H2 и Windows Server 2025 Credential Guard включается по умолчанию на машинах в домене (кроме контроллеров домена), которые отвечают требованиям, если администратор явно его не отключал. Но «отвечают требованиям» — это прежде всего лицензия: Enterprise (E3/E5) или Education, а на обычной Windows 11 Pro функция по умолчанию не включается (исключение — машины, где она уже работала до понижения редакции). Плюс аппаратная часть: поддержка безопасности на основе виртуализации (VBS). В офисах на 30 рабочих мест парк почти всегда на Pro, так что Credential Guard там выключен молча — и именно эти машины попадают под октябрьское изменение.

Тут есть ирония, которую я не могу не отметить: Credential Guard и раньше блокировал NTLMv1 SSO, просто никто не смотрел. Документация Microsoft прямо перечисляет, что при включённом Credential Guard SSO через MS-CHAP, WDigest и NTLMv1 блокируется, а вручную вводить пароль всё ещё можно. Поэтому «у меня на ноутбуках Wi-Fi каждое утро просит пароль после обновления до 24H2» — это часто Credential Guard, а не октябрьское ужесточение. Различать эти два случая надо по журналу: события 4013 и 4014 говорят о Credential Guard, события 4024 и 4025 — о новом механизме.

Сводка по сценариям, которую я показываю на планёрках, выглядит так: | Ситуация | Что происходит с SSO | Что видно в журнале | |---|---|---| | Credential Guard включён | SSO по NTLMv1/MS-CHAP блокируется давно | 4013 (предупреждение), 4014 (ошибка) | | Credential Guard выключен, BlockNtlmv1SSO = 0 | SSO работает, запрос аудируется | 4024 (предупреждение) | | Credential Guard выключен, значение не задано, обновление не стоит | аудит, как при 0 | 4024 | | Credential Guard выключен, значение не задано, обновление стоит | SSO блокируется, ручной ввод работает | 4025 (ошибка) | | Credential Guard выключен, BlockNtlmv1SSO = 1 | SSO блокируется | 4025 |

Проверять, работает ли Credential Guard на конкретной машине, надо не по диспетчеру задач (Microsoft прямо пишет, что наличие процесса LsaIso.exe — ненадёжный признак), а штатными средствами. Подходит msinfo32.exe: в разделе «Сведения о системе» строка «Службы безопасности на основе виртуализации: выполняются» должна содержать Credential Guard. Для парка удобнее PowerShell из сеанса с повышенными правами:

(Get-CimInstance -ClassName Win32_DeviceGuard -Namespace root\Microsoft\Windows\DeviceGuard).SecurityServicesRunning

По документации 1 в выводе означает, что Credential Guard работает, а 0 — что нет (если запущено несколько служб VBS, команда вернёт список чисел, и ищите в нём единицу). Это важно для приоритетов: машины, где он уже включён, этим обновлением не затрагиваются, и тратить на них время в первую очередь не нужно.

Как найти подключения, которые сломаются: события 4024 и 4025

Это самый «больной» раздел, потому что искать приходится не в конфигурации Wi-Fi, а в журналах. Снаружи всё выглядит одинаково: сотрудник подключается к корпоративной сети, и Windows молча подставляет его доменный пароль. Что при этом внутри использует MS-CHAPv2, видно только из профиля Wi-Fi или VPN, а кто и сколько раз к нему обращался — из журнала. Разработчики Microsoft дали именно такой инструмент: оба события пишутся в журнал Microsoft-Windows-NTLM/Operational с источником NTLM. В Просмотре событий это Журналы приложений и служб, Microsoft, Windows, NTLM, Operational.

Событие 4024 — предупреждение: запрос SSO на учётных данных, производных от NTLMv1, проаудирован, но разрешён. Событие 4025 — ошибка: тот же запрос заблокирован политикой. В обоих записываются целевой сервер, указанные пользователь и домен, данные клиентского процесса (идентификатор и имя процесса, LUID, учётная запись) и идентификатор механизма (OID). Именно по целевому серверу и пользователю вы поймёте, чей это Wi-Fi или VPN-шлюз, — угадывать не придётся.

Чтобы события 4024 вообще появились на машине, где обновление уже стоит, значение BlockNtlmv1SSO надо задать явно. Включить аудит можно без перезагрузки. На одном компьютере:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\msv1_0' -Name 'BlockNtlmv1SSO' -Type DWord -Value 0

На парке я рассылаю это через групповые политики (параметр реестра в предпочтениях групповой политики) на отдельную группу машин, а не на весь домен. Сразу предупреждаю: значение 0 — это не «выключить опасность навсегда», а временная мера. Сама Microsoft пишет, что такое исключение снижает защиту, должно быть ограниченным по охвату и по времени.

Дальше нужно собрать события со всех компьютеров. Для небольшого парка хватает обычного Get-WinEvent с фильтром по журналу и идентификаторам. Удалённый вызов через параметр -ComputerName не требует PowerShell Remoting, но на целевых машинах должен быть открыт порт службы журналов событий в брандмауэре:

$pcs = Get-Content .\pcs.txt
$since = (Get-Date).AddDays(-14)
$pcs | ForEach-Object {
  $pc = $_
  Get-WinEvent -ComputerName $pc -ErrorAction SilentlyContinue -FilterHashtable @{
    LogName   = 'Microsoft-Windows-NTLM/Operational'
    Id        = 4024, 4025
    StartTime = $since
  } | Select-Object @{n='PC';e={$pc}}, TimeCreated, Id, Message
} | Export-Csv .\ntlmv1-sso.csv -NoTypeInformation -Encoding UTF8

Файл pcs.txt — список имён компьютеров по одному в строке. Вместо -ErrorAction SilentlyContinue на первом проходе лучше смотреть ошибки: недоступная машина и машина без событий — это разные ответы, и путать их опасно. В CSV смотрите на текст события: целевой сервер сгруппирует всё по Wi-Fi-сети и VPN-шлюзу.

Теперь о подводных камнях выборки. Первое: журнал круговой и может быть небольшим, на активных ноутбуках события перетрутся раньше, чем вы их соберёте, — следите за размером. Второе: два-три дня аудита обманывают, потому что люди ходят в офис не каждый день и подключаются к VPN из дома по настроению. Я собираю минимум две недели, а при сезонных командировках — и месяц. Третье: единичное событие на одной машине не означает «всё хорошо» на остальных, там просто мог не быть пользователь. Для самых любопытных могу посоветовать изучить, как организована беспроводная сеть через RADIUS, — это поможет прочитать целевой сервер в событии осмысленно.

Нужна помощь с аудитом? Это делается за два дня

Если читать журналы на тридцати компьютерах вам некогда, а Wi-Fi и VPN нужны завтра, мы в «АйТи-Фреш» можем снять картину за вас: включим аудит на нужной группе машин, соберём события и вернём вам таблицу, кто и куда ходит по MS-CHAPv2. Это обычно два рабочих дня плюс срок накопления аудита.

Остальное в статье можно делать и без нас — просто знайте, что такая опция есть. Дальше разберу, чем именно заменять MS-CHAPv2 и в каком порядке двигаться.

Чем заменить MS-CHAPv2: сертификаты вместо паролей, а исключение — на время

Здесь у Microsoft позиция однозначная, и я с ней согласен. В документации по Credential Guard рекомендуется для Wi-Fi и VPN уходить от подключений на базе MS-CHAPv2 (PEAP-MSCHAPv2 и EAP-MSCHAPv2) к аутентификации на сертификатах — PEAP-TLS или EAP-TLS. Сертификатную аутентификацию Credential Guard не блокирует. То есть вы закрываете сразу две проблемы: октябрьскую блокировку SSO и тот факт, что MS-CHAPv2 сам по себе уязвим для тех же атак, что и NTLMv1.

Практический порядок у меня такой. Сначала ищем и классифицируем: сколько у вас сетей и шлюзов на MS-CHAPv2, какие устройства их используют, есть ли среди них не-Windows клиенты (телефоны, принтеры с Wi-Fi, старые точки доступа). Затем проверяем, на чём живёт RADIUS: если это сервер политики сети на Windows Server, то поддержка сертификатов у него есть, и переход описан в нашей статье про NPS и RADIUS для Wi-Fi. Потом выдаём сертификаты (внутренний центр сертификации, автоматическая выдача по групповой политике), переключаем профили на EAP-TLS и только после этого выключаем MS-CHAPv2 на RADIUS.

По VPN картина сложнее: у каждого шлюза своя модель аутентификации, и обещать универсальную инструкцию было бы нечестно. Если ваш VPN сегодня принимает логин и пароль от Active Directory через MS-CHAPv2, переход на сертификаты вам придётся планировать вместе с поставщиком шлюза, а выбор самого решения я подробно обсуждал в разборе VPN для удалённых сотрудников. Конкретные настройки для вашей модели шлюза проверяйте в его документации — единого рецепта здесь нет.

Пока сертификатов нет, на критичных компьютерах работает «костыль» — явное значение BlockNtlmv1SSO = 0. Бюллетень Microsoft описывает его как допустимое временное исключение для зависимостей, которые нельзя перенести сразу. Я делаю это адресно: через отдельную группу безопасности в групповой политике, с записью в тикете и датой, когда исключение снимается. Запомните: «временное» в офисах склонно становиться «навсегда», если дату не поставить.

Отдельный вопрос — включать ли Credential Guard на всём парке. Microsoft настоятельно рекомендует его включать там, где позволяет оборудование, потому что он закрывает гораздо больше поверхностей атаки, чем это обновление. Но обратите внимание на ловушку: включённый Credential Guard тоже ломает SSO по MS-CHAPv2, и отключать его «ради Wi-Fi» вы можете, но это уже осознанное ослабление защиты. Либо вы переходите на сертификаты и спокойно держите Credential Guard включённым, либо живёте в вечном компромиссе. Я выбираю первое.

• Wi-Fi: PEAP-MSCHAPv2 или EAP-MSCHAPv2 меняем на EAP-TLS (или PEAP-TLS) с сертификатами устройств или пользователей
• VPN: смотрим метод аутентификации шлюза, план перехода согласуем с документацией производителя
• Временное исключение: BlockNtlmv1SSO = 0 только для группы машин, с датой окончания
• Credential Guard: включаем там, где позволяет оборудование, после перехода на сертификаты

Кейс: бюро «АрхГрад», 32 рабочих места

Приведу случай из практики на условном примере. «АрхГрад» — архитектурное проектирование, 32 рабочих места: 26 ноутбуков на Windows 11 и 6 стационарных рабочих станций, из которых часть работает на Windows 11 24H2, остальные на 25H2. Корпоративная сеть Wi-Fi и VPN для выездных сотрудников были построены на PEAP-MSCHAPv2 с проверкой через NPS на одном сервере в виртуальной машине. Системный администратор в штате один, и о связи октябрьского изменения с Wi-Fi он узнал только когда я написал ему про него.

Мы включили аудит на всех 32 машинах через групповую политику (значение 0) и ждали двенадцать дней, с 8 по 19 сентября, — с запасом почти в месяц до октябрьского обновления. За это время события 4024 появились на 19 компьютерах из 32. Остальные 13 мы проверили отдельно: Credential Guard, как и ожидалось на редакции Pro, не работал ни на одной машине (команда на Win32_DeviceGuard вернула 0), значит, эти люди просто не подключались к корпоративному Wi-Fi и VPN в период аудита — их добавили в план перехода по умолчанию. Разбор целевых серверов в событиях показал две группы: корпоративный SSID и VPN-шлюз. Третьей группы, которую никто не ожидал, не оказалось, и это был хороший исход — иногда «находок» нет, и это нормально.

Дальше работы на шесть рабочих дней. Для сертификатов подняли внутренний центр сертификации, настроили автоматическую выдачу сертификатов компьютеров через групповую политику, переключили профиль корпоративного Wi-Fi на EAP-TLS и постепенно, по группам, вывели людей на новый профиль. С VPN сложнее: шлюз требовал отдельных настроек у производителя, и три ноутбука выездных сотрудников остались на временном исключении BlockNtlmv1SSO = 0 с датой снятия через месяц. Итог: сотрудники не остались без сети, ручной ввод пароля понадобился единицам в переходный период, а к моменту, когда обновление стало приходить на все машины, Wi-Fi в офисе уже работал на сертификатах.

Чего не делать: типовые ошибки перед октябрьским ужесточением

Первая ошибка — «отключим обновление, и всё останется как раньше». Я видел людей, которые на полном серьёзе откладывали накопительные обновления на квартал ради одного параметра. Это обмен одной проблемы на десятки: уязвимости, закрытые в обновлении, никуда не уйдут. Вторая ошибка — выставить BlockNtlmv1SSO = 0 глобально и забыть. Через год вы будете отвечать на вопрос аудитора, почему у вас везде разрешён протокол, который Microsoft сама решила закрыть.

Третья ошибка — считать, что проблема только в Wi-Fi. Бюллетень прямо называет Wi-Fi, Ethernet и VPN. Проводная сеть с проверкой 802.1X в офисах встречается реже, но если у вас порты коммутаторов настроены на проверку подлинности, в журнале появятся те же события. Четвёртая — смотреть только на ноутбуки. Стационарный компьютер, который подключается по Wi-Fi-адаптеру или по защищённому проводному порту, находится в зоне риска так же.

Пятая ошибка тоньше и касается чтения документации. Описанный механизм относится к устройствам с отключённым Credential Guard; бюллетень предупреждает, что поведение на устройствах с ним иное. Поэтому «у нас всё сломалось на 24H2» не обязательно означает «октябрьское обновление»: проверяйте номер события, а не только факт отказа. И последнее: обновление от 13 октября уже вышло, но Microsoft раскатывает выпуски постепенно. Не ждите, пока у всех сработает: машины, на которых значение не задано явно, переключатся тогда, когда до них дойдёт обновление, и вы не контролируете этот момент.

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