Merhaba

Active Directory ortamlarını yıllardır rahatsız eden eski kimlik doğrulama protokollerinin başında NTLMv1 geliyor. Windows Server 2025 ile birlikte Microsoft bu protokolü resmen kaldırma yoluna girdi. Bu, güvenlik ekipleri için hem bir fırsat hem de dikkatli yönetilmesi gereken bir geçiş süreci anlamına geliyor.

Bu yazı, Active Directory Sıkılaştırma (AD Hardening) serisinin ilk bölümü. Seri boyunca kimlik altyapısını adım adım daha dayanıklı hale getirmeyi hedefliyoruz. İlk durak, en kritik ve en çok gözden kaçan başlıklardan biri: NTLMv1’in ortamdan temizlenmesi.

NTLMv1 Neden Bu Kadar Tehlikeli

NTLMv1, günümüz saldırı senaryolarına karşı savunmasız, modası geçmiş bir challenge/response kimlik doğrulama protokolü. Sorunun kökeni, zayıf ve kırılabilir DES tabanlı şifreleme kullanması.

Kısacası NTLMv1, ortamınızda açık bırakılmış bir kimlik doğrulama arka kapısı gibi davranıyor. Kerberos ve NTLMv2 gibi daha güçlü alternatifler yıllardır standart olmasına rağmen, eski uygulamalar, yanlış yapılandırılmış cihazlar veya legacy sistemler nedeniyle NTLMv1 pek çok kurumda hala aktif durumda.

Windows Server 2025 ile Ne Değişti

Microsoft, Windows 11 24H2 ve Windows Server 2025 ile birlikte NTLMv1 protokolünü işletim sisteminden kaldırdığını duyurdu. Ancak burada iki önemli ayrıntı var.

Birincisi, protokolün kaldırılması NTLMv1 kriptografisinin her senaryoda tamamen yok olduğu anlamına gelmiyor. Domain’e katılmış ortamlarda MS-CHAPv2 kullanımı gibi bazı durumlarda NTLMv1 kriptografisinin kalıntıları hala mevcut olabiliyor. Yani “protokol kaldırıldı” ifadesini “artık hiç düşünmeme gerek yok” şeklinde okumamak gerekiyor.

İkincisi, Microsoft bu geçişi kademeli bir denetim (audit) ve zorlama (enforce) modeliyle yönetiyor. İşin merkezinde yeni bir registry anahtarı var:

• Anahtar konumu: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\msv1_0
• Değer adı: BlockNtlmv1SSO
• 0 (Audit): NTLMv1 tabanlı Single Sign-On (SSO) istekleri başarılı olur ancak uyarı kaydı üretir.
• 1 (Enforce): Bu istekler engellenir ve hata kaydı üretilir.

Denetim modunda Event ID 4024 (Warning), zorlama modunda ise Event ID 4025 (Error) üretiliyor. Bu iki kayıt, ortamınızda hangi süreçlerin hala NTLMv1 SSO’ya bağımlı olduğunu görmenin en doğrudan yolu.

Önemli bir istisna: bu değişiklikler yalnızca Credential Guard’ın devre dışı olduğu cihazları etkiliyor. Credential Guard etkin olduğunda kimlik bilgileri zaten NTLMv1 üzerinden bu şekilde ifşa edilemiyor.

Yaklaşan Geçiş Takvimi

Microsoft’un açıkladığı kademeli plana göre yaklaşık zaman çizelgesi şöyle:

• Ağustos 2025 sonu: Windows 11 24H2 istemcilerinde audit modu devreye alınmaya başlandı.
• Kasım 2025: Değişiklikler Windows Server 2025 tarafına yaygınlaştırıldı.
• Ekim 2026: Ayrıca yapılandırılmadıysa varsayılan davranış Enforce moduna geçecek.

Buradaki mesaj net: NTLMv1’i kendi kontrolünüzde, planlı biçimde kapatmazsanız Microsoft bir noktada sizin adınıza zorlamaya başlayacak. O yüzden doğru yaklaşım, kontrolü elde tutup geçişi bilinçli yönetmek.

LmCompatibilityLevel Seviyeleri

NTLMv1’in klasik ve en temel kontrol noktası hala LmCompatibilityLevel ayarı. Bu ayar, istemcilerin hangi protokolü gönderdiğini ve sunucuların hangilerini kabul ettiğini belirliyor.

Aşama 1: Keşif ve Denetim (Audit)

En sık yapılan hata, NTLMv1’i doğrudan zorlama moduna almak ve ardından üretim ortamının çeşitli noktalarında kesintiler yaşamak. Doğru yaklaşım önce görmek, sonra kapatmak.

Mevcut Ayarların Envanteri

Öncelikle ortamdaki tüm sistemlerde mevcut LmCompatibilityLevel değerini çıkarın.

Basit bir PowerShell sorgusu:

Windows PowerShell‘i Run as administrator (Yönetici olarak) açın ve aşağdaki komutu çalıştırın:

$path = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"
Get-ItemProperty -Path $path -Name LmCompatibilityLevel -ErrorAction SilentlyContinue |
    Select-Object PSComputerName, LmCompatibilityLevel

Bu sorguyu tüm sunucu ve istemcilerde toplu çalıştırarak bir baseline oluşturun. Değer boşsa varsayılan davranış geçerlidir; bunu da kayıt altına alın.

NTLMv1 Kullanımını Loglardan Tespit Etmek

NTLMv1 kullanımını görmenin en güvenilir yolu logon olaylarını izlemek. Anahtar kayıt Event ID 4624 (An account was successfully logged on).

İlgili alanlar:

• Authentication Package: NTLM
• Package Name (NTLM only): NTLM V1

Package Name alanında NTLM V1 içeren kayıtlar, ortamınızda hala NTLMv1 kullanan istemci ve uygulamaları işaret eder. Bu kayıtları merkezi bir SIEM üzerinde toplayıp ANONYMOUS LOGON girişlerini eleyerek gerçek bağımlılıkları listeleyin.

Ek olarak Restrict NTLM denetim politikaları da değerli veri üretir:

• • Event ID 8004: Domain genelindeki NTLM kimlik doğrulama denemeleri
  • Event ID 8001 – 8003: Gelen ve giden NTLM trafiği ayrıntıları

Windows 11 24H2 ve Windows Server 2025 ile birlikte gelen gelişmiş NTLM loglaması ise süreç adı ve fallback nedeni gibi çok daha zengin ayrıntılar sunar. Bunu şu politika altından etkinleştirebilirsiniz:

Computer Configuration > Administrative Templates > System > NTLM > NTLM Enhanced Logging

Hazır Script: Get-NTLMv1Usage.ps1

Yukarıdaki adımları elle tek tek çalıştırmak yerine, hem mevcut ayarları hem de gerçek NTLMv1 kullanımını tek seferde raporlayan hazır bir script kullanabilirsiniz. Get-NTLMv1Usage.ps1 scriptini her makinede LmCompatibilityLevel ve BlockNtlmv1SSO değerlerini okur, Security log’unda NTLM V1 içeren Event 4624 kayıtlarını çıkarır ve ANONYMOUS LOGON girişlerini eler.

Windows PowerShell‘i Run as administrator (Yönetici olarak) açın ve scriptlerin bulunduğu klasöre geçip komutu çalıştırın:

cd "C:\scripts"
.\Get-NTLMv1Usage.ps1

Birden fazla sunucuda ve sonucu CSV’ye alarak:

cd "C:\scripts"
.\Get-NTLMv1Usage.ps1 -ComputerName W25DC,W25ADC,W25EXCSE -CsvPath .\ntlmv1.csv

Aşama 2: Kademeli Devreye Alma

Bağımlılıkları tespit edip giderdikten sonra sıkılaştırmayı katman katman uygulayın. Sıralama kritik.

1. Önce istemciler: Tüm istemcilere LmCompatibilityLevel = 3 uygulayın ve izleyin.
2. Sonra üye sunucular (member servers): Domain Controller olmayan sunuculara LmCompatibilityLevel = 5 uygulayın, erişim sorunlarını takip edin.
3. En son Domain Controller Belirli bir gözlem döneminin ardından, herhangi bir erişim sorunu yaşanmıyorsa Domain Controller LmCompatibilityLevel = 5 uygulayın.

Genel kural: en kısıtlayıcı ayarı en son ve en dikkatli izlenen katmana uygulayın.

Group Policy Object ve Intune Yolları

Group Policy tarafında ayar şu yolda:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options > Network Security: LAN Manager authentication level

Intune ile yönetilen cihazlarda Settings Catalog üzerinden “Network Security LAN Manager Authentication Level” politikasını kullanabilir veya şu OMA-URI’yi tanımlayabilirsiniz:

./Device/Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions/NetworkSecurity_LANManagerAuthenticationLevel

NTLMv1 Açıksa: Ayarı Uygulama Komutları

Denetim sonucunda NTLMv1 kullanımı tespit ettiyseniz ve bağımlılıkları gidermeye başladıysanız, ayarı fiilen uygulama sırası geldiğinde aşağıdaki komutları kullanabilirsiniz. Kurumsal ortamda önerilen yöntem her zaman GPO (Group Policy Object)’dur; tek makine testleri veya izole senaryolar için registry doğrudan yazılabilir.

Tek bir makinede LmCompatibilityLevel değerini ayarlamak (istemci için 3, sunucu/Domain Controller için 5):

$path = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa"

İstemcilerde Birinci Aşama:

Set-ItemProperty -Path $path -Name LmCompatibilityLevel -Value 3 -Type DWord

Üye Sunucu ve (Doğrulama Sonrası) Domain Controller:

Set-ItemProperty -Path $path -Name LmCompatibilityLevel -Value 5 -Type DWord

Windows Server 2025 / Windows 11 24H2 tarafında NTLMv1 SSO’yu zorlama moduna almak için BlockNtlmv1SSO anahtarı:

$msv = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\msv1_0"

0 = Audit (Yalnızca Uyarı), 1 = Enforce (Engelle)

Set-ItemProperty -Path $msv -Name BlockNtlmv1SSO -Value 1 -Type DWord

Tekrar kontrol ediyoruz.

Windows PowerShell‘i Run as administrator (Yönetici olarak) açın ve scriptlerin bulunduğu klasöre geçip komutu çalıştırın:

cd <span class="token string">"C:\scripts"</span>
<span class="token punctuation">.</span>\Get-NTLMv1Usage<span class="token punctuation">.</span>ps1

Aynı ayarları reg.exe ile uygulamak isterseniz:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel /t REG_DWORD /d 5 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\msv1_0" /v BlockNtlmv1SSO /t REG_DWORD /d 1 /f

Uygulamadan sonra gpupdate /force çalıştırın (GPO (Group Policy Object) ile dağıtıyorsanız) ve değişikliğin etkin olması için ilgili makineleri yeniden başlatın. Kritik uyarı: seviye 5’i doğrudan tüm ortama tek seferde uygulamayın. Önce istemcileri 3’e alıp bir süre izleyin, ardından sunucuları, en son da Domain Controller’leri 5’e taşıyın. Aksi halde bir sonraki başlıkta anlatılan hesap kilitlenmesi riskiyle karşılaşırsınız.

Hesap Kilitlenmesi Riskine Dikkat

Bu geçişte en çok canyakan tuzak burada. Bir Domain Controller LmCompatibilityLevel = 5 olarak yapılandırıldığında, NTLMv1 üzerinden gelen istekler başarısız parola denemesi (failed password attempt) olarak değerlendirilir.

Geri Alma (Rollback) Planı

Her sıkılaştırma adımı öncesi geri dönüş planınız hazır olmalı. Pratikte iki temel araç:

• İlgili GPO (Group Policy Object)’yu geri alıp gpupdate /force ile hızlı dağıtım.
• Registry değerini önceki haline döndürme (gerekirse LmCompatibilityLevel değerinin eski değerini geri yazma).

Pilot yaklaşım her zaman önerilir: değişikliği önce düşük riskli bir OU (Organizational Unit) üzerinde uygulayın, bir hafta izleyin, ardından dalgalar halinde ortama yayın.

Genel Görünüm

Windows Server 2025, NTLMv1 için bir dönüm noktası. Microsoft protokolü kaldırıyor ve Ekim 2026 itibarıyla zorlama modunu varsayılan yapmaya hazırlanıyor. Bu geçişi kendi takviminizde yönetmek, bir gün beklenmedik bir kesintiyle karşılaşmaktan çok daha sağlıklı.

Özetle izlenmesi gereken yol: önce görünürlük (audit ve loglama), sonra istemcilerden başlayıp Domain Controller doğru kademeli sıkılaştırma, en son ise seviye 5 zorlaması. Bu sırayı korudukça hem NTLMv1’in getirdiği pass-the-hash ve relay risklerini kapatır hem de üretim ortamını kesintiye uğratmadan sıkılaştırmayı tamamlarsınız.

Serinin bir sonraki bölümünde başka bir Active Directory sıkılaştırma başlığını ele alacağız. Ortamınızı adım adım daha dayanıklı hale getirmeye devam edeceğiz.

Başka bir yazımızda görüşmek dileğiyle…