NTLM'den Kerberos'a Güvenli Geçiş

Bu süreci daha net anlamak adına, Kerberos'un neden daha güvenli olduğunu ve Microsoft'un bu yeni çözümlerle neyi hedeflediğini biraz daha yakından inceleyelim:

Kerberos vs. NTLM: Neden Değişiyor?

NTLM, "Challenge-Response" (Meydan Okuma-Yanıt) mekanizmasına dayanır. Bu süreçte hash değerleri ağ üzerinden iletildiği için saldırganlar bu trafiği yakalayıp başka bir sunucuya "yansıtabilir" (Relay Attack). Kerberos ise çok daha sofistike bir biletleme sistemi kullanır.

Microsoft'un Yeni Silahları: IAKerb ve Local KDC

BT yöneticilerinin en büyük korkusu, NTLM'yi kapattıkları gün "Local Admin" hesaplarının kilitlenmesi veya uzak ofislerdeki bağlantıların kopmasıdır. Microsoft bunu aşmak için iki kritik köprü kuruyor:

1. IAKerb (Initial Authentication Kerberos): Kerberos'un çalışması için normalde istemcinin Domain Controller (DC) ile doğrudan konuşabilmesi gerekir. IAKerb, istemci ve sunucu arasındaki mevcut bağlantıyı kullanarak Kerberos paketlerini DC'ye iletir (proxy görevi görür). Yani "DC'yi göremiyorum" bahanesi ortadan kalkar.

2. Local KDC (Key Distribution Center): Yerel hesaplar için Kerberos biletlerini yerel olarak yöneten bir yapı sunar. Bu, NTLM'ye olan bağımlılığı yerel oturum açma seviyesinde bile bitirmeyi hedefler.

Geçiş Takvimi ve Stratejik Önem

Bu değişim, ağınızdaki "görünmez kapıları" kapatmak adına devasa bir adım. Özellikle Pass-the-Hash saldırılarının önünü kesmek, fidye yazılımı (ransomware) gruplarının lateral movement (yanal ilerleme) kabiliyetini ciddi oranda kısıtlayacaktır.

Kuruluşunuzdaki eski uygulamaların NTLM bağımlılığını tespit etmek için özel bir denetim (audit) stratejisi veya PowerShell scripti ile kontrol yapalım

NTLM'yi kapatmadan önce atılacak en kritik adım, ağınızda kimin, nereden ve hangi uygulamayla hala NTLM kullandığını sessizce izlemektir. Eğer bunu yapmadan protokolü devre dışı bırakırsanız, eski bir veritabanı bağlantısı veya bir ağ yazıcısı nedeniyle iş akışlarınız durabilir.

Aşağıdaki PowerShell scripti, Windows Olay Görüntüleyicisi (Event Viewer) üzerindeki NTLM Denetim (Auditing) kayıtlarını tarar ve size anlamlı bir özet sunar.

1. Adım: Denetimi Etkinleştirme (GPO üzerinden)

Scripti çalıştırmadan önce, sisteminizin bu verileri kaydetmesi gerekir. Grup İlkesi Düzenleyicisi'nde (gpedit.msc) şu yolu izleyin:

• Bilgisayar Yapılandırması > Windows Ayarları > Güvenlik Ayarları > Yerel İlkeler > Güvenlik Seçenekleri

• Ağ güvenliği: NTLM'yi kısıtla: Bu etki alanındaki NTLM denetimi -> Tümünü Etkinleştir olarak ayarlayın.

2. Adım: NTLM Analiz Scripti

Bu script, NTLM Audit loglarını (Event ID 8001, 8002, 8003 ve 8004) tarayarak hangi kullanıcıların ve hangi sunucuların hala bu eski protokolü kullandığını listeler.

# NTLM Kullanımını Raporlama Scripti
# Bu script 'Microsoft-Windows-NTLM/Operational' günlüğünü analiz eder.

$Events = Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -ErrorAction SilentlyContinue

if ($null -eq $Events) {
    Write-Host "[-] NTLM Log kaydı bulunamadı. Denetim modunun açık olduğundan emin olun." -ForegroundColor Red
    return
}

$NTLMReport = foreach ($Event in $Events) {
    [xml]$XmlEvent = $Event.ToXml()
    
    # XML verisinden detayları ayıklama
    $TargetName = $XmlEvent.Event.EventData.Data | Where-Object { $_.Name -eq "TargetName" } | Select-Object -ExpandProperty "#text"
    $UserName   = $XmlEvent.Event.EventData.Data | Where-Object { $_.Name -eq "UserName" }   | Select-Object -ExpandProperty "#text"
    $Process    = $XmlEvent.Event.EventData.Data | Where-Object { $_.Name -eq "ProcessName" }| Select-Object -ExpandProperty "#text"

    [PSCustomObject]@{
        TimeCreated = $Event.TimeCreated
        EventID     = $Event.Id
        User        = $UserName
        Target      = $TargetName
        Process     = $Process
        Message     = $Event.Message
    }
}

# Sonuçları Tablo Olarak Göster
$NTLMReport | Out-GridView -Title "NTLM Kullanım Analizi"

# İsteğe bağlı: CSV olarak dışa aktar
# $NTLMReport | Export-Csv -Path "C:\Temp\NTLM_Audit_Report.csv" -NoTypeInformation

• TargetName: Hangi sunucuya bağlanılmaya çalışıldığını gösterir.

• ProcessName: NTLM çağrısını yapan uygulamanın adını verir (Örn: sqlservr.exe veya bir eski muhasebe yazılımı).

• Event ID 8004: En kritik olanıdır; "Eğer NTLM'yi engelleseydik, bu bağlantı kopacaktı" anlamına gelir.

Sonraki Adımlar

Bu raporu aldıktan sonra, listedeki uygulamaların konfigürasyonlarını inceleyip "Authentication Method" kısmını Kerberos veya Negotiate olarak güncellemeniz gerekecek.

Kerberos SPN (Service Principal Name) yapılandırması

Kerberos dünyasında SPN (Service Principal Name), bir servisin kimliğini etki alanı (Active Directory) içerisinde benzersiz kılan bir "etiket" gibidir. Kerberos biletleme sisteminin çalışması için istemcinin hangi servis ile konuştuğunu tam olarak bilmesi gerekir.

SPN doğru yapılandırılmadığında Kerberos başarısız olur ve sistem otomatik olarak (ve güvensiz olan) NTLM'e geri döner. NTLM'i emekliye ayırırken SPN hatalarını çözmek bu yüzden hayatidir.

1. SPN Sözdizimi (Syntax)

Bir SPN kaydı genellikle şu formatta olur: ServisSınıfı / AnaBilgisayarAdı : Port / ServisAdı

• ServisSınıfı: HTTP, MSSQLSvc, HOST, NFS gibi servis türü.

• AnaBilgisayarAdı: Servisin çalıştığı sunucunun FQDN (Tam Etki Alanı Adı) veya NetBIOS adı.

• Port: Standart dışı bir port kullanılıyorsa belirtilir.

2. Kritik Komutlar (Setspn Kullanımı)

SPN yönetimi için en temel araç setspn.exe komut satırı aracıdır. Bu komutları Domain Admin yetkisiyle çalıştırmalısınız.

A. Mevcut SPN'leri Listeleme

Bir kullanıcı veya bilgisayar hesabına atanmış SPN'leri kontrol etmek için:

setspn -L <HesapAdi>
# Örnek: setspn -L SQLServiceAccount

B. Yeni Bir SPN Kaydı Ekleme

Örneğin, bir web sunucusu (IIS) için uygulama havuzu kullanıcısına SPN atamak:

setspn -S HTTP/web01.sirket.local SQLServiceAccount
setspn -S HTTP/web01 SQLServiceAccount

Not: -S parametresi (Add Unique), aynı SPN'in başka bir hesapta olup olmadığını kontrol eder. Bu, çakışmaları önlemek için -A yerine tercih edilmelidir.

C. Yinelenen (Duplicate) SPN'leri Bulma

Kerberos'un en büyük düşmanı aynı SPN'in iki farklı hesapta tanımlı olmasıdır. Bunu bulmak için:

setspn -X

3. Yaygın Hata: "Kayıp SPN" Senaryosu

Bir kullanıcı http://app01 adresine gitmeye çalıştığında, Windows önce bu isim için bir Kerberos bileti ister. Eğer AD içerisinde HTTP/app01 şeklinde bir SPN kaydı yoksa, Kerberos "Ben bu servisi tanımıyorum" der ve NTLM kullanmaya başlar.

Çözüm Akışı:

1. Servisin hangi hesap (LocalSystem, NetworkService veya bir Domain User) altında çalıştığını bulun.

2. İstemcilerin servise hangi isimle (FQDN veya kısa isim) eriştiğini netleştirin.

3. Eksik olan kombinasyonları setspn -S ile ilgili hesaba tanımlayın.

4. PowerShell ile Otomatik Kontrol

Eğer elinizde uzun bir sunucu listesi varsa, SPN kayıtlarının durumunu şu script ile hızlıca görebilirsiniz:

# Belirli bir servis için SPN kontrolü
$SearchName = "web01" 
Get-ADObject -Filter "ServicePrincipalName -like '*$SearchName*'" -Properties ServicePrincipalName | 
Select-Object Name, DistinguishedName, ServicePrincipalName | 
Format-List

# FQDN için kayıt
setspn -S MSSQLSvc/sql01.ondernet.local:1433 ondernet\sql_service_account

# NetBIOS (Kısa ad) için kayıt
setspn -S MSSQLSvc/sql01:1433 ondernet\sql_service_account

# Web sitesi adresi için SPN kaydı
setspn -S HTTP/portal.ondernet.net ondernet\web_app_pool_user
setspn -S HTTP/portal ondernet\web_app_pool_user