Windows Server’da Kerberos Delegation Güvenliği: Unconstrained ve Constrained Delegation Yapılandırması

Yazar:komut.io ekibi Windows Server Güvenlik Ayarları
0 Yorum

Kerberos delegation, Active Directory ortamlarında en çok yanlış yapılandırılan ve dolayısıyla en çok istismar edilen güvenlik mekanizmalarından biri. Bir servisin, kullanıcı adına başka bir servise erişebilmesi için kullanıcının kimliğini “devralması” prensibine dayanan bu mekanizma, doğru yapılandırılmadığında saldırganlara domain admin yetkisi kazanma yolu açabiliyor. Bu yazıda hem unconstrained hem de constrained delegation’ı gerçek dünya senaryolarıyla birlikte ele alacağız, yanlış yapılandırmaların nasıl tehlike yarattığını göreceğiz ve güvenli bir delegation ortamı nasıl kurulur onu inceleyeceğiz.

Kerberos Delegation Nedir ve Neden Gereklidir?

Klasik bir senaryoyu düşünelim: Kullanıcı bir web uygulamasına bağlanıyor, web uygulaması arka planda bir SQL Server’a erişmesi gerekiyor. Kullanıcının kimliğinin SQL Server’a da taşınması gerekiyorsa, yani “double-hop” problemi yaşanıyorsa, Kerberos delegation devreye giriyor.

Mesela şirketinizde bir SharePoint farm var. Kullanıcılar SharePoint’e erişiyor, SharePoint da arka planda SQL Server’daki veritabanına, Exchange Server’a veya başka kaynaklara erişiyor. Bu akışın sorunsuz çalışması için delegation zorunlu.

Delegation’ın üç türü var:

  • Unconstrained Delegation: Servis hesabı, kullanıcı adına herhangi bir servise erişebilir. En tehlikeli seçenek.
  • Constrained Delegation: Servis hesabı, yalnızca belirtilen servislere kullanıcı adına erişebilir. Daha güvenli.
  • Resource-Based Constrained Delegation (RBCD): Hedef kaynak kimin kendisine delegate edebileceğini tanımlar. Modern ve önerilen yöntem.

Unconstrained Delegation: En Büyük Risk

Unconstrained delegation, bir servis hesabına “istediğin servise, istediğin kullanıcı adına eriş” yetkisi veriyor. Active Directory’de bir bilgisayar veya servis hesabında TrustedForDelegation flag’i set edildiğinde bu durum oluşuyor.

Unconstrained Delegation Nasıl Çalışır?

Kullanıcı unconstrained delegation yetkisi olan bir servise bağlandığında, Kerberos TGT (Ticket Granting Ticket) bileti servis hesabına gönderiliyor. Bu bilet bellekte saklanıyor ve servis hesabı bu TGT’yi kullanarak domain içindeki herhangi bir servise kullanıcı adına erişebiliyor.

Saldırı açısından düşündüğünüzde, eğer bir saldırgan bu sunucuya erişim sağlarsa bellekteki TGT’leri çalabilir ve domain admin dahil herhangi bir kullanıcıyı impersonate edebilir. “Printer Bug” veya “SpoolSample” saldırısı da bu zafiyeti kullanıyor: Domain controller’ı unconstrained delegation yetkisi olan sunucuya bağlanmaya zorluyorsunuz, DC’nin makine hesabının TGT’si bellekte beliriyor ve oyun bitiyor.

Unconstrained Delegation Olan Hesapları Tespit Etme

Önce ortamınızda unconstrained delegation yetkisi olan hesapları tespit edin:

# PowerShell ile unconstrained delegation hesaplarını bulma
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation, TrustedToAuthForDelegation, servicePrincipalName, Description | Select-Object Name, TrustedForDelegation, servicePrincipalName

# Kullanıcı hesaplarını da kontrol edin
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation, servicePrincipalName | Select-Object Name, TrustedForDelegation, servicePrincipalName
# Domain controller'ları unconstrained delegation listesinden çıkararak filtreleyin
# DC'ler zaten unconstrained delegation ile çalışır, onları listelemek anlamsız
Get-ADComputer -Filter {TrustedForDelegation -eq $true -and PrimaryGroupID -ne "516" -and PrimaryGroupID -ne "521"} -Properties * | Select-Object Name, OperatingSystem, TrustedForDelegation

Domain controller’lar varsayılan olarak unconstrained delegation ile çalışır ve bu normaldir. Asıl sorun, DC olmayan sunucularda bu yetkinin bulunmasıdır.

Unconstrained Delegation’ı Kaldırma

# Bir bilgisayar hesabından unconstrained delegation kaldırma
Set-ADComputer -Identity "WEBSERVER01" -TrustedForDelegation $false

# Servis hesabından kaldırma
Set-ADUser -Identity "svc-webapp" -TrustedForDelegation $false

# Değişikliği doğrulama
Get-ADComputer -Identity "WEBSERVER01" -Properties TrustedForDelegation | Select-Object Name, TrustedForDelegation

Constrained Delegation Yapılandırması

Constrained delegation, servis hesabının yalnızca belirli hedef servislere kullanıcı adına erişebildiği, çok daha kontrollü bir mekanizma. İki modda çalışır:

  • Kerberos only: Sadece Kerberos kimlik doğrulaması yapan kullanıcılar için çalışır.
  • Use any authentication protocol (Protocol Transition): NTLM ile giriş yapan kullanıcılar da Kerberos’a geçiş yapabilir. Bu mod daha riskli.

Senaryo: SharePoint’ten SQL Server’a Delegation

Şirketinizde SharePoint 2019 farm’ı var. SharePoint App Pool hesabı [email protected] ve SQL Server’a erişmesi gerekiyor. SQL Server SPN’leri MSSQLSvc/SQLSERVER01.domain.local:1433 olarak tanımlı.

# Önce SPN'lerin tanımlı olduğunu doğrulayın
setspn -L SQLSERVER01

# SharePoint servis hesabına constrained delegation ekleyin
# Active Directory Users and Computers yerine PowerShell kullanmak daha güvenilir

Set-ADUser -Identity "svc-sharepoint" -Add @{
    'msDS-AllowedToDelegateTo' = @(
        'MSSQLSvc/SQLSERVER01.domain.local:1433',
        'MSSQLSvc/SQLSERVER01:1433'
    )
}

# Constrained delegation flag'ini set edin (Kerberos only mod)
# TrustedToAuthForDelegation = false = Kerberos only
# TrustedToAuthForDelegation = true = Protocol Transition (any auth)

$user = Get-ADUser -Identity "svc-sharepoint" -Properties UserAccountControl
$userAccountControl = $user.UserAccountControl
# TRUSTED_TO_AUTH_FOR_DELEGATION flag (0x1000000) EKLEMEDEN bırakıyoruz
Set-ADUser -Identity "svc-sharepoint" -Replace @{UserAccountControl = $userAccountControl}
# Yapılandırmayı doğrulama
Get-ADUser -Identity "svc-sharepoint" -Properties 'msDS-AllowedToDelegateTo', TrustedToAuthForDelegation | 
    Select-Object Name, TrustedToAuthForDelegation, 'msDS-AllowedToDelegateTo'

Senaryo: IIS Uygulama Havuzundan Dosya Sunucusuna Delegation

Bir .NET web uygulamanız var, kullanıcıların kimliğini taşıyarak bir dosya sunucusuna erişmesi gerekiyor.

# Web sunucusu makine hesabı için constrained delegation
# (Makine hesabı üzerinden yapılandırma senaryosu)

Set-ADComputer -Identity "WEBSERVER01" -Add @{
    'msDS-AllowedToDelegateTo' = @(
        'cifs/FILESERVER01.domain.local',
        'cifs/FILESERVER01'
    )
}

# Protocol transition OLMADAN constrained delegation
# UserAccountControl'dan TrustedForDelegation flag'ini temizleyin
Set-ADComputer -Identity "WEBSERVER01" -TrustedForDelegation $false

# Doğrulama
Get-ADComputer -Identity "WEBSERVER01" -Properties 'msDS-AllowedToDelegateTo', TrustedForDelegation, TrustedToAuthForDelegation |
    Format-List Name, TrustedForDelegation, TrustedToAuthForDelegation, 'msDS-AllowedToDelegateTo'

Resource-Based Constrained Delegation (RBCD)

Windows Server 2012 ile gelen RBCD, delegation kontrolünü kaynak tarafına taşıyor. “Hangi hesaplar bana delegate edebilir?” sorusuna hedef kaynak cevap veriyor. Bu yaklaşım özellikle workgroup sunucular veya farklı domainler arası senaryolarda çok daha esnek.

RBCD Yapılandırması

# Senaryo: WEBSERVER01'in svc-webapp servis hesabı adına SQLSERVER01'e erişmesine izin ver
# Bu kez yapılandırmayı SQLSERVER01 üzerinde yapıyoruz

# Önce WEBSERVER01'in SID'ini alalım
$webServer = Get-ADComputer -Identity "WEBSERVER01"

# SQLSERVER01'de RBCD yapılandırması
Set-ADComputer -Identity "SQLSERVER01" -PrincipalsAllowedToDelegateToAccount $webServer

# Birden fazla kaynak için
$allowedComputers = @(
    (Get-ADComputer -Identity "WEBSERVER01"),
    (Get-ADComputer -Identity "APPSERVER01")
)
Set-ADComputer -Identity "SQLSERVER01" -PrincipalsAllowedToDelegateToAccount $allowedComputers

# Doğrulama
Get-ADComputer -Identity "SQLSERVER01" -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object -ExpandProperty PrincipalsAllowedToDelegateToAccount

RBCD’nin geleneksel constrained delegation’a göre avantajları:

  • Kaynak sahibi kimin erişebileceğini kontrol eder, domain admin’e bağımlılık azalır.
  • Farklı domain’ler ve forest’lar arası delegation desteği daha iyi.
  • Orman güveni gerektirmeyen senaryolarda kullanılabilir.
  • msDS-AllowedToDelegateTo attribute yerine msDS-AllowedToActOnBehalfOfOtherIdentity kullanır.

Delegation Güvenlik Denetimi

Ortamınızın delegation yapılandırmasını düzenli olarak denetlemek şart. İşte kapsamlı bir denetim scripti:

# Kapsamli delegation audit scripti
function Get-DelegationAudit {
    $report = @()
    
    # Unconstrained delegation - Bilgisayarlar (DC haric)
    $unconstrainedComputers = Get-ADComputer -Filter {
        TrustedForDelegation -eq $true
    } -Properties TrustedForDelegation, OperatingSystem, LastLogonDate, Description |
    Where-Object { $_.PrimaryGroupID -notin @(516, 521) }
    
    foreach ($comp in $unconstrainedComputers) {
        $report += [PSCustomObject]@{
            Name = $comp.Name
            Type = "Computer"
            DelegationType = "Unconstrained"
            AllowedServices = "ANY"
            LastLogon = $comp.LastLogonDate
            OS = $comp.OperatingSystem
            RiskLevel = "KRITIK"
        }
    }
    
    # Unconstrained delegation - Kullanicilar
    $unconstrainedUsers = Get-ADUser -Filter {
        TrustedForDelegation -eq $true
    } -Properties TrustedForDelegation, LastLogonDate, Description
    
    foreach ($user in $unconstrainedUsers) {
        $report += [PSCustomObject]@{
            Name = $user.SamAccountName
            Type = "User"
            DelegationType = "Unconstrained"
            AllowedServices = "ANY"
            LastLogon = $user.LastLogonDate
            OS = "N/A"
            RiskLevel = "KRITIK"
        }
    }
    
    # Constrained delegation - Protocol Transition ile
    $protocolTransition = Get-ADObject -Filter {
        TrustedToAuthForDelegation -eq $true
    } -Properties TrustedToAuthForDelegation, 'msDS-AllowedToDelegateTo', LastLogonDate
    
    foreach ($obj in $protocolTransition) {
        $report += [PSCustomObject]@{
            Name = $obj.Name
            Type = $obj.ObjectClass
            DelegationType = "Constrained (Protocol Transition)"
            AllowedServices = ($obj.'msDS-AllowedToDelegateTo' -join "; ")
            LastLogon = $obj.LastLogonDate
            OS = "N/A"
            RiskLevel = "YUKSEK"
        }
    }
    
    $report | Sort-Object RiskLevel | Format-List
}

Get-DelegationAudit

Güvenlik Sertleştirme Önerileri

Korunan Kullanıcılar Grubunu Kullanın

Windows Server 2012 R2 ile gelen “Protected Users” güvenlik grubu, grup üyelerinin delegation için kullanılmasını engeller. Domain admin ve yüksek yetkili hesapları bu gruba ekleyin.

# Kritik hesapları Protected Users grubuna ekleyin
Add-ADGroupMember -Identity "Protected Users" -Members @(
    "DomainAdmin1",
    "svc-critical-app",
    "CEO_Account"
)

# Grubun mevcut üyelerini kontrol edin
Get-ADGroupMember -Identity "Protected Users" | Select-Object Name, ObjectClass, SamAccountName

# Bir hesabın Protected Users grubunda olup olmadığını kontrol
(Get-ADUser -Identity "DomainAdmin1" -Properties MemberOf).MemberOf -like "*Protected Users*"

Protected Users grubunun üyelerine uygulanan kısıtlamalar:

  • NTLM kimlik doğrulaması kullanılamaz.
  • DES ve RC4 Kerberos şifreleme türleri kullanılamaz.
  • Kerberos delegation için kimlik bilgileri önbelleğe alınmaz.
  • Kerberos biletleri 4 saatten uzun süre geçerli olmaz.

Delegation İzlemesi için Audit Policy

# Delegation olaylarını izlemek için audit policy yapılandırma
# Kerberos Service Ticket Operations audit etkinleştirme
auditpol /set /subcategory:"Kerberos Service Ticket Operations" /success:enable /failure:enable

# Kerberos Authentication Service audit
auditpol /set /subcategory:"Kerberos Authentication Service" /success:enable /failure:enable

# Mevcut audit policy kontrolu
auditpol /get /subcategory:"Kerberos Service Ticket Operations"
auditpol /get /subcategory:"Kerberos Authentication Service"

Event ID’leri ve anlamları:

  • 4769: Kerberos service ticket talep edildi. Delegation saldırılarında yoğun olarak bu event görülür.
  • 4770: Kerberos service ticket yenilendi.
  • 4771: Kerberos pre-authentication başarısız.
  • 4624: Hesap başarıyla giriş yaptı, logon type 3 (network) delegation senaryolarında kritik.

SPN Temizliği

Duplike veya gereksiz SPN’ler delegation saldırılarında kullanılabilir. Düzenli olarak temizleyin:

# Duplicate SPN kontrolu
setspn -X -P

# Tum SPN'leri listele ve dosyaya kaydet
Get-ADComputer -Filter * -Properties servicePrincipalName |
    Where-Object { $_.servicePrincipalName -ne $null } |
    Select-Object Name, @{N='SPNs';E={$_.servicePrincipalName -join ', '}} |
    Export-Csv -Path "C:AuditSPN_Audit_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

# Gereksiz SPN silme
setspn -D "HTTP/eskisunucu.domain.local" "ESKISUNUCU"

Yaygın Hatalar ve Çözümleri

Hata 1: “The security context could not be delegated”

Bu hatayı aldığınızda genellikle SPN tanımlı değildir veya delegation yapılandırması eksiktir.

# SPN varlığını doğrulayın
setspn -Q MSSQLSvc/SQLSERVER01.domain.local:1433

# Hedef servis SPN'ini ekleyin
setspn -S MSSQLSvc/SQLSERVER01.domain.local:1433 SQLSERVER01

# Klist ile bilet durumunu kontrol edin
klist
klist tickets

Hata 2: Delegation Çalışıyor Ama Yanlış Kullanıcı Kimliğiyle

Protocol Transition aktifse ve NTLM ile bağlantı kuruluyorsa, servis hesabının kimliği taşınıyor olabilir. Bağlantı tipini Kerberos’a zorlayın ve TrustedToAuthForDelegation flag’ini devre dışı bırakın.

Hata 3: “KDC_ERR_BADOPTION” Hatası

Bu hata genellikle hedef SPN msDS-AllowedToDelegateTo listesinde yok demektir.

# Mevcut delegation izinlerini kontrol edin
Get-ADUser -Identity "svc-webapp" -Properties 'msDS-AllowedToDelegateTo' |
    Select-Object -ExpandProperty 'msDS-AllowedToDelegateTo'

# Eksik SPN'i ekleyin
Set-ADUser -Identity "svc-webapp" -Add @{
    'msDS-AllowedToDelegateTo' = 'MSSQLSvc/SQLSERVER01.domain.local:1433'
}

Sonuç

Kerberos delegation, doğru yapılandırıldığında hayat kurtarıcı bir mekanizma; yanlış yapılandırıldığında ise domain’in anahtarını saldırganlara teslim etmek anlamına geliyor. Özetle yapmanız gerekenler şunlar:

Öncelikle ortamınızda hangi hesapların unconstrained delegation yetkisine sahip olduğunu tespit edin ve DC’ler dışındaki hesaplardan bu yetkiyi kaldırın. Constrained delegation kullanmanız gerekiyorsa, mümkün olduğunca “Kerberos only” modunda yapılandırın, protocol transition’ı sadece zorunlu durumlarda aktif edin. Modern ortamlarda RBCD’ye geçiş yapın; hem daha güvenli hem de yönetimi daha kolay.

Kritik ve yüksek yetkili hesaplarınızı Protected Users grubuna ekleyerek delegation zincirinin dışında tutun. Düzenli SPN denetimi yapın, duplike ve atıl SPN’leri temizleyin. Audit policy’leri doğru yapılandırarak Kerberos olaylarını izleyin ve anormal delegation girişimlerini zamanında fark edin.

Delegation yapılandırması “bir kez yap, unut” mantığıyla çalışmaz. Uygulama değişiklikleri, sunucu ekleme-çıkarma ve servis hesabı değişiklikleri delegation yapılandırmalarını doğrudan etkiler. Bu yüzden periyodik denetim scriptlerini otomatize edin ve sonuçları güvenlik ekibinizle paylaşın.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir