Windows blokuje poświadczenia NTLMv1 SSO: firmowe Wi-Fi i VPN mogą przestać działać
Październikowa aktualizacja Windows domyślnie wymusza BlockNtlmv1SSO. Wyjaśniamy wpływ na PEAP-MSCHAPv2, Wi-Fi, Ethernet i VPN oraz bezpieczny plan migracji.
- AUTOR
- Karol Rapacz / CEO Breachroad · OSCP · PNPT
- PUBLIKACJA
- 24 października 2026
- CZAS CZYTANIA
- 10 min czytania
- TEMAT
- Tożsamość i dostęp
Aktualizacje zabezpieczeń Windows wydane 13 października 2026 roku zmieniły domyślne zachowanie BlockNtlmv1SSO z trybu audytu na wymuszanie. Na kwalifikujących się urządzeniach Windows blokuje teraz generowanie poświadczeń opartych na kryptografii NTLMv1 dla logowania jednokrotnego. W firmach nadal korzystających z PEAP-MSCHAPv2 lub EAP-MSCHAPv2 może to przerwać automatyczne łączenie z siecią Wi-Fi, przewodowym 802.1X albo VPN.
Microsoft podkreśla, że to zaplanowane wzmocnienie, a nie znany błąd aktualizacji. Zmiana dotyczy urządzeń z wyłączonym Credential Guard, gdy wartość rejestru BlockNtlmv1SSO nie została wcześniej jawnie ustawiona. Obejmuje Windows 11 w wersjach 24H2, 25H2, 26H1 i 26H2 oraz Windows Server 2025.
Wniosek Breachroad: problem z łącznością może być pierwszym widocznym dowodem długo ukrytej zależności od starego mechanizmu uwierzytelniania. Powrót do trybu Audit może dać czas, lecz celem powinno być przejście na uwierzytelnianie certyfikatowe, a nie trwałe cofnięcie kontroli.
Co zmieniła aktualizacja
Od sierpnia 2025 roku Windows potrafił rejestrować próby użycia poświadczeń pochodnych NTLMv1. Gdy BlockNtlmv1SSO nie był skonfigurowany, domyślnie działał tryb Audit: system dopuszczał żądanie i zapisywał ostrzeżenie.
Po październikowej aktualizacji brak jawnej wartości oznacza wewnętrznie tryb Enforce. System blokuje żądanie i zapisuje błąd. Aktualizacja nie tworzy ani nie modyfikuje samej wartości rejestru, dlatego administrator może błędnie uznać, że zachowanie nie powinno się zmienić.
Microsoft usunął protokół NTLMv1 z nowych wersji Windows, ale pozostałości jego kryptografii występują w scenariuszach MS-CHAPv2. W środowisku domenowym mogą służyć do automatycznego przekazania bieżącej tożsamości użytkownika do firmowej sieci.
Kiedy użytkownik odczuje problem
Typowy scenariusz wygląda następująco: laptop po instalacji aktualizacji nie łączy się automatycznie z firmowym Wi-Fi, choć prywatna sieć domowa działa. Podobny efekt może pojawić się w przewodowym 802.1X lub VPN. Ręczne wpisanie poświadczeń może działać, ale zapisywanie ich do późniejszego automatycznego użycia nie rozwiązuje przyczyny.
Najbardziej narażone są organizacje, które:
- używają PEAP-MSCHAPv2 lub EAP-MSCHAPv2 w profilach sieciowych;
- mają urządzenia przyłączone do domeny i korzystają z SSO do sieci;
- nie włączyły Credential Guard;
- nie ustawiły wcześniej
BlockNtlmv1SSOprzez GPO, Intune albo inną platformę; - nie analizowały ostrzeżeń zbieranych od sierpnia 2025 roku.
Zmiana nie oznacza awarii sterownika Wi-Fi. Jeśli użytkownicy zgłaszają problem po aktualizacji, zespół powinien sprawdzić uwierzytelnianie i log NTLM przed reinstalacją sterowników albo wycofaniem całej poprawki bezpieczeństwa.
Jak potwierdzić przyczynę
Microsoft wskazuje dziennik Microsoft-Windows-NTLM/Operational. W trybie Audit zdarzenie 4024 oznacza, że próba użycia poświadczeń NTLMv1 SSO została dopuszczona i zarejestrowana. W trybie Enforce zdarzenie 4025 oznacza jej zablokowanie przez politykę.
Log zawiera między innymi serwer docelowy, użytkownika, domenę, proces klienta i identyfikator procesu. To pozwala odróżnić problem zależności uwierzytelniania od ogólnej awarii karty sieciowej.
Nie analizuj wyłącznie jednego laptopa. Zbierz zdarzenia centralnie i połącz je z wersją systemu, statusem Credential Guard, profilem Wi-Fi/VPN i lokalizacją użytkownika. Brak zdarzenia 4025 może oznaczać inną przyczynę, a nie dowód, że cała organizacja jest wolna od zależności.
Tymczasowy powrót do Audit — kiedy ma sens
Jawne ustawienie BlockNtlmv1SSO na 0 w ścieżce HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 przywraca Audit: żądania są dozwolone i generują 4024. Zmiana nie wymaga restartu. Ustawienie na 1 wymusza blokowanie i generuje 4025.
Audit może być kontrolowanym wyjątkiem dla grupy urządzeń, gdy brak sieci uniemożliwia działalność, a migracja wymaga przygotowania certyfikatów i profili. Nie powinien stać się globalną, bezterminową odpowiedzią. Wyjątek musi mieć:
- udokumentowany zakres urządzeń i usług;
- właściciela ryzyka oraz termin zakończenia;
- monitoring zdarzeń 4024;
- plan migracji i test powrotu do Enforce;
- kontrolę, aby ustawienie nie rozprzestrzeniło się na urządzenia, które go nie potrzebują.
Wycofanie całej aktualizacji usuwa również inne poprawki bezpieczeństwa i zwykle jest gorszym wyborem niż precyzyjny, czasowy wyjątek.
Docelowa migracja na uwierzytelnianie certyfikatowe
Microsoft rekomenduje odejście od MS-CHAPv2 na rzecz metod opartych na certyfikatach, takich jak EAP-TLS lub PEAP-TLS. Taka zmiana jest projektem tożsamości, sieci i zarządzania urządzeniami, nie prostą zamianą pola w profilu.
Firma powinna zaplanować:
- inwentaryzację kontrolerów, RADIUS/NPS, profili Wi-Fi, LAN i VPN;
- źródło zaufania, wydawanie, odnawianie i odwoływanie certyfikatów;
- dystrybucję certyfikatów do urządzeń zarządzanych i scenariusz BYOD;
- mapowanie certyfikatu na tożsamość oraz reakcję po odejściu pracownika;
- pilotaż na reprezentatywnych urządzeniach i lokalizacjach;
- równoległy okres przejściowy z mierzalnym spadkiem zdarzeń 4024;
- ponowne włączenie Enforce i test negatywny starego profilu.
Szczególną uwagę trzeba poświęcić urządzeniom współdzielonym, terminalom, skanerom, drukarkom i systemom, których nie da się łatwo objąć nowoczesnym MDM.
Komunikacja z ludźmi ma znaczenie
Jeżeli aktualizacja blokuje dostęp do sieci, użytkownik widzi tylko „Wi-Fi nie działa”. Helpdesk potrzebuje krótkiego scenariusza: jakie urządzenie i wersja systemu, jaka sieć, czy logowanie ręczne działa, czy występuje 4025 i do którego zespołu eskalować.
Nie instruuj pracowników, aby obchodzili problem przez prywatny hotspot bez oceny ryzyka. Dla części organizacji może to być zatwierdzony kanał awaryjny, ale powinien mieć reguły dotyczące urządzenia, VPN, danych i czasu użycia.
Fakty źródłowe i wnioski Breachroad
Microsoft potwierdza zmianę domyślną po aktualizacjach od 13 października 2026 roku, zakres wersji Windows, warunki dotyczące Credential Guard i braku wartości rejestru, wpływ na MS-CHAPv2 oraz identyfikatory zdarzeń 4024 i 4025. Producent rekomenduje migrację do uwierzytelniania certyfikatowego.
Zakres wyjątku, centralne mierniki, plan projektu i procedura helpdesku są rekomendacjami Breachroad. Powiąż je z bezpieczeństwem Active Directory i oceną ryzyka NTLM relay. Zmianę warto przećwiczyć z IT, helpdeskiem i właścicielami usług podczas szkoleń cyberbezpieczeństwa dla organizacji, a stan starszego uwierzytelniania zweryfikować przez audyt bezpieczeństwa IT.
Źródła pierwotne: Microsoft Support — zarządzanie zmianami NTLMv1, Microsoft — Bracing for BlockNtlmv1SSO.


