Bilet ömrü, yenileme ve hata durumları: Double-hop, SPN ve saat sorunlarını okumak.

1. Core Mechanism / Temel mekanizma

Ticket içindeki EncTicketPart ile KDC yanıtının ayrı enc-part alanı farklı korunur ve farklı taraflarca okunur. Yenileme, RENEW kullanan bir TGS değişimidir. KRB-ERROR okurken önce göndereni, isteği ve değişim aşamasını belirle; sonra kodu yorumla. Adı KRB_AP_ERR ile başlayan kod, hatanın application server’da oluştuğunu kanıtlamaz; KDC de AS/TGS isteğini işlerken bu namespace’i kullanabilir.

Arabirimler ve belirtimler

• RFC 4120 §§5.3 ve 5.4.2: Ticket içindeki EncTicketPart ile KDC-REP içindeki EncKDCRepPart ayrı yapılardır; zaman alanları her ikisinde yer alır, ancak farklı anahtarlarla korunur.
• RFC 4120 §§2.3/5.4.1: endtime mevcut geçerlilik sonudur; renew-till yenilemenin son sınırıdır. Bunlar ayrı alanlardır; renew-till genellikle daha ileridir ama değerlerin mutlaka farklı olması gerekmez.
• RFC 4120 §3.3 ve KDCOptions RENEW: mevcut bilet sunularak yeni endtime alınır; renew-till sabit kalır.
• RFC 4120 §5.9.1: KRB-ERROR ::= [APPLICATION 30]; error-code [6] Int32 hatanın sayısal kimliğidir, e-text [11] ve e-data [12] ek bilgidir.
• RFC 4120 §7.5.9 error kodları: KDC_ERR_S_PRINCIPAL_UNKNOWN 7, KDC_ERR_PREAUTH_FAILED 24, KDC_ERR_PREAUTH_REQUIRED 25, KRB_AP_ERR_TKT_EXPIRED 32 (0x20), KRB_AP_ERR_REPEAT 34 (0x22), KRB_AP_ERR_SKEW 37 (0x25), KRB_AP_ERR_MODIFIED 41 (0x29).
• Saat farkı, isteğin işlendiği bağlamda denetlenir. KDC pre-authentication hatası 4771/0x25 olarak görülebilir; servis de AP isteğini saat farkı nedeniyle reddedebilir. Aşamayı adlandırmadan önce event/mesaj kaynağını oku.
• Windows Security 4768 (Result Code), 4769 (Status) ve 4771 (Failure Code): KDC işlem kayıtları; bu alanlar yukarıdaki error namespace'in Windows'taki karşılığıdır ve yalnız DC'de üretilir.

Biletin saati nerede yazılı

Biletin geçerlilik penceresi EncTicketPart içindedir: authtime ilk kimlik doğrulama zamanını, starttime başlangıcı, endtime bitişi gösterir. starttime yoksa authtime başlangıç olarak kullanılır. Renewable biletlerde renew-till, yenilemeyle ulaşılabilecek son zamanı belirler. Bu bölüm TGT'de krbtgt anahtarıyla, service ticket'ta servis hesabının anahtarıyla şifrelenir.

İstemci biletin bu bölümünü açmaz; AS-REP veya TGS-REP yanıtının ayrı enc-part alanını açar. EncKDCRepPart içindeki authtime/starttime/endtime/renew-till değerleri, biletle birlikte verilen istemci bilgisidir. Ticket ve yanıtın enc-part alanı kardeştir: yanıtı okumak, biletin şifreli içini okumak değildir. İstemci zamanları öğrenebilir ama korunan bileti değiştirerek ömrünü uzatamaz.

endtime'ın gelecekte olması tek başına yeterli değildir; başlangıç da gelmiş olmalıdır. Örneğin servis saati 09:00, starttime 10:00 ve endtime 18:00 ise başlangıç saat toleransının ötesinde kalır: süresi dolmamış bu bilet henüz kullanılamaz. Servis starttime/endtime değerlerini kendi saati ve izin verilen clock skew ile değerlendirir; INVALID flag ve servis politikası gibi ek kontroller de kabulü etkiler.

endtime mevcut biletin geçerlilik sonudur; renew-till ise yenilemenin ulaşabileceği üst sınırdır. renew-till'in ileride olması, endtime'ı geçmiş mevcut bileti yeniden geçerli yapmaz. Yenileme için KDC ile ayrıca bir değişim gerekir.

Yenileme yeni bir bilet üretir, ömrü sınırsız uzatmaz

Renewable ticket, mevcut süresi dolmadan KDC’ye RENEW ile sunulabilir. Yenilenmiş örnek, renew-till ve policy sınırları içinde yeni session key ve bitiş zamanı alır; yenileme son sınırı sınırsız ileri taşımaz.

Renewable ticket, her seferinde yeni AS değişimi yapmadan oturumun belirli bir üst sınıra kadar sürmesini sağlar. Yenileme için renewable flag, renew-till, geçerli istek ve KDC koşulları birlikte gerekir. Yenilenebilir olması, ticket kopyasının yalnız meşru kullanıcı tarafından kullanılabileceğine dair ayrı bir güvence değildir; geçerlilik süresiyle credential sahipliğini karıştırma.

Yenileme mümkün değilse sıradaki değişimi hâlâ geçerli credential’lara göre seç. Süresi dolmuş veya artık yenilenemeyen service ticket, geçerli TGT varsa yeni TGS isteğiyle değiştirilebilir. Uygun geçerli TGT kalmadığında yeni AS değişimi gerekir. Credential geçerliliği, iptal kontrolleri ve aktif application session’ları ayrı koşullardır.

Hata kodundan önce değişim aşamasını belirle

Hata kodu bir başarısızlık koşulunu anlatır, tek bir değişim aşamasını değil. Önce AS, TGS veya AP isteğini ve hatayı döndüren endpoint’i belirle. KRB_AP_ERR namespace’indeki kodlar, isteği doğrulayan KDC tarafından da döndürülebilir.

Örneğin 4771/0x25, KDC tarafında TGT/pre-authentication bağlamındadır; 4769/0x20 ise TGS isteğinde KDC’ye sunulan kanıt biletiyle ilgilidir. Servisin AP reddi için o servisten kanıt gerekir. Sayısal kod tek başına bu konumları ayıramaz.

Aşağıdaki KRB-ERROR yapısı, error-code'un mesajın neresinde durduğunu gösterir. Bu dersin artifact'i tam da bu mesajın sentetik bir örneğidir.

KRB-ERROR ::= [APPLICATION 30] SEQUENCE {
        pvno            [0] INTEGER (5),
        msg-type        [1] INTEGER (30),
        stime           [4] KerberosTime,      -- KDC yaniti zamani
        susec           [5] Microseconds,
        error-code      [6] Int32,             -- hatanin sayisal kimligi
        realm           [9] Realm,             -- servis realm'i
        sname           [10] PrincipalName,    -- cozulmeyen SPN
        e-text          [11] KerberosString OPTIONAL,
        e-data          [12] OCTET STRING OPTIONAL
}
-- Bu ornekte error-code = 7 (KDC_ERR_S_PRINCIPAL_UNKNOWN): TGS asamasinda
-- istenen SPN hicbir hesaba kayitli degil. Hata AS/AP degil, TGS asamasinin kaydidir.

Double-hop: kimlik ikinci sıçramada kaybolur

tunahan WEB01'e bağlanıp WEB01 da DB01'e tunahan adına gitmek istediğinde, WEB01'in elindeki service ticket yalnızca 'tunahan WEB01'e kimliğini kanıtladı' bilgisini taşır. Delegation yoksa WEB01, DB01'e tunahan adına bir bilet isteyemez.

İkinci sıçramanın davranışı uygulamaya ve onun fallback tercihine bağlıdır: bağlantı servisin kendi kimliğiyle (computer/service account) denenebilir, hiç Kerberos isteği gönderilmeden başarısız olabilir ya da kaynakta reddedilebilir. Bu yüzden ikinci hop çoğu senaryoda bir KDC error-code'u üretmeyebilir; ancak bir KDC hatasının yokluğu, kök nedenin 'kimlik taşınamadı' olduğunun kesin kanıtı değildir. Double-hop çoğu zaman bir bilet hatası değil, bir yetkilendirme/uygulama davranışı sonucudur.

Çözüm bir hata düzeltmesi değil, delegation modelidir (06.06): constrained veya RBCD ile tunahan'ın kimliği ikinci sıçramaya taşınır. Bu yüzden 'access denied' görünce erken sorulardan biri 'bir KDC error-code'u üretildi mi ve hangi aşamayı gösteriyor' olmalıdır; kod varsa aşamayı okur, yoksa bu tek başına teşhis değildir ve kaynak host ile uygulama davranışına bakmak gerekir.

SPN ve saat: aynı belirti, farklı aşama

İstenen SPN hiçbir hesaba çözülemezse hata TGS aşamasındadır: KDC_ERR_S_PRINCIPAL_UNKNOWN (7 / 0x7). Ticket düzenlenmez; başarısız 4769 bu KDC sonucunu gösterebilir.

Aynı SPN birden fazla principal'a kayıtlıysa KDC, TGS aşamasında KDC_ERR_PRINCIPAL_NOT_UNIQUE (8 / 0x8) döndürebilir; belirsiz eşleşmede ticket'ı hangi anahtarla mühürleyeceğini seçmesi beklenmez. Farklı bir durum, SPN'in tek bir hesaba kayıtlı ama çalışan hedef servisin kullandığı hesaptan farklı olmasıdır: KDC ticket'ı kayıtlı hesabın anahtarıyla mühürler ve hedef AP aşamasında KRB_AP_ERR_MODIFIED ile reddedebilir.

Örneğin 4771/0x25, KDC tarafında TGT/pre-authentication bağlamındadır; 4769/0x20 ise TGS isteğinde KDC’ye sunulan kanıt biletiyle ilgilidir. Servisin AP reddi için o servisten kanıt gerekir. Sayısal kod tek başına bu konumları ayıramaz.

Durum ve veri akışı

1. starttime, endtime ve renew-till’i ayrı incele. endtime mevcut bitiştir; renew-till yenilemenin sınırıdır ve mutlaka daha ileri olmak zorunda değildir.
2. tunahan saatlerce çalışır; istemci endtime yaklaşınca TGS-REQ'i KDCOptions RENEW ile gönderir ve TGT'yi yeniler. Yeni endtime gelir ama renew-till aşılmaz.
3. Yenileme mümkün değil ama geçerli TGT varsa TGS üzerinden yeni service ticket iste. Uygun geçerli TGT kalmamışsa yeni AS değişimi gerekir.
4. tunahan DB01'e MSSQLSvc/DB01.iyelabs.example:1433 için bilet ister. SPN hiçbir hesaba kayıtlı değilse KDC TGS aşamasında KRB-ERROR error-code 7 (KDC_ERR_S_PRINCIPAL_UNKNOWN) döner; Uygun unknown-SPN failure logging ve audit/toplama koşullarında DC01’de başarısız 4769 (Status 0x7) görülebilir.
5. SPN yanlış hesaba kayıtlıysa bilet o hesabın anahtarıyla mühürlenir; DB01 kendi anahtarıyla açamaz ve AP aşamasında bütünlük hatası (KRB_AP_ERR_MODIFIED ailesi) döner.
6. Saat farkı farklı değişimlerde ret nedeni olabilir. 4771/0x25 gözlemi KDC’nin pre-authentication bağlamındadır; AP-only hata varsaymadan ilgili endpoint saatlerini incele.
7. WEB01 üzerinden double-hop gerekiyorsa ve delegation yoksa, ikinci sıçrama uygulamanın fallback'ine göre servis kimliğiyle denenebilir, Kerberos isteğine hiç ulaşmadan başarısız olabilir ya da kaynakta reddedilebilir; sonuç çoğu zaman 'access denied'tır ve bir KDC error-code'unun yokluğu kök nedenin kanıtı değildir.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım şudur: 'Elimde geçerli görünen bir bilet varsa istek başarılı olur.' Gerçekte bir bilet yalnızca kendi zaman penceresi (starttime–endtime) içindeyken, doğru servis anahtarıyla mühürlüyken ve alıcının saatiyle uyumluyken kabul edilir. Bu üç koşuldan biri bozulduğunda istek sessizce değil, belirli bir error-code ile çöker. Saldırgan açısından bu, 'eski bir bilet' veya 'yanlış servise bağlanmış bir varsayım' üzerine kurulan planların iz bırakan bir kodla başarısız olacağı anlamına gelir; error namespace hem saldırı hem savunma için bir haritadır.

Technical prerequisites

• Biletin başlangıcının gelmiş ve endtime'ının geçmemiş olması; servis saat toleransını da uygular. Başlangıcı toleransın ötesinde gelecekte kalan veya INVALID işaretli bilet AP aşamasında KRB_AP_ERR_TKT_NYV (33 / 0x21), süresi toleransın ötesinde dolan bilet KRB_AP_ERR_TKT_EXPIRED (32 / 0x20) ile reddedilir.
• Biletin hedef servisin güncel anahtar sürümüyle mühürlenmiş olması; anahtar döndüyse eski bilet AP aşamasında reddedilir.
• İstemci ile hedef/DC saatinin tolerans içinde (varsayılan 5 dk) olması; değilse KRB_AP_ERR_SKEW (0x25).
• Doğru SPN'e istek; yanlış SPN varsayımı TGS aşamasında KDC_ERR_S_PRINCIPAL_UNKNOWN (0x7) üretir ve hedef niyeti KDC'de görünür kılar.

Exploitation mechanism / İstismar mekanizması

Bu katman bir tek zafiyet değil, 'bayat bilet' ve 'yanlış bağlama' varsayımlarının nasıl gürültülü biçimde başarısız olduğunu ve savunma için nasıl sinyale döndüğünü açıklar. Bir authenticator yeniden oynatılırsa (replay) servis, replay cache sayesinde KRB_AP_ERR_REPEAT (0x22) döndürür; süresi geçmiş bir bilet KRB_AP_ERR_TKT_EXPIRED (0x20) üretir. Öte yandan uzun bilet ömrü ve uzun renew-till, çalınmış bir biletin yeniden kullanım penceresini büyütür: bu bir protokol açığı değil, bir politika seçimidir. Dolayısıyla saldırı tarafında 'ne kadar süre kullanılabilir' sorusunun yanıtı doğrudan endtime/renew-till politikasında yazılıdır ve hardening tam bu pencereyi hedefler.

Süresi geçmiş bilet ve replay: sessiz değil, kodlu başarısızlık

Endtime'ı geçmiş bir bilet sunmak KRB_AP_ERR_TKT_EXPIRED üretir; bu rutin bir durumdur ve tek başına saldırı anlamı taşımaz. Ama bir authenticator'ın yeniden oynatılması KRB_AP_ERR_REPEAT üretir ve bu, replay cache'in devrede olduğunu gösterir.

Yani biletle ilgili kötüye kullanım denemeleri protokol tarafında iz bırakır. 'Eski bir bileti yeniden kullanayım' varsayımı, çoğu zaman beklenen sonucu vermek yerine belirli bir hata koduyla geri döner.

Uzun bilet ömrü pencereyi büyütür

Bir bilet veya TGT çalındığında saldırganın kullanım süresi doğrudan endtime ve renew-till ile sınırlıdır. Politika bu değerleri gereksiz yere uzun tutuyorsa çalınmış kimliğin kullanım penceresi de uzar.

Bu bir zafiyet değil, ayarlanabilir bir risktir. Kısa bir user ticket lifetime ile makul bir renewal penceresi, meşru kullanımı bozmadan çalınmış bilet penceresini daraltır. Bu yüzden ömür değerleri savunma tarafında bir kontrol noktasıdır.

Sınır: kod bir aşamayı kanıtlar, saldırıyı değil

Bir error-code yalnızca 'şu aşama şu nedenle başarısız oldu' der; saldırı kanıtı değildir. KRB_AP_ERR_SKEW çoğunlukla saat sapmasına; KDC_ERR_S_PRINCIPAL_UNKNOWN eksik/çözülemeyen SPN’e; KDC_ERR_PRINCIPAL_NOT_UNIQUE duplicate SPN’e işaret eder. KRB_AP_ERR_MODIFIED ise ticket’ın hedef servis hesabının beklediği anahtarla açılamamasıyla, örneğin SPN’in yanlış service account’a kayıtlı olmasıyla görülebilir.

İyi huylu nedenler bu kodlarda baskındır. Bu yüzden bir kodu saldırı kanıtı saymak yerine, hangi aşamayı işaret ettiğini okuyup doğru gözlem noktasına (KDC mi, kaynak host mu) bakmak gerekir.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Audit Kerberos Authentication Service (yalnız DC): 4768 (TGT talebi, Result Code alanı) ve 4771 (pre-authentication başarısız, Failure Code alanı).
• Audit Kerberos Service Ticket Operations (yalnız DC): 4769 KDC'nin TGS aşamasındaki işlem kaydıdır; başarısız service ticket taleplerinde Status alanı KDC'nin verdiği TGS-aşaması sonucunu taşır (ör. 0x7 SPN çözülemedi). Bu alan hedef servisin bir service ticket'ı reddetmesini (AP aşaması) göstermez; 0x20 burada görünürse anlamı, TGS-REQ'te KDC'ye kanıt olarak sunulan TGT'nin süresinin dolmuş olmasıdır, hedef servisin ret kararı değil.
• AP aşaması hataları (KRB_AP_ERR_SKEW, KRB_AP_ERR_MODIFIED) kararın verildiği yerde, yani kaynak host tarafında (servis/System kayıtları) görünür; DC'de görünmeyebilir çünkü çözme/doğrulama orada yapılmaz. Bu nedenle bu AP hataları için hiç başarısız 4769 üretilmeyebilir ve olayı kaynak host'ta aramak gerekir.
• 4771, ilgili saat farkı hataları da dahil KDC pre-authentication başarısızlığını kaydeder. Daha sonraki servis tarafı AP hatası için kaynak kanıtı gerekir; 4771’in yokluğu tek başına hatanın yerini göstermez.
• Clock skew için ilgili endpoint'lerin saat ölçümünü karşılaştır; iki event'in TimeCreated farkı tek başına gerçek clock offset'i kanıtlamaz. İstek gecikmesi, olayın üretildiği host ve mesaj aşaması da ayrılmalıdır.
• Biletin zaman penceresini istemcinin cache bilgisinden ve KDC yanıtındaki zamanlardan incele; 4769 Status tek başına starttime/endtime değerlerini vermez. Hedefin henüz geçerli değil kararı ile KDC'nin ticket verme/yenileme sonucu farklı gözlem noktalarıdır.

Events and relevant fields

• 4769 / Status: 0x0 hata yok; 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN (istenen SPN çözülemedi, TGS aşaması); 0x20 KRB_AP_ERR_TKT_EXPIRED — bu KDC kaydında anlamı, TGS-REQ'te KDC'ye sunulan TGT'nin (kanıt biletinin) süresinin dolmuş olmasıdır, hedef servisin service ticket'ı reddi değil.
• 4771 / Status (Event Viewer’da Failure Code): 0x18 KDC_ERR_PREAUTH_FAILED, geçersiz pre-authentication bilgisi; yanlış parola sık görülen bir nedendir. 0x17 KDC_ERR_KEY_EXPIRED parola süresinin dolduğunu, pre-auth aşamasındaki 0x25 KRB_AP_ERR_SKEW saat farkı sınırının aşıldığını belirtir.
• 4768 / Status (Event Viewer’da Result Code): TGT talebinin sonucu; 0x0 başarıdır. Preauth içermeyen bir AS isteğine KDC 0x19 KDC_ERR_PREAUTH_REQUIRED dönebilir; istemci gerekli preauth ile yeniden denerse bu müzakere tek başına saldırı veya nihai başarısızlık değildir. Her istemcinin ilk turda bu yolu izleyeceğini varsayma.
• 4769 / ServiceName: service ticket istenen hesap veya bilgisayarın adı; tam requested SPN ile aynı alan değildir ve bazı kayıtlarda boş olabilir. Hangi SPN’in istendiğini ve çözülemediğini belirlemek için istemci/istek bağlamını ayrıca incele.
• 4769 / TicketOptions: talebin KDCOptions bit maskesi (forwardable, renewable gibi); bilet ömrü ve yenileme davranışını etkileyen bayrakları taşır.
• TimeCreated, DC olayının zaman damgasıdır. Tek başına offset ölçümü değildir; saat farkını uygun endpoint zaman gözlemleri ve istek bağlamıyla belirle.

Önce kaynağı, sonra kodu oku

Hata kodu bir başarısızlık koşulunu anlatır, tek bir değişim aşamasını değil. Önce AS, TGS veya AP isteğini ve hatayı döndüren endpoint’i belirle. KRB_AP_ERR namespace’indeki kodlar, isteği doğrulayan KDC tarafından da döndürülebilir.

Örneğin 4771/0x25, KDC tarafında TGT/pre-authentication bağlamındadır; 4769/0x20 ise TGS isteğinde KDC’ye sunulan kanıt biletiyle ilgilidir. Servisin AP reddi için o servisten kanıt gerekir. Sayısal kod tek başına bu konumları ayıramaz.

Source / request     Code example     Interpretation
4771 / KDC AS        0x25             Pre-authentication clock-skew failure
4769 / KDC TGS       0x20             Expired evidence ticket in TGS request
KDC / TGS reply      0x07             Requested service principal unresolved
Resource / AP        Context required Service-side ticket/authenticator checks
Code alone does not identify the exchange or prove an attack.

Aynı belirti, farklı kök neden

“Access denied” için beş olası açıklama: ikinci hop’a kimlik taşınmaması, SPN’in çözülememesi, duplicate SPN, ticket/key uyuşmazlığı veya saat farkı. Bunlar farklı kanıt gerektirir; bu ifade tek başına hiçbirini belirlemez.

Kod varsa onu bilinen istek ve endpoint bağlamında yorumla. KDC hatasının yokluğu teşhis değildir: uygulama kendi kimliğini kullanmış, Kerberos’a ulaşmadan başarısız olmuş veya kaynakta reddedilmiş olabilir. DC, kaynak ve uygulama kanıtını ayrı incele.

Detection logic · XPath

<!-- Ornek 4769 belgesi icinde basarisiz (Status != 0x0) service ticket taleplerini secer. -->
<!-- Bu yalnizca tek bir Event XML belgesi uzerindeki secimdir; cok-host zaman -->
<!-- korelasyonu yapmaz ve kaynak host'taki AP hatalarini gormez. -->
//*[local-name()='Event']
  [*[local-name()='System']/*[local-name()='EventID']='4769']
  [*[local-name()='EventData']/*[local-name()='Data'][@Name='Status'][normalize-space(text())!='0x0']]

Query assumptions

• XPath yalnızca verilen tek Event XML belgesi üzerinde seçim yapar; birden çok host veya zaman penceresi arasında korelasyon kurmaz.
• Status değeri metin olarak '0x0' biçiminde karşılaştırılır; bir backend değeri tamsayı olarak saklıyorsa eşleşme türü uyarlanmalıdır.
• AP aşaması hataları (skew, modified) bu 4769 seçiminde görünmez; onlar kaynak host tarafındaki kayıtlarda aranır ve bu AP hataları için hiç başarısız 4769 üretilmemiş olabilir. Bu ifade bu oturumda yalnızca örnek belge üzerinde denendi, canlı bir sistemde çalıştırılmadı.
• Status 0x20 (TGS-REQ'te KDC'ye sunulan TGT'nin süresi dolmuş) gibi rutin başarısızlıklar da seçilir; kod bazlı ikinci bir filtre olmadan sonuç gürültü içerir.

False positives

• Status 0x20, TGS-REQ'te KDC'ye sunulan TGT'nin (kanıt biletinin) süresinin dolmasıdır (rutin) ve çoğunlukla güvenlik anlamı taşımaz; hedef servisin service ticket'ı reddiyle (AP aşaması) karıştırılmamalıdır.
• Yanlış yazılmış veya henüz kaydedilmemiş SPN'ler 0x7 üretir; bu genellikle bir yapılandırma hatasıdır, saldırı değil.
• Negatif örnek: saldırgan zaten geçerli bir bilete sahipse başarılı 4769 (Status 0x0) üretir ve bu filtre onu hiç görmez. Başarısızlık seçimi bir kapsam sınırıdır, kanıt değildir.

Hardening

• Kerberos Policy'de 'Maximum lifetime for user ticket' (varsayılan 10 saat) ve 'Maximum lifetime for user ticket renewal' (varsayılan 7 gün) değerlerini ihtiyaç temelinde tut; gereksiz uzun ömür, çalınmış biletin kullanım penceresini büyütür.
• Saat senkronizasyonunu (W32Time) DC hiyerarşisine hizala; MaxClockSkew varsayılanı 5 dakikadır ve düşürmeden önce en yavaş/mobil istemcinin gerçek sapmasını ölç, yoksa meşru kimlik doğrulama kırılır.
• SPN’leri envanterle ve tekilleştir: duplicate kayıtlar KDC’de TGS KDC_ERR_PRINCIPAL_NOT_UNIQUE (0x8) doğurabilir; SPN tekil ama yanlış service account’a bağlıysa kayıt sahibini düzelt ve hedefte KRB_AP_ERR_MODIFIED (0x29) olasılığını araştır.
• Double-hop gereksinimini unconstrained delegation ile değil, constrained veya RBCD ile karşıla (06.06); böylece kimlik taşıma kapsamı daraltılır.
• Başarısız 4769/4771 kayıtlarını error-code'a göre grupla ve rutin kodları (0x20, 0x19) ayır; yalnızca beklenmedik kod dağılımlarını incele.
• Doğrulama adımı: değişiklik sonrası aynı iş akışını tekrarla; 4769 Status 0x0 dönmeli, istemci–DC saat farkı tolerans içinde olmalı ve hedef SPN tekil olmalı.

Örnekler üzerinde oku / Read the examples

7e 81 8e 30 81 8b a0 03 02 01 05 a1 03 02 01 1e
a4 11 18 0f 32 30 32 36 30 39 32 39 30 36 31 35
33 30 5a a5 03 02 01 00 a6 03 02 01 07 a9 11 1b
0f 49 59 45 4c 41 42 53 2e 45 58 41 4d 50 4c 45
aa 30 30 2e a0 03 02 01 02 a1 27 30 25 1b 08 4d
53 53 51 4c 53 76 63 1b 19 44 42 30 31 2e 69 79
65 6c 61 62 73 2e 65 78 61 6d 70 6c 65 3a 31 34
33 33 ab 1d 1b 1b 4b 44 43 5f 45 52 52 5f 53 5f
50 52 49 4e 43 49 50 41 4c 5f 55 4e 4b 4e 4f 57
4e

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" />
    <EventID>4769</EventID>
    <Version>2</Version>
    <Level>0</Level>
    <Task>14337</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8010000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T06:15:30.4120000Z" />
    <EventRecordID>20714</EventRecordID>
    <Correlation />
    <Execution ProcessID="712" ThreadID="1180" />
    <Channel>Security</Channel>
    <Computer>DC01.iyelabs.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">tunahan@IYELABS.EXAMPLE</Data>
    <Data Name="TargetDomainName">IYELABS.EXAMPLE</Data>
    <Data Name="ServiceName">MSSQLSvc/DB01.iyelabs.example:1433</Data>
    <Data Name="ServiceSid">S-1-0-0</Data>
    <Data Name="TicketOptions">0x40810000</Data>
    <Data Name="TicketEncryptionType">0xffffffff</Data>
    <Data Name="IpAddress">::ffff:192.0.2.60</Data>
    <Data Name="IpPort">52140</Data>
    <Data Name="Status">0x7</Data>
    <Data Name="LogonGuid">{00000000-0000-0000-0000-000000000000}</Data>
    <Data Name="TransmittedServices">-</Data>
  </EventData>
</Event>

İki yanlış kanı / Two reality checks

Sanılan: Bilet yenileme, biletin ömrünü istendiği kadar uzatır.

Gerçekte: Yenileme mümkün değilse sıradaki değişimi hâlâ geçerli credential’lara göre seç. Süresi dolmuş veya artık yenilenemeyen service ticket, geçerli TGT varsa yeni TGS isteğiyle değiştirilebilir. Uygun geçerli TGT kalmadığında yeni AS değişimi gerekir. Credential geçerliliği, iptal kontrolleri ve aktif application session’ları ayrı koşullardır. RFC 4120 §§2.3/5.4.1: endtime mevcut geçerlilik sonudur; renew-till yenilemenin son sınırıdır. Bunlar ayrı alanlardır; renew-till genellikle daha ileridir ama değerlerin mutlaka farklı olması gerekmez.

Sanılan: Double-hop hatası bir saat veya SPN sorunudur; error-code'a bakmaya gerek yok.

Gerçekte: Double-hop, kimliğin ikinci sıçramada taşınamamasıdır; ikinci hop'un davranışı uygulamaya bağlıdır — servis kendi kimliğiyle deneyebilir, Kerberos isteğine hiç ulaşmadan başarısız olabilir ya da kaynakta reddedilebilir — bu yüzden çoğu zaman bir KDC error-code'u üretmez. Ancak bu kodun yokluğu, kök nedenin kimlik taşıma olduğunun kanıtı değildir. Saat sorunu (KRB_AP_ERR_SKEW, 0x25) ve SPN sorunu (KDC_ERR_S_PRINCIPAL_UNKNOWN, 0x7) ise belirgin error-code üretir. Bu yüzden 'access denied' görünce 'bir KDC error-code'u var mı ve hangi aşamayı gösteriyor' diye bakmak yardımcı olur; kod yoksa teşhis kaynak host ve uygulama davranışıyla tamamlanır.

Kaynaklar / Sources

• RFC 4120 · The Kerberos Network Authentication Service (V5)
  §2.3 Renewable tickets (renew-till üst sınırı); §3.3 TGS renewal; §5.3 EncTicketPart (authtime/starttime/endtime/renew-till); §5.9.1 KRB-ERROR ([APPLICATION 30], error-code/e-text/e-data); §7.5.9 error kod tablosu (7, 24, 25, 32, 34, 37, 41). §§3.2.3, 5.4.2: başlangıç/bitiş kontrolü ve istemcinin açabildiği ayrı yanıt kısmı.
• Microsoft · 4769(S, F) A Kerberos service ticket was requested
  Event XML (Failure); Status/Failure Code tablosu (0x0, 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN, 0x20 KRB_AP_ERR_TKT_EXPIRED); ServiceName, ServiceSid (başarısızlıkta NULL), TicketEncryptionType 0xffffffff, LogonGuid alanları.
• Microsoft · 4768(S, F) A Kerberos authentication ticket (TGT) was requested
  Result Code / Failure Code tablosu; 0x19 KDC_ERR_PREAUTH_REQUIRED (rutin ilk tur), 0x18 KDC_ERR_PREAUTH_FAILED; Audit Kerberos Authentication Service, yalnız DC.
• Microsoft · 4771(F) Kerberos pre-authentication failed
  Failure Code alanı ve değer tablosu (0x18 preauth failed, 0x17 key expired, 0x25 clock skew); pre-authentication aşaması; yalnız DC.
• Microsoft · Maximum tolerance for computer clock synchronization
  İstemci–DC azami saat farkı varsayılan 5 dakika; replay saldırısı gerekçesi; Account Policies\Kerberos Policy.
• Microsoft · Maximum lifetime for user ticket
  Kullanıcı bileti azami ömrü varsayılan 10 saat; ilgili 'Maximum lifetime for user ticket renewal' varsayılan 7 gün; Account Policies\Kerberos Policy.
• Microsoft · KDC configuration and unknown-SPN failure audit
  KdcExtraLogLevel unknown-SPN error logging; protocol failure versus collected Security4769. No registry action performed.