Active Directory ortamında “erişim reddedildi” hatalarının büyük bölümü, aslında yetkilendirme değil kimlik doğrulama (authentication) katmanında, yani Kerberos veya NTLM protokolleri seviyesinde yaşanır. Bu iki protokolü ayırt etmek, sorun giderme sürecinin ilk adımıdır.
Kerberos vs NTLM: Temel Fark
Kerberos, modern AD ortamlarının varsayılan ve tercih edilen kimlik doğrulama protokolüdür; bilet (ticket) tabanlı çalışır ve NTLM’e göre çok daha güvenlidir. NTLM ise eski, geriye dönük uyumluluk için hâlâ var olan bir protokoldür ve mümkün olduğunca kullanımdan kaldırılması önerilir.
En Sık Karşılaşılan Kerberos Hataları
- KRB_AP_ERR_SKEW (Saat Senkronizasyon Hatası): Kerberos, istemci ve sunucu arasında en fazla 5 dakikalık saat farkına izin verir. Domain’e bağlı bir makinenin saati kayarsa, kimlik doğrulama tamamen başarısız olur. Çözüm: NTP/zaman senkronizasyonunu (genellikle Domain Controller üzerinden) doğrulamak.
- KRB_AP_ERR_MODIFIED: Genellikle bilgisayar hesabının parolasının (computer account password) domain ile senkron olmamasından kaynaklanır — makineyi domain’den çıkarıp tekrar eklemek çoğu zaman çözer.
- SPN (Service Principal Name) Çakışmaları: Aynı SPN’in birden fazla hesaba kayıtlı olması, “double hop” veya hizmet erişim hatalarına yol açar.
setspn -Xkomutuyla çakışan SPN’ler tespit edilebilir.
NTLM Hatalarında Dikkat Edilmesi Gerekenler
NTLM ile ilgili sorunlar genellikle iki şekilde ortaya çıkar: ya bir uygulama/cihaz Kerberos’u desteklemediği için NTLM’e “düşer” (fallback) ya da güvenlik politikaları NTLM’i tamamen engellediği için kimlik doğrulama başarısız olur. Event Viewer’da Security logundaki Event ID 4624/4625 kayıtları, kullanılan protokolü (Kerberos mı NTLM mi) ve başarısızlık nedenini gösterir.
Pratik Teşhis Adımları
klist # Mevcut Kerberos biletlerini listele klist purge # Bilet önbelleğini temizle (çoğu sorunu çözer) w32tm /query /status # Saat senkronizasyon durumu setspn -L [hesap] # Bir hesaba kayıtlı SPN'leri listele
Sahadan Bir Not
NTLM’i kademeli olarak azaltmak isteyen kurumlar için, doğrudan “NTLM’i tamamen kapat” yaklaşımı risklidir — eski uygulamaları kırabilir. Bunun yerine, önce Group Policy üzerinden NTLM denetim (audit) modunu aktif ederek hangi sistem/uygulamaların hâlâ NTLM’e bağımlı olduğunu tespit etmeyi, ardından kademeli olarak kısıtlamayı öneririm.
Sonuç
Kerberos ve NTLM hatalarının çoğu, karmaşık görünse de saat senkronizasyonu, SPN bütünlüğü ve bilet önbelleği gibi birkaç temel noktaya inildiğinde hızla çözülebilir.