Ekim 2026 Windows Güncellemesi Sonrası 802.1X PEAP-MSCHAPv2 Kimlik Doğrulama Sorunu: BlockNtlmv1SSO Değişikliği ve Çözüm Yolları

Merhaba

13 Ekim 2026 tarihli Windows 11 güncellemesinden (KB5127648, OS Build 26100.9711, 26200.9711 ve 26300.9711) sonra, NPS (Network Policy Server) üzerinde PEAP-MSCHAPv2 (Protected Extensible Authentication Protocol, Microsoft Challenge Handshake Authentication Protocol version 2) kullanan kablolu ve kablosuz 802.1X (IEEE 802.1X, port tabanlı ağ erişim kontrolü) ağlarında bilgisayar kimlik doğrulaması başarısız olmaya başladı. Microsoft Q&A üzerindeki konuya kısa sürede 90’ın üzerinde kullanıcı aynı sorun bende de var diyerek katıldı.

Bu yazıda sorunun belirtilerini, büyük olasılıkla arkasında yatan BlockNtlmv1SSO değişikliğini, geçici çözümü ve kalıcı çözüm olan sertifika tabanlı kimlik doğrulamaya geçişi anlatıyoruz

Sorunun Özeti

Belirtiler ve Event Kayıtları

Microsoft Q&A konusunu açan yönetici, güncellemeden sonra Windows 11 istemcilerinin WPA2-Enterprise (802.1X/PEAP) kablosuz ağa bağlanamadığını bildirdi. Kimlik doğrulama başlıyor ama tamamlanmıyor. WPA2-Personal ağlar sorunsuz çalışıyor, kablosuz grup ilkesi uygulanmaya devam ediyor ve kablosuz profil yerinde duruyor. Sorun Intel ve Qualcomm gibi farklı Wi-Fi yonga setlerinde ve farklı donanım üreticilerinde tekrarlanıyor. Güncellemeyi kaldırıp yeniden başlatınca bağlantı geliyor, güncelleme tekrar kurulunca sorun geri dönüyor. Diğer yöneticiler aynı sorunun kablolu (Ethernet) 802.1X tarafında da yaşandığını, bilgisayar hesabıyla (machine authentication) yapılan alan adı kimlik doğrulamasının etkilendiğini bildirdi.

İki ayrıntı ipucu veriyor. Birincisi, Schannel sertifika doğrulama hatası görülmüyor, yani sorun sertifika zincirinde değil. İkincisi, kullanıcı hesabıyla yapılan bağlantıda Use my Windows user account kutusu işaretliyken kimlik doğrulama başarısız oluyor, kutu kaldırılıp kimlik bilgisi elle girildiğinde başarılı oluyor. Bu davranış, Microsoft’un NTLMv1 değişikliğini anlatan sayfasındaki SSO açıklamasıyla birebir uyuşuyor. Ayrıca bir kullanıcı, BlockNtlmv1SSO değerinin güncellemeden önce de sonra da tanımlı olmadığını bildirdi. Bu da sorunun varsayılan değerin değişmesinden kaynaklandığı görüşünü destekliyor.

BlockNtlmv1SSO Nedir?

Microsoft, NTLMv1 protokolünü Windows 11 24H2 ve Windows Server 2025 sürümlerinden kaldırdı. Ancak NTLMv1 kriptografisinin bazı kalıntıları, özellikle etki alanına (domain) katılmış ortamlarda MS-CHAPv2 kullanıldığında hala duruyor. Microsoft bu kalıntıyı kapatmak için NTLMv1 türevi kimlik bilgilerinin oturum açmış kullanıcı için üretilmesini engelleyen yeni bir registry değeri getirdi.

Microsoft bu tarihlerin tahmini olduğunu ve değişebileceğini belirtiyor. Önemli nokta şu: Enforce varsayılanı yalnızca değer daha önce dağıtılmamış cihazlarda devreye giriyor. Değeri kendimiz tanımladığımız cihazlarda bizim ayarımız geçerli kalıyor.

Neden PEAP-MSCHAPv2 Etkileniyor?

Burada sık yapılan bir karışıklığı netleştirmek gerekiyor. MS-CHAPv2 içindeki v2, bağlantının NTLMv2 kullandığı anlamına gelmiyor. PEAP-MSCHAPv2 yapılandırmasında PEAP bir TLS tüneli kurar, kullanıcı adı ve parola doğrulamasını ise tünelin içindeki MS-CHAPv2 yapar. SSO sırasında MS-CHAPv2, NTLMv1 türevi kimlik bilgilerine ihtiyaç duyabiliyor ve yeni kısıtlama tam olarak bu kimlik bilgisinin üretilmesini engelliyor.

Windows’un Kerberos’u tercih etmesi yalnızca Negotiate kullanan bağlantılar için geçerli. Kurumsal Wi-Fi veya Ethernet bağlantısında kullanılacak EAP yöntemini profil ve kimlik doğrulama sunucusu belirliyor. PEAP-MSCHAPv2 olarak yapılandırılmış bir bağlantıyı Windows kendiliğinden Kerberos’a veya NTLMv2’ye çevirmiyor. Microsoft’un Credential Guard’a benzettiği SSO davranışı da aynı: SSO akışı çalışmıyor, kimlik bilgisi elle girilirse bağlantı devam ediyor.

Doğrulama: NTLM Operational Logu

Çözüme geçmeden önce kesintinin gerçekten bu değişiklikten kaynaklandığını doğruluyoruz. Etkilenen Windows istemcide Event Viewer (Olay Görüntüleyicisi) içinde Applications and Services Logs > Microsoft > Windows > NTLM > Operational yolunu açıyoruz. Event ID 4025 görüyorsak SSO girişimi ilke nedeniyle engellenmiştir. Event ID 4024 ise aynı kullanımın Audit modunda kaydedildiğini, ama engellenmediğini gösterir. Kesinti zamanı ile log zamanını karşılaştırıyoruz.

Aynı kontrolü PowerShell ile de yapabiliriz.

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-NTLM/Operational'; Id=4024,4025} -MaxEvents 20 | Format-List TimeCreated, Id, Message

Değerin cihazda tanımlı olup olmadığına da bakıyoruz.

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" -Name BlockNtlmv1SSO -ErrorAction SilentlyContinue

Değer tanımlı değilse ve güncelleme yüklüyse, varsayılan Enforce davranışı geçerli demektir. NPS tarafında da Event ID 6272 (başarılı) ve 6273 (başarısız) kayıtlarına bakmak faydalı. İstek NPS’e hiç ulaşmıyorsa sorun istemci tarafındadır.

Geçici Çözüm: BlockNtlmv1SSO Değerini 0 Yapmak

Sorunun bu kısıtlamadan kaynaklandığını doğruladıktan sonra, etkilenen istemcide Command Prompt (Komut İstemi) uygulamasını Run as administrator (Yönetici olarak çalıştır) seçeneğiyle açıyoruz ve aşağıdaki komutu çalıştırıyoruz.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 0 /f

Aynı değeri regedit ile de oluşturabiliriz. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 anahtarına geliyoruz, New (Yeni) > DWORD (32-bit) Value (DWORD (32 bit) Değeri) ile BlockNtlmv1SSO adında bir değer oluşturuyoruz ve Data alanına 0 giriyoruz. Ardından bağlantıyı yeniden deniyoruz. Gerekirse bilgisayarı yeniden başlatıyoruz. Yaptığımız ilk testte NPS kimlik doğrulaması bu ayarla yeniden çalıştı.

Birden fazla cihaz varsa değeri GPO (Group Policy Object, Grup İlkesi Nesnesi) ile dağıtıyoruz. Group Policy Management Console (Grup İlkesi Yönetim Konsolu) içinde ilgili GPO’yu düzenleyip Computer Configuration (Bilgisayar Yapılandırması) > Preferences (Tercihler) > Windows Settings (Windows Ayarları) > Registry (Kayıt Defteri) yolundan New > Registry Item (Kayıt Defteri Öğesi) ekliyoruz. Action (Eylem) alanında Update (Güncelle) seçiyoruz, Hive (Kovan) olarak HKEY_LOCAL_MACHINE, Key Path (Anahtar Yolu) olarak SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0, Value name (Değer adı) olarak BlockNtlmv1SSO, Value type (Değer türü) olarak REG_DWORD ve Value data (Değer verisi) olarak 0 (Decimal) giriyoruz. Etkilenen cihaz grubunu sınırlamak için Common sekmesinde Item-level targeting (Öğe düzeyinde hedefleme) kullanabiliriz. GPO ile dağıtım yaptığımızda istemcide aşağıdaki komutla ilkeyi hemen çekiyoruz.

gpupdate /force

Registry değerini doğrudan yazdıysak gpupdate /force gerekmez, yalnızca GPO ile dağıtırken işe yarar.

Henüz güncellemeyi almamış cihazlar için değeri güncellemeden önce dağıtmak da mümkün. Değer tanımlı olduğu sürece Ekim 2026 varsayılan değişikliği o cihazlarda devreye girmez. Bazı kullanıcılar, acil durumda KB5127648’i kaldırarak da bağlantıyı geri getirdi. Bu yol ekim ayı güvenlik düzeltmelerini de geri aldığı için tercih etmiyoruz.

Hangi Yolu Seçmeliyiz?

Kalıcı Çözüm: Sertifika Tabanlı Kimlik Doğrulama

Microsoft, MS-CHAPv2 tabanlı bağlantılardan EAP-TLS veya PEAP-TLS gibi sertifika tabanlı yöntemlere geçilmesini öneriyor. Geçiş tek bir ayar değil, üç parçalı bir çalışma. İstemci sertifikalarının dağıtılması, NPS ağ ve bağlantı ilkelerinin güncellenmesi ve Wi-Fi ile kablolu 802.1X profillerinin değiştirilmesi birlikte planlanmalı.

Altyapı tarafında, AD CS (Active Directory Certificate Services, Active Directory Sertifika Hizmetleri) üzerinde bilgisayar kimlik doğrulaması için sertifika şablonunu hazırlıyoruz ve autoenrollment (otomatik kayıt) ile cihazlara dağıtıyoruz. NPS sunucusunun da geçerli bir sunucu kimlik doğrulama sertifikasına sahip olduğunu kontrol ediyoruz. NPS tarafında Network Policy (Ağ İlkesi) içindeki kimlik doğrulama yöntemini sertifika tabanlı yönteme (Smart Card or other certificate) çeviriyoruz. İstemci tarafında ise Wireless Network (IEEE 802.11) Policies ve Wired Network (IEEE 802.3) Policies altındaki profillerde ağ kimlik doğrulama yöntemini aynı şekilde güncelliyoruz.

Geçişi önce pilot bir cihaz grubunda deniyoruz, bağlantıların çalıştığını doğruluyoruz ve ancak sonra merkezi dağıtıma geçiyoruz. Geçiş tamamlandığında geçici BlockNtlmv1SSO = 0 ayarını kaldırıp Enforce davranışını yeniden uyguluyoruz.

Önerilen Aksiyon Planı

Önce etkilenen cihazlarda NTLM Operational logunu ve NPS kayıtlarını kontrol ederek sorunun gerçekten bu değişiklikten kaynaklandığını doğruluyoruz. Ardından geçici çözüm olarak BlockNtlmv1SSO = 0 değerini GPO ile, mümkünse yalnızca etkilenen cihaz gruplarına dağıtıyoruz. Henüz güncellenmemiş cihazlar için değeri güncellemeden önce göndermek, aynı kesintiyi baştan önler. Paralelde EAP-TLS geçiş projesini başlatıyor, pilot sonrası geçici ayarı kaldırıyoruz.

Sonuç

Ekim 2026 güncellemesiyle birlikte gelen NTLMv1 kısıtlaması, PEAP-MSCHAPv2 ile çalışan kurumsal Wi-Fi ve Ethernet ağlarını doğrudan etkileyebiliyor. Registry ayarı hızlı bir kurtarma sağlıyor, ancak güvenlik kısıtlamasını gevşettiği için kalıcı bir çözüm değil. Asıl hedef, parola tabanlı MS-CHAPv2 bağımlılığından çıkıp EAP-TLS ile sertifika tabanlı kimlik doğrulamaya geçmek.