Active Directory ortamlarında kimlik, bütün diğer güvenlik kontrollerinin temelini oluşturuyor. Özellikle ayrıcalıklı hesaplardan birinin ele geçirilmesi durumunda saldırganın erişebileceği kaynak sayısı çok daha fazla olabilir. MFA, ayrıcalıklı erişim iş istasyonları (PAW), minimum yetki ve erişim kısıtlamaları önemli; ancak bunlara ek olarak doğrudan Windows kimlik doğrulama altyapısında kullanabileceğimiz, ilave bir ürün gerektirmeyen bir özellik var: Protected Users Security Group.
Bu yazıda grubun ne yaptığını, hangi koşullarda kullanılabileceğini, sistemlere etkisini ve olası erişim kesintilerini yaşamadan nasıl devreye alınacağını ele alacağım. Örnekler Windows Server 2016/2019/2022/2025 etki alanı ortamları için de geçerlidir; gerçek davranışta domain functional level ve istemci sürümü belirleyicidir.
Protected Users Security Group Nedir?
Protected Users, Active Directory içerisinde hazır gelen global security group türünde bir gruptur. Temel amacı, belirli kullanıcı hesaplarının kimlik bilgilerinin istemcilerde gereksiz şekilde saklanmasını azaltmak ve uygun etki alanı koşullarında zayıf kimlik doğrulama yöntemleriyle kullanılmasını engellemektir. Bu bir MFA çözümü değildir; parola veya kimlik bilgisinin her türlü saldırıda çalınmasını kesin olarak önlediği anlamına da gelmez.
Grup varsayılan olarak CN=Users altında bulunur, varsayılan üyesi yoktur ve etki alanına özgü SID değeri S-1-5-21-<domain SID>-525 biçimindedir. Grubun korumaları sabit kurallardır; belirli bir kullanıcı için tek tek gevşetilemez. Bir kullanıcı için bu kısıtlamaları kaldırmak gerekiyorsa grup üyeliğinden çıkarmak gerekir.
Ön Koşullar ve Dikkat Edilmesi Gerekenler
Etki alanı: Tam DC tarafı korumaları için domain functional level en az Windows Server 2012 R2 olmalıdır. Domain functional level ile bir DC üzerinde kurulu işletim sisteminin sürümü aynı kavram değildir.
İstemci/oturum açılan makine: Güncel Windows 10/11 ile Windows Server 2012 R2 ve sonraki desteklenen sürümlerde ilgili istemci korumaları uygulanır. Eski Windows sürümlerinde aynı davranışı varsaymayın.
Kerberos AES: Korunan hesapların AES ile kimlik doğrulama yapabilecek anahtarlara sahip olması gerekir. Eski etki alanlarından taşınmış veya uzun süredir parolası değişmemiş hesaplarda bu ön koşul sorun yaratabilir.
Test yaklaşımı: Önce pilot kullanıcı ve kritik olmayan bir yönetim senaryosunda deneyin. Domain Admins/Enterprise Admins üyelerini topluca eklemek erişim kaybına neden olabilir.
Uygun hesap türü: İnsan kullanıcılarına ait ayrıcalıklı hesaplar için düşünülmüştür; servis hesapları, gMSA ve bilgisayar hesapları eklenmemelidir.
Grup Üyeliği Neleri Değiştirir?
1. İstemci Tarafındaki Kimlik Bilgisi Korumaları
CredSSP: “Allow delegating default credentials” ilkesi izin verse bile korunan kullanıcının düz metin kimlik bilgileri bu sağlayıcı tarafından önbelleğe alınmaz.
Windows Digest: Kullanıcının düz metin parolası önbellekte tutulmaz.
NTLM: Parolanın NT tabanlı türevi (NTOWF) istemcide önbelleğe alınmaz. Bu, bütün olası credential-theft tekniklerini ortadan kaldırmaz.
Kerberos: DES/RC4 anahtarları veya düz metin parola; ilk TGT alındıktan sonra uzun süreli anahtarlar istemcide tutulmaz.
Offline sign-in: Oturum açma/kilit açma için önbelleğe alınmış doğrulayıcı oluşturulmadığından, ilgili kullanıcının etki alanına erişim olmadan oturum açması mümkün olmayabilir.
NTLM ile kimlik doğrulaması engellenir. Kerberos kullanmayan uygulamalar veya senaryolar başarısız olabilir.
Kerberos DES ve RC4 preauthentication kullanılamaz. AES desteği zorunludur.
Constrained ve unconstrained delegation engellenir. İkinci sıçrama (double-hop) gerektiren uygulamalar etkilenebilir.
Kerberos TGT ömrü 4 saatle (240 dakika) sınırlanır. Normal TGT yenileme davranışı bu hesaplar için geçerli değildir; yeniden kimlik doğrulaması gerekebilir.
Önemli: İstemci tarafındaki koruma ile etki alanı denetleyicisinin kimlik doğrulama kısıtları aynı şey değildir. Yalnızca gruba kullanıcı ekleyip bütün sistemlerde aynı sonucu beklemek yerine etki alanı işlev düzeyini, uç nokta sürümünü ve gerçek kimlik doğrulama yolunu kontrol etmek gerekir.
Protected Users ile Credential Guard veya MFA Aynı Şey mi?
Hayır. Protected Users, üyeler için protokol kullanımını ve kimlik bilgisi saklama davranışını sınırlar. Windows Defender Credential Guard, belirli kimlik bilgilerini sanallaştırma tabanlı güvenlik mekanizmalarıyla korumaya yardımcı olur. MFA ise oturum açma veya erişim doğrulamasına ilave faktör ekler. Bunlar birbirini tamamlar; biri diğerinin yerine geçmez.
Uygulamadan Önce Kontrol Listesi
Etki alanı işlev düzeyini ve DC sürümlerini doğrulayın.
Kullanıcının NTLM gerektiren eski bir uygulamaya, NAS cihazına veya RDP/CredSSP senaryosuna bağımlı olup olmadığını test edin.
Hesabın Kerberos AES anahtarlarının mevcut olduğundan emin olun; eski hesaplar için planlı parola değişikliği gerekebilir.
Uygulamada Kerberos delegation/second-hop ihtiyacını analiz edin.
Ağ erişimi yokken etki alanı hesabıyla oturum açma ihtiyacı bulunmadığını doğrulayın.
Kurtarma için pilot dışında kalan, güvenli biçimde korunan bir acil durum yönetici erişim yolu bulundurun.
PowerShell ile Mevcut Durumu İnceleme
Aşağıdaki komutlar ActiveDirectory modülü ve uygun okuma yetkisi bulunan bir yönetim oturumunda çalıştırılabilir. Bunlar ilk aşamada herhangi bir üyelik değişikliği yapmaz.
Import-Module ActiveDirectory
# Etki alanı işlev düzeyi ve DC bilgileri
Get-ADDomain | Select-Object DNSRoot, DomainMode
Get-ADDomainController -Filter * | Select-Object HostName, OperatingSystem
# Protected Users grubunun mevcut üyeleri
Get-ADGroupMember -Identity "Protected Users" |
Select-Object Name, SamAccountName, ObjectClass
# Pilot kullanıcının Kerberos şifreleme ayarları
Get-ADUser -Identity "pilot.admin" -Properties msDS-SupportedEncryptionTypes,PasswordLastSet |
Select-Object SamAccountName, msDS-SupportedEncryptionTypes, PasswordLastSet
Not:msDS-SupportedEncryptionTypes değerinin tek başına görülmesi veya boş olması hesapta AES anahtarının bulunup bulunmadığını kesin olarak kanıtlamaz. Kimlik doğrulama olaylarıyla ve kontrollü giriş denemeleriyle birlikte değerlendirin.
Pilot Kullanıcıyı Protected Users Grubuna Ekleme
Aşağıdaki işlem üretimde oturum açma davranışını değiştirebilir. Yalnızca önceki kontrollerden geçmiş pilot kullanıcı üzerinde ve geri dönüş planı hazırken uygulanmalıdır.
# ÖRNEK: Kullanıcı adını kendi test hesabınıza göre değiştirin
Add-ADGroupMember -Identity "Protected Users" -Members "pilot.admin"
# Grup üyeliğini doğrulayın
Get-ADGroupMember -Identity "Protected Users" |
Where-Object SamAccountName -eq "pilot.admin"
Gruba eklendikten sonra istemci tarafındaki korumalar yeni oturum açıldığında etkinleşir. Bu nedenle mevcut oturuma bakarak sonuç çıkarmayın; pilot kullanıcıyla yeniden oturum açarak Kerberos ile kaynak erişimini test edin.
Sorun Yaşarsanız Geri Alma
Kimlik doğrulama sorunları yaşanırsa yetkili farklı bir yönetici hesabıyla pilot hesabı gruptan çıkarabilirsiniz. Grup üyeliği değişikliklerinin istemci oturumuna ve etki alanındaki biletlere yansıması için yeniden oturum açma veya bilet yenileme gerekebilir.
Olay günlükleri Event Viewer → Applications and Services Logs → Microsoft → Windows → Authentication altında bulunur. İlgili günlükler varsayılan olarak kapalı olabilir; test öncesinde kullanacağınız istemci ve DC üzerinde gerekli günlükleri ayrıca etkinleştirin.
İstemci – Event ID 104 / ProtectedUser-Client: Kimlik doğrulama için gereken credential ilgili güvenlik paketinde bulunmadı.
İstemci – Event ID 304 / ProtectedUser-Client: Korunan kullanıcının kimlik bilgisinin saklanmadığını gösteren bilgi olayı.
DC – Event ID 100 / ProtectedUserFailures-DomainController: Protected Users üyesi için NTLM kimlik doğrulaması reddedildi.
DC – Event ID 104 / ProtectedUserFailures-DomainController: DES/RC4 kullanılan Kerberos ön kimlik doğrulaması reddedildi.
DC – Event ID 303 / ProtectedUserSuccesses-DomainController: Protected Users üyesine başarıyla Kerberos TGT verildi.
Her başarısız giriş grubun yanlış yapılandırıldığını göstermez. Önce hangi sistemin NTLM, RC4 veya delegation gerektirdiğini belirleyin; mümkünse bağımlılığı giderin, ardından pilotu genişletin.
Hangi Hesapları Eklememeliyiz?
Windows servislerini çalıştıran hesaplar, bilgisayar hesapları ve gMSA türündeki yönetilen servis hesaplarını Protected Users grubuna eklemeyin. Ayrıca fiziksel olarak erişemeyeceğiniz makineler veya etki alanına çevrimdışı erişme zorunluluğu olan hesaplarda risk analizi yapın. Ayrıcalıklı bütün kullanıcıları aynı anda gruba almak yerine önce küçük ve temsili bir grupla başlayın.
Sonuç
Protected Users, Active Directory güvenliğinde özellikle ayrıcalıklı kullanıcı hesapları için oldukça değerli ve lisans maliyeti gerektirmeyen bir savunma katmanıdır. Ancak başarısı yalnızca gruba üye eklemeye değil, Kerberos/AES uyumluluğuna ve uygulama bağımlılıklarının doğru analiz edilmesine bağlıdır. Benim önerim, önce test hesabıyla NTLM ve delegation bağımlılıklarını görünür hale getirmeniz, logları kontrol etmeniz ve ancak bundan sonra yönetici hesaplarını kademeli biçimde taşımanızdır.
Bu konudaki uygulama örnekleri için ÇözümPark üzerindeki Active Directory Domain Service Protected Users Güvenlik Grubu Uygulamaları yazısını da inceleyebilirsiniz.
