Active Directory'de Kerberos Kimlik Doğrulama Akışı ve Adımları

Kerberos, Active Directory ortamında kimlik doğrulamanın varsayılan yoludur. Bir kullanıcı sabah bilgisayarını açıp parolasını yazdığında, bir dosya paylaşımına girdiğinde, bir intranet uygulamasına bağlandığında veya Outlook ile Exchange Server'a eriştiğinde arka planda çalışan protokol budur. Windows 2000 ile birlikte Active Directory'nin standardı haline gelmiş ve o günden beri NTLM'in yerini almıştır.

NTLM'e göre daha güvenli olmasının nedeni basittir. NTLM'de parolanın Hash'i her doğrulamada Domain Controller'a taşınırken Kerberos'ta parola ve türevleri Client'tan hiç çıkmaz. NTLM'de yalnızca Client kendini kanıtlarken Kerberos'ta sunucu da Client'a kendini kanıtlayabilir. NTLM'de her erişim Domain Controller'a gidip gelirken Kerberos'ta bir kez alınan bilet süresi boyunca yeniden kullanılır.

Bu kadar yaygın ve NTLM'den bu kadar üstün olmasına karşın pek çok sistem yöneticisi Kerberos'un içini bilmez. Çalıştığı sürece fark edilmez, bozulduğunda ise ne olduğu anlaşılmaz. Eksik bir SPN, Domain Controller ile beş dakikadan fazla sapan bir sistem saati veya yanlış hesap altında çalışan bir servis, kullanıcının önüne çoğu zaman anlamsız bir Access Denied hatası olarak çıkar. Sorunun nerede olduğunu bulmak için Network Trace'ini, Security Log'daki kayıtları ve klist çıktısını okuyabilmek gerekir. Bunun için de protokolün her adımda ne gönderdiğini bilmek şarttır.

Kerberos'un mantığı üç cümleye sığar.

✔ Parola hiçbir zaman Network üzerinden geçmez.
✔ Client hiçbir bileti açamaz; biletleri yalnızca KDC ve hedef servis açabilir.
✔ Kullanıcının kim olduğu ve hangi gruplarda bulunduğu biletin içinde taşınır.

Bu üç cümle akılda tutulduğunda AS-REQ, TGS-REQ ve AP-REQ gibi adımlar ezberlenecek kısaltmalar olmaktan çıkar; her biri belirli bir anahtarla belirli bir verinin şifrelendiği basit bir zincire dönüşür.

Bu yazıda klasik On-Premises Active Directory senaryosu anlatılır. KDC rolünü Domain Controller üstlenir, Client tarafında Windows çalışır, hedef servis ise Domain'e katılmış bir dosya sunucusudur. Şifreleme türü olarak günümüz ortamlarının varsayılanı olan AES256 esas alınır. Hybrid ortamlarda Microsoft Entra ID tarafındaki oturumlar farklı protokollerle yürür; ancak On-Premises dosya sunucularına, SQL Server'lara ve Exchange Server'a erişim hala Kerberos ile yapılır. Dolayısıyla Domain'e bağlı tek bir kaynak var olduğu sürece bu akışı bilmek gerekir.

Aşağıdaki bölümler, kullanıcının parolasını yazmasından dosya paylaşımına erişim almasına kadar geçen süreci altı adımda ele alır. Önce Domain Controller'ın KDC olarak nasıl çalıştığı ve Client tarafında LSASS'ın rolü açıklanır. Ardından AS-REQ, AS-REP, TGS-REQ, TGS-REP, AP-REQ ve isteğe bağlı AP-REP adımları sırayla işlenir. Her adımda ne gönderildiği, hangi anahtarın kullanıldığı, karşı tarafın neyi kontrol ettiği ve hata durumunda Security Log'da hangi kaydın oluştuğu anlatılır. Yazının sonunda tüm akış tek bir tabloda toplanır.

Temel Bilgi

Kerberos akışında Domain Controller, Key Distribution Center (KDC) olarak çalışır. Bu rol, Domain Controller üzerindeki Kerberos Key Distribution Center servisi tarafından yürütülür ve services.msc içinde aynı adla görülebilir. Servis, Domain Controller rolüyle birlikte otomatik olarak kurulur, Automatic olarak başlar ve elle yönetilmesi gerekmez. Çalışmadığı bir Domain Controller, Kerberos açısından hiç yokmuş gibi davranır.

KDC tek bir servis gibi görünse de mantıksal olarak iki alt hizmetten oluşur.

1. Authentication Service (AS): Kullanıcının kimliğini parolasıyla doğrular ve karşılığında bir Ticket Granting Ticket (TGT) verir.

2. Ticket Granting Service (TGS): Elinde geçerli bir TGT olan Client'a, erişmek istediği hedef servis için bir Service Ticket (ST) düzenler.

İki hizmet aynı süreç içinde çalışır ve aynı 88 numaralı TCP ve UDP Port'unu dinler; ayrım, gelen isteğin türüne göre yapılır. Aşağıdaki diyagram, Client, KDC ve hedef servis arasında geçen altı adımı sırasıyla ve numaralarıyla gösterir; ilerleyen bölümler bu numaraları takip eder.



Bu iki alt hizmet ve hedef servis, akışın altı adımını üç çifte böler. Her çift bir öncekinin çıktısını girdi olarak kullanır.

1. AS çifti (adım 1 ve 2): KDC'nin AS alt hizmeti ile konuşulur. Paroladan TGT üretilir. Şifreleme anahtarı, paroladan türetilen Derived Key'dir.

2. TGS çifti (adım 3 ve 4): KDC'nin TGS alt hizmeti ile konuşulur. TGT'den Service Ticket üretilir. Şifreleme anahtarı, AS-REP ile gelen Session Key'dir.

3. AP çifti (adım 5 ve 6): KDC devrede değildir, doğrudan hedef servisle konuşulur. Service Ticket sunulur. Şifreleme anahtarı, TGS-REP ile gelen Service Session Key'dir.

Her çiftte anahtar değişir; bir önceki adımın verdiği anahtar bir sonraki adımın kilidini açar. 

Adını Yunan mitolojisinde Hades'in kapısını bekleyen üç başlı köpek Kerberos'tan alır. MIT'de Project Athena kapsamında tasarlanırken bu isim, kimlik doğrulamanın üç taraf arasında geçmesine atıfla seçilmiştir. Üç baş Client, KDC ve hedef servisi simgeler; AS, TGS ve AP mesaj çiftleri ise bu tarafların arasındaki konuşmalardır.



Her iki görselde de Client kutusunun altında LSASS yazmasının sebebi, Client tarafında bu sürecin tamamını Local Security Authority Subsystem Service (LSASS) sürecinin yürütmesidir. lsass.exe, Windows'ta kimlik doğrulamadan sorumlu sistem sürecidir. Kullanıcının parolasından türetilen anahtarlar, KDC'den alınan Session Key'ler ve biletler yalnızca bu sürecin belleğinde tutulur. Uygulamalar Kerberos'u doğrudan konuşmaz; SSPI üzerinden LSASS'tan bilet talep eder ve LSASS gerekirse KDC ile konuşarak bileti sağlar. Bu yüzden bir Kerberos sorununu incelerken bakılacak yer uygulamanın kendisi değil, LSASS'ın bilet önbelleğidir. Zincirin ilk halkası AS-REQ'tur ve aşağıda oradan başlanır. 

1. Authentication Service Request (AS-REQ)

Client Tarafı

Akış, kullanıcının Windows oturum açma ekranına kullanıcı adını ve parolasını yazmasıyla başlar. Oturum açma ekranı bu bilgileri LSASS'a teslim eder ve bundan sonraki her şey LSASS içinde gerçekleşir.

Kullanıcı adı, örneğin mehmet.kaya, KDC'ye Plaintext olarak, yani düz metin halinde gider. Bu bir güvenlik zaafı değildir. Bu aşamada henüz kurulmuş bir güvenli oturum yoktur ve KDC'nin, gelen isteği hangi hesabın anahtarıyla doğrulayacağını bilmesi gerekir. Kullanıcı adı olmadan KDC, veritabanındaki binlerce hesaptan hangisinin anahtarını deneyeceğini bilemez.

Parola, örneğin P@ssw0rd!, hiçbir biçimde ağa çıkmaz. Bunun yerine LSASS beş adımlık bir işlem yürütür.

1. Derived Key türetilir: LSASS, parolayı bir Salt ile birleştirip AES256 tabanlı bir Derived Key üretir. Kullanıcı hesapları için Salt, büyük harfli Realm adı ile kullanıcı adının birleşimidir; ABC.LOCALfirat.boyan gibi. Salt sayesinde aynı parolayı kullanan iki farklı kullanıcının anahtarı birbirinden farklı olur.

2. Anahtar bellekte tutulur: Derived Key diske yazılmaz, yalnızca LSASS'ın belleğinde tutulur.

3. Anahtar sabittir: Aynı kullanıcı için parola değişmediği sürece Derived Key her zaman aynıdır, çünkü türetme fonksiyonu deterministiktir.

👉 Aşağıda örnek bir AES256 Derived Key görülüyor.

0x9A 4F B3 12 7D E8 6C 5A 99 23 88 1F 74 20 5D 67
  3E 42 91 56 AA 7B 44 98 FE 1A C0 11 3F 9D 2C 77

4. Timestamp oluşturulur: LSASS, o anki sistem saatinden bir Timestamp üretir.

5. Timestamp şifrelenir: Timestamp, Derived Key ile şifrelenir. Ortaya çıkan şifreli veriye Cipher denir ve KDC'ye giden istekte parolanın yerini bu Cipher alır.

👉 Aşağıda örnek bir Cipher görülüyor.

0x09 D2 F6 BE D5 DA 49 61 AF 86 C5 2E FC 46 8D 0D
0xB2 A5 82 21 FE 55 2E 31 AA C8 E5 1D 96 08 A8 57
0xD2 F6 EA E5 9D AA 2D 3A D4 AF 74 CB 48 29 D5 C6
0xF9 60 A0 D9 DB 82 F9 49

Sonuç olarak AS-REQ'un içeriği iki parçadan ibarettir: düz metin kullanıcı adı ve Derived Key ile şifrelenmiş Timestamp.

Bu şifreli Timestamp, Pre-Authentication mekanizmasıdır. Kerberos'un ilk sürümlerinde bu adım yoktu; herkes herhangi bir kullanıcı adına TGT talep edebiliyor ve dönen cevap üzerinde çevrimdışı parola denemesi yapabiliyordu. Pre-Authentication bu açığı kapatır ve Active Directory'de varsayılan olarak zorunludur. Kapatılması yalnızca hesap bazında, hesap özelliklerindeki Do not require Kerberos preauthentication seçeneğiyle mümkündür. Bu seçenek AS-REP Roasting adı verilen saldırının önünü açtığı için üretim ortamında kullanılmamalıdır.

Network Trace'inde bakıldığında Windows Client'ın AS-REQ'u iki kez gönderdiği görülür. İlk istek şifreli Timestamp olmadan gider. KDC buna KDC_ERR_PREAUTH_REQUIRED hatasıyla cevap verir ve bu hatanın içinde Client'ın kullanması gereken şifreleme türünü ve Salt değerini bildirir. Client ikinci isteği şifreli Timestamp ile gönderir ve asıl doğrulama bu ikinci istekte yapılır.

Authentication Service Tarafı

AS, gelen isteği kullanıcı adına göre NTDS.DIT veritabanındaki hesapla eşleştirir ve hesabın anahtarını okur. Active Directory, bir kullanıcının parolası ilk kez belirlendiğinde veya değiştirildiğinde AES256, AES128 ve RC4 anahtarlarını hesaplar ve hesabın supplementalCredentials Attribute'u içinde saklar. Dolayısıyla AS her istekte anahtarı yeniden türetmez; veritabanında hazır duran AES256 anahtarını doğrudan kullanır. Bu anahtar, Client'ın kendi parolasından türettiği Derived Key ile bire bir aynıdır, çünkü iki taraf da aynı parolayı, aynı Salt'ı ve aynı türetme fonksiyonunu kullanmıştır.

AS bu anahtarla Cipher'ı açar, içinden Timestamp'i çıkarır ve üç ayrı kontrol yapar.

1. Parola kontrolü: Cipher'ın açılabilmesi, kullanıcının doğru parolayı girdiğinin kanıtıdır. Yanlış parola girilseydi Client farklı bir Derived Key üretecek, KDC'nin elindeki anahtar Cipher'ı açamayacak ve KDC_ERR_PREAUTH_FAILED dönecekti. Bu durumda hesabın badPwdCount değeri artar ve Domain Controller'ın Security Log'una Event ID 4771 yazılır. Hesap kilitlenmelerini araştırırken 4771 kayıtlarındaki Client Address alanı, yanlış parolayı hangi makinenin gönderdiğini gösterir.

2. Saat kontrolü: Açılan Timestamp, KDC'nin kendi saatiyle karşılaştırılır. Varsayılan tolerans 5 dakikadır ve bu değere Clock Skew denir. Amaç, ele geçirilmiş bir AS-REQ paketinin daha sonra tekrar gönderilmesini, yani Replay Attack'i engellemektir. Client ile Domain Controller arasındaki fark 5 dakikayı aşarsa KRB_AP_ERR_SKEW döner ve kullanıcı doğru parolayı girse bile oturum açamaz. Sanal makinelerde geri alınan Snapshot'lar ve bozuk Windows Time hiyerarşisi bu hatanın en sık nedenleridir.

3. Hesap kontrolü: Hesap devre dışıysa, kilitliyse, süresi dolmuşsa veya oturum açma saatleri dışındaysa TGT verilmez ve KDC_ERR_CLIENT_REVOKED döner.

Üç kontrol de geçildiğinde Security Log'a Event ID 4768 yazılır. Bu kayıt, o kullanıcı için bir TGT düzenlendiğini gösterir ve kullanıcının hangi Domain Controller'da, hangi şifreleme türüyle Authentication olduğunu takip etmenin en doğrudan yoludur.

A Kerberos authentication ticket (TGT) was requested.

Account Information:
    Account Name:                   firat.boyan
    Supplied Realm Name:            ABC
    User ID:                        ABC\firat.boyan
    MSDS-SupPortedEncryptionTypes:  0x27 (DES, RC4, AES-Sk)
    Available Keys:                 AES-SHA1, RC4

Service Information:
    Service Name:                   krbtgt
    Service ID:                     ABC\krbtgt
    MSDS-SupPortedEncryptionTypes:  0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
    Available Keys:                 AES-SHA1, RC4

Domain Controller Information:
    MSDS-SupPortedEncryptionTypes:  0x1F (DES, RC4, AES128-SHA96, AES256-SHA96)
    Available Keys:                 AES-SHA1, RC4

Network Information:
    Client Address:                 2a02:ff0:23c:45f3:31f4:544d:679f:41a
    Client Port:                    62164
    Advertized Etypes:
        AES256-CTS-HMAC-SHA1-96
        AES128-CTS-HMAC-SHA1-96
        RC4-HMAC-NT
        DES-CBC-MD5

Additional Information:
    Ticket Options:                 0x40810010
    Result Code:                    0x0
    Ticket Encryption Type:         0x12
    Session Encryption Type:        0x12
    Pre-Authentication Type:        2
    Pre-Authentication EncryptionType: 0x12

Kayıtta dikkat edilecek alanlar aşağıdaki tabloda verilmiştir.

AS-REQ'un tüm amacı tek cümleye sığar. Client "ben bu kişiyim ve parolasını biliyorum" der; AS de bunu aynı anahtarla Cipher'ı açarak doğrular. Parola bu süreçte Network üzerinden bir kez bile geçmemiştir. 

2. Authentication Service Response (AS-REP)

Doğrulama başarılı olduğunda AS, Client'a iki parça veri döner.

1. Session Key: AS tarafından rastgele üretilen ve Client ile TGS arasındaki sonraki iletişimde kullanılacak geçici simetrik anahtardır. Client'ın Derived Key'i ile şifrelenerek gönderilir; dolayısıyla yalnızca doğru parolayı bilen Client bunu açabilir. LSASS, belleğindeki Derived Key ile şifreyi çözer ve ham Session Key'e ulaşır. Bu noktadan sonra Derived Key'in görevi biter; parola ve ondan türetilen anahtar akışta bir daha kullanılmaz.

2. TGT (Ticket Granting Ticket): Kullanıcının kimliğinin KDC tarafından doğrulandığını kanıtlayan bilettir. İçinde üç şey bulunur. Kullanıcının SID'i ve grup üyelikleri; bu bilgiler PAC (Privilege Attribute Certificate) adı verilen, Windows'a özgü ve KDC tarafından imzalanan bir yapıda taşınır, Client bu imzayı üretemez. Session Key'in bir kopyası. Biletin geçerlilik süresi.

Varsayılan Kerberos Policy'de bir TGT 10 saat geçerlidir ve 7 güne kadar yenilenebilir. Bu değerler Default Domain Policy altındaki Kerberos Policy bölümünde tutulur. Group Policy Management Editor'ı açmadan, doğrudan SYSVOL'daki ilke dosyasından okumak için Domain Controller'da aşağıdaki komut kullanılabilir. Komuttaki GUID, Default Domain Policy'nin her Domain'de aynı olan sabit kimliğidir.

Get-Content "\\abc.local\SYSVOL\abc.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\MACHINE\Microsoft\Windows NT\SecEdit\GptTmpl.inf" | Select-String "Kerberos Policy" -Context 0,5

Komutun çıktısı beş değer döndürür.

[Kerberos Policy]
MaxTicketAge = 10
MaxRenewAge = 7
MaxServiceAge = 600
MaxClockSkew = 5
TicketValidateClient = 1

Komut çıktısındaki değerlerin anlamı aşağıdaki tabloda verilmiştir.

Bu değerler Group Policy ile değiştirilebilir; ancak varsayılanlar Microsoft'un önerdiği dengeyi yansıtır ve üretim ortamında somut bir gerekçe olmadan değiştirilmemelidir.

TGT'nin en önemli özelliği, KRBTGT hesabının long-term anahtarıyla şifrelenmiş olmasıdır. KRBTGT, her Active Directory Domain'inde otomatik olarak var olan ve devre dışı görünen özel bir hesaptır; anahtarı yalnızca Domain Controller'lar bilir. Hesap, Active Directory Users and Computers içinde Users container'ında Key Distribution Center Service Account açıklamasıyla görülür.



KRBTGT anahtarının yalnızca Domain Controller'larda bulunmasının iki sonucu vardır.

1. Client TGT'yi açamaz: Client, TGT'nin içeriğini ne okuyabilir ne de değiştirebilir. Bileti olduğu gibi saklar ve sonraki adımlarda TGS'ye sunar.

2. Parola bir daha sorulmaz: TGT'nin amacı, kullanıcının parolasını her servis erişiminde yeniden sormadan, süresi boyunca Service Ticket alabilmesini sağlamaktır.

AS-REP tamamlandığında Client'ın elinde iki şey vardır. Açabildiği ve LSASS belleğinde tuttuğu Session Key ile açamadığı ama saklayacağı TGT. Bilet önbelleğinin o anki durumu Client üzerinde aşağıdaki komutla görülebilir.

klist

klist, o oturumda alınmış tüm biletleri numaralı olarak listeler. Aşağıdaki ekran görüntüsü, oturum açıldıktan hemen sonra alınan çıktıdır ve iki bilet içerir.

#0 numaralı bilet - Ticket Granting Ticket (TGT)

#1 numaralı bilet - Service Ticket (ST)

3. Ticket Granting Service Request (TGS-REQ)

Client Tarafı

Kullanıcı oturum açtıktan bir süre sonra bir dosya sunucusundaki paylaşıma, bir intranet uygulamasına veya bir SQL Server'a erişmek ister. Bunun için LSASS, TGS'ye üç parçadan oluşan bir istek gönderir.

1. TGT: AS-REP'te alınan ve KRBTGT anahtarıyla şifreli olan bilet. Client bunu açamaz ve olduğu gibi iletir. TGT'nin burada sunulması, KDC'ye "kimliğim daha önce doğrulandı, işte kanıtı" demenin yoludur.

2. Authenticator: LSASS, kullanıcı adını ve güncel bir Timestamp'i içeren bu yapıyı elindeki Session Key ile şifreler. Authenticator, Client'ın gerçekten Session Key'e sahip olduğunu, yani TGT'yi ağdan kopyalayan biri değil de AS-REP'i açabilen asıl Client olduğunu kanıtlar. İçindeki Timestamp de AS-REQ'taki ile aynı Replay Attack korumasını sağlar.

3. SPN (Service Principal Name): Hangi servise erişilmek istendiğinin adıdır. HTTP/portal.abc.local ya da CIFS/fileserver.abc.local gibi yazılır.

Her SPN, Active Directory'de bir hesaba kayıtlıdır ve bu kayıt hesabın servicePrincipalName Attribute'unda tutulur. Servis Local System veya Network Service olarak çalışıyorsa SPN bilgisayar hesabındadır; bir Domain hesabıyla çalışıyorsa SPN o hesaptadır.

TGS, SPN'e bakarak iki şeyi öğrenir: bileti hangi servis için hazırlayacağını ve hangi hesabın anahtarıyla şifreleyeceğini. SPN olmazsa TGS bu ikisini bilemez ve bilet üretemez.

Dosya paylaşımı için bilgisayar hesabında CIFS ile başlayan bir SPN görmek şart değildir. Active Directory, CIFS'i otomatik olarak HOST SPN'ine eşler; bu yüzden HOST/fileserver.abc.local kaydı dosya paylaşımı için yeterlidir.

Ticket Granting Service Tarafı

TGS, gelen isteği dört adımda işler.

1. TGT açılır: TGS, KRBTGT anahtarıyla TGT'yi açar ve içinden Session Key ile PAC'i çıkarır.

2. Authenticator doğrulanır: Bu Session Key ile Authenticator çözülür; içindeki kullanıcı adının TGT'deki ile eşleştiği ve Timestamp'in Clock Skew sınırı içinde olduğu kontrol edilir. Bu iki adım geçildiğinde TGS, karşısındaki tarafın hem geçerli bir TGT'ye hem de o TGT'ye ait Session Key'e sahip olduğundan emindir.

3. SPN çözülür: TGS, istenen SPN'i Active Directory'de arar ve hangi hesaba kayıtlı olduğunu bulur. SPN hiçbir hesapta kayıtlı değilse KDC_ERR_S_PRINCIPAL_UNKNOWN döner. Sahada en sık karşılaşılan Kerberos hatası budur ve genellikle eksik SPN, yanlış hesaba yazılmış SPN veya iki hesapta birden bulunan çift SPN'den kaynaklanır. Çift SPN durumunda KDC hangi hesabın anahtarını kullanacağına karar veremez ve bilet yanlış anahtarla şifrelenebilir; sonuç, uygulama tarafında NTLM'e düşme veya doğrudan erişim reddidir.

SPN kayıtlarını incelemek ve çift kayıtları tespit etmek için aşağıdaki komutlar kullanılır. İlk komut belirtilen hesaba kayıtlı SPN'leri listeler, ikincisi belirli bir SPN'in hangi hesapta olduğunu sorgular, üçüncüsü Forest genelinde çift SPN'leri arar. Listeleme ve sorgulama için Domain'de yetkili herhangi bir kullanıcı yeterlidir; SPN ekleme veya silme için ilgili hesap üzerinde yazma izni, pratikte Domain Admins üyeliği veya hesaba delege edilmiş Validated Write to Service Principal Name hakkı gerekir.

setspn -L FILESERVER01
setspn -Q CIFS/fileserver.abc.local
setspn -X -F

4. Service Ticket düzenlenir: Doğrulamalar başarılıysa TGS hedef servis için bir Service Ticket üretir. Biletin içinde TGT'den kopyalanıp yeniden imzalanan PAC, Client ile hedef servis arasında kullanılacak yeni bir Service Session Key ve biletin geçerlilik süresi bulunur.

Bu işlem Domain Controller'ın Security Log'una Event ID 4769 olarak yazılır. Kayıtta Service Name alanı hangi SPN için bilet istendiğini, Ticket Encryption Type alanı ise biletin hangi algoritmayla şifrelendiğini gösterir. RC4 ile şifrelenen biletleri bulmanın en pratik yolu 4769 kayıtlarını bu alana göre filtrelemektir.

4. Ticket Granting Service Response (TGS-REP)

TGS'nin Client'a döndüğü cevap da iki parçadan oluşur.

1. Service Ticket: Hedef servisin hesap anahtarıyla şifrelenmiş bilet. Client bu biletin içeriğini göremez; tıpkı TGT gibi bunu da olduğu gibi saklar ve hedef servise iletir. Biletin içinde Client'ın kimlik ve yetki bilgilerini taşıyan PAC, Client ile servis arasında ortaklaşa kullanılacak Service Session Key ve biletin geçerlilik süresi bulunur. Varsayılan süre 600 dakikadır ve bu değer Kerberos Policy'deki Maximum lifetime for service ticket ayarından gelir.

2. Service Session Key: Client ile hedef servis arasında kullanılacak yeni anahtar. Client ile TGS arasındaki Session Key ile şifrelenerek gönderilir; dolayısıyla yalnızca o Session Key'e sahip olan Client açabilir. Bir bileti ağdan kopyalayan saldırganın işine yaramamasını sağlayan şey biletin kendisi değil, o biletle birlikte sunulması gereken ve yalnızca Service Session Key'e sahip tarafın üretebileceği Authenticator'dır.

Client aldığı Service Ticket'ı LSASS belleğindeki bilet önbelleğine koyar. Bilet süresi dolana kadar aynı servise yapılan her erişimde TGS'ye tekrar gidilmez; önbellekteki bilet doğrudan kullanılır. Paylaşıma eriştikten sonra klist çıktısında cifs/ ile başlayan bir satırın belirmesi bu önbelleklemenin sonucudur. Sorun giderirken önbelleği temizlemek gerekirse klist purge komutu kullanılır; komut yalnızca çalıştıran kullanıcının oturumundaki biletleri siler ve sonraki erişimde LSASS tüm akışı baştan yürütür.

TGS-REP tamamlandığında Client'ın elinde yine iki şey vardır: açamadığı ama servise ileteceği Service Ticket ve açabildiği Service Session Key. Bu noktadan sonra KDC ile iletişim biter; kalan adımlar Client ile hedef servis arasında geçer.

5. Application Request (AP-REQ)

Client Tarafı

Bu, sürecin son zorunlu adımıdır. Client artık KDC ile değil, doğrudan hedef servisle konuşur. LSASS, hedef servise iki parça gönderir.

1. Service Ticket: TGS'den alınan ve hedef servisin kendi anahtarıyla şifrelenmiş bilet. Client bunu açamaz, olduğu gibi iletir.

2. Authenticator: Kullanıcı adı ve güncel Timestamp içeren, Service Session Key ile şifrelenmiş veri. TGS-REQ'taki Authenticator ile aynı mantıkta çalışır; tek fark, şifrelemede Session Key yerine Service Session Key kullanılmasıdır.

Bu iki parça, kullanılan protokolün kendi kimlik doğrulama alanı içinde taşınır. SMB'de Session Setup paketi, HTTP'de Authorization başlığı, LDAP'ta SASL Bind bu görevi görür.

Hedef Servis Tarafı

Hedef servis, gelen paketi şu sırayla işler.

1. Service Ticket açılır: Servis, bileti kendi hesap anahtarıyla açar. Servis Local System veya Network Service altında çalışıyorsa bu anahtar bilgisayar hesabına, bir Domain servis hesabı altında çalışıyorsa o hesaba aittir. SPN yanlış hesaba kayıtlıysa bilet yanlış anahtarla şifrelenmiş olur ve açılamaz.

2. Authenticator doğrulanır: Biletin içinden Service Session Key ve PAC çıkarılır. Authenticator bu anahtarla çözülür; kullanıcı adı ve Timestamp kontrol edilir.

3. Access Token üretilir: PAC'teki SID ve grup bilgilerinden kullanıcı için bir Access Token oluşturulur. Kimlik doğrulama bu noktada tamamlanır ve Client'a erişim verilir. Kullanıcının paylaşımda hangi yetkilere sahip olacağı, bu Token'daki gruplar ile NTFS ve Share izinlerinin kesişiminden belirlenir.

Bu adımın izi, hedef sunucunun Security Log'unda Event ID 4624 olarak görülür. Kayıtta Logon Type alanı 3, Authentication Package alanı Kerberos olmalıdır. Authentication Package alanında NTLM görülüyorsa kullanıcı erişim almış olsa bile Kerberos akışı bir yerde kırılmıştır; SPN, DNS veya isim çözümleme tarafında düzeltilmesi gereken bir sorun vardır. Paylaşıma Hostname yerine IP adresiyle erişmek de aynı sonucu verir, çünkü IP adresi için kayıtlı bir SPN yoktur ve Client NTLM'e düşer.

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddMinutes(-5)} | Where-Object { $_.Properties[5].Value -eq 'firat.boyan' } | Select-Object TimeCreated, RecordId, @{n='LogonType';e={$_.Properties[8].Value}}, @{n='AuthPkg';e={$_.Properties[10].Value}} | Format-Table -AutoSize

Kaydın tam içeriği aşağıdaki gibidir.

An account was successfully logged on.

Subject:
    Security ID:                NULL SID
    Account Name:               -
    Account Domain:             -
    Logon ID:                   0x0

Logon Information:
    Logon Type:                 3
    Restricted Admin Mode:      -
    Virtual Account:            No
    Elevated Token:             Yes

Impersonation Level:            Delegation

New Logon:
    Security ID:                ABC\firat.boyan
    Account Name:               firat.boyan
    Account Domain:             ABC.LOCAL
    Logon ID:                   0x210EDF
    Linked Logon ID:            0x0
    Network Account Name:       -
    Network Account Domain:     -
    Logon GUID:                 {a757f453-5a84-828a-7cc7-030fc27545be}

Process Information:
    Process ID:                 0x0
    Process Name:               -

Network Information:
    Workstation Name:           -
    Source Network Address:     2a02:ff0:23c:45f3:d893:715a:7d27:a615
    Source Port:                55505

Detailed Authentication Information:
    Logon Process:              Kerberos
    Authentication Package:     Kerberos
    Transited Services:         -
    Package Name (NTLM only):   -
    Key Length:                 0

This event is generated when a logon session is created. It is generated on the computer that was accessed.

The subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.

The logon type field indicates the kind of logon that occurred. The most common types are 2 (interactive) and 3 (network).

The New Logon fields indicate the account for whom the new logon was created, i.e. the account that was logged on.

The network fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.

The impersonation level field indicates the extent to which a process in the logon session can impersonate.

The authentication information fields provide detailed information about this specific logon request.
    - Logon GUID is a unique identifier that can be used to correlate this event with a KDC event.
    - Transited services indicate which intermediate services have participated in this logon request.
    - Package name indicates which sub-protocol was used among the NTLM protocols.
    - Key length indicates the length of the generated session key. This will be 0 if no session key was requested.

Kayıtta dikkat edilecek alanlar aşağıdaki tabloda verilmiştir.

6. Application Response (AP-REP)

Akışın altıncı adımı isteğe bağlıdır ve yalnızca Mutual Authentication istendiğinde gerçekleşir. Bu durumda hedef servis de kendini Client'a kanıtlar.

1. Servis Timestamp'i alır: Servis, AP-REQ ile gelen Authenticator'dan çıkardığı Timestamp'i alır.

2. Servis Timestamp'i şifreleyip döner: Bu Timestamp, Service Session Key ile şifrelenir ve Client'a geri gönderilir.

3. Client doğrular: Client, elindeki Service Session Key ile bunu açar ve Timestamp'in kendi gönderdiğiyle eşleştiğini doğrular.

Bu sayede Client, konuştuğu sunucunun gerçekten o SPN'in sahibi olduğundan emin olur. Sahte bir servis, Service Ticket'ı açamayacağı için Service Session Key'i elde edemez ve doğru Timestamp'i döndüremez. Windows istemcilerinin çoğu Kerberos üzerinden bağlanırken Mutual Authentication talep eder; NTLM'de böyle bir mekanizmanın hiç olmaması, Kerberos'un tercih edilmesinin somut nedenlerinden biridir.

Özet Akış Tablosu

Sonuç

Parola ağdan hiç geçmez. Client ve KDC aynı Derived Key'i birbirlerinden bağımsız olarak bilir; doğrulama, bu anahtarla şifrelenmiş Timestamp'in karşı tarafta açılabilmesiyle yapılır. Parola yalnızca ilk adımda ve yalnızca bir anahtar türetmek için kullanılır; sonraki her adım bir önceki adımda güvenli biçimde paylaşılmış geçici bir anahtara dayanır.

Client hiçbir bileti açamaz. TGT'yi yalnızca KDC, Service Ticket'ı yalnızca hedef servis açar. Client'ın işi biletleri saklamak, doğru yere iletmek ve her seferinde elindeki Session Key ile bir Authenticator üreterek biletin gerçek sahibi olduğunu kanıtlamaktır.

Kullanıcının kimlik ve grup bilgileri bilet içinde PAC olarak taşınır. Hedef sunucudaki Windows Access Token bu PAC'ten üretilir; dolayısıyla kullanıcı bir gruba eklendiğinde yeni yetkinin geçerli olması için yeni bir TGT alınması, yani oturumun kapatılıp açılması ya da bilet önbelleğinin temizlenmesi gerekir.

TGS, SPN'i Active Directory'deki hesaba çözer ve Service Ticket'ı o hesabın anahtarıyla şifreler. Eksik, çift veya yanlış hesaba kayıtlı SPN, Kerberos hatalarının en yaygın sebebidir. Sahada bir Kerberos sorunuyla karşılaşıldığında bu zincirin hangi halkasının koptuğunu bulmak için sırasıyla saat farkı, SPN kaydı, şifreleme türü uyumu ve Domain Controller ile hedef sunucudaki 4768, 4769, 4771 ve 4624 kayıtları kontrol edilir. Bu dört kontrol, Kerberos kaynaklı erişim sorunlarının büyük çoğunluğunu yerinde tespit etmeye yeter.

Faydalı olması dileğiyle...