service principal name spn

SPN – Service Principal Name, Active Directory içerisinde bir servis instance’ını benzersiz olarak tanımlayan ve Kerberos authentication sırasında kullanılan bir değerdir. SPN konusunu anlamak için önce Active Directory içerisindeki attribute mantığını hatırlamak faydalı. Active Directory veri tabanında bulunan user, computer ve diğer objelerin kendilerine ait çeşitli öznitelikleri yani attribute’ları vardır. Örneğin bir kullanıcı objesinde displayName attribute’u “Hakan Uzuner”, sAMAccountName attribute’u ise “hakanuzuner” değerini içerebilir. Bazı attribute’lar tek değer alırken bazıları multi-value, yani birden fazla değer alabilir. servicePrincipalName de bu attribute’lardan biridir ve multi-value olarak çalışır. Bir user, computer veya servis hesabının üzerinde birden fazla SPN bulunabilir.

SPN Nedir?

Service Principal Name – SPN, Kerberos’un bir servisi hangi Active Directory hesabıyla ilişkilendireceğini belirlemek için kullandığı benzersiz servis kimliğidir. Başka bir ifadeyle Kerberos authentication sırasında istemci yalnızca “SQL Server’a bağlanmak istiyorum” demez. Erişmek istediği servis instance’ını temsil eden SPN bilgisini KDC’ye bildirir. KDC Active Directory içerisinde bu SPN’in hangi user veya computer account üzerinde kayıtlı olduğunu bulur ve ilgili servis için Service Ticket oluşturur.

SPN Kerberos İçerisinde Nasıl Kullanılır?

Kerberos authentication sürecinde kullanıcı önce KDC’den bir TGT – Ticket Granting Ticket alır. Daha sonra belirli bir servise erişmek istediğinde TGT’yi kullanarak KDC üzerindeki Ticket Granting Service’ten bir Service Ticket talep eder. İşte bu aşamada client, erişmek istediği servisin SPN değerini KDC’ye gönderir. Örneğin bir SQL Server servisi için SPN aşağıdaki gibi olabilir:

MSSQLSvc/PROD-SQL01.cozumpark.com:1433

KDC bu SPN değerini Active Directory içerisinde arar. SPN hangi account üzerinde kayıtlıysa o servis hesabının sahip olduğu Kerberos key’leri kullanılarak ilgili Service Ticket oluşturulur. Client aldığı ticket’ı hedef servise gönderir. Servis kendi hesabına ait key ile ticket’ı doğrulayabildiği için KDC’nin bu client’ı ilgili servis için doğruladığını anlayabilir. Burada önemli bir ayrım var: Bu aşama doğrudan kullanıcının kaynağa hangi yetkiyle erişeceğini belirlemez. Önce authentication, yani kimliğin doğrulanması gerçekleşir. Ardından uygulama veya işletim sistemi kendi authorization mekanizmasıyla kullanıcının hangi kaynaklara erişebileceğine karar verir. Kerberos’un genel çalışma mantığını daha detaylı incelemek için Kerberos Nedir? Kerberos Nasıl Çalışır? makaleme göz atabilirsiniz.

SPN Formatı Nasıldır?

SPN genel olarak aşağıdaki yapıyı kullanır:

serviceclass/host:port

Servise göre port veya ek servis bilgileri de kullanılabilir. Örnek bazı SPN’ler:

HTTP/web01.contoso.com
MSSQLSvc/sql01.contoso.com:1433
TERMSRV/server01
TERMSRV/server01.contoso.com
HOST/server01.contoso.com

Buradaki ilk bölüm servis sınıfını, ikinci bölüm ise servisin çalıştığı host veya servis instance’ını ifade eder.

SPN Nerede Saklanır?

SPN kayıtları Active Directory içerisindeki servicePrincipalName attribute’unda saklanır. Servisin çalışma şekline göre SPN bir:

• Computer account,
• User account,
• Managed Service Account,
• Group Managed Service Account

üzerinde bulunabilir. Örneğin Local System altında çalışan birçok Windows servisi için SPN ilgili computer account üzerinde bulunurken, domain user account altında çalışan SQL Server gibi servislerde SPN çoğunlukla ilgili servis hesabı üzerinde kayıtlıdır.

SPN Neden Benzersiz Olmalıdır?

Bir SPN’in Active Directory içerisinde yalnızca bir account üzerinde kayıtlı olması gerekir. Bunun nedeni oldukça basit: KDC bir Service Ticket üretirken SPN’in hangi security principal’a ait olduğunu kesin olarak bilmek zorundadır. Aynı SPN iki farklı account üzerinde kayıtlıysa buna duplicate SPN diyoruz. Böyle bir durumda Kerberos authentication başarısız olabilir çünkü KDC doğru service account’u güvenilir şekilde belirleyemez.

Duplicate SPN Nedir?

Duplicate SPN, aynı Service Principal Name değerinin Active Directory içerisinde birden fazla account üzerinde kayıtlı olmasıdır. Sahada SPN kaynaklı Kerberos sorunlarında ilk baktığım konulardan biri budur. Özellikle servis hesabı değiştirildiğinde eski account üzerindeki SPN kayıtları temizlenmezse duplicate veya yanlış account üzerinde SPN problemleri oluşabilir. Örneğin SQL Server servisi daha önce CONTOSO\sql-old hesabıyla çalışırken daha sonra CONTOSO\sql-prod hesabına geçirildiyse, MSSQLSvc SPN kayıtlarının da yeni account’a taşınması gerekir. Eski hesap üzerinde SPN bırakılırsa Kerberos authentication beklediğiniz şekilde çalışmayabilir.

SPN Nasıl Kontrol Edilir?

Windows Server ortamlarında SPN kayıtlarını yönetmek ve sorgulamak için kullanılan temel araç setspn komutudur. Bir user veya computer account üzerindeki SPN kayıtlarını listelemek için:

setspn -L AccountName

Örneğin:

setspn -L SQLService

veya computer account için:

setspn -L PROD-SQL01

Belirli Bir SPN Nasıl Aranır?

Belirli bir SPN’in hangi account üzerinde kayıtlı olduğunu görmek için -Q parametresini kullanabilirsiniz.

setspn -Q MSSQLSvc/PROD-SQL01.cozumpark.com:1433

Bu komut Active Directory içerisinde ilgili SPN’i arar ve hangi account üzerinde kayıtlı olduğunu gösterir.

Duplicate SPN Nasıl Bulunur?

Domain içerisindeki duplicate SPN kayıtlarını kontrol etmek için aşağıdaki komutu kullanabilirsiniz:

setspn -X

Forest genelinde kontrol yapmak için:

setspn -F -X

komutu kullanılabilir. Burada eski yazımdaki bir noktayı özellikle düzeltmek istiyorum: setspn -F -X duplicate SPN kayıtlarını silmez. Bu komut duplicate kayıtları tespit etmek için kullanılır. Hangi kaydın hatalı olduğuna karar verdikten sonra ilgili SPN ayrıca kaldırılmalıdır.

SPN Nasıl Eklenir?

Yeni bir SPN eklemek için mümkün olduğunca -S parametresini kullanmanızı öneririm:

setspn -S MSSQLSvc/PROD-SQL01.cozumpark.com:1433 CONTOSO\SQLService

-S parametresi SPN’i eklemeden önce duplicate kontrolü yapar. Bu nedenle eski -A yaklaşımına göre daha güvenlidir.

SPN Nasıl Silinir?

Yanlış veya artık kullanılmayan bir SPN’i kaldırmak için -D parametresi kullanılabilir:

setspn -D MSSQLSvc/PROD-SQL01.cozumpark.com:1433 CONTOSO\SQLService

SPN silmeden önce servisin hangi account altında çalıştığını ve ilgili kaydın gerçekten gereksiz olduğunu doğrulamak gerekir.

SPN PowerShell ile Nasıl Görüntülenir?

SPN kayıtlarını Active Directory PowerShell modülüyle de görüntüleyebilirsiniz. User account için:

Get-ADUser -Identity SQLService -Properties ServicePrincipalName |
Select-Object -ExpandProperty ServicePrincipalName

Computer account için:

Get-ADComputer -Identity PROD-SQL01 -Properties ServicePrincipalName |
Select-Object -ExpandProperty ServicePrincipalName

SPN Sorunu Olduğunda Ne Olur?

SPN hataları her zaman kullanıcıya doğrudan “SPN hatası” şeklinde görünmez. Bu nedenle troubleshooting sırasında belirtileri doğru yorumlamak önemlidir. Karşılaşabileceğiniz tipik durumlar şunlardır:

• Kerberos authentication başarısız olabilir.
• Uygulama NTLM authentication’a fallback yapabilir.
• Integrated Windows Authentication beklediğiniz gibi çalışmayabilir.
• SQL Server bağlantılarında Kerberos yerine NTLM görülebilir.
• IIS uygulamalarında authentication problemleri oluşabilir.
• Double-hop ve delegation senaryoları çalışmayabilir.
• Servis hesabı değişikliğinden sonra bağlantı sorunları başlayabilir.

SPN Problemlerinde Ben Neleri Kontrol Ediyorum?

Kerberos ile ilgili bir servis problemi yaşadığımda SPN tarafında genel olarak aşağıdaki sırayla ilerliyorum:

1. Servis gerçekten hangi account altında çalışıyor?
2. Client servise hangi DNS adıyla bağlanıyor?
3. Bu isim için beklenen SPN nedir?
4. SPN hangi account üzerinde kayıtlı?
5. Aynı SPN başka bir account üzerinde de bulunuyor mu?
6. Servis hesabı yakın zamanda değiştirildi mi?
7. DNS alias veya load balancer kullanılıyor mu?
8. Client gerçekten Kerberos mu kullanıyor, yoksa NTLM’e mi düşüyor?

Özellikle DNS alias kullanılan ortamlarda SPN konusu daha da önemli hale geliyor. Kullanıcı servise gerçek sunucu adı yerine bir alias üzerinden bağlanıyorsa Kerberos client’ı ticket’ı da çoğunlukla bu isim üzerinden talep eder. Bu nedenle ilgili alias için gerekli SPN kaydının doğru account üzerinde bulunması gerekir.

SPN ve DNS Arasındaki İlişki

SPN problemlerini DNS’ten bağımsız düşünmemek gerekir. Client bir servise bağlanırken kullandığı hostname üzerinden hedef servis için SPN oluşturur. Örneğin kullanıcı:

https://portal.contoso.com

adresine bağlanıyorsa HTTP servisi için Kerberos tarafında beklenen SPN genellikle:

HTTP/portal.contoso.com

olacaktır. Bu nedenle CNAME, DNS alias, load balancer veya cluster name kullanılan yapılarda servis hesabının SPN kayıtlarını ayrıca kontrol etmek gerekir.

SPN ve Kerberos Troubleshooting

SPN kontrolünden sonra client üzerindeki Kerberos ticket’larını görmek için klist komutunu kullanabilirsiniz:

klist

Yapılan SPN değişikliklerinden sonra eski Service Ticket cache üzerinde kalıyorsa test sonucunuz yanıltıcı olabilir. Bu durumda mevcut Kerberos ticket’larını temizlemek için:

klist purge

komutunu kullanıp bağlantıyı yeniden test edebilirsiniz. Ayrıca Domain Controller üzerindeki Event ID 4769 kayıtları, hangi SPN için Service Ticket talep edildiğini görmek açısından oldukça değerlidir.

SPN Güvenlik Açısından Neden Önemlidir?

SPN yalnızca troubleshooting açısından değil, Active Directory güvenliği açısından da önemlidir. Bir domain user account üzerinde SPN bulunması, bu hesabın bir servis hesabı olarak kullanıldığını gösterebilir. Kerberos kullanan bir kullanıcı bu servis için Service Ticket talep edebilir. Bu özellik Kerberoasting olarak bilinen saldırı tekniğinde de kullanılır. Saldırgan SPN tanımlı servis hesapları için Service Ticket talep ederek elde ettiği şifreli veriler üzerinde offline password cracking denemeleri yapabilir. Bu nedenle SPN tanımlı servis hesaplarında uzun ve güçlü parolalar kullanılması, mümkün olan servislerde gMSA – Group Managed Service Account tercih edilmesi ve artık kullanılmayan SPN kayıtlarının temizlenmesi önemlidir.

Özet

SPN, Active Directory ve Kerberos authentication mimarisinin temel parçalarından biridir. Kerberos, bir servise Service Ticket üretirken ilgili servisin kimliğini SPN üzerinden belirler. SPN kayıtları Active Directory içerisindeki servicePrincipalName attribute’unda saklanır ve aynı SPN’in yalnızca bir security principal üzerinde kayıtlı olması gerekir. Kerberos problemlerinde benim için SPN kontrolünün temel sırası basittir: önce servisin hangi hesap altında çalıştığını, ardından client’ın hangi isimle bağlandığını, daha sonra bu isim için doğru SPN’in hangi account üzerinde kayıtlı olduğunu kontrol ederim. setspn -Q, setspn -X, setspn -L ve klist komutları bu kontroller sırasında en sık kullandığımız araçlardır.