Kerberos Nedir? Kimlik Doğrulama ve Bilet Mantığı

Kerberos, bir ağdaki kullanıcı ve servislerin birbirine kimliğini parola göndermeden kanıtladığı kimlik doğrulama protokolüdür. Bunu süreli biletlerle yapar: kullanıcı oturum açarken bir kez kimliğini kanıtlar, karşılığında süreli bir belge alır ve gün boyunca her kapıda parolasını değil o belgeyi gösterir. Active Directory ortamında bir kullanıcı oturum açtığında arka planda çalışan şey budur ve 88 numaralı portu kullanır.

Adı tesadüf değil. Yunan mitolojisinde Hades’in yönettiği yeraltı dünyasının kapısında üç başlı bir köpek nöbet tutar: Kerberos. Görevi kapıdan geçeni denetlemektir, ve geçiş hakkı kişinin kim olduğuna değil elindeki geçerli belgeye bakılarak verilir. MIT, 1983’te başlayan Project Athena kapsamında bu protokolü geliştirirken ismi oradan aldı, çünkü tasarımda da tam olarak üç taraf vardı. Bu makale boyunca o kapıda kalacağız.

Aşağıda önce Kerberos’un ne olduğunu ve üç başın kime karşılık geldiğini, sonra biletin nasıl üretildiğini belirleyen KDC mimarisini göreceğiz. Ardından oturum açmadan bir dosya sunucusuna erişmeye kadar giden akışı mesaj mesaj izleyeceğiz, aynı akışı Wireshark’ta paket düzeyinde açacağız, klist ile makinedeki gerçek biletleri okuyacağız ve son olarak Kerberos arızalarında belirtiden hata koduna giden teşhis sırasını kuracağız. Elinizde şu an kimlik doğrulayamayan bir sistem varsa doğrudan teşhis bölümüne atlayabilirsiniz.

Bu makale kurumsal network kurulumu hizmetimizin kimlik doğrulama katmanına odaklanır; Kerberos’un içinde yer aldığı protokol zincirinin tamamını kurumsal ağ protokolleri rehberimizde ele alıyoruz.

Kerberos Nedir, Adı Nereden Geliyor?

Kerberos, güvenilmeyen bir ağ üzerinde iki tarafın birbirine kimliğini kanıtlamasını sağlayan, bilet tabanlı bir kimlik doğrulama protokolüdür. Bugün kullanılan sürüm Kerberos 5’tir ve RFC 4120 ile tanımlanır; bu belge 1993 tarihli RFC 1510’un yerini almıştır. Windows, Linux, macOS ve pek çok kurumsal uygulama aynı protokolü konuşur, yani Kerberos bir Microsoft teknolojisi değildir. Microsoft’un yaptığı şey onu Active Directory’nin varsayılan kimlik doğrulama yöntemi haline getirmek olmuştur.

Üç Baş, Üç Taraf

Protokolün adındaki üç baş, kimlik doğrulamaya katılan üç tarafı temsil eder: istemci, servis ve ikisinin de güvendiği KDC (Key Distribution Center). Bu üçlü yapı protokolün tamamını açıklar, çünkü Kerberos’un çözdüğü asıl problem şudur: birbirini hiç tanımayan iki taraf, aralarında parola alışverişi yapmadan nasıl güvenir?

Cevap gündelik hayatta zaten var. Bir binaya girerken güvenlik görevlisi sizi tanımaz, tanımak zorunda da değildir. Kimliğinizi lobide bir kez gösterirsiniz, size o gün için geçerli bir kart verilir, sonra her kapıda o kartı okutursunuz. Kattaki kapı sizi tanımıyor, kartı tanıyor. Kartı veren makama güvendiği için de sizi sorgulamıyor.

Kerberos’un mimarisi budur ve buradan çıkan sonuç çoğu kişinin beklediğinin tersidir: servis, sizi doğrulamak için KDC’ye hiç sormaz. Bilet zaten servisin kendi anahtarıyla şifrelenmiş olarak gelir; servis onu açabiliyorsa bileti veren makamın gerçekten KDC olduğunu anlamış olur. Bu ayrıntı protokolün neden ölçeklendiğini de açıklar. Binlerce kullanıcının binlerce dosya erişiminde Domain Controller trafiğe hiç karışmaz.

Parola Neden Ağda Dolaşmaz?

Kerberos’un tasarım amacı, parolanın ağ üzerinde hiç taşınmamasıdır. Bunun yerine parola her iki tarafta da bir şifreleme anahtarına dönüştürülür ve taraflar birbirine, o anahtarı bildiklerini şifre çözerek kanıtlar. Parolanın kendisi hiçbir mesajın içinde yer almaz.

Bu, 1980’lerin ortasında radikal bir fikirdi. O dönemin protokollerinin çoğu kullanıcı adı ve parolayı düz metin gönderiyordu; aynı kabloyu dinleyen herkes ikisini de okuyabiliyordu. Telnet ve FTP’nin bugün hâlâ taşıdığı kusur budur. Project Athena, MIT kampüsündeki binlerce paylaşımlı iş istasyonunu tek bir kimlik altyapısına bağlamak zorundaydı ve o ağdaki hiçbir makineye güvenilemezdi. Kerberos bu kısıtın altında doğdu.

Pratik sonucu bugün de aynı: ağı dinleyen bir saldırgan Kerberos trafiğinden parola çıkaramaz. Yakalayabileceği şey biletlerdir, biletlerin de ömrü vardır. Bu makalenin ilerleyen bölümlerinde Wireshark’ta göreceğiniz paketlerin içinde tek bir okunabilir parola bulunmayacak.

Kerberos’un Bilet Mantığı: KDC, AS ve TGS

KDC, biletleri üreten ve dağıtan merkezi otoritedir; Active Directory’de her Domain Controller aynı zamanda bir KDC’dir. Bu rolün Windows’a özgü olmadığını eklemek gerekiyor: bir Linux sunucuya Samba AD DC kurduğunuzda o makine de aynı biletleri basan bir KDC haline gelir. Kapının önündeki tek yetkili makam odur ve iki ayrı işi vardır. Bu iki iş protokolde iki ayrı servis olarak tanımlanmıştır ve isimlerini bilmek teşhis sırasında doğrudan işe yarar.

AS (Authentication Service), kimliği ilk kez doğrulayan taraftır. Lobideki kimlik kontrolü budur: parolanızdan türetilen anahtarı bildiğinizi kanıtlarsınız, karşılığında gün boyu kullanacağınız kartı alırsınız.

TGS (Ticket Granting Service), o kartı gösterene belirli bir kapı için izin veren taraftır. Kata çıkmak istediğinizde kartınızı okutursunuz, sistem o kata yetkiniz olduğunu görür ve kapıyı açar. TGS her erişimde yeniden devreye girer; AS ise günde bir kez.

TGT ile Servis Bileti Arasındaki Fark

Kerberos’ta iki tür bilet vardır ve ikisini karıştırmak teşhisi baştan yanlış yola sokar.

TGT bir anahtar değil, anahtar isteme hakkıdır. Elinizdeki kartla hiçbir kapıyı doğrudan açamazsınız; kart yalnızca “bu kişi lobiden geçti, kimliği doğrulandı” der. Kapıyı açan şey o kart gösterilerek alınan kapıya özel izindir.

Bunun günlük hayattaki karşılığını her sabah yaşarsınız. Sabah oturum açtığınızda parola sorulur, bu AS aşamasıdır. Gün içinde dosya sunucusuna, yazıcıya, intranet sitesine girerken bir daha parola sorulmaz; her birinde arka planda ayrı bir servis bileti alınır ama siz bunu hiç görmezsiniz. Tek oturum açmayla her yere erişebilmenizin (Single Sign-On) altındaki mekanizma budur.

krbtgt: Biletleri İmzalayan Hesap

TGT’yi şifreleyen anahtar, domain’deki krbtgt adlı özel hesabın parolasından türetilir. Bu hesap her Active Directory domain’inde otomatik olarak oluşur, hiçbir zaman oturum açmaz, devre dışı görünür ve tek işi budur.

Neden önemli olduğunu bir cümleyle söyleyeyim: krbtgt anahtarını ele geçiren biri, domain’deki herhangi bir kullanıcı için istediği ömürde geçerli bir TGT üretebilir. Saldırı literatüründe “Golden Ticket” denilen şey tam olarak budur ve KDC’nin ürettiğinden ayırt edilemez, çünkü matematiksel olarak aynı anahtarla imzalanmıştır.

Sıkılaştırma tarafındaki diğer kontrolleri Active Directory güvenlik sıkılaştırması rehberimizde, bu kontrollerin 1.500 cihazlık bir ortamda nasıl uygulandığını ise Active Directory modernizasyon projemizde anlatıyoruz.

Kerberos Nasıl Çalışır? AS-REQ’ten AP-REQ’e

Kerberos akışı üç geçişten oluşur ve her geçiş bir istek ile bir cevaptan ibarettir. Mesajların adları protokolde sabittir; Wireshark’ta göreceğiniz isimler de, olay günlüğünde karşınıza çıkacak hata kodlarının önekleri de bunlardır. Altı mesajın tamamı şu sırayla akar:

Birinci Geçiş: Kimliğin Kanıtlanması

AS-REQ, istemcinin KDC’ye “ben şu kullanıcıyım, bana bir TGT ver” dediği mesajdır. Active Directory’de bu isteğin içinde, kullanıcının parolasından türetilen anahtarla şifrelenmiş bir zaman damgası bulunması gerekir. Buna ön kimlik doğrulama (pre-authentication) denir ve varsayılan olarak zorunludur.

Buradaki “gerekir” kelimesi önemli, çünkü istemci bunu her zaman ilk denemede yapmaz. Gerçekte ne olduğunu bu makalenin Wireshark bölümünde paket paket göreceksiniz ve akış kitapta yazandan bir mesaj uzun çıkacak.

Kerberos’un saate bu kadar bağımlı olmasının sebebi işte bu ilk adımdır. KDC gelen zaman damgasını çözer ve kendi saatiyle karşılaştırır; fark toleransı aşıyorsa isteği daha kimlik doğrulamaya geçmeden reddeder. Active Directory’de tolerans varsayılan olarak 5 dakikadır. Bunun sebebi bir saldırganın yakaladığı bir isteği sonradan yeniden göndermesini (replay) engellemektir: damga eskimişse istek geçersizdir.

Kapıdaki köpek belgenin üstündeki tarihe bakar. Belge gerçek olabilir, taşıyan kişi de gerçekten o olabilir; tarih tutmuyorsa geçiş yoktur. Saat kaynağının nasıl kurulacağını ve saat kaydığında ödenen diğer bedelleri NTP ve saat senkronizasyonu rehberimizde ele alıyoruz.

AS-REP ise iki paket taşır. Birincisi TGT’dir ve krbtgt anahtarıyla şifrelenmiştir, yani istemci onu açamaz; sadece taşır. İkincisi, istemcinin kendi anahtarıyla şifrelenmiş bir oturum anahtarıdır ve istemci bunu açabilir. Bu asimetri protokolün kalbidir: elinizdeki belgenin içini okuyamazsınız, ama onu ibraz edebilirsiniz.

İkinci Geçiş: Servis Bileti Alma

TGS-REQ, istemcinin elindeki TGT’yi göstererek belirli bir servis için bilet istediği mesajdır. İstenen servis burada bir isimle belirtilir ve o ismin adı SPN’dir (Service Principal Name). Bir dosya sunucusuna erişiyorsanız istenen SPN cifs/dosya01.ad.sercebilisim.com biçiminde olur.

KDC bu isteği alınca TGT’yi kendi krbtgt anahtarıyla açar, geçerliyse istenen SPN’i dizinde arar ve o SPN’in kayıtlı olduğu hesabı bulur. TGS-REP ile dönen servis bileti, işte o hesabın anahtarıyla şifrelenir.

Bu cümle teşhis bölümünün tamamının anahtarıdır, o yüzden bir kez daha durayım: KDC bileti, SPN’i hangi hesapta bulduysa o hesabın anahtarıyla şifreler. SPN yanlış hesaba yazılmışsa bilet üretilir, istemciye ulaşır, hiçbir hata görünmez; ama hedef servis onu açamaz çünkü kendi anahtarı değildir. Arıza istemcide değil, iki adım ötede ve bambaşka bir belirtiyle çıkar.

Üçüncü Geçiş: Servise Başvuru

AP-REQ, istemcinin servis biletini nihayet hedef servise sunduğu mesajdır ve buradaki en önemli ayrıntı, bu mesajın KDC üzerinden geçmemesidir. İstemci doğrudan dosya sunucusuna, web sunucusuna ya da SQL sunucusuna bağlanır ve bileti ona verir.

Servis bileti kendi anahtarıyla açar. Açabildiyse bileti üreten makamın KDC olduğunu doğrulamış olur, çünkü o anahtarı bilen başka kimse yoktur. İçindeki kullanıcı kimliğini ve grup üyeliklerini okur, yetkilendirme kararını buna göre verir. İstemci isterse AP-REP talep eder ve servis de kendini kanıtlar; karşılıklı kimlik doğrulama (mutual authentication) budur ve sahte sunucuya bağlanmayı engeller.

Buradan çıkan pratik sonuç teşhiste sürekli işinize yarayacak: Kerberos arızalarının bir kısmında Domain Controller tamamen sağlıklıdır ve loglarında hiçbir şey yoktur, çünkü sorunlu adım DC’ye hiç uğramamıştır. Hangi geçişin bozulduğunu bilmeden log aramak, yanlış sunucunun kayıtlarında saatler harcamak demektir.

Kerberos Trafiğini Wireshark ile İzlemek

Kerberos mesajlarının hepsi ağda düz olarak görünür ve Wireshark bunları isimleriyle çözümler. Bu bölüm protokolü anlatmıyor, gösteriyor: akışı bir kez paket düzeyinde gördüğünüzde teşhis sırasında hangi adımın nerede durduğunu tahmin etmek yerine ölçersiniz.

Aşağıdaki çıktıların hepsi kendi lab ortamımızda üretildi: domain ad.sercebilisim.com, Domain Controller dc01 (192.168.1.10), domain üyesi Windows 10 istemci PCTEST01 (192.168.1.105).

Yakalamayı domain üyesi istemcide yapın, Domain Controller’da değil. DC üzerinde yakalama yaparsanız ortamdaki bütün makinelerin trafiği karışır ve kendi oturumunuzu ayırt edemezsiniz. İstemcide yalnız o makinenin akışını görürsünüz.

Wireshark’ı açtıktan sonra görüntüleme filtresine kerberos yazın. Bu filtre 88 numaralı port üzerindeki hem TCP hem UDP trafiğini kapsar ve mesajları isimleriyle listeler.

Temiz bir akış yakalamanın yolu, önce makinedeki mevcut biletleri temizlemektir. Önbellek boşsa istemci akışı baştan kurmak zorunda kalır:

klist purge
klist get HOST/dc01.ad.sercebilisim.com

Yakalanan Gerçek Akış: Kitaptan Bir Mesaj Uzun

Yakalamayı tshark ile çözümlediğimde çıkan liste bu. Okumadan önce üç şeyi bilmek yeterli:

• Her satır bir mesajdır. Baştaki sayı çerçeve numarası, yani o paketin yakalamadaki sırası.
• 192.168.1.105 istemci, 192.168.1.10 Domain Controller. Ok yönü kimin konuştuğunu gösterir.
• Sondaki isim mesajın tipidir. AS-REQ, AS-REP gibi. Bunlar protokolün sabit isimleri, uydurma kısaltma değil.

   25   2.647739  192.168.1.105 → 192.168.1.10   KRB5  305  AS-REQ
   31   2.649731  192.168.1.10  → 192.168.1.105  KRB5  423  KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED
   65   2.651290  192.168.1.105 → 192.168.1.10   KRB5  385  AS-REQ
   72   2.653078  192.168.1.10  → 192.168.1.105  KRB5  352  AS-REP
  115   2.655686  192.168.1.105 → 192.168.1.10   KRB5 1843  TGS-REQ
  126   2.658453  192.168.1.10  → 192.168.1.105  KRB5  345  TGS-REP
  223   4.699501  192.168.1.105 → 192.168.1.10   KRB5 1843  TGS-REQ
  234   4.701797  192.168.1.10  → 192.168.1.105  KRB5  345  TGS-REP

Sekiz satırın hikâyesi sırayla şu:

1. Çerçeve 25: İstemci “bana bir TGT ver” diyor. Bu ilk denemede yanında hiçbir kanıt yok, sadece talep var.
2. Çerçeve 31: KDC talebi geri çeviriyor. Dönen hata KRB5KDC_ERR_PREAUTH_REQUIRED, yani “önce kim olduğunu kanıtla”.
3. Çerçeve 65: İstemci aynı talebi tekrarlıyor, ama bu sefer içine parolasından türetilen anahtarla şifrelenmiş bir zaman damgası koyuyor.
4. Çerçeve 72: KDC ikna oluyor ve TGT’yi teslim ediyor. Oturumun kimlik belgesi artık istemcide.
5. Çerçeve 115: İstemci TGT’sini gösterip belirli bir servis için bilet istiyor.
6. Çerçeve 126: O servisin bileti geliyor.
7. Çerçeve 223: Aynı istek, bu sefer başka bir servis için.
8. Çerçeve 234: İkinci servisin bileti de geliyor.

İkinci satır bu listenin sürprizi. Kitaplarda akış altı mesaj olarak anlatılır ve ilk isteğin doğrudan kabul edildiği varsayılır. Gerçekte istemci ilk denemeyi boş gönderiyor, ret yiyor, sonra kanıtla geliyor. Yani sahadaki akış bir mesaj daha uzun.

Bu bir arıza değil, normal davranış. Ama pratik sonucu şu: bir Kerberos yakalamasında KRB-ERROR görmeniz tek başına sorun olduğu anlamına gelmez. İlk AS-REQ’e gelen ret her sağlıklı oturum açmada vardır. Teşhis yaparken bakılacak şey hatanın varlığı değil, kodu ve akışın ondan sonra devam edip etmediğidir.

Kapıdaki köpek belgeyi ilk uzatışta almıyor. Önce “mührün nerede” diyor.

Paketlerin İçinde Ne Var?

Paketlerin içinde takip etmeye değer tek bir alan varsa o sname’dir. Açılımı service name, yani “bu mesajda hangi servisin bileti konuşuluyor”. Değeri iki türlü olur ve ikisini ayırt etmek akışın neresinde olduğunuzu söyler:

• krbtgt/... yazıyorsa konu TGT’dir, yani “bilet isteme hakkı”. İstemci henüz kimlik aşamasındadır.
• Başka bir isim yazıyorsa (HOST/..., ldap/..., cifs/...) konu belirli bir servise erişimdir. Kimlik zaten kanıtlanmış, sıra kapıya gelmiştir.

Aşağıdaki listede göreceğiniz ldap/... bileti bu ayrımın iyi bir örneği: makine kimliğini Kerberos ile kanıtladıktan sonra dizini sorgulamak için ayrı bir bilet alıyor. Kerberos “bu kişi gerçekten o” der, dizin sorgusu ise “bu kişi neye yetkili” sorusunu cevaplar. İkinci sorunun protokolünü LDAP nedir rehberimizde ele alıyoruz.

Yakalamadaki dağılım şöyle:

TGS-REQ satırlarında iki isim birden görünmesi tesadüf değil: Wireshark o çerçevede iki mesaj tipi birden raporluyor, 12 (TGS-REQ) ve 14 (AP-REQ). Sebebi şu: istemci TGT’sini KDC’ye ibraz ederken onu bir AP-REQ içine koyar. Yani TGT’nin gösterilmesi de bir bilet ibrazıdır; KDC bu noktada sıradan bir servis gibi davranır. Makalenin başında kurduğumuz “her kapıda belge gösterilir” kuralı KDC’nin kendi kapısı için de geçerli.

AS-REP paketini açtığımda protokolün kalbindeki asimetri gözle görünür hale geliyor. Aşağıdaki döküm bir ağaç: girintiler neyin neyin içinde olduğunu gösteriyor ve asıl mesele orada. Bakılacak dört yer var:

• cname: bileti kimin aldığı. Burada PCTEST01$, yani makine hesabı.
• ticket: biletin kendisi. İçindeki sname krbtgt diyorsa elinizdeki TGT’dir.
• ticket içindeki enc-part: biletin şifreli gövdesi. kvno alanı hangi anahtarla kilitlendiğini söyler.
• ticket dışındaki ikinci enc-part: aynı isimde ama bir seviye dışarıda duran ayrı bir blok. Bu makalenin en önemli ayrıntısı bu ikisinin farkı.

as-rep
    pvno: 5
    msg-type: krb-as-rep (11)
    padata: 1 item
        PA-DATA pA-ETYPE-INFO2
            etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
            salt: AD.SERCEBILISIM.COMhostpctest01.ad.sercebilisim.com
    crealm: AD.SERCEBILISIM.COM
    cname
        CNameString: PCTEST01$
    ticket
        tkt-vno: 5
        realm: AD.SERCEBILISIM.COM
        sname
            SNameString: krbtgt
            SNameString: AD.SERCEBILISIM.COM
        enc-part
            etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
            kvno: 2
            cipher: 4fcc2824c144df7f305d3758b80bce30...
    enc-part
        etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
        kvno: 4
        cipher: 573eb26fcbbf981b3a437287802fcff0...

Aynı pakette iki tane enc-part var ve anahtar numaraları farklı. Fark şurada:

Yani KDC tek bir cevapta iki farklı kilit kullanmış. Birincisi biletin gövdesini kilitliyor ve anahtarı yalnız KDC ile hedef serviste var; istemci o bloğu taşıyor ama içini göremiyor. İkincisi istemciye özel ve içinden oturum anahtarı çıkıyor, onu açabiliyor.

Makalenin başında “elinizdeki belgenin içini okuyamazsınız ama ibraz edebilirsiniz” demiştik. İşte o cümlenin paket karşılığı bu iki satır. Kapalı zarfı taşıyan kurye zarfın içindekini bilmez, ama zarfı doğru makama teslim edebilir.

salt değeri de öğretici: AD.SERCEBILISIM.COM + host + makine adı. Parolanın kendisi hiçbir yerde geçmiyor, geçen şey ondan türetilen anahtarın hangi tuzla üretileceği. Bütün yakalama boyunca okunabilir tek bir parola yok.

Son bir ayrıntı: bu akışın tamamı TCP 88 üzerinden geçti, UDP değil. Kerberos ikisini de kullanır; mesaj belirli bir boyutu aştığında Windows TCP’ye geçer ve pratikte modern ortamlarda çoğu akışı TCP’de görürsünüz. Filtrenizi yalnız UDP’ye kurarsanız hiçbir şey yakalayamazsınız.

Üçüncü Geçiş: Bilet KDC’ye Değil Servise Gidiyor

Yukarıdaki yakalamada AP-REQ’i hep TGS-REQ’in içine gömülü halde gördük. Gerçek üçüncü geçişi görmek için bir dosya paylaşımına eriştim ve yakalamayı tekrarladım:

143  TGS-REQ  → 192.168.1.10:88    sname: cifs/dc01.ad.sercebilisim.com
154  TGS-REP  ← 192.168.1.10
235  SMB2 Session Setup Request → 192.168.1.10:445   sname: cifs/dc01.ad.sercebilisim.com
245  SMB2 Session Setup Response ← 192.168.1.10

Port numaralarına bakın, bütün mesele orada. İstemci cifs/dc01.ad.sercebilisim.com biletini KDC’den 88’den alıyor, sonra o bileti servise 445’ten sunuyor. İkinci adımda Domain Controller’a kimlik doğrulama sorusu gitmiyor; giden şey SMB oturum açma isteğinin içine yerleştirilmiş biletin kendisi.

Makalenin başında “servis sizi doğrulamak için KDC’ye sormaz” demiştik. Kanıtı bu dört satır: dosya sunucusuyla konuşurken 88 numaralı porta tek bir paket bile gitmiyor.

Saat Kayınca Ne Oluyor? Ölçtük, ve Beklediğimiz Çıkmadı

Bu bölümdeki en öğretici sonuç bir deneyden geldi. İstemcinin saatini bilinçli olarak 400 saniye geri alıp (tolerans 300 saniye) akışı yeniden yakaladım. Beklenti netti: kimlik doğrulama duracak. Çıkan şu:

33   AS-REQ                                     →
39   KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED    ←   error-code: 25
73   AS-REQ (zaman damgalı, ama saat 400 sn geri)  →
79   KRB Error: KRB5KRB_AP_ERR_SKEW             ←   error-code: 37
113  AS-REQ (yeniden)                           →
120  AS-REP                                     ←   BAŞARILI

Bu altı satır sırayla şunu anlatıyor:

1. Çerçeve 33: İstemci her zamanki gibi boş bir talep gönderiyor.
2. Çerçeve 39: Bildiğimiz ret geliyor, “kanıt ekle” (error-code: 25).
3. Çerçeve 73: İstemci zaman damgasını ekleyip tekrar gönderiyor. Ama saati 400 saniye geri olduğu için damganın üstündeki saat yanlış.
4. Çerçeve 79: KDC bu sefer saat yüzünden reddediyor. Aradığımız hata bu: KRB_AP_ERR_SKEW, error-code: 37.
5. Çerçeve 113: İstemci pes etmiyor, bir kez daha deniyor.
6. Çerçeve 120: Ve bileti alıyor.

Son iki satır beklentiyi bozuyor. Saat hâlâ 400 saniye geriyken klist get başarılı döndü, paylaşıma erişim de çalıştı. Yani hata üretildi ama kimlik doğrulama durmadı.

Sebep hata paketinin içinde duruyor:

krb-error
    msg-type: krb-error (30)
    stime: Aug  7, 2026 21:10:09
    error-code: eRR-PREAUTH-REQUIRED (25)

KDC hatayı gönderirken kendi saatini de (stime) veriyor. Windows istemcisi bunu okuyup Kerberos zaman damgasını KDC’nin saatine göre düzeltiyor ve isteği tekrarlıyor. Yani protokol, saat farkını tek bir tur içinde kendi kendine telafi edebiliyor.

Sahadaki karşılığı şu: “saat kaydı, Kerberos durdu” cümlesi her ortamda doğru değil. Windows istemcilerin bulunduğu bir ağda saat dakikalarca kaymışken oturum açma çalışmaya devam edebilir ve arıza yalnız belirli cihazlarda görünür. Bir kullanıcıda çalışıp diğerinde çalışmayan kimlik doğrulama arızalarının bir kısmı buradan gelir. Saat toleransının kurulumu ve izlenmesi NTP ve saat senkronizasyonu rehberimizde ele alınıyor.

Kapıdaki köpek belgenin tarihini beğenmedi ve geri çevirdi. Ama aynı nefeste doğru tarihi de söyledi. Yolcu tarihi düzeltip tekrar uzattı ve içeri girdi. Kapı katı, ama sağır değil.

Kerberos Biletlerini Okumak: klist, Bilet Ömrü ve SPN

klist, bir Windows makinesinde o an önbellekte duran Kerberos biletlerini listeleyen komuttur ve Windows ile birlikte gelir, ayrıca kurulum gerektirmez. Teşhise buradan başlanır, çünkü bilet var mı yok mu sorusunun cevabı bütün akışı ikiye böler.

Komutu parametresiz çalıştırdığınızda tüm biletler listelenir. Lab’daki PCTEST01 üzerinde aldığım gerçek çıktı şu:

Current LogonId is 0:0x3e7

Cached Tickets: (2)

#0>     Client: pctest01$ @ AD.SERCEBILISIM.COM
        Server: krbtgt/AD.SERCEBILISIM.COM @ AD.SERCEBILISIM.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 8/7/2026 20:53:27 (local)
        End Time:   8/8/2026 6:53:27 (local)
        Renew Time: 8/14/2026 20:53:27 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: dc01.ad.sercebilisim.com

#1>     Client: pctest01$ @ AD.SERCEBILISIM.COM
        Server: HOST/dc01.ad.sercebilisim.com @ AD.SERCEBILISIM.COM
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate name_canonicalize
        Start Time: 8/7/2026 20:53:27 (local)
        End Time:   8/8/2026 6:53:27 (local)
        Renew Time: 8/14/2026 20:53:27 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: dc01.ad.sercebilisim.com

Bu iki kayıt, makalenin başında anlattığımız iki bilet türünün ta kendisi. Ayırt etmenin iki yolu var ve ikisi de bu çıktıda görünüyor:

• Server alanı. #0’da krbtgt/AD.SERCEBILISIM.COM yazıyor, yani bu bilet “bilet isteme hakkı”dır: TGT. #1’de HOST/dc01.ad.sercebilisim.com yazıyor, yani belirli bir servise erişim izni: servis bileti.
• initial bayrağı. Yalnız #0’da var. Bu bayrak biletin doğrudan parola doğrulamasıyla alındığını söyler; servis biletleri onu taşımaz, çünkü onlar TGT gösterilerek alınmıştır.

Süreler de teoriyi doğruluyor. Start Time 20:53:27, End Time ertesi sabah 6:53:27, yani tam 10 saat. Renew Time bir hafta sonrası, yani tam 7 gün. İkisi de Active Directory’nin varsayılanı ve hiçbir ayar değiştirilmemiş bir ortamda böyle çıkar.

Geri kalan alanların okunuşu:

• KerbTicket Encryption Type ve Session Key Type: kullanılan şifreleme. Burada AES-256. Eğer RC4-HMAC görüyorsanız ortamda eski bir yapılandırma var demektir ve sıkılaştırma adayıdır.
• ok_as_delegate: servisin, istemcinin kimliğini başka bir servise taşımasına izin verildiğini gösterir. Delegasyon konusuna bu bölümün sonunda döneceğiz.
• Kdc Called: bileti hangi Domain Controller’ın verdiği. Birden fazla DC olan ortamlarda arıza ararken ilk bakılacak alan budur.

Yalnızca TGT’yi görmek için klist tgt, önbelleği temizlemek için klist purge kullanılır. Temizlemek zararsızdır: bir sonraki erişimde biletler yeniden alınır.

Bu liste cebinizdeki belgelerin dökümüdür. Kapıdan geçerken hangi kâğıdı uzattığınızı, ne zaman aldığınızı ve ne zaman geçersizleşeceğini gösterir. Bir kimlik doğrulama arızasında ilk sorulacak soru da budur: cepte belge var mı, varsa hangisi eksik.

Bilet Ömrü Nereden Ayarlanır?

Bilet ömürleri makinede değil, domain politikasında tanımlıdır. Yol şudur: Computer Configuration > Windows Settings > Security Settings > Account Policies > Kerberos Policy. Buradaki dört ayar ömrü belirler ve varsayılanları aşağıdaki gibidir.

Bu değerleri değiştirmeden önce ne aldığınızı ve ne verdiğinizi bilin. Ömrü uzatmak KDC yükünü azaltır ve kullanıcıya konfor sağlar; aynı zamanda çalınmış bir biletin işe yarama süresini uzatır. Kısaltmak tersini yapar. Sahada gördüğüm hatalı müdahale neredeyse her zaman aynı yönde oluyor: bir arıza çıkıyor, tolerans ya da ömür büyütülüyor, arıza gizleniyor ve sebep yerinde kalıyor.

SPN Nedir? Kerberos’un En Sık Yanlış Yapılandırılan Parçası

SPN, bir servisin Kerberos dünyasındaki adıdır ve servis-sınıfı/makine-adı biçiminde yazılır. cifs/dosya01.ad.sercebilisim.com bir dosya paylaşımını, HTTP/portal.ad.sercebilisim.com bir web uygulamasını, MSSQLSvc/sql01.ad.sercebilisim.com:1433 bir SQL örneğini işaret eder.

Kural tek cümledir ve tüm SPN arızaları bu cümlenin ihlalinden doğar: bir SPN, domain içinde yalnızca bir hesaba kayıtlı olabilir. Aynı SPN iki hesapta göründüğünde KDC hangisini seçeceğini bilemez ve bilet üretmeyi reddeder.

Bir hesabın SPN kayıtlarını listelemek için setspn -L kullanılır. Lab’daki istemcinin gerçek çıktısı:

Registered ServicePrincipalNames for CN=PCTEST01,OU=Bilgisayarlar,OU=Genel_Mudurluk,OU=Lokasyonlar,DC=ad,DC=sercebilisim,DC=com:
        WSMAN/PCTEST01
        WSMAN/PCTEST01.ad.sercebilisim.com
        RestrictedKrbHost/PCTEST01
        HOST/PCTEST01
        RestrictedKrbHost/PCTEST01.ad.sercebilisim.com
        HOST/PCTEST01.ad.sercebilisim.com

Buradaki desen her makine hesabında aynıdır ve bir kez görünce SPN mantığı yerine oturur: her isim iki kez kayıtlı, biri kısa ad biri FQDN. Sebebi şu: istemci servise \\PCTEST01 diye de \\PCTEST01.ad.sercebilisim.com diye de bağlanabilir, ve KDC hangi biçim istendiyse onu dizinde bulmak zorundadır. Tek biçimi kaydedip diğerini unutmak, “kısa adla çalışıyor, FQDN ile çalışmıyor” arızasının en yaygın sebebidir.

Mükerrer kayıt taraması domain genelinde yapılır:

setspn -X

Sağlıklı bir ortamda çıktı şöyle biter:

Checking domain DC=ad,DC=sercebilisim,DC=com
found 0 group of duplicate SPNs.

Bu komut “uygulama bazen parola soruyor” tipi arızalarda bakılacak ilk yerdir. Çıktı boşsa sorun başka yerdedir; doluysa sorunu bulmuşsunuzdur.

Mükerrer SPN’in nasıl oluştuğu da hep aynıdır. Bir uygulama önce bir servis hesabıyla kurulur, sonra hesap değiştirilir ama eski hesaptaki SPN silinmez. Ya da uygulama makine hesabı altında çalışırken özel bir servis hesabına taşınır. İki hesap da aynı ismi iddia eder ve o andan itibaren Kerberos o servis için çalışmaz, sessizce NTLM’e düşülür.

Kerberos Teşhisi: Belirtiden Hata Koduna

Kerberos arızalarının teşhisi zordur, çünkü hata mesajlarında Kerberos kelimesi geçmez. Kullanıcı “oturum açamıyorum”, “paylaşıma giremiyorum” ya da “uygulama sürekli parola soruyor” der. Ekrandaki metin genellikle güven ilişkisinden, erişim reddinden veya etki alanına ulaşılamamasından bahseder. Kimlik doğrulama katmanına inmek teknisyenin kararıdır, mesaj oraya yönlendirmez.

Bu yüzden teşhis, hata kodundan değil belirtiden başlar. Aşağıdaki tablo sahada en sık karşılaşılan üç belirtiyi ilk bakılacak yere bağlar.

Hata kodunu eline aldığında ise anlamı şudur:

Sayısal karşılıklarını da veriyorum, çünkü Wireshark’ta arayacağınız alan kerberos.error_code ve orada kodun adı değil sayısı durur:

İlk iki satırı bu makale için lab ortamında bilerek ürettik ve paket düzeyinde doğruladık; geri kalanlar Microsoft’un teşhis dokümantasyonundan alınmıştır. Birinci satırı tabloya koymamın sebebi de bu: 25 bir arıza kodu değil, ama yakalamada gördüğünüzde ilk refleks onu arıza sanmak oluyor.

Kerberos ile NTLM Arasındaki Fark ve Sessiz Düşüş

Kerberos başarısız olduğunda Windows genellikle hata vermez: NTLM’e düşer. NTLM, Kerberos’tan önceki kimlik doğrulama yöntemidir ve bilet kullanmaz; istemci ile sunucu arasında meydan okuma/cevap (challenge/response) alışverişi yapılır, her erişimde Domain Controller’a sorulur.

İkisi arasındaki fark teşhis açısından belirleyici:

Son satır bu bölümün asıl konusu. NTLM’in SPN’e ihtiyacı olmadığı için, SPN yanlış yapılandırıldığında sistem çalışmaya devam eder. Kullanıcı erişebilir, kimse arıza bildirmez, ve ortamda Kerberos’un fiilen devre dışı olduğu bir servis sessizce yaşamaya başlar. Bu, SPN hatalarının aylarca fark edilmemesinin sebebidir.

Düşüşün olup olmadığını anlamak için biletin varlığına bakın:

klist get cifs/dosya01.ad.sercebilisim.com

Bilet alınabiliyorsa Kerberos çalışıyordur. KDC_ERR_S_PRINCIPAL_UNKNOWN alıyor ama uygulama yine de açılıyorsa, düşüş olmuş demektir. Sunucu tarafında da doğrulanabilir: Güvenlik günlüğündeki oturum açma olaylarında Authentication Package alanı Kerberos yerine NTLM gösterir.

Belge sisteminin işlemediği yerde kapı tamamen kapanmıyor, eski usule dönülüyor: görevli sizi tanıyor mu diye soruyor. İşliyor, ama iz bırakmıyor ve daha zayıf.

Teşhis Sırası

Bu sırayı bozmayın, çünkü her adım bir sonrakinin ön koşuludur ve alttaki katman bozukken üsttekini incelemek zaman kaybıdır.

1. KDC bulunabiliyor mu? İstemci Domain Controller’ı DNS’teki SRV kayıtlarından bulur. Bu kayıtlar yoksa Kerberos hiç başlamaz.

nslookup -type=SRV _kerberos._tcp.ad.sercebilisim.com

Çıktı dc01.ad.sercebilisim.com ve 88 portunu göstermelidir. Göstermiyorsa sorun Kerberos’ta değil, DNS’tedir; DNS nedir rehberimizdeki teşhis bölümüne geçin.

Sorgu boş dönüyor ama Domain Controller’ın sağlıklı olduğundan eminseniz, sonucu kabul etmeden önce aynı soruyu TCP üzerinden bir kez daha sorun:

Resolve-DnsName _kerberos._tcp.ad.sercebilisim.com -Type SRV -Server 192.168.1.10 -TcpOnly

DNS sorguları varsayılan olarak UDP ile gider ve UDP, yol üstündeki bir cihazın araya girmesine açıktır. Pek çok ev tipi modem ve bazı kurumsal güvenlik cihazları 53 numaralı UDP portundaki trafiği şeffaf biçimde kendi çözümleyicisine yönlendirir; siz iç sunucunuza sorduğunuzu sanırsınız, cevap başka yerden gelir. TCP aynı müdahaleye uğramaz. İki taşıma farklı cevap veriyorsa sorun sizin DNS sunucunuzda değil, yolun üstündedir.

Bu ayrımın pratik değeri şudur: aksi halde saatlerinizi sağlıklı bir sunucunun zone kayıtlarını incelemekle geçirirsiniz. Araya giren cihazı doğrulamanın hızlı yolu da, üzerinde hiçbir DNS sunucusu bulunmayan bir adrese sorgu göndermektir. Cevap geliyorsa o cevabı üreten, sorduğunuz makine değildir.

2. Saatler yakın mı? Fark 5 dakikayı aşıyorsa akış ilk mesajda durur.

w32tm /stripchart /computer:dc01.ad.sercebilisim.com /samples:5 /dataonly

Sapma bulduğunuzda refleks olarak w32tm /resync /force çalıştırırsınız ve komut büyük ihtimalle “The command completed successfully” der. Sonra tekrar ölçtüğünüzde sapmanın hiç değişmediğini görebilirsiniz. Lab’da tam olarak bu oldu: 128 saniyelik fark, resync öncesi ve sonrası aynı kaldı, üstelik servis hiçbir hata üretmedi (Last Sync Error: 0).

Sebep, Windows Time’ın MaxAllowedPhaseOffset ayarında yazılı:

MaxAllowedPhaseOffset: 300
Phase Offset:          -128.3335403s
State Machine:         1 (Hold)

Windows, sapma bu eşikten büyükse saati bir anda düzeltir (step); küçükse düzeltmez, saatin hızını değiştirerek yavaş yavaş kapatır (slew). 128 saniye eşiğin altında kaldığı için servis “acelesi yok” deyip Hold durumunda bekliyor.

Şimdi iki sayıya birlikte bakın: Windows’un atlatma eşiği 300 saniye, Kerberos’un toleransı da 300 saniye. Aynı sayı. Bunun pratik sonucu, sistemin en tehlikeli bölgeyi en sessiz geçmesidir: 300’ün hemen altındaki bir sapma Windows tarafından acil sayılmaz, saatlerce sürüklenerek taşınır, hiçbir uyarı üretmez, ama Kerberos’un kırılma noktasının bir adım berisinde durur. Cihaz o haldeyken biraz daha kayarsa kimlik doğrulama aniden durur ve o ana kadar hiçbir belirti görmemişsinizdir.

Bu yüzden resync komutunun çıktısına değil, komuttan sonraki ölçüme bakın. Sapma inmediyse eşiği geçici olarak düşürüp saati atlatmaya zorlamanız gerekir.

3. Bilet alınabiliyor mu? TGT var mı yok mu sorusu, arızanın AS aşamasında mı yoksa daha ileride mi olduğunu söyler.

klist tgt

4. Servis bileti alınabiliyor mu? TGT varken servis bileti yoksa sorun SPN tarafındadır.

klist
setspn -X

5. Hangi mesajda duruyor? Buraya kadar netleşmediyse Wireshark yakalaması alın ve KRB-ERROR mesajındaki error-code alanını yukarıdaki tabloyla eşleştirin.

Bu sıranın kıymeti şudur: dördüncü adıma kadar hiçbir sunucuya dokunmadınız, hiçbir ayar değiştirmediniz ve arızanın hangi katmanda olduğunu ölçtünüz. Kerberos arızalarında en pahalı hata, ölçmeden müdahale etmektir; tolerans büyütmek, hesap yeniden oluşturmak veya makineyi domain’den çıkarıp tekrar eklemek genellikle sebebi ortadan kaldırmaz, yalnız belirtiyi bir süreliğine siler. Makinenin domain’e katılma ön koşullarını bilgisayarı domaine ekleme rehberimizde, Active Directory mimarisinin tamamını ise Active Directory rehberimizde ele alıyoruz.

Sonuç: Kapıdaki Köpek Kimseyi Tanımaz

Kerberos’u anlaşılmaz kılan şey karmaşıklığı değil, görünmezliğidir. Doğru çalıştığında kimse varlığını fark etmez; kullanıcı sabah parolasını girer, gün boyu hiçbir yerde bir daha sorulmaz ve bunun arkasında altı ayrı mesajın aktığı aklına gelmez. Bozulduğunda ise kendini kendi adıyla tanıtmaz, başka bir şeyin arızası gibi görünür.

Bu makalede kurduğumuz zincir tam da bu boşluğu kapatmak içindi: adın kökeninden üç tarafa, üç taraftan bilet mantığına, biletten altı mesaja, mesajlardan hata kodlarına. Bir Kerberos arızasıyla karşılaştığınızda soracağınız soru artık “Kerberos neden çalışmıyor” değil, “akış hangi mesajda durdu” olmalı. İkincisinin cevabı ölçülebilir, birincisininki değil.

Kapıdaki köpek sizi tanımaz ve tanımak zorunda da değildir. Baktığı tek şey elinizdeki belgedir: geçerli mi, tarihi tutuyor mu, doğru makam mı vermiş. Kimlik doğrulamayı güvenilir kılan da budur, çünkü tanımaya dayanan bir sistem kandırılabilir; belgeye dayanan bir sistem ise ancak belge sahtelenirse kandırılır. Kerberos’un bütün tasarımı o belgeyi sahtelenemez kılmak üzerine kuruludur.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.