Sertifika ile AD kimlik doğrulaması: PKINIT, NTAuth ve certificate mapping.

1. Core Mechanism / Temel mekanizma

11.03 sertifikanın nasıl alındığını anlattı. Bu ders alınan sertifikanın authentication tarafında nasıl değerlendirildiğini, yani issuance ile identity binding arasındaki farkı kurar.

Arabirimler ve belirtimler

• PKINIT, AS exchange’de certificate ve private-key sahipliği kanıtını kullanır. Private key istemcide kalır; KDC’ye gönderilmez.
• Klasik certificate yolu, chain validation ve domain authentication trust koşullarını account mapping’den ayrı değerlendirir. Bu kontrollerin yerine issuance onayı geçmez.
• NTAuth, domain authentication için kabul edilen CA’larla ilgili directory trust kapsamıdır. Genel root trust ile aynı karar değildir; Key Trust için ayrı davranış belgelenmiştir.
• altSecurityIdentities, account üzerinde explicit certificate mapping tanımlayabilir. Biçim, sürüm ve uygulanabilir policy birlikte okunur.
• Key Trust, public key üzerinden account arayan ayrı bir yoldur. AD-backed KDC, aynı public key’in msDS-KeyCredentialLink içinde bulunduğunu doğrular; burada attribute yazma veya key üretme işlemi yapılmaz.
• Kdcsvc / System olayları sürümle yorumlanır: no-strong-mapping için modern 39, eski 41; SID uyuşmazlığı için modern 41, eski 49. Eski ID kapsamı Windows Server 2008 R2 SP1 / 2008 SP2’dir.

PKINIT kanıtı değiştirir, account’u kendiliğinden seçmez

Klasik parola tabanlı ilk adım yerine istemci ilgili private key’e sahip olduğunu kriptografik olarak kanıtlar. Public certificate ile private key’in görevleri farklıdır; dosyanın varlığı sahiplik kanıtı değildir.

Sonraki soru hâlâ kimliktir: bu kanıt hangi account için kabul ediliyor? Account binding kurulmadan bir CA’nın sertifika vermiş olması bu soruyu cevaplamaz. Authentication’dan sonra kaynağın account haklarına göre verdiği karar da ayrıca gerekir.

Klasik certificate yolu ve Key Trust

Klasik yolda certificate chain ve domain authentication trust değerlendirmesi, certificate’in account’a eşlenmesinden ayrıdır. Örnekte chain reddediliyorsa bu yol mapping kararına devam etmez. Strong mapping yoksa güncel Enforcement koşulunda authentication reddedilir.

Key Trust’ta KDC public key üzerinden account arar. AD-backed KDC aynı key’in msDS-KeyCredentialLink içinde bulunduğunu doğrulamak zorundadır. Güvenilen account key’i bulunduğunda MS-PKCA chain validation hatalarının dikkate alınmamasını belirtir. Bu, herhangi bir certificate için genel trust kontrolünü kaldırmak değildir; bulunan key’e ve account’a bağlı ayrı bir yoldur. cname ile bulunan account farklıysa ayrı bir isim uyuşmazlığı vardır.

Public-key lookup eski Server 2012 R2 ve önceki KDC sürümlerinde desteklenmez; ortamın sürümünü kontrol et. Key Trust, altSecurityIdentities içine yazılan yedinci bir string biçimi değildir. Anahtar kayıtlarının sahibi, değiştirme yetkileri ve account ilişkisi savunma envanterinde ayrıca incelenir.

Strong mapping envanteri altı biçimden ibaret değil

KB5014754’ün altı explicit altSecurityIdentities biçimi arasında X509IssuerSubject, X509SubjectOnly ve X509RFC822 weak; X509IssuerSerialNumber, X509SKI ve X509SHA1PublicKey strong olarak sınıflandırılır. İsim veya e-posta gibi devredilebilir alanlar, kimliği kalıcı biçimde bağladığı varsayımıyla kullanılmamalıdır.

MS-PKCA’nın daha geniş listesinde SID ve Key Trust da vardır. Issuer+SID explicit mapping için Product Behavior, Server 2022/2025 ve ilgili KB5060525/KB5060841 güncelleme sınırını verir. Uygulanabilir ürün ve servicing profilini doğrulamadan bunu bütün DC’lerde destekleniyor sayma.

Ayrıca MS-PKCA, yapılandırılmış Issuer-OID-MappingType policy’si için sınırlı bir istisna belgeler. Belirli issuer, certificate policy OID ve mapping türü birlikte değerlendirilir. Bu yüzden bir name-based mapping’i yalnız görünen ismine göre sınıflandırma; uygulanabilir policy’yi de kaydet. Buradaki karşılaştırma bu özel policy’yi yürütmez.

Aynı Event ID, farklı sürümde farklı anlam

No-strong-mapping olayı modern ID 39’dur; eski Windows Server 2008 R2 SP1 / 2008 SP2’de ID 41’dir. Tarihsel Compatibility’de warning, Enforcement’ta error olur. Certificate’in account’tan önce verilmesi ayrı modern 40 / eski 48 koşuludur ve KB bunu yalnız Compatibility için belgeler.

Modern Event 41 ise certificate SID ile eşlenen user SID’sinin farklı olduğunu bildirir; eski ID 49’dur. Modern 41’in User SID ve Certificate SID alanlarını, eski 41’in no-strong-mapping mesajıyla aynı şema sayma. DC sürümü, Kdcsvc kaynağı, System kanalı ve mesaj birlikte yorumlanır.

Buradan sonraki mekanizmaya

Şubat 2025’teki uygulanabilir güncellemeler Enforcement geçişini, 9 Eylül 2025 güncellemesi StrongCertificateBindingEnforcement ile Compatibility’ye dönüş desteğinin bitişini belirler. Güncel DC için eski Compatibility davranışını varsayma. 11.05’te sertifika iptali ile verifier’ın bu kararı ne zaman gördüğünü, 12.05’te hybrid trust yollarını karşılaştır.

Durum ve veri akışı

1. İstemci certificate ve private-key sahipliği kanıtını KDC’ye sunar; private key istemcide kalır.
2. Seçili yolun koşullarını ayır: klasik certificate yolunda chain ve NTAuth; Key Trust’ta güvenilen account key’i ve AD kaydı.
3. Klasik yolda strong mapping ve SID tutarlılığı; Key Trust’ta key/account ve cname tutarlılığı değerlendirilir.
4. Örnekte trust reddi, strong mapping yokluğu veya SID/name uyuşmazlığı devamı durdurur. Uyumlu seçili koşullar diğer authentication kontrollerinin yerini tutmaz.
5. TGT ve kaynak erişimi burada gözlenmez. Authentication’dan sonraki authorization, kaynağın ayrı account ve hak kararıdır.

2. Exploitation / İstismar

Broken trust assumption

İnceleme, certificate veya account key’i için hangi binding yolunun kabul edildiğini ve bu bağın hangi güven varsayımlarına dayandığını araştırır. Bu ders account key’i kaydetmez, certificate üretmez ve kimlik taklidi denemesi yapmaz.

Technical prerequisites

• Kullanılan authentication yolu, DC sürümü ve uygulanabilir policy belirlenmiştir.
• Certificate zinciri, account mapping veya Key Trust kaydı hakkında ayrı kanıtlar vardır; tek birinin varlığı diğerlerini doğrulamaz.
• Weak mapping riski tarihsel Compatibility ya da uygulanabilir özel policy bağlamıyla sınırlanır. Güncel Enforcement’ta weak-only mapping’in kabul edildiği varsayılmaz.

Exploitation mechanism / İstismar mekanizması

Sorun yalnız certificate’in şifreleme gücü değildir. Yeniden kullanılabilir bir isimle kurulan bağın hangi account’u seçtiğini ve ilgili policy’nin bu bağı kabul edip etmediğini incelemek gerekir. Key Trust için farklı soru sorulur: key hangi account’a güvenilir biçimde bağlıdır ve bu kaydı kim değiştirebilir? Bu iki yolun kontrollerini birbirine taşımak eksik risk değerlendirmesine yol açar.

Binding’in dayanağını bul

Anahtar uzunluğunu artırmak, yanlış account binding’i düzeltmez. Klasik certificate yolu için issuer/trust kapsamını ve mapping dayanağını; Key Trust için account’a kayıtlı key’in kökenini ve yönetim kapsamını ayrı incele.

Bir trust kaydını veya account attribute’unu bulmak, kötüye kullanımın gerçekleştiğini göstermez. Seçili yol, değişiklik geçmişi ve authentication kanıtı arasındaki ilişkiyi kur; gözlenmeyen sonucu başarılı kullanım sayma.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• İlk olarak hangi yol kullanılıyor: klasik certificate mapping mi, Key Trust mı? DC sürümünü, güncellemeyi ve policy kapsamını kaydet.
• Klasik yol için NTAuth/chain trust ve SID/explicit mapping dayanağını ayrı envanterle. Key Trust için account’a bağlı key kayıtlarını, kökenini ve değiştirme yetkilerini incele.
• 39/41/49’u numaraya bakarak birleştirme: DC sürümü ve mesajın no-strong-mapping mi SID-mismatch mi dediğini kontrol et. Certificate-predates-account ayrı 40/48 koşuludur.
• Issuer+SID ve özel Issuer-OID-MappingType policy gibi sürüm/policy bağımlılıklarını envantere ekle. Alanın varlığını, o KDC’nin kabul ettiği yolun kanıtı sayma.

Events and relevant fields

• 39 / eski 41 · Kdcsvc, System: strong mapping bulunamadı. Compatibility’de warning; Enforcement’ta error. Eski kapsam Server 2008 R2 SP1 / 2008 SP2.
• 41 / eski 49 · Kdcsvc, System: certificate SID ile user SID uyuşmuyor. Eski 41’in no-strong-mapping anlamından ayrı tut.
• 40 / eski 48 · Certificate account’tan önce verilmiş; KB5014754 bunu Compatibility koşulu olarak belgeler.
• 4768 · TGT request/issuance kaydı. Event ID tek başına PKINIT değildir; güncel event sürümündeki PreAuthType ve certificate alanlarını incele.

Önce yolu ve kanıtı ayır

Certificate verildi, mapping bulundu, authentication kabul edildi ve kaynak erişildi dört ayrı iddiadır. Her birinin gözlem noktası farklıdır. Bu dersteki durum tablosu ilk iki kararın sınırlı örneklerini karşılaştırır; TGT veya kaynak sonucu üretmez.

Uyumluluk araştırmasında eski olayları güncel DC davranışı gibi yorumlama. Event mesajı ve sürüm kaydı, aynı numaranın hangi koşulu anlattığını belirlemek için gerekir.

Verilmiş ticket ve açık session

Certificate iptali yeni PKINIT denemesiyle ilgilidir; daha önce verilmiş TGT, service ticket ve kurulmuş uygulama session’ının bittiğini tek başına göstermez. 11.05’te yeni certificate denemesini eski ticket ve session gözlemlerinden ayırıyoruz.

Detection logic · XPath

*[System[(EventID=39) and Provider[@Name='Kdcsvc']]]

Query assumptions

• Bu XPath, DC’nin System günlüğünde Kdcsvc Event 39 kaydını seçer; bütün certificate authentication hatalarını toplamaz.
• DC sürümü ve mesajı ayrıca kontrol et. Eski no-strong-mapping ID 41’i, modern SID-mismatch ID 41 ile aynı anlamda kullanma.
• Sentetik XML yalnız Event 39 / Level 3 Compatibility zarfıdır. Olay mesajı alanları EventData olarak uydurulmamıştır.

False positives

• Mapping sorunu tek başına kötü niyet kanıtı değildir. Hesap, issuer, güncelleme ve olay mesajını birlikte incele.
• Event 39 yokluğu strong mapping’in yaygın olduğunu göstermez: certificate authentication olmamış, log eksik veya olay numarası sürüme göre farklı olabilir.

Hardening

• Klasik certificate yolu için genel trust ve domain authentication trust kapsamlarını ayrı yönet; gerekli issuer’larla sınırla.
• Binding dayanağını ve uygulanabilir policy’yi doğrula. Key Trust kayıtlarının yönetim yetkilerini, certificate explicit mapping yetkilerinden ayrı gözden geçir.
• Weak mapping bağımlılıklarını gider ve güncel Enforcement davranışını doğrula. 9 Eylül 2025+ güncellemesinde eski StrongCertificateBindingEnforcement ayarıyla Compatibility’ye dönüşü planlama.
• Policy değişikliğinden önce hangi account ve uygulamaların hangi binding yoluna bağlı olduğunu belirle; authentication uygunluğunu kaynak yetkisiyle aynı kabul etme.

Örnekler üzerinde oku / Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Kdcsvc"/><EventID>39</EventID><Level>3</Level><Channel>System</Channel><Computer>DC01.outreason.example</Computer></System></Event>

İki yanlış kanı / Two reality checks

Sanılan: Certificate’in chain’i geçerliyse hangi account’a ait olduğu kendiliğinden bellidir.

Gerçekte: Chain güveni account binding’i seçmez. Klasik certificate yolu ile Key Trust farklı bağlama dayanaklarına sahiptir; uygun binding bile kaynak hakkını belirlemez.

Sanılan: altSecurityIdentities içindeki her değer strong’dur ve bütün KDC sürümleri aynı yolları destekler.

Gerçekte: KB5014754 altı biçimin üçünü weak sayar. MS-PKCA’daki daha geniş envanterde Key Trust ve sürüme bağlı Issuer+SID de vardır. Biçimle birlikte DC sürümü ve özel policy kapsamı incelenmelidir.

Kaynaklar / Sources

• Microsoft · KB5014754 Certificate-based authentication changes on Windows domain controllers
  Audit events bölümü (Event Log System, Event Source Kdcsvc, Event ID 39) ve Certificate mappings tablosu (altı altSecurityIdentities biçimi, weak/strong sınıflandırması).
• Microsoft Open Specifications · [MS-PKCA]: Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol
  PKINIT uzantısının Windows uygulamasına ilişkin protokol kapsamı ve genel bakış.
• IETF · RFC 4556 (Public Key Cryptography for Initial Authentication in Kerberos)
  PKINIT akışı ve PKINIT'e özgü KDC hata kodları tablosu.
• Microsoft · certutil
  Dizin tabanlı CA güven deposu ve sertifika doğrulama işlemlerine ilişkin komut referansı.
• Microsoft · Event 4768: A Kerberos authentication ticket (TGT) was requested
  Event versions and Pre-Authentication Type table; updated version includes PreAuthType and certificate fields. PA-PK-AS-REQ (16) is listed for smart-card authentication scenarios; event ID alone should not be treated as the method.
• MS-PKCA · Key Trust
  §3.1.5.2.1.4: public-key lookup, AD confirmation and conditional chain-error behavior.
• MS-PKCA · Mapping Strength
  §3.1.5.2.1.5: broader mapping inventory and scoped issuer/OID policy exception.
• MS-PKCA · Product Behavior
  Footnotes23/26/27: Key Trust version exclusion, Issuer+SID update scope and special-policy scope.
• RFC4120 · Kerberos ticket lifecycle
  §1.1 and §3.3.3.1; ticket lifetime and TGS/hot-list scope; not a Windows control recipe.
• MS-KILE · Check Account Policy for Every Session Ticket Request
  §3.3.5.7.1; conditional account-standing validation is not certificate-status checking.