SPN ve servis anahtarı: İstenen hizmet hangi kimliğe ait?

1. Core Mechanism / Temel mekanizma

TGS değişiminde istemci (WS01), KDC rolündeki domain controller (DC01) ve dizin. İstenen servis, TGS-REQ içindeki KDC-REQ-BODY'nin sname alanında bir PrincipalName olarak taşınır. KDC bu ismi dizinde servicePrincipalName özniteliği üzerinden bir hesaba çözer ve service ticket'ın enc-part'ını o hesabın uzun süreli anahtarıyla (key usage 2) korur. Bu dersin sınırı isim→hesap→anahtar zinciridir: AS/TGS akışının tamamı 06.02'de, pre-authentication ve etype ayrıntısı 06.04'te, biletin taşıdığı PAC ise 06.05'tedir.

Arabirimler ve belirtimler

• RFC 4120 §5.2.2: PrincipalName ::= SEQUENCE { name-type [0] Int32, name-string [1] SEQUENCE OF KerberosString }.
• RFC 4120 §6.2: name-type NT-PRINCIPAL (1) ve NT-SRV-INST (2); sname çoğunlukla NT-SRV-INST tipiyle servis örneğini adlandırır.
• RFC 4120 §7.5.1 key usage 2: ticket enc-part, servis anahtarıyla korunur; bu, sname'in çözüldüğü hesabın anahtarıdır.
• RFC 4120 §7.5.9 hata kodları: KDC_ERR_S_PRINCIPAL_UNKNOWN (7) bilinmeyen SPN, KDC_ERR_PRINCIPAL_NOT_UNIQUE (8) aynı SPN'in birden fazla hesapta bulunması.
• SPN sözdizimi: <service class>/<host>:<port>/<service name>; ilk iki bileşen zorunlu, port ve service name isteğe bağlıdır (Microsoft, Name Formats for Unique SPNs).
• Windows Security kanalı: 4769 / ServiceName, ServiceSid, TicketEncryptionType alanları; yalnız domain controller üzerinde.

SPN bir adres değil, bir kimlik göstergesidir

tunahan kullanıcısı \\db01\ üzerindeki SQL örneğine eriştiğinde istemci TGS-REQ'in req-body'sinde sname = MSSQLSvc/db01.outreason.example:1433 değerini taşır. KDC bu ismi çözerken hedef hostun IP'sine veya ağ konumuna bakmaz; dizinde bu SPN'i servicePrincipalName özniteliğinde barındıran hesabı arar.

Bulunan hesap kritik olandır: service ticket’ın enc-part’ı o hesabın uzun süreli anahtarıyla şifrelenir. Kullanıcı hesabındaki anahtar insan tarafından seçilmiş parolaya dayanabilir. Makine hesabının sırrı Windows tarafından yönetilir ve rollover davranışı makine hesabı politikasına bağlıdır; gMSA parolası Windows tarafından üretilip yönetilir, varsayılan aralık 30 gündür ve hesap oluşturulurken değiştirilebilir. Bunlar çevrimdışı parola tahmini riskini azaltır; hesap türü tek başına risksizlik garantisi değildir.

Bu ayrım dersin çekirdeğidir. Aynı SQL servisi için SPN'i svc_mssql adlı bir kullanıcı hesabında da, MSSQL01$ adlı bir makine hesabında da kayıtlı tutabilirsin; ikisi de aynı istemci deneyimini verir, fakat biletin anahtarını koruyan sırrın niteliği tamamen farklıdır.

SPN'in bileşenleri neyi söyler

SPN dört bileşenli bir sözdizimine sahiptir: <service class>/<host>:<port>/<service name>. service class servisin türünü belirtir (ör. MSSQLSvc, HTTP, cifs, ldap). host, servisin çalıştığı makinenin FQDN veya NetBIOS adıdır. port, aynı host üzerinde aynı sınıftan birden fazla örneği ayırt eder ve varsayılan portta çalışan servisler için atlanır.

Kerberos düzeyinde bu SPN, sname alanında bir PrincipalName olarak kodlanır. Örnekteki MSSQLSvc/db01.outreason.example:1433, name-string dizisinde iki bileşene ayrılır: ilk bileşen service class (MSSQLSvc), ikinci bileşen host:port (db01.outreason.example:1433). name-type genellikle NT-SRV-INST (2) olur.

Bir SPN'in ormanda benzersiz olması gerekir. Microsoft'un belgesi bunu açıkça söyler: SPN benzersiz değilse authentication başarısız olur. Benzersizlik service class, host ve gerektiğinde port ile sağlanır.

-- TGS-REQ req-body icindeki sname (RFC 4120 5.2.2)
sname  PrincipalName ::= SEQUENCE {
        name-type    [0] Int32           = 2,   -- NT-SRV-INST
        name-string  [1] SEQUENCE OF KerberosString {
              "MSSQLSvc",                        -- service class
              "db01.outreason.example:1433"          -- host:port
        }
}
-- KDC bu ismi servicePrincipalName ozniteliginde arar;
-- bulunan hesabin uzun sureli anahtari ticket enc-part'i korur (key usage 2).

Alias, bilinmeyen ve tekrarlı SPN durumları

Bir hesap birden fazla SPN taşıyabilir; servicePrincipalName çok değerli bir özniteliktir. MSSQLSvc/db01 ve MSSQLSvc/db01.outreason.example:1433 gibi farklı yazımlar aynı hesaba alias olarak kayıtlı olabilir. İstemci hangi yazımı isterse istesin, KDC aynı hesabı çözer ve aynı anahtarla korunan bir bilet üretir. Alias, anahtar sahipliğini değiştirmez.

İstenen SPN dizinde hiçbir hesapta kayıtlı değilse KDC KDC_ERR_S_PRINCIPAL_UNKNOWN (0x7) döner. Bu, "servis yok" değil, "bu isimle kayıtlı bir principal bulunamadı" demektir; SPN yazım hatası da aynı hatayı üretir.

Aynı SPN yanlışlıkla iki ayrı hesaba kaydedilirse benzersizlik kuralı bozulur. Bu durumda KDC hangi anahtarı kullanacağını kesin belirleyemez ve KDC_ERR_PRINCIPAL_NOT_UNIQUE (0x8) ile veya doğrulanamayan biletlerle sonuçlanan authentication hatalarına yol açar. Tekrarlı SPN, çoğu zaman elle SPN taşıma veya iki hesaba aynı servisi kurma sonucu ortaya çıkar.

Servis anahtarının niteliği neden önemli

KDC, service ticket'ın enc-part'ını üretirken hedef hesabın o an geçerli anahtar sürümünü kullanır ve biletin dış alanına kvno yazar. Servis bu bileti aldığında hangi anahtar sürümüyle şifrelendiğini bu kvno'dan okur; sürüm elinde yoksa 06.02'de görülen KRB_AP_ERR_BADKEYVER döner.

Anahtarın nasıl üretildiği çevrimdışı risk için belirleyicidir. Kullanıcı hesabına kayıtlı bir SPN’de anahtar, insan tarafından seçilmiş bir paroladan string-to-key ile türetilir. Makine hesabı sırrını Windows yönetir; rollover makine hesabı parola ilkesiyle kontrol edilir. gMSA parolası sistem tarafından üretilir ve yönetilir; varsayılan değiştirme aralığı 30 gündür, ancak hesap oluşturulurken farklı bir aralık seçilebilir.

Bu yüzden "SPN nerede kayıtlı?" sorusu güvenlik sorusudur. SPN bir kullanıcı hesabındaysa, o hesabın anahtarıyla korunan her bilet, o parolanın gücü kadar korunur.

Kayıtlı hesap ile çalışan servis aynı mı?

cifs/files.example.test SPN’si svc-files-A hesabında kayıtlı, servis ise svc-files-B ile çalışıyor olsun. KDC, A’nın anahtarıyla bir ticket verebilir; bu başarı B’nin elindeki anahtarın ticket’ı açabileceğini göstermez. Adres çözümleme, SPN sahibinin bulunması ve acceptor’ın anahtarını yüklemesi farklı kontrollerdir. Örnek yalnız bu uyumsuzluğu gösterir; her native hata kodunu bu tabloya bağlamaz.

İkinci durumda hesap adı aynı, ancak servisin yüklediği anahtar eski olabilir. gMSA’nın Windows tarafından yönetilen parola değişimi, her service instance’ın o anda hangi anahtarı kullandığının gözlemi değildir. Üçüncü durumda ilk hop’un anahtarları uyumludur; ikinci servise hangi kimlikle gidileceği ve delegation izni yine ayrı karardır. 08.04’te hesabın yönetimini, 06.06’da bu ikinci hop sınırını takip et.

Durum ve veri akışı

1. İstemci hedef servise erişmek ister ve o servisin SPN'ini oluşturur: MSSQLSvc/db01.outreason.example:1433.
2. İstemci TGS-REQ hazırlar; req-body'nin sname alanına bu SPN'i PrincipalName olarak yazar (NT-SRV-INST).
3. KDC TGT'yi doğruladıktan sonra sname'i dizinde servicePrincipalName özniteliği üzerinden bir hesaba çözer.
4. SPN bulunamazsa KDC_ERR_S_PRINCIPAL_UNKNOWN (7); aynı SPN birden fazla hesapta ise benzersizlik bozulur (KDC_ERR_PRINCIPAL_NOT_UNIQUE, 8).
5. SPN tek bir hesaba çözülürse KDC yeni bir oturum anahtarı üretir ve service ticket'ın enc-part'ını o hesabın uzun süreli anahtarıyla (key usage 2) şifreler.
6. DC01 bu noktada 4769 üretir; ServiceName alanı biletin düzenlendiği hesabı adlandırır.
7. İstemci bileti alır ama açamaz; yalnızca hedef hesabın anahtarına sahip olan servis enc-part'ı çözebilir.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım: "SPN yalnızca hangi servise gitmek istediğimi söyleyen bir etikettir." Gerçekte SPN, service ticket'ın şifreli bölümünü koruyan anahtarın sahibini adlandırır. Herhangi bir kimliği doğrulanmış hesap, geçerli bir TGT ile herhangi bir kayıtlı SPN için bilet isteyebildiğinden, saldırgan hedef hesabın anahtarıyla üretilmiş bir ciphertext'i hedefe hiç dokunmadan eline geçirir. Eğer o hesabın anahtarı insan seçimi bir parolaya dayanıyorsa, ciphertext çevrimdışı parola denemesine açıktır.

Technical prerequisites

• Domain'de kimliği doğrulanmış herhangi bir hesap ve geçerli bir TGT; ayrıcalıklı üyelik gerekmez.
• KDC’ye Kerberos üzerinden erişim. RFC 4120 UDP/IP ve TCP/IP taşımasını tanımlar; varsayılan port 88’dir ve istemcinin seçtiği transport/KDC keşfi ortam yapılandırmasına bağlıdır.
• Hedef SPN’in kullanıcı hesabında kayıtlı olması çevrimdışı tahmin açısından daha yüksek öncelikli bir durum olabilir. Makine hesaplarının sırrı OS tarafından, gMSA parolası Windows tarafından yönetilir; bu sırlar insan seçimi parolalara göre tahmini zorlaştırır. Yine de rollover politikası, gMSA parolasını almaya yetkili hostlar ve hesap yapılandırması değerlendirilmelidir.
• Hedef hesabın anahtarının tahmin edilebilir bir parolaya dayanması; aksi halde elde edilen ciphertext üzerinde deneme anlamlı sonuç vermez.
• Hedef hesabın RC4 gibi zayıf bir etype ile bilet vermeye razı olması denemeyi ucuzlaştırır; yalnız AES kabul eden bir yapılandırma işi belirgin biçimde zorlaştırır.

Exploitation mechanism / İstismar mekanizması

Mekanizma bir protokol zafiyeti değil, SPN→anahtar ilişkisinin sonucudur. İstemci sname'i istediği SPN'e ayarlar; KDC bunu bir kullanıcı hesabına çözer ve service ticket'ın enc-part'ını o hesabın uzun süreli anahtarıyla, key usage 2 altında şifreler. Bu ciphertext ağdan elde edilebilir; sname alanı şifreli olmadığı için hangi hesaba ait olduğu bellidir. Saldırgan çevrimdışı olarak parola adaylarını dener; her aday için türetilen anahtarla ciphertext'in bütünlük kontrolünü sağlayıp sağlamadığına bakar. Doğru aday bulunduğunda hedef hesabın anahtarı, dolayısıyla o hesabın kimliğini üstlenme imkanı elde edilir. Bu, Kerberoasting olarak bilinen tekniğin çekirdeğidir ve tek bir kuralı çiğnemez; çiğnenen şey "servis hesabı parolası insan tarafından seçilebilir" varsayımıdır.

SPN talebi bir yetki kontrolü değildir

KDC, bilet üretirken hedef servisin kaynak DACL'ine bakmaz; bakamaz da, çünkü erişim kararı kaynağı barındıran hostta verilir. Bu yüzden bir SPN için bilet alabilmek, o servise erişebilmekle aynı şey değildir. Saldırganın istediği zaten erişim değildir; hedef hesabın anahtar materyaline dayalı bir ciphertext'tir.

Talep DC üzerinde 4769 üretir; hedef servis bu talepten haberdar olmaz. Bu yüzden telemetride gözlem noktası kaynak host değil, KDC'dir.

Bir hesap için düzenlenmiş bilet sayısının aniden artması tek başına saldırı kanıtı değildir. Anlamlı sinyal, kullanıcı hesaplarına kayıtlı SPN'ler için zayıf etype ile bilet talepleridir.

Hangi hesap türü hedeftir

Kullanıcı hesabına kayıtlı SPN'ler birincil hedeftir; çünkü bu hesapların parolası çoğu zaman bir kez belirlenip yıllarca döndürülmez. Eski uygulama kurulumları MSSQLSvc, HTTP veya benzeri SPN'leri sıradan kullanıcı hesaplarına kaydetmiş olabilir.

OS tarafından yönetilen machine-account secret’ları ve Windows’un yönettiği gMSA parolaları, insan seçimi service-account parolalarına göre sıradan parola tahmini riskini ciddi biçimde azaltır. Hesap türü tek başına “risk yok” demek değildir. Secret’a erişebilen hostların güvenliği, gMSA password retrieval yetkileri, rollover policy ve account configuration ayrıca incelenir.

Etki, ele geçirilen servis hesabının kapsamıyla sınırlıdır. "Servis hesabı ele geçti" tek başına domain'in düştüğü anlamına gelmez; hesabın üyelikleri, kayıtlı SPN'leri ve üzerindeki nesne hakları ayrı ayrı değerlendirilir.

Bu örneğin risk sınırı

SPN yazabilmek, servisin process identity’sini veya bütün delegation haklarını değiştirmekle aynı değildir. Etkiyi ilgili kayıt, anahtar ve hop sınırında değerlendir.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Audit Kerberos Service Ticket Operations alt kategorisi, Success: 4769 kayıtlarını üretir. Kerberoasting sinyali için bu kategori açık olmalıdır.
• 4769 yalnızca domain controller üzerinde oluşur; nesne SACL'i gerekmez, bu bir KDC işlem kaydıdır.
• 4769 hacmi yüksektir; her normal servis erişimi bir kayıt üretir. Filtre, saklama ve normal davranış temeli önceden planlanmazsa sinyal gürültüde kaybolur.
• SPN envanteri ayrı bir veri kaynağıdır: hangi SPN hangi hesapta kayıtlı sorusu dizinden (servicePrincipalName) çıkarılır ve 4769 ile birlikte değerlendirilir.
• Kaynak tarafındaki gerçek erişim, DC'deki 4769'dan değil, hedef host üzerindeki oturum ve nesne erişim kayıtlarından okunur.

Events and relevant fields

• 4769 / ServiceName: biletin düzenlendiği hesabın adı; istenen SPN’in tam metni değildir. Ad sonunda $ bulunması çoğunlukla computer/gMSA gibi managed account türlerine işaret eder, ancak hesap türü dizin envanteriyle doğrulanmalıdır. Düz ad sıradan user service account olasılığını artırır; tek başına parola niteliğini kanıtlamaz.
• 4769 / ServiceSid: hedef hesabın SID'i; başarısız kayıtlarda NULL SID görülebilir.
• 4769 / TargetUserName: bileti isteyen istemci, normalize UPN biçiminde.
• 4769 / TicketEncryptionType: düzenlenen biletin etype'ı, yani servis anahtarıyla korunan bölümün algoritması. 0x17 = RC4-HMAC (zayıf, çevrimdışı denemeyi ucuzlatır), 0x12 = AES256-CTS-HMAC-SHA1-96.
• 4769 / TicketOptions: talep edilen bilet bayrakları; hexadecimal.
• 4769 / Status: Windows audit kaydındaki KDC sonucu; 0x0 başarıdır. Bilinmeyen SPN için protokol yanıtı KRB-ERROR / KDC_ERR_S_PRINCIPAL_UNKNOWN (0x7) olabilir. Bu yanıt ile failure 4769 ayrı gözlemlerdir: unknown-SPN kaydı KdcExtraLogLevel içindeki Audit SPN unknown errors (0x01) koşuluna da bağlıdır. Event’in bulunmaması isteğin hiç yapılmadığını göstermez.
• 4769 / IpAddress: bileti isteyen istemcinin adresi; tek kaynaktan çok sayıda farklı kullanıcı-SPN talebini ilişkilendirmek için kullanılır.

ServiceName alanı türü ele verir

4769 kaydındaki ServiceName, biletin düzenlendiği hesabın adıdır; istenen SPN’in tam metni değildir. Ad $ ile bitiyorsa çoğunlukla computer veya managed service account türü düşünülür; bu bir ilk ipucudur, kesin sınıflandırma için directory inventory gerekir. Düz bir hesap adı sıradan user service account olasılığını artırır; parolanın insan tarafından seçildiğini tek başına kanıtlamaz.

Bu yüzden ServiceName ve TicketEncryptionType birlikte okunmalıdır. Kullanıcı hesabı + RC4 kombinasyonu, çevrimdışı denemenin hem hedefinin hem de ucuzluğunun telemetrideki karşılığıdır.

Tek bir 4769 kaydı erişimin gerçekleştiğini göstermez; yalnızca bir biletin düzenlendiğini gösterir. Kerberoasting'de saldırgan zaten erişmeyi değil, ciphertext toplamayı hedefler.

Değişiklik sonrası doğrulama

Requested SPN, kayıtlı principal, çalışan service identity ve yüklenmiş key zamanını birlikte karşılaştır. 4769 issuance kanıtını AP kabulü veya ikinci hop’un başarısı yerine kullanma.

Detection logic · KQL

// Kullanici hesaplarina kayitli SPN'ler icin RC4 ile service ticket talepleri.
// Tek basina kanit degildir; SPN envanteri ve normal davranis temeli ile birlikte degerlendirilir.
SecurityEvent
| where EventID == 4769
| where Status == "0x0"
| where TicketEncryptionType == "0x17"                 // RC4-HMAC
| where ServiceName !endswith "$"                       // makine hesaplarini disla
| where ServiceName !startswith "krbtgt"
| summarize Requests = count(), Services = make_set(ServiceName, 50)
          by TargetUserName, IpAddress, bin(TimeGenerated, 1h)
| where array_length(Services) >= 3                     // esik ortam temeline gore ayarlanir

Query assumptions

• Tablo Microsoft Sentinel / Log Analytics'teki SecurityEvent tablosudur; alan adları Windows Security kanalındaki EventData adlarını yansıtır. Farklı bir ingest şeması (ör. ASIM veya ham WEF) kullanılıyorsa alan eşlemesi ayrıca yapılmalıdır.
• TicketEncryptionType ve Status bu şemada metin ("0x17", "0x0") olarak saklanır; sayısal saklayan bir backend'de karşılaştırma türü uyarlanmalıdır.
• Eşik (array_length >= 3) ve zaman penceresi (1 saat) ortam temeline göre ayarlanır; sabit bir değer değildir.
• Makine hesabı ve krbtgt filtreleri gürültüyü azaltır fakat makine hesaplarına kayıtlı SPN'leri kapsam dışında bırakır; bu bilinçli bir daraltmadır.
• Bu sorgu bu oturumda gerçek bir Sentinel workspace'inde çalıştırılmadı; yalnızca alan adları ve olay semantiği birincil kaynağa göre doğrulandı.

False positives

• RC4'ün hâlâ etkin olduğu eski ortamlarda meşru istemciler de RC4 ile bilet alır; etype tek başına kötü niyet göstermez.
• Çok sayıda arka uç servisine bağlanan uygulama sunucuları kısa sürede birçok farklı SPN'e bilet ister.
• Yedekleme, envanter ve izleme ajanları benzer desenler üretebilir.
• Negatif örnek: hedef hesabın anahtarı zaten elde edilmişse saldırganın yeni bilet istemesine gerek kalmaz ve bu sorgu hiçbir şey görmez. Sorgu bir kapsam sınırıdır, kanıt değildir.

Hardening

• Önce envanter: hangi SPN hangi hesapta kayıtlı? servicePrincipalName üzerinden kullanıcı hesaplarına kayıtlı SPN'leri çıkar; bunlar öncelikli risktir.
• Kullanıcı hesabına kayıtlı servis SPN’lerini mümkün olduğunda gMSA’ya taşı. Windows gMSA parolasını üretip yönetir; varsayılan değiştirme aralığı 30 gündür ve oluşturma sırasında ayarlanabilir. Parolayı alabilecek hostları kısıtla; bu yönetim çevrimdışı tahmin riskini düşürür fakat host güvenliğinin yerini tutmaz.
• Taşınamayan servis hesaplarında uzun, rastgele parola zorunlu kıl ve düzenli döndür; parola uzunluğu string-to-key maliyetini artırır.
• Etype politikasını aşamalı sertleştir: önce TicketEncryptionType dağılımını ölç, RC4 bağımlılıklarını tespit et, pilot kapsamda AES'e geç, geri dönüş yolunu hazır tut.
• Kullanılmayan ve tekrarlı SPN kayıtlarını temizle; kayıtlı olmayan bir SPN için bilet üretilemez, tekrarlı SPN ise authentication hatalarına yol açar.
• Doğrulama adımı: değişiklik sonrası aynı iş akışını tekrarla ve 4769 kayıtlarında hedef SPN için TicketEncryptionType değerinin AES'e geçtiğini, Status'un 0x0 kaldığını gör.

Örnekler üzerinde oku / Read the examples

30 49 a2 13 1b 11 4f 55 54 52 45 41 53 4f 4e 2e
45 58 41 4d 50 4c 45 a3 32 30 30 a0 03 02 01 02
a1 29 30 27 1b 08 4d 53 53 51 4c 53 76 63 1b 1b
64 62 30 31 2e 6f 75 74 72 65 61 73 6f 6e 2e 65
78 61 6d 70 6c 65 3a 31 34 33 33

<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>0</Version>
    <Level>0</Level>
    <Task>14337</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2026-09-29T07:41:02.5510000Z" />
    <EventRecordID>20714</EventRecordID>
    <Correlation />
    <Execution ProcessID="712" ThreadID="980" />
    <Channel>Security</Channel>
    <Computer>DC01.outreason.example</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="TargetUserName">tunahan@OUTREASON.EXAMPLE</Data>
    <Data Name="TargetDomainName">OUTREASON.EXAMPLE</Data>
    <Data Name="ServiceName">svc_mssql</Data>
    <Data Name="ServiceSid">S-1-5-21-111111111-222222222-333333333-2604</Data>
    <Data Name="TicketOptions">0x40810000</Data>
    <Data Name="TicketEncryptionType">0x17</Data>
    <Data Name="IpAddress">::ffff:192.0.2.44</Data>
    <Data Name="IpPort">52190</Data>
    <Data Name="Status">0x0</Data>
    <Data Name="LogonGuid">{7b2e0a41-6c33-4d9a-8f11-2a90c5e7b401}</Data>
    <Data Name="TransmittedServices">-</Data>
  </EventData>
</Event>

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "E02",
  "requestedSPN": "HTTP/app.example.test",
  "registeredAccount": "svc-A",
  "runningIdentity": "svc-B",
  "issuerResult": "ticket-issued",
  "acceptorResult": "key-mismatch-model",
  "secondHop": "not-attempted"
}

İki yanlış kanı / Two reality checks

Sanılan: SPN sadece istemcinin hangi sunucuya gitmek istediğini söyleyen bir adrestir; güvenlikle ilgisi yoktur.

Gerçekte: SPN, service ticket'ın enc-part'ını koruyan anahtarın sahibini adlandırır. KDC sname'i servicePrincipalName özniteliğinde bir hesaba çözer (RFC 4120 §5.2.2/§6.2) ve bileti o hesabın uzun süreli anahtarıyla, key usage 2 altında şifreler (§7.5.1). SPN bir kullanıcı hesabına kayıtlıysa bu anahtar insan seçimi bir paroladan türer ve elde edilen ciphertext çevrimdışı denemeye açık olur (Kerberoasting). Yani SPN'in nerede kayıtlı olduğu doğrudan güvenlik sorusudur.

Sanılan: Aynı SPN'i iki hesaba kaydetmek yedeklilik sağlar, en kötü ihtimalle zararsızdır.

Gerçekte: SPN ormanda benzersiz olmalıdır; değilse authentication başarısız olur (Microsoft, Name Formats for Unique SPNs). Modern AD bunu yazma anında zorlar: Windows Server 2012 R2 ve sonrası bir DC tarafından işlenen ve forest'ta zaten var olan bir SPN'i eklemeye/değiştirmeye (restore, reanimation, rename dahil) çalışan yazma, ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST (0x21C7) ile bloklanır ve Directory Services'te event 2974 üretilir; setspn.exe de duplicate kontrolü yapar. Bu yüzden duplicate SPN yazımı rutin olarak başarılı olmaz. Yine de duplicate'lar eski/kenar durumlarda ortaya çıkabilir: enforcement öncesi oluşturulmuş kayıtlar, yazmayı işleyen daha eski bir DC veya multi-master replication çakışmaları. Böyle bir duplicate mevcutsa KDC hangi hesabın anahtarını kullanacağını kesin belirleyemez ve KDC_ERR_PRINCIPAL_NOT_UNIQUE (0x8) ya da doğrulanamayan biletlerle sonuçlanan hatalar ortaya çıkar. Tekrarlı SPN yedeklilik değil, teşhisi zor bir kesinti kaynağıdır; çözümü SPN'i tek bir hesapta tutmaktır.

Kaynaklar / Sources

• RFC 4120 · The Kerberos Network Authentication Service (V5)
  §5.2.2 PrincipalName (name-type/name-string), §6.2 principal name types (NT-PRINCIPAL 1, NT-SRV-INST 2), §7.5.1 key usage 2 (ticket enc-part servis anahtarı), §7.5.9 hata kodları KDC_ERR_S_PRINCIPAL_UNKNOWN 7 ve KDC_ERR_PRINCIPAL_NOT_UNIQUE 8. §7.2 UDP/IP, TCP/IP ve varsayılan port 88.
• Microsoft · Name Formats for Unique SPNs
  SPN sözdizimi <service class>/<host>:<port>/<service name>; zorunlu ve isteğe bağlı bileşenler; SPN ormanda benzersiz olmalıdır yoksa authentication başarısız olur; host-based ve replicable service ayrımı.
• Microsoft · 4769(S, F) A Kerberos service ticket was requested
  Subcategory Audit Kerberos Service Ticket Operations; Task 14337; Version 0 Event XML ve Field Descriptions (ServiceName, ServiceSid, TargetUserName, TicketEncryptionType, TicketOptions, Status); etype tablosu 0x12 ve 0x17.
• Microsoft · SPN and UPN uniqueness
  Windows Server 2012 R2 (ve sonrası) DC'ler duplicate SPN/UPN yazımını engeller (restore/reanimation/rename dahil); yalnız yazma bir 2012 R2 DC tarafından işlenirse bloklanır; ERROR_DS_SPN_VALUE_NOT_UNIQUE_IN_FOREST (0x21C7) ve Directory Services event 2974; setspn.exe (Server 2008) duplicate kontrolü.
• Microsoft · Service Accounts in Windows Server
  Traditional service account vs gMSA password management; gMSA password is generated/managed by Windows, authorized hosts retrieve it, default rotation interval 30 days and configurable at creation.
• Microsoft · Domain member: Maximum machine account password age
  Policy controls maximum age/rollover behavior of computer account passwords; machine-account password lifecycle is policy-dependent.
• RFC 4120 — Kerberos V5
  §3.2.1–3.2.3 AP exchange
• gMSA overview
  Overview, managed password/KDS and platform requirements
• MS-SFU overview
  §1.3 Overview
• Microsoft Learn · KDC registry configuration
  KdcExtraLogLevel 0x01: unknown-SPN failure logging; protokol sonucu ile audit görünürlüğü ayrı.