Сбой доверия домена после установки Windows 11 KB5124008 оставил часть корпоративных машин без нормального входа в Active Directory: пользователи вводят правильные доменные учётные данные, а система отвечает ошибкой доверительных отношений или сообщает о неверном логине и пароле. Для русскоязычных IT-команд это не абстрактная неприятность из чужого парка, а типичный ночной сценарий для админов: патч безопасности поставили, рабочие станции перезагрузили, утром helpdesk уже принимает заявки.
Microsoft расследует жалобы на проблему, сообщает BleepingComputer. Компания подтвердила изданию, что знает о сообщениях администраторов и обещает опубликовать рекомендации, когда они появятся. Официальной причины и официального обходного решения пока нет.
Судя по жалобам на Reddit и в Microsoft Q&A, проблема проявляется на некоторых системах Windows 11 25H2 после установки обновления безопасности KB5124008 и последующей перезагрузки. Машины теряют защищённый канал с Active Directory. В нормальном режиме доменный компьютер хранит учётные данные машинной записи и через них поддерживает доверительные отношения с контроллерами домена. Если локальный секрет машины больше не совпадает с тем, что ожидает Active Directory, доменная аутентификация разваливается. Пользователь при этом может быть ни в чём не виноват: пароль правильный, учётная запись жива, но вход через домен не проходит.
Один из администраторов, Алекс Тёрнер, описал в Microsoft Q&A воспроизводимый сценарий: рабочие станции Windows 11 25H2 работали штатно до установки KB5124008, а после обновления и перезагрузки начали отказывать в доменном входе. Кэшированные учётные данные продолжали работать в офлайн-режиме, что указывало не на пользовательские пароли, а именно на проблему с доменной аутентификацией. По его словам, удаление KB5124008 и восстановление доверительных отношений возвращали доступ, но повторная установка обновления снова приводила к сбою.
Масштаб пока выглядит неровным. Один администратор на Reddit сообщил о 11 пострадавших устройствах Windows 11 25H2 Enterprise примерно из 256. Он также увидел множество ошибок Kerberos, после которых системы переходили к NTLM и Netlogon. Другой участник обсуждения заявил, что после установки обновлений все рабочие станции Windows 11 25H2 в его сети начали отвергать корректные доменные учётные данные. Это важная деталь для инфраструктурных команд: проблема может выглядеть как локальная поломка нескольких ноутбуков, а может внезапно превратиться в инцидент на весь парк, если совпадут настройки безопасности.
Главный подозреваемый в обсуждениях администраторов — параметр Windows Machine Identity Isolation. Он относится к конфигурации Virtualization-Based Security и Credential Guard и отвечает за изоляцию машинных учётных данных, с помощью которых доменные компьютеры аутентифицируются в Active Directory. Тёрнер связал отказы с тем, что после установки KB5124008 значение MachineIdentityIsolation оказалось равным 2, то есть режиму enforcement. Другой администратор увидел похожее поведение и сообщил, что отключение этой функции остановило удаление машинного секрета из LSA без удаления самого обновления.
Но здесь начинается неприятная часть. В enforcement-режиме Windows переносит секрет машинной учётной записи в Credential Guard и удаляет копию из LSA. Некоторые администраторы восстанавливали системы, выставляя MachineIdentityIsolation в 0, перезагружая компьютер и затем чиня защищённый канал командой PowerShell Test-ComputerSecureChannel -Repair с доменными учётными данными администратора. Один из участников обсуждения, Марсель Цендер, написал, что после такого восстановления компьютер больше не терял защищённый канал. Звучит как рабочий рецепт, но Microsoft пока его не утвердила.
Более того, отключение Machine Identity Isolation само по себе может сломать доменную аутентификацию. Один администратор предупредил, что перевод параметра из audit или enforcement в disabled вызвал сбой доверия домена в его среде, включая машины, на которых KB5124008 вообще не ставили. Документация Microsoft тоже предупреждает: если Machine Identity Isolation уже работала в enforcement-режиме, отключение может потребовать вывода устройства из домена и повторного присоединения. Для крупной сети это уже не «поменять ключ реестра», а полноценная операция с риском простоя, очередью в поддержку и недовольными пользователями.
Для бизнеса вывод простой и скучный, как обычно у инфраструктурных инцидентов: не раскатывать KB5124008 на весь парк без пилотной группы, особенно если включены Credential Guard, VBS и политики, связанные с Machine Identity Isolation. Разработчикам и продуктовым командам эта история тоже полезна: когда корпоративная ОС усиливает защиту идентичности машины, старые допущения о «просто доменном входе» перестают быть бесплатными. Пока Microsoft не назвала корневую причину, самый разумный прогноз такой: ближайшие дни админы будут сверять политики, журналы Kerberos и Netlogon, а Microsoft — искать способ закрыть дыру так, чтобы не вырубить вход в домен тем, кто патчи ставит вовремя.