Protected Users Güvenlik Grubu ile Ayrıcalıklı Hesapları Koruma

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

Ayrıcalıklı hesaplar, bir Active Directory ortamının en kritik noktalarından birini oluşturur. Domain Admin, Enterprise Admin veya Schema Admin gibi hesaplar ele geçirildiğinde, saldırgan tüm kurumsal altyapıyı kontrol altına alabilir. İşte tam bu noktada Protected Users güvenlik grubu devreye giriyor. Windows Server 2012 R2 ile birlikte hayatımıza giren bu özellik, ayrıcalıklı hesaplara yönelik kimlik bilgisi hırsızlığı saldırılarını ciddi ölçüde zorlaştırıyor. Bu yazıda Protected Users grubunu derinlemesine inceleyecek, gerçek dünya senaryoları üzerinden nasıl kullanacağınızı göstereceğim.

Protected Users Grubu Nedir ve Neden Önemlidir?

Geleneksel Windows kimlik doğrulama mekanizmaları, yıllar içinde çeşitli saldırı vektörlerine karşı savunmasız olduğunu kanıtladı. Pass-the-Hash, Pass-the-Ticket, Credential Dumping gibi saldırılar, özellikle Mimikatz gibi araçların yaygınlaşmasıyla birlikte kurumsal ortamlar için ciddi tehditler haline geldi.

Protected Users grubu, bu tehditlere karşı doğrudan LSASS (Local Security Authority Subsystem Service) üzerinde çalışan bir koruma katmanı sağlar. Gruba eklenen hesaplar için işletim sistemi seviyesinde bir dizi kısıtlama devreye girer ve bu kısıtlamalar Group Policy veya registry değişiklikleyle devre dışı bırakılamaz. Bu, özellikle iç tehditlara ve lateral movement saldırılarına karşı güçlü bir savunma hattı oluşturur.

Önemli bir nokta: Protected Users grubunun korumaları etki alanı üyesi sistemlerde geçerlidir. Workgroup makinelerde veya domain controller olmayan standalone sunucularda bazı korumalar çalışmaz.

Hangi Kısıtlamalar Uygulanır?

Protected Users grubuna bir hesap eklendiğinde, aşağıdaki kısıtlamalar otomatik olarak devreye girer:

NTLM kimlik doğrulaması devre dışı bırakılır: Hesap artık NTLM üzerinden kimlik doğrulama yapamaz. Sadece Kerberos kullanılabilir. Bu, Pass-the-Hash saldırılarını kökten engeller.

DES ve RC4 şifreleme algoritmaları engellenir: Kerberos bilet şifrelemesinde artık yalnızca AES128 veya AES256 kullanılabilir. DES ve RC4, bilinen zayıflıkları nedeniyle devre dışı kalır.

Kerberos Constrained veya Unconstrained Delegation çalışmaz: Grup üyesi olan hesaplar Kerberos delegation işlemlerine tabi tutulamaz. Bu, delegation tabanlı saldırıları engeller.

Kimlik bilgileri LSASS belleğinde önbelleğe alınmaz: WDigest, CredSSP ve benzeri protokoller üzerinden kimlik bilgileri plain-text veya reversible encryption formatında bellekte saklanmaz.

Kerberos TGT bilet süresi kısıtlanır: Varsayılan olarak 4 saat ile sınırlıdır, yenilenebilir süre maksimum 4 saattir. Normal hesaplarda bu süre genellikle 10 saat veya daha uzundur.

Cached credentials çalışmaz: Kullanıcı domain controller’a ulaşamadığında önbelleğe alınmış kimlik bilgileriyle oturum açamaz.

Ön Koşullar ve Desteklenen Ortamlar

Protected Users grubunu etkin biçimde kullanabilmek için altyapınızın belirli gereksinimleri karşılaması gerekir.

Domain Functional Level gereksinimleri:

  • Windows Server 2012 R2 Domain Functional Level: Tam koruma için gereklidir
  • Windows Server 2008 R2 veya 2012 DFL: Grup oluşturulabilir ancak DC tarafı korumalar sınırlı çalışır

İstemci tarafı gereksinimler:

  • Windows 8.1 / Windows Server 2012 R2 ve üzeri sistemlerde tam koruma
  • Windows 7 / Windows Server 2008 R2 sistemlerde bazı korumalar çalışmayabilir

Ön koşul kontrolü için PowerShell:

# Domain Functional Level kontrolü
Get-ADDomain | Select-Object DomainMode, Forest

# Forest Functional Level kontrolü
Get-ADForest | Select-Object ForestMode, Name

# DC işletim sistemi sürümlerini kontrol et
Get-ADDomainController -Filter * | Select-Object Name, OperatingSystem, OperatingSystemVersion

Protected Users Grubunu Yapılandırma

Grup Üyeliği Yönetimi

Protected Users grubunu yapılandırmak için Active Directory Users and Computers (ADUC) veya PowerShell kullanabilirsiniz.

# Protected Users grubuna tek bir hesap ekleme
Add-ADGroupMember -Identity "Protected Users" -Members "adminkullanici"

# Birden fazla hesabı gruba ekleme
$AdminAccounts = @("dadmin01", "eadmin01", "srvadmin01", "helpdesk_senior")
Add-ADGroupMember -Identity "Protected Users" -Members $AdminAccounts

# Mevcut grup üyelerini listeleme
Get-ADGroupMember -Identity "Protected Users" -Recursive | 
    Select-Object Name, SamAccountName, ObjectClass | 
    Sort-Object Name

Toplu Ekleme Senaryosu

Gerçek bir kurumda genellikle belirli OU’lardaki tüm yönetici hesaplarını gruba eklemek isteyebilirsiniz. Aşağıdaki script, belirli bir OU altındaki tüm kullanıcıları Protected Users grubuna ekler ve işlemi loglar.

# Belirli OU'daki tüm admin hesaplarını Protected Users'a ekleme
$AdminOU = "OU=AdminAccounts,OU=IT,DC=sirket,DC=local"
$LogFile = "C:LogsProtectedUsers_$(Get-Date -Format 'yyyyMMdd').log"

$AdminUsers = Get-ADUser -Filter * -SearchBase $AdminOU -Properties MemberOf

foreach ($User in $AdminUsers) {
    $IsAlreadyMember = ($User.MemberOf | Where-Object { $_ -like "*Protected Users*" })
    
    if (-not $IsAlreadyMember) {
        try {
            Add-ADGroupMember -Identity "Protected Users" -Members $User.SamAccountName
            $LogEntry = "$(Get-Date) - EKLENDI: $($User.SamAccountName)"
            Add-Content -Path $LogFile -Value $LogEntry
            Write-Host "Eklendi: $($User.SamAccountName)" -ForegroundColor Green
        } catch {
            $ErrEntry = "$(Get-Date) - HATA: $($User.SamAccountName) - $($_.Exception.Message)"
            Add-Content -Path $LogFile -Value $ErrEntry
            Write-Host "Hata: $($User.SamAccountName)" -ForegroundColor Red
        }
    } else {
        Write-Host "Zaten üye: $($User.SamAccountName)" -ForegroundColor Yellow
    }
}

Authentication Policy ve Authentication Policy Silo ile Entegrasyon

Protected Users grubu tek başına güçlü bir koruma sağlasa da, Authentication Policy ve Authentication Policy Silo ile birlikte kullanıldığında çok daha kapsamlı bir güvenlik katmanı oluşturur. Bu özellikler Windows Server 2012 R2 ile gelmiş olup Protected Users’ı tamamlayıcı niteliktedir.

# Yeni bir Authentication Policy oluşturma
New-ADAuthenticationPolicy -Name "AdminAuthPolicy" `
    -UserTGTLifetimeMins 60 `
    -Description "Kritik Admin Hesaplari icin Auth Policy" `
    -Enforce

# Authentication Policy Silo oluşturma
New-ADAuthenticationPolicySilo -Name "PrivilegedAdminSilo" `
    -Description "Ayricalikli Admin Hesaplari Silo" `
    -UserAuthenticationPolicy "AdminAuthPolicy" `
    -ComputerAuthenticationPolicy "AdminAuthPolicy" `
    -ServiceAuthenticationPolicy "AdminAuthPolicy" `
    -Enforce

# Hesabı silo'ya atama
Grant-ADAuthenticationPolicySiloAccess -Identity "PrivilegedAdminSilo" `
    -Account "dadmin01"

Set-ADUser -Identity "dadmin01" `
    -AuthenticationPolicySilo "PrivilegedAdminSilo"

Gerçek Dünya Senaryosu: Pass-the-Hash Saldırısını Engelleme

Şöyle bir senaryo düşünelim: Kurumunuzda bir saldırgan, phishing yoluyla standart bir kullanıcı hesabını ele geçirdi. Ardından bu makinede Mimikatz çalıştırarak LSASS belleğinden kimlik bilgilerini dump etmeye çalışıyor. Eğer domain admin hesabı o makinede daha önce oturum açmışsa ve Protected Users grubunda değilse, NTLM hash’i bellekten çekilebilir ve Pass-the-Hash saldırısı gerçekleştirilebilir.

Protected Users grubuna eklenmiş bir hesap için durum farklıdır:

# Protected Users grubundaki hesapların kimlik doğrulama loglarını izleme
# Olay Kimliği 4624: Başarılı oturum açma
# Olay Kimliği 4625: Başarısız oturum açma  
# Olay Kimliği 4771: Kerberos ön kimlik doğrulama başarısız

Get-WinEvent -LogName Security -FilterXPath `
    "*[System[EventID=4624] and EventData[Data[@Name='LogonType']='3']]" `
    -MaxEvents 100 | 
    Where-Object { $_.Message -like "*dadmin01*" } |
    Select-Object TimeCreated, Message |
    Format-List

# NTLM kimlik doğrulama girişimlerini tespit etme
Get-WinEvent -LogName Security -FilterXPath `
    "*[System[EventID=4776]]" -MaxEvents 50 |
    Select-Object TimeCreated, 
    @{N="Kullanici";E={$_.Properties[1].Value}},
    @{N="Kaynak";E={$_.Properties[2].Value}}

Protected Users grubundaki bir hesapla NTLM kimlik doğrulaması denendiğinde, sistem bu isteği reddedecek ve event log’a Event ID 4776 ile “NTLM_BLOCKED” hatası kaydedecektir.

Uyumluluk Sorunları ve Dikkat Edilmesi Gerekenler

Protected Users grubunu uygulamadan önce mutlaka dikkat etmeniz gereken kritik noktalar var. Yanlış yapılandırma, üretim ortamında ciddi kesintilere yol açabilir.

NTLM gerektiren servisler: Eğer bir servis hesabı NTLM kimlik doğrulaması gerektiriyorsa ve Protected Users grubuna eklenirse, o servis çalışamaz hale gelir.

Kerberos delegation kullanan uygulamalar: SharePoint, Exchange veya özel uygulamalar delegation kullandığında bu hesaplar Protected Users grubunda olmamalıdır.

VPN ve uzak erişim çözümleri: Bazı VPN çözümleri NTLM veya NTLMv2 kullanır. Bu durumlarda Protected Users grubundaki hesaplar VPN bağlantısı kuramaz.

# Servis hesaplarının NTLM kullanıp kullanmadığını tespit etme
# Domain Controller'da NTLM audit'i etkinleştirme
auditpol /set /subcategory:"Credential Validation" /success:enable /failure:enable

# NTLM kimlik doğrulama girişimlerini raporlama
$StartTime = (Get-Date).AddDays(-7)
Get-WinEvent -LogName Security | 
    Where-Object { $_.Id -eq 4776 -and $_.TimeCreated -gt $StartTime } |
    Group-Object { $_.Properties[1].Value } |
    Sort-Object Count -Descending |
    Select-Object Name, Count |
    Format-Table -AutoSize
# Kerberos delegation kullanan hesapları tespit etme
Get-ADUser -Filter { (TrustedForDelegation -eq $true) -or 
                     (TrustedToAuthForDelegation -eq $true) } `
    -Properties TrustedForDelegation, TrustedToAuthForDelegation, 
                ServicePrincipalName, Description |
    Select-Object Name, SamAccountName, TrustedForDelegation, 
                  TrustedToAuthForDelegation, ServicePrincipalName

# Constrained delegation kullanan hesapları bul
Get-ADUser -Filter { msDS-AllowedToDelegateTo -like "*" } `
    -Properties "msDS-AllowedToDelegateTo" |
    Select-Object Name, SamAccountName, "msDS-AllowedToDelegateTo"

Protected Users Uygulaması Öncesi Test Ortamı Hazırlığı

Üretim ortamında uygulama yapmadan önce mutlaka test etmeniz gerekiyor. Aşağıdaki yaklaşım, riskleri minimize eder.

Aşamalı uygulama planı:

  • 1. Hafta: Servis hesapları hariç tüm Admin hesaplarını tespit edin ve NTLM bağımlılıklarını analiz edin
  • 2. Hafta: Test ortamında pilot uygulamayı gerçekleştirin, log analizini yapın
  • 3. Hafta: En kritik ve en az bağımlılığı olan hesaplarla üretimde başlayın
  • 4. Hafta ve sonrası: Kalan hesapları aşamalı olarak gruba ekleyin
# Protected Users uygulaması sonrası kapsamlı doğrulama scripti
function Test-ProtectedUserStatus {
    param([string]$UserName)
    
    $User = Get-ADUser -Identity $UserName -Properties MemberOf, 
            PasswordNeverExpires, SmartcardLogonRequired,
            TrustedForDelegation, "msDS-SupportedEncryptionTypes"
    
    $IsProtected = ($User.MemberOf | Where-Object { $_ -like "*CN=Protected Users*" })
    
    Write-Host "`n=== $UserName Koruma Durumu ===" -ForegroundColor Cyan
    Write-Host "Protected Users Uyesi: $(if($IsProtected){'EVET'}else{'HAYIR'})" `
        -ForegroundColor $(if($IsProtected){'Green'}else{'Red'})
    Write-Host "Sifre Suresi Dolmaz: $($User.PasswordNeverExpires)"
    Write-Host "Smartcard Zorunlu: $($User.SmartcardLogonRequired)"
    Write-Host "Delegation Acik: $($User.TrustedForDelegation)"
    
    $EncTypes = $User."msDS-SupportedEncryptionTypes"
    Write-Host "Desteklenen Sifrele Tipleri: $EncTypes"
    
    if ($User.PasswordNeverExpires -and $IsProtected) {
        Write-Host "UYARI: Sifre suresi dolmayan Protected User hesabi!" `
            -ForegroundColor Yellow
    }
}

# Kullanimi
Test-ProtectedUserStatus -UserName "dadmin01"

Monitoring ve Alerting Yapılandırması

Protected Users grubuna yapılan değişiklikleri izlemek kritik önemdedir. Saldırganlar ele geçirdikleri hesapları Protected Users grubundan çıkarmaya çalışabilir.

# Protected Users grubu değişikliklerini izleme
# Event ID 4756: Güvenlik grubuna üye eklendi
# Event ID 4757: Güvenlik grubundan üye çıkarıldı

$FilterXML = @"
<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[System[EventID=4757] and 
        EventData[Data[@Name='TargetUserName']='Protected Users']]
    </Select>
  </Query>
</QueryList>
"@

$Events = Get-WinEvent -FilterXml $FilterXML -ErrorAction SilentlyContinue

if ($Events) {
    foreach ($Event in $Events) {
        Write-Host "KRITIK UYARI: Protected Users grubundan uye cikarildi!" `
            -ForegroundColor Red
        Write-Host "Zaman: $($Event.TimeCreated)"
        Write-Host "Detay: $($Event.Message)"
        
        # Burada email veya SIEM entegrasyonu eklenebilir
        Send-MailMessage -To "[email protected]" `
            -From "[email protected]" `
            -Subject "KRITIK: Protected Users Grup Degisikligi" `
            -Body $Event.Message `
            -SmtpServer "mail.sirket.com"
    }
}

Tier Model ile Entegrasyon

Microsoft’un Administrative Tier Model yaklaşımı ile Protected Users grubunu birlikte kullanmak, savunma derinliği açısından en iyi sonucu verir.

  • Tier 0 (Domain Controllers, PKI, AD): Bu katmandaki tüm admin hesapları mutlaka Protected Users grubunda olmalıdır
  • Tier 1 (Sunucular ve Uygulamalar): Sunucu yönetimi yapan hesapların büyük çoğunluğu gruba eklenebilir, uyumluluk testleri yapılmalıdır
  • Tier 2 (Workstationlar): Helpdesk ve desktop admin hesapları da Protected Users kapsamına alınabilir ancak NTLM gereksinimleri dikkatli analiz edilmelidir

Tier 0 hesapları için ek güvenlik katmanı:

# Tier 0 admin hesaplarını tespit ve Protected Users uyumluluğunu raporlama
$Tier0Groups = @("Domain Admins", "Enterprise Admins", "Schema Admins", 
                  "Group Policy Creator Owners", "Administrators")

$AllTier0Users = @()
foreach ($Group in $Tier0Groups) {
    $Members = Get-ADGroupMember -Identity $Group -Recursive | 
               Where-Object { $_.objectClass -eq "user" }
    $AllTier0Users += $Members
}

$UniqueTier0Users = $AllTier0Users | Sort-Object SamAccountName -Unique
$ProtectedGroupMembers = Get-ADGroupMember -Identity "Protected Users" | 
                          Select-Object -ExpandProperty SamAccountName

Write-Host "`n=== Tier 0 Hesap Protected Users Uyum Raporu ===" -ForegroundColor Cyan
foreach ($T0User in $UniqueTier0Users) {
    $IsProtected = $ProtectedGroupMembers -contains $T0User.SamAccountName
    $Status = if ($IsProtected) { "KORUNUYOR" } else { "KORUMASIZ - AKSIYON GEREKLI" }
    $Color = if ($IsProtected) { "Green" } else { "Red" }
    Write-Host "$($T0User.SamAccountName): $Status" -ForegroundColor $Color
}

Sık Karşılaşılan Sorunlar ve Çözümleri

Sorun 1: Kullanıcı oturum açamıyor Genellikle Kerberos bilet süresi dolmuş veya DC’ye ulaşılamıyor. Cached credentials artık çalışmadığı için DC erişimi zorunludur.

Sorun 2: Uygulama hatası veriyor Uygulama NTLM veya delegation gerektiriyordur. İlgili hesabı gruptan çıkarın ve uygulamayı Kerberos’a geçirin.

Sorun 3: VPN bağlantısı kurulamıyor VPN çözümünüzün Kerberos desteği olup olmadığını kontrol edin. Yoksa VPN için ayrı bir hesap yapısı oluşturmayı düşünün.

# Protected Users kaynaklı oturum açma sorunlarını debug etme
# Kullanıcı bilgisayarında çalıştırılacak
klist tickets          # Mevcut Kerberos biletlerini görüntüle
klist purge            # Kerberos biletlerini temizle
klist get krbtgt       # Yeni TGT al

# DC üzerinde Kerberos hata loglarını kontrol etme
Get-WinEvent -LogName "Microsoft-Windows-Kerberos-Key-Distribution-Center/Operational" `
    -MaxEvents 50 | 
    Where-Object { $_.LevelDisplayName -eq "Error" -or $_.LevelDisplayName -eq "Warning" } |
    Select-Object TimeCreated, Id, Message |
    Format-List

Sonuç

Protected Users güvenlik grubu, Active Directory ortamlarında ayrıcalıklı hesapları korumak için ciddi bir araç. Sıfır maliyet, minimum yapılandırma gerektiren ve işletim sistemi çekirdeğinde çalışan bu mekanizma, Pass-the-Hash ve Pass-the-Ticket gibi yaygın saldırıları kökten engeller.

Ancak şunu unutmayın: Protected Users tek başına bir “sihirli değnek” değil. En iyi sonucu, Tier Model uygulaması, Authentication Policy Silo, düzenli erişim gözden geçirmeleri ve kapsamlı loglama ile birlikte alırsınız. Özellikle Domain Admins ve Enterprise Admins grubundaki tüm hesapların Protected Users grubunda olması artık bir best practice değil, bir zorunluluk olarak değerlendirilmeli.

Uygulamaya başlamadan önce NTLM bağımlılık analizini mutlaka yapın, test ortamında doğrulayın ve aşamalı bir rollout planı izleyin. Aceleyle yapılan bir Protected Users uygulaması, üretim ortamında öngörülemeyen kesintilere yol açabilir. Ama doğru yapıldığında, kimlik bilgisi tabanlı saldırılara karşı altyapınızın dayanıklılığını önemli ölçüde artırır.

Bir yanıt yazın

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