Active Directory Güvenlik Rehberi

Mehmet Sait YILMAZ 18/08/2025

1 21 dakika okuma süresi

Built-in\Administrator ve Domain Admin Hesaplarında SPN Kayıtlarının Bulunması

Risk: Yüksek ayrıcalıklı bir hesapta SPN (Service Principal Name) tanımlıolduğunda, herhangi bir etki alanı kullanıcısı bu hesaba ait Kerberos service ticket talep edebilir. Bu ticket çevrimdışı (offline) ortamda kırılabilir ve bu işlem sırasında hesap kilitlenmez veya tespit edilmez. Administrator ya da Domain Admin hesabının ele geçirilmesi, tüm etki alanının kontrolünü kaybetmeye yol açar.

Öneri: Yüksek ayrıcalıklı kullanıcı hesaplarında SPN tanımlı olmamalıdır. Servis hesaplarında SPN gerekiyorsa en az 25 karakter uzunluğunda güçlü parola kullanılmalı.

Kontrol:

Setspn -L Administrator
Setspn -D MSSQLsvc/corp.contoso.com:DBA:1443 Administrator

Do not require Kerberos pre-authentication

Risk: Kerberos ön kimlik doğrulaması devre dışı bırakıldığında, saldırgan AS-REP roasting saldırısı yapabilir. Bu durumda parola özeti (hash) doğrudan alınarak çevrimdışı brute-force ile kırılabilir.

Kontrol:

get-aduser -LDAP "(&(objectCategory=person)
(userAccountControl:1.2.840.113556.1.4.803:=4194304))" -properties
DoesNotRequirePreAuth

Öneri: Bu seçenek yalnızca belirli test hesaplarında veya özel uyumluluk senaryolarında kullanılmalı; yüksek ayrıcalıklı hesaplarda kesinlikle devre dışı olmamalıdır.

Exchange Gruplarının DNC Üzerinde WriteDacl Yetkisi

Risk: Exchange güvenlik gruplarına Domain Naming Context (DNC) üzerinde yazma yetkisi verilmişse, bir saldırgan bu yetkileri kötüye kullanarak DCSync veya benzeri yollarla yüksek ayrıcalık kazanabilir.

Öneri: Exchange kurulumundan sonra yetkiler gözden geçirilmeli; özellikle Exchange Windows Permissions ve Exchange Trusted Subsystem için gereksiz DACL yetkileri kaldırılmalıdır.

Kontrol:

Exchange Sunucularında WriteDacl Yetkisi Güvenlik Riski Taşıyor

Exchange 2013–2019 sürümleri için bu güvenlik açığı, en son Cumulative Update yüklenerek giderilebiliyor. Tamamen Office 365’e geçiş yapılmış ortamlarda ise on-prem yapı kullanılmıyorsa, Exchange gruplarından WriteDacl yetkisinin kaldırılması öneriliyor.

Exchange 2010’da ise durum farklı: Exchange Trusted Subsystem grubundan WriteDacl yetkisi kaldırıldığında, kullanıcıya “Send As” yetkisi verme işlevi bozuluyor. Bu, Exchange Management Console yerine doğrudan kullanıcıların bulunduğu OU üzerinde Descendant Users için WriteDacl delegasyonu yapılarak aşılabiliyor. Öte yandan, Exchange Windows Permissions grubunda WriteDacl kaldırıldığında herhangi bir sorun yaşanmadığı bildiriliyor.

Uzmanlar, Exchange gruplarının DNC üzerinde WriteDacl yetkisi bulundurmasına kesinlikle izin verilmemesi gerektiğini, aksi halde saldırganların Active Directory’yi çok daha kolay ele geçirebileceğini vurguluyor.

Default Domain Password Policy

Risk: Zayıf parola politikaları (örneğin minimum 8 karakter) parola tahmini ve parola püskürtme (password spraying) saldırılarına karşı savunmasızdır.

Kontrol:

Net accounts /domain

Öneri: Minimum parola uzunluğunu 12–14 karaktere çıkarın; Azure AD Password Protection ile kötü parola listesini denetleyin; gerektiğinde ince ayar için ince taneli (fine-grained) parola ilkelerini kullanın.

DHCP Sunucu Yetkilendirmesi ve Domain Admin Gereksinimi

Birçok IT personelinin “Domain Admin” (DA) yetkisine ihtiyaç duyma nedenlerinden biri, DHCP sunucularını yetkilendirme gereksinimidir. Ancak varsayılan olarak bu işlem sadece Domain Admins veya eşdeğer yetkili hesaplarla yapılabilir. Bu da güvenlik açısından riskli çünkü aslında DHCP yetkilendirmesi için DA yetkisi gerekmemelidir.

Risk:

Varsayılan durumda DA yetkisi verilmesi, gereksiz ayrıcalık artışına (privilege escalation) ve olası domain ele geçirilmesine kapı aralar.

Teknik Detay:

DHCP ile ilgili tüm meta veriler CN=NetServices konteynerinde tutulur.
Varsayılan durumda bu konteynerin DACL’inde sadece Domain Admins ve Enterprise Admins gruplarının GenericAll (tam yetki) izinleri bulunur.
Bu nedenle başka bir kullanıcı veya grup yetkilendirme yapamaz.

Önerilen Çözüm (Delegation):

DHCP sunucularını yetkilendirme iznine sahip özel bir grup oluşturun.
ADSI Edit aracını açın.
Şu yola gidin: CN=Configuration > CN=Services > CN=NetServices
Properties > Security sekmesine gidin.
Oluşturduğunuz grubu ekleyin.
Advanced > Edit > Descendant dHCPClass objects seçeneğini açın.
İlgili yetkilendirme izinlerini (ör. GenericWrite, GenericRead) verin.
Artık bu gruptaki kullanıcılar DA olmadan DHCP sunucularını yetkilendirebilir.

Site ve Alt Ağ (Subnet) Yönetimi Yetkilerinin Domain Admins’ten Alınıp Delegasyon ile Verilmesi

Durum (Problem):

Daha önce oluşturduğunuz özel grup, CN=NetServices konteynerinde yetkilendirilerek Domain Admin (DA) olmadan DHCP sunucularını yetkilendirebiliyordu.
Ancak yeni site veya subnet (alt ağ) oluşturma/silme işlemleri varsayılan olarak yine sadece DA veya eşdeğer hesaplar tarafından yapılabilir.
Bu durum çoğu organizasyonda gereksiz yere DA yetkisi verilmesine yol açar.

Teknik Detay:

Active Directory’de CN=Sites konteyneri altında Inter-Site Transport ve Subnets gibi alt konteynerler bulunur.
Varsayılan DACL (Discretionary Access Control List) bu alanlarda değişiklik yapma yetkisini yalnızca Domain Admins / Enterprise Admins gruplarına verir.

Önerilen Çözüm (Delegation):

Daha önce oluşturduğunuz özel yetkilendirme grubunu kullanın.
CN=Sites konteynerinde bu gruba şu izinleri tanımlayın:
- Create all child objects
- Delete all child objects
Bu sayede DA yetkisi gerekmeksizin site ve subnet ekleme/silme yetkisi verilir.

Avantaj:

En az yetki prensibi (Least Privilege Principle) uygulanır.
Domain Admin gereksinimi azaltılarak olası privilege escalation riskleri düşürülür.

DHCP Yedeklerinin Düzenli ve Güvenli Şekilde Alınması

Teknik Detay

DHCP, ağ cihazlarına IP adresi atayarak ağa katılımlarını sağlar.
DHCP veritabanı bozulduğunda veya kaybolduğunda ağ iletişimi kesintiye uğrayabilir.
Varsayılan yedekleme konumu: C:\Windows\System32\dhcp\backup
Yedek almak için:
1. DHCP Yönetim Konsolunu açın.
2. DHCP sunucusunu yetkilendirin (Authorize).
3. Sağ tıklayıp Backup seçeneğini kullanın.
4. Yedeklerin belirtilen dizinde oluştuğunu doğrulayın.
Yedeklerin AD domain’e üye olmayan, güvenli bir sunucuda saklanması önerilir.

Kontrol

C:\Windows\System32\dhcp\backup dizininde güncel yedek dosyalarının bulunup bulunmadığı kontrol edilmeli.
Yedekleme tarihleri incelenerek politika ile uyumlu (ör. günlük/haftalık) çalıştığı doğrulanmalı.
Geri yükleme (restore) testleri düzenli olarak yapılarak felaket durumunda süre ve doğruluk ölçülmeli.
Yedeklerin saklandığı ortamın güvenli (AD’ye üye olmayan, erişim kontrollü) olup olmadığı doğrulanmalı.

Çözüm

DHCP yedekleme politikası oluşturulmalı ve düzenli olarak uygulanmalı.
Yedekleme işlemleri mümkünse otomasyona bağlanmalı.
Yedekler, hem çevrim içi güvenli bir sunucuda hem de şifrelenmiş offline ortamda saklanmalı.
Yılda en az 2 kez geri yükleme tatbikatı yapılarak prosedürler test edilmeli.

DNS RBAC Delegasyon

1. Yeni Grupların Oluşturulması

Active Directory Users and Computers üzerinden iki yeni güvenlik grubu oluştur:

DnsManagers > DNS yönetim işleri için.
DnsCreators > Yeni DNS kayıtları oluşturabilen kullanıcılar için.

Her iki grup da Security Group – Global tipinde olmalıdır.

Neden DnsAdmins Kullanılmamalı?

DnsAdmins grubunun DC üzerinde SYSTEM hakları ile DLL çalıştırma yetkisi vardır.
Bu, saldırganların kolayca Domain Admin seviyesine yükselmesine olanak tanır.
Bu yüzden, tüm kullanıcıları DnsAdmins’e almak yerine RBAC modeliyle görev bazlı küçük gruplar kullanılmalıdır.

Yetkilerin Dağılımı

Görev	DnsAdmins	DnsManagers	DnsCreators
DNS Server debug/event log yapılandırma	+	–	–
Yeni kayıt oluşturma (A, MX, CNAME vb.)	+	+	+
Oluşturulan kaydı silme	+	+	+
DNS Event log okuma	+	+	–
Yeni zone oluşturma/silme	+	+	–
Zone tipini değiştirme	+	+	–
Zone transfer izni verme	+	+	–
Name server ekleme/çıkarma	+	+	–
Zone TTL değiştirme	+	+	–
DNSSEC ile zone imzalama	+	+	–

DnsManagers için Delegasyon

DC DNS Object güvenlik ayarlarına DnsManagers grubunu ekle.
- Minimum izin: Read all properties.

Forward Lookup Zones konteynerinde DnsManagers grubuna GenericAll yetkisi ver.
- Bu sayede mevcut DNS kayıtlarını yönetebilirler.

DnsManagers Grubuna DNS Server Log Okuma Yetkisi Verme

Domain Admin olarak oturum aç.
CMD’yi yönetici yetkileriyle aç.
Aşağıdaki komutu çalıştır: wevtutil gl “DNS Server” > C:\Temp\DNS_Server.txt
Bu işlem, DNS Server log kanalı ayarlarını C:\Temp\DNS_Server.txt dosyasına aktarır.

channelAccess Bilgisini Düzenleme

C:\Temp\DNS_Server.txt dosyasını aç.
İçerikte channelAccess: ile başlayan satırı bul.
Örnek: channelAccess: O:BAG:SYD:(A;;0x1;;;IU)(A;;0x1;;;SU)…

Bu satırı kopyala, çünkü içine DnsManagers SID bilgisini ekleyeceğiz.
DnsManagers SID Bilgisini Alma
PowerShell aç ve aşağıdaki komutu çalıştır: Get-ADGroup -Identity “DnsManagers”
Çıktıdaki SID bilgisini kopyala.

Örnek: “S-1-5-21-3566662483-2648771335-1709913503-20601”

ChannelAccess İçine SID Ekleme

Daha önce aldığın satırın sonuna aşağıdaki formatta SID’i ekle:

(A;;0x1;;;S-1-5-21-3566662483-2648771335-1709913503-20601)
Sonuç olarak channelAccess: satırın şu şekilde görünmeli:

O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x5;;;SO)(A;;0x1;;;IU)(A;;0x1;;;SU)
(A;;0x1;;;S-1-5-3)(A;;0x2;;;LS)(A;;0x2;;;NS)(A;;0x2;;;S-1-5-33)(A;;0x1;;;S-1-5- 21-3566662483-2648771335-1709913503-20601)

Yeni channelAccess Ayarını Uygulama

CMD’yi yönetici olarak aç.
Aşağıdaki komutu çalıştır (tek satır olmalı):

wevtutil sl “DNS Server” /ca: O:BAG:SYD:(A;;0xf0007;;;SY)(A;;0x7;;;BA) (A;;0x5;;;SO)(A;;0x1;;;IU)(A;;0x1;;;SU)(A;;0x1;;;S-1-5-3)(A;;0x2;;;LS) (A;;0x2;;;NS)(A;;0x2;;;S-1-5-33)(A;;0x1;;;S-1-5-21-3566662483-2648771335-1709913503-20601)

Doğrulama

Bir DnsManagers üyesi ile oturum aç.
Event Viewer > Applications and Services Logs > DNS Server yoluna git.
Eğer logları görebiliyorsa işlem başarılıdır.

Bu adımlar sonunda DnsManagers üyeleri, Domain Admin olmadan DNS Server loglarını okuyabilir.

DnsCreators Grubunu DNS Nesnesine Ekle

DNS Manager aç > ilgili DC üzerinde sağ tık > Properties.
Security sekmesine gir.
Add > DnsCreators grubunu ekle.
Bu gruba sadece şu izin ver:
- Read (Read all properties)

Bu adım, grubun DNS nesnesini görmesini sağlar.

Varsayılan Authenticated Users Yetkileri

Varsayılan olarak Authenticated Users grubunun Create all child objects ve Delete all child objects izinleri zaten vardır.
Bu sayede DnsCreators, DNS Object üzerinde Read izni aldığı anda yeni DNS kayıtları (A, MX, CNAME, AAAA vb.) oluşturabilir.

Yetki Etkileri

Yeni DNS kayıtları oluşturabilir
Oluşturduğu kayıtları silebilir
Zone oluşturma/silme, zone transfer, TTL değiştirme, log okuma gibi işlemleri yapamaz

Böylece günlük DNS kayıt ekleme/silme işi için Domain Admin kullanmaya gerek kalmaz.

Öneri

DnsCreators grubunu sadece kayıt ekleyip kaldıracak operasyonel ekiplere ver.
Daha ileri yönetim görevleri için DnsManagers grubunu kullan.
DnsAdmins grubunu boş bırak saldırı yüzeyini küçültmüş olursun.

DNS Yedekleme ve Güvenli Saklama

Tüm DNS kayıtları ve zone bilgileri aşağıdaki dizinde tutulur:

C:\Windows\System32\dns

DNS Zone Yedekleme (Manual Export)

DNS Manager aç > Forward Lookup Zone genişlet.

PowerShell veya CMD’yi yönetici olarak çalıştır.
Aşağıdaki komutlarla DNS zonelerini dışa aktar: dnscmd /zoneexport _msdcs.contoso.com _msdcs.contoso.com.txt dnscmd /zoneexport contoso.com contoso.com.txt
Çıktılar C:\Windows\System32\dns klasörüne kaydedilir.

Öneriler

Yedekleri güvenli sakla > AD üyesi olmayan, ayrı bir sunucuda veya offline depolama alanında tut.
Yedekleme prosedürü oluştur > Günlük, haftalık veya aylık periyotlara karar ver.
Disaster Recovery planı hazırla
- Bir zone yanlışlıkla silinirse, en hızlı nasıl geri yükleneceğini ekibine öğret.
- Zone dosyaları .txt formatından geri import edilebileceğini bil.
DnsAdmins kullanımını kısıtla > Çoğu DNS yönetim işlemi için bu gruba gerek yok.
RBAC (Role-Based Access Control) uygula > Günlük işleri DnsCreators / DnsManagers gibi daha düşük yetkili gruplara dağıt.

RBAC ile PKI

Amaç:

CA yönetimi için ayrı görev tanımları.

Yeni gruplar:

CA Administrators > CA’yı yapılandırma
CA Managers > Sertifika onaylama / iptal

Yetkiler:

CA Admin: Template yönetimi, rol konfigürasyonu, CA servis kontrolü.
CA Manager: Sertifika approve/deny/revoke.
Uygulama:
- ADSI Edit’te CN=Certificate Templates ve CN=OID üzerinde CA Admin’e full control verildi.
- CA Properties’te:
  - CA Administrators: Manage CA (Read + Manage CA, Request Certificates kaldırılır)
  - CA Managers: Issue and Manage Certificates + Request Certificates

PKI Üzerinde Auditing & SIEM

CA aktivitelerinin SOC/SIEM’e loglanması.
Yeni Grup: SOC – Security Logs Reader

Adımlar:
1. Grup oluşturulur, SOC üyeleri eklenir.
2. Local Security Policy > User Rights Assignment > “Manage auditing and security logs” içine grup eklenir.
3. CA Properties’te Read yetkisi verilir.
4. SOC ekibi audit policy’lerini açar.

Audit log ayarları:
- Backup/restore CA DB
- CA configuration değişiklikleri
- Sertifika isteği/onayı
- Key recovery, revoke, CRL yayınlama
Auditpol ile etkinleştirme: auditpol /set /subcategory:”Certification Services” /success:enable /failure:enable auditpol /get /category:*

Sonuç: SOC ekibi PKI ile ilgili tüm event loglarını okuyabilir ve SIEM’e yönlendirebilir.

PKI Yedeklerinin Alınması ve Güvenli Saklanması

Backup Operators Yetkisi Verme

CA sunucusuna giriş yap.
Computer Management > Local Users and Groups > Groups > Backup Operators yolunu izle.
Backup alacak kullanıcıyı bu gruba ekle.
Not: Bu kullanıcı lokal olarak giriş yapabilir, ancak RDP ile giriş yapamaz.

CA Backup İşlemleri

Certification Authority (certsrv.msc) konsolunu aç.
CA adına sağ tıkla > All Tasks > Back up CA
Backup sırasında şu 3 şey mutlaka seçilmeli:
- CA sertifikası ve özel anahtar(lar)
- CA veritabanı
- CA registry bilgisi

Yedekleme Konumu

Yedekleri güvenli ve şifreli bir klasörde sakla.
Tercihen AD domain’e üye olmayan bir sunucuda depola.
Dosya sistemi erişimlerini sadece Backup Operators grubuna sınırla.

Registry Yedeği

Registry yolu: HKLM\System\CurrentControlSet\Services\CertSvc\Configuration\<CAName>
Bu yolu export et ve yedek dosyasına dahil et.

Doğrulama

Backup tamamlandıktan sonra klasörde şu dosyalar olmalı:
- Sertifika ve Private Key
- Veritabanı yedeği
- Registry export dosyası
Örnek klasör:
D:\CA Backups\contoso-DC-CA\

Öneriler

Düzenli backup (günlük/haftalık) planı oluştur.
Yedekleri offline bir lokasyonda da sakla (örn. tape, offline disk).
Yedeklenen özel anahtar için güçlü bir parola kullan.
SIEM veya güvenlik ekibi ile yedekleme denetimlerini logla.

Windows Server Ortamlarında Varsayılan Domain Controllers Policy Yerine Güvenli GPO Kullanımı Öneriliyor

Windows Server kurulumlarında varsayılan olarak gelen Default Domain Controllers Policy, güvenlik açısından zayıf kabul ediliyor. Uzmanlar, bu politikanın kullanılmaya devam edilmesi yerine, daha güvenli ayarlarla oluşturulmuş yeni bir GPO’nun uygulanmasını öneriyor.

Neden Değişiklik Gerekli?

Varsayılan “Default Domain Controllers Policy” içerisinde gelen ayarlar güncel güvenlik gereksinimlerini karşılamıyor. Özellikle kullanıcı hakları (User Right Assignment) ve güvenlik seçenekleri (Security Options) kritik riskler barındırıyor. Bu nedenle:

Yeni bir Security GPO oluşturulması,
Varsayılan politikanın ise devre dışı bırakılması tavsiye ediliyor.

Ayar	Yetkili Gruplar / Hesaplar
Access this computer from the network	Administrators, Authenticated Users, Enterprise Domain Controllers
Add workstation to a domain	Administrators
Allow log on locally	Administrators, Backup Operators
Allow log on through Remote Desktop Services	Administrators
Backup files and directories	Administrators, Backup Operators
Restore files and directories	Administrators, Backup Operators
Change the system time	Administrators
Debug Programs	Administrators
Deny access to this computer from the network	Guests, DC
Deny log on through Remote Desktop Services	Guests, DC
Shutdown the system	Administrators
Log on as a service	Service accounts that need to run as a service
Log on as a batch job	Service accounts for scheduled tasks

Ayar	Değer
Allowed to format and eject removable media	Administrators
Devices: Prevent users from installing printer drivers	Enabled
Domain controller: Allow server operators to schedule tasks	Disabled
Network access: Do not allow anonymous enumeration of SAM accounts	Enabled
Network access: Do not allow anonymous enumeration of SAM accounts and shares	Enabled
Network security: LAN Manager authentication level	Send NTLMv2 response only (Test this first)

DSRM (Directory Services Restore Mode) – Break-Glass Account Kullanımı

Directory Services Restore Mode (DSRM), Windows Server Domain Controller’lar için güvenli bir kurtarma modudur. Active Directory veritabanının onarılması veya geri yüklenmesi gerektiğinde kullanılır. Bu hesap, felaket senaryoları için Active Directory’nin “break-glass account” yani acil durum hesabı olarak değerlendirilir.

Kritik Noktalar

Bu hesabın şifresini kimlerin bildiği mutlaka takip edilmelidir.
Parolanın en son ne zaman değiştirildiği bilinmeli ve düzenli aralıklarla güncellenmelidir.
Parola, tüm AD yöneticileriyle paylaşılmamalı; sadece yetkili ve sınırlı sayıda kişi tarafından bilinmelidir.

DSRM Parolasını Sıfırlama Adımları

CMD’yi Run as Administrator ile açın. (Domain Admin veya eşdeğer yetki gerekir.)
ntdsutil komutunu yazın.
set DSRM password komutunu girin.

Reset password on server DC yazarak parola sıfırlama sürecini başlatın. (DC, Domain Controller adını temsil eder.)
Yeni bir parola belirleyin ve onaylayın.
Ardından quit, tekrar quit ve exit komutları ile çıkış yapın.
Bu işlemden sonra, DSRM hesabıyla doğrudan oturum açmak mümkündür.

Öneriler

DSRM hesabının parolası hiç değiştirilmediyse, en kısa zamanda güncellenmelidir.
Parola yönetimi için güvenli bir parola kasası kullanılmalıdır.
Şifre değişiklikleri kayıt altına alınmalı ve periyodik olarak kontrol edilmelidir.

Windows Server Backup ile Active Directory Yedekleme

Windows Server Backup Kurulumu

Windows Server Backup, varsayılan olarak yüklü gelmez.

Kurulum için Server Manager > Add roles and features üzerinden ilerleyin.

Domain Controller üzerinde bu özelliğin kurulu olduğundan emin olun.

Yedekleme Seçenekleri

Active Directory için iki temel yedekleme yöntemi bulunur:

Backup schedule > Görev zamanlayıcı ile otomatik yedekleme
Backup once > Manuel yedekleme

Bu rehberde Backup Schedule seçeneği örnek alınmıştır.

Yedekleme Adımları

Backup Schedule seçeneğini tıklayın.
Next ile ilerleyin.
Custom seçeneğini işaretleyin.

Add Items kısmından System state seçin.

Advanced Settings > VSS Settings bölümünde VSS Full Backup seçeneğini belirleyin.

Eğer başka bir yedekleme yazılımı kullanılmıyorsa bu seçenek önerilir.
Yedekleme zamanını belirleyin (örneğin, her gün saat 21:00).

Yedekleme için hedef belirleyin:
- Ayrı bir disk
- Volume (sistem diski dışındaki bir sürücü)
- Paylaşımlı klasör (network folder)
Disk seçimini yaptıktan sonra Finish ile kurulumu tamamlayın.

Zamanlanmış Görev ve Takip

Kurulum sonrası, Task Scheduler altında Microsoft\Windows\Backup dizininde Microsoft-Windows-WindowsBackup adında bir görev oluşturulur.
Yedekleme tamamlandığında durum Successful olarak görünür.
Event Viewer > Microsoft-Windows-Backup/Operational logları üzerinden takip yapılabilir.
- Özellikle Event ID 14 başarılı yedekleme tamamlandığını gösterir.

Öneriler

Active Directory Domain Controller’ların (AD/DC) düzenli yedeği alınmalıdır.
Yedekler AD’ye join edilmemiş bağımsız bir sunucuda veya izole bir diskte tutulmalıdır.
Yaygın bir hata: Şirketler, yedekleri domain’e dahil edilmiş member server’larda tutar. Bu saldırganların hedef alabileceği bir güvenlik açığıdır.
AD/DC yedekleme işlemleri genellikle Tier 0 seviyesinde görülür. Domain Admin hesabı zorunlu değildir; Backup Operators grubu yeterlidir.
Periyodik denetim (audit) yapılmalı ve yedeklerin gerçekten başarıyla (successful) tamamlandığı teyit edilmelidir.

GPO Üzerinde “Authenticated Users” Yetkilerinin Kaldırılması

Active Directory ortamında her authenticated user (doğrulanmış kullanıcı), GPO’lar üzerinde read (okuma) yetkisine sahiptir. Bu, normal şartlarda tasarlanmış bir davranıştır. Ancak Domain Controller’a bağlı GPO’larda bu varsayılan izin ciddi bir güvenlik riski oluşturabilir.

BloodHound gibi saldırı araçları bu izinleri kullanarak hatalı veya zayıf yetkilendirmeleri tespit edebilir.
Bir saldırgan, DC’ye bağlı bir GPO’yu değiştirebilirse, kod çalıştırma veya kendisine Domain Admin yetkisi verme imkânı bulabilir.

Örneğin, “Default Domain Controllers Policy” üzerinde kullanıcı Werner’in GpoEdit yetkisine sahip olması, yanlış yapılandırmaya bir örnektir.

Riskin Sonuçları

Domain Controller GPO’sunun manipüle edilmesi, DC üzerinde yetki yükseltme (privilege escalation) senaryosuna yol açabilir.
Saldırgan kendisine “Take ownership of files and objects” gibi ek izinler vererek, Domain Admin seviyesine kadar yükselebilir.

Çözüm Adımları

Get-GPPermission komutu ile ilgili GPO’daki mevcut yetkileri görüntüleyin.
Eğer “Authenticated Users” grubu görünüyorsa, bu grubu kaldırın.
Bunun yerine Domain Controllers grubunu “Security Filtering” kısmına ekleyin.
- Böylece sadece Domain Controllers bilgisayar hesabı bu GPO’yu okuyup uygulayabilir.
Tekrar kontrol ederek, yetkilendirme değişikliklerinin başarıyla uygulandığını doğrulayın.

Öneriler

Varsayılan GPO’larda (özellikle Default Domain Controllers Policy) “Authenticated Users” grubunun kaldırılması önerilir.
Bunun yerine Domain Controllers grubu eklenerek, erişim sadece DC’lere sınırlandırılmalıdır.
Bu değişiklik, BloodHound gibi keşif araçlarının yanlış yetki yapılarını bulmasını zorlaştıracaktır.
Düzenleme sonrası test edilerek, GPO’nun DC’ler üzerinde beklendiği gibi çalıştığı teyit edilmelidir.

Tier 0 Kaynaklarına Bağlı GPO’ların Yönetimi

Sorun

Büyük organizasyonlarda sıkça görülen bir problem, GPO seviyesinde yanlış yetki delegasyonu yapılmasıdır. Bu, özellikle Domain Controller’lara (Tier 0 kaynaklar) bağlı GPO’lar için büyük risk taşır.

Örneğin; Default Domain Controllers Policy üzerinde rastgele bir kullanıcıya GpoEdit yetkisi verilmişse, bu kritik bir güvenlik açığıdır.
Başka bir yanlış örnek; Domain Users grubuna, Default Domain Policy üzerinde Full Control yetkisinin verilmesidir.

Bu tür yapılandırmalar, saldırganların kritik GPO’ları manipüle ederek Domain Controller seviyesinde kontrol elde etmesine yol açabilir.

Yönetim Modeli: Administrative Tiers

Microsoft’un Tiered Administration Model yaklaşımı bu tür riskleri azaltmak için geliştirilmiştir.

Tier 0: En kritik kaynaklar (Domain Controllers, ADFS, PKI, Azure AD Connect vb.)
Tier 1: Uygulama ve sunucu yönetimi
Tier 2: İstemci bilgisayarlar ve kullanıcı yönetimi

Modelin kuralı:

Tier 0 adminler, yalnızca Tier 0 kaynaklara erişebilir.
Tier 0 adminler Tier 1 veya Tier 2’ye giriş yapamaz.
Aynı şekilde, Tier 1 adminler Tier 2 kaynaklarını yönetebilir ama Tier 0’a erişemez.

Çözüm ve En İyi Uygulama

Tier 0 kaynaklara (Domain Controllers, ADFS, PKI, Azure AD Connect vb.) bağlanan tüm GPO’lar sadece Tier 0 adminleri tarafından yönetilmelidir.
Domain seviyesine uygulanan ve özellikle Default Domain Controllers Policy gibi kritik GPO’lar yanlış kullanıcı veya gruplara Edit/Full Control yetkisi vermemelidir.
GPO üzerinde yapılan değişiklikler düzenli olarak incelenmeli ve beklenmeyen yetkiler derhal kaldırılmalıdır.

Öneriler

Domain seviyesinde ve Domain Controller’lara uygulanan tüm GPO’lar Tier 0 adminler tarafından yönetilmelidir.
Tier 0 sunucularına uygulanan GPO’lar da yine sadece Tier 0 adminler tarafından kontrol edilmelidir.
Yetki delegasyonu yapılması gerekiyorsa, yalnızca belirlenmiş güvenilir gruplar kullanılmalı, geniş kapsamlı gruplar (örn. Domain Users, Authenticated Users) kullanılmamalıdır.

Group Policy Creator Owners Kullanımı

Sorun

Active Directory’de yer alan Group Policy Creator Owners grubu, varsayılan olarak fazla yetkiyle gelen bir yerleşik (built-in) gruptur.

Bu grup sadece GPO oluşturabilir, fakat oluşturduğu GPO’yu başka yerlere bağlama (link) yetkisine sahip değildir.
Bununla birlikte, defaultSecurityDescriptor üzerinde yetki devri (delegation) çok zor olduğu için pratikte kullanışsızdır.
Yine de varsayılan yapı nedeniyle, GPO yönetiminde gereksiz bir risk taşır.

Risk

Domain Admins ile birlikte Group Policy Creator Owners grubu da GPO oluşturma yetkisine sahiptir.
Bu, kontrolsüz şekilde GPO oluşturulmasına neden olabilir.
Sonrasında yetkilerin başka gruplara yanlışlıkla devredilmesi, Active Directory üzerinde ciddi güvenlik açıkları oluşturur.

Çözüm: Delegated Group Kullanımı

En iyi uygulama, Group Policy Creator Owners grubunu kullanmak yerine yetkili bir delegated group oluşturmaktır.

Adımlar:

Active Directory’de örneğin TestGPOAdmins adında yeni bir güvenlik grubu oluşturun.

Bu grubu Group Policy Objects konteyneri üzerinde delegasyon ile yetkilendirin.
- Bu sayede grup, yeni GPO’lar oluşturabilecek hale gelir.
Get-ADGroup komutu ile yeni grubun SID bilgisini alın.

ADSI Edit kullanarak CN=Group-Policy-Container nesnesine gidin.

defaultSecurityDescriptor özniteliğini bulun, mevcut değerini kopyalayın.

D:P(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;DA)
(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;EA)
(A;CI;RPWPCCDCLCLOLORCWOWDSDDTSW;;;CO)
(A;CI;RPWPCCDCLCLORCWOWDSDDTSW;;;SY)(A;CI;RPLCLORC;;;AU)
(OA;CI;CR;edacfd8f-ffb3-11d1-b41d-00a0c968f939;;AU)

İçine yeni grubun SID bilgisini ekleyin.
- Böylece yeni oluşturulan GPO’larda bu grup otomatik olarak Full Control yetkisine sahip olur.

Ek Yetkilendirmeler

Eğer yeni grubun GPO’ları linkleme yetkisine de sahip olmasını istiyorsanız:

Write gpLink > GPO’ları OU’lara bağlama izni
Write gpOptions > Inheritance engelleme izni

Öneriler

Group Policy Creator Owners grubunun kullanımı tamamen bırakılmalı.
Bunun yerine, yalnızca belirlenmiş delegasyon grupları kullanılmalıdır.
Bu gruplar üzerinde düzenli denetim yapılmalı ve yanlış üyelikler engellenmelidir.
Böylece hem GPO oluşturma hem de bağlama süreçleri güvenli şekilde merkezi olarak yönetilebilir.

Account Operators Kullanılmamalı

Sorun Tanımı

Active Directory’de yerleşik gelen Account Operators grubu, kutudan çıktığı haliyle çok geniş haklara sahiptir.

Bu gruptaki kullanıcılar, potansiyel olarak Domain Admin seviyesine yükseltme (privilege escalation) gerçekleştirebilir.
Dolayısıyla modern AD güvenlik standartlarına göre Account Operators grubu kullanılmamalıdır.

Saldırı Yolları (Attack Path)

Account Operators > Exchange Trusted Subsystem > Exchange Windows Permissions > WriteDacl on DNC > DCSync
- Bu yol, saldırganın Replication yetkisi kazanarak Domain Controller’daki parolaları (NTLM hash/Kerberos key) çekmesini sağlar.
Account Operators > DnsAdmins > DLL Injection > SYSTEM > Domain Admin
- Burada saldırgan, DNS hizmetine zararlı bir DLL yükleyerek SYSTEM hakları elde edebilir ve sonunda Domain Admin seviyesine çıkabilir.

Öneriler

Account Operators grubunu kesinlikle kullanmayın.
Eğer belirli hesap yönetim ihtiyaçları varsa, özel yetki delegasyonu (custom delegation) yaparak sadece gereken izinleri verin.
Düzenli olarak AD’deki yerleşik grupların üyeliklerini denetleyin ve gereksiz kullanıcıları çıkarın.
Güvenlik testleri (örneğin BloodHound) ile bu grupların yetkilerini periyodik olarak analiz edin.

Print Operators Kullanılmamalı

Sorun Tanımı

Print Operators grubu, varsayılan olarak Domain Controller’lara logon hakkına sahiptir.

Bu hak, modern ortamda hiçbir şekilde gerekli değildir.
Bu nedenle grup, kötüye kullanıldığında ciddi bir güvenlik riski oluşturur.

Yetki Alternatifleri

Eğer baskı yönetimi yapılacaksa, gerekli tüm izinler Print Management Console (GUI) üzerinden özel delegasyon ile tanımlanabilir.
Böylece sadece ihtiyaç duyulan kullanıcılar, belirli yazıcılar üzerinde gerekli yetkilere sahip olur.
Gerekli haklar, DAC (Discretionary Access Control) listeleri üzerinden de verilebilir.

Örneğin:

Yeni bir grup oluşturulup, DAC listesine eklenerek sadece ilgili yazıcı üzerinde “Print”, “Manage this printer” gibi izinler atanabilir.
Böylece geniş yetkili Print Operators grubunun kullanımına gerek kalmaz.

Öneriler

Print Operators grubunu boş bırakın.
Yetki ihtiyacı varsa, özel delegasyon grupları oluşturun ve yalnızca ilgili yazıcıya yetki atayın.
Düzenli olarak AD içindeki yerleşik grupların (Account Operators, Server Operators, Print Operators) üyeliklerini denetleyin.

Server Operators Kullanılmamalı

Sorun Tanımı

Server Operators, varsayılan olarak çok geniş haklara sahip bir yerleşik gruptur.

Bu grup, Domain Controller’lara logon yetkisine sahiptir.
Genellikle “DC Admins” olarak tanımlanabilecek düzeyde riskli haklar içerir.
Bu nedenle modern Active Directory güvenlik standartlarına göre kullanılmaması tavsiye edilir.

Neden Riskli

Grup üyeleri, Domain Controller üzerinde kritik yönetim işlemleri yapabilir.
Yanlışlıkla yetki verilmiş bir kullanıcı, DC üzerinde kontrol elde ederek Domain Admin seviyesine çıkabilir.
Sunucu yönetimi için gerekli haklar, daha güvenli şekilde özel delegasyon ile verilebilir.

Öneriler

Server Operators grubunu boş bırakın.
Eğer bir kullanıcıya veya gruba sunucu yönetim hakları verilmesi gerekiyorsa, bunun yerine Role-Based Access Control (RBAC) veya özel delegasyon yöntemleri kullanılmalıdır.
Düzenli olarak yerleşik grupların üyeliklerini denetleyin ve gereksiz üyelikleri kaldırın.

Active Directory Recycle Bin’i Etkinleştirin

Active Directory üzerinde yanlışlıkla silinen bir nesneyi (örneğin üst düzey bir kullanıcının hesabını) geri getirmek için Recycle Bin özelliği büyük kolaylık sağlar.

Varsayılan durumda Recycle Bin etkin değildir. Bu nedenle kritik bir hata durumunda kurtarma süreci çok daha zahmetli olur.

Nasıl kontrol edilir?
Aşağıdaki PowerShell komutuyla Recycle Bin’in etkin olup olmadığı görülebilir:
Get-ADOptionalFeature -Filter ‘name -like “Recycle Bin Feature”‘

Nasıl etkinleştirilir?
Recycle Bin özelliğini etkinleştirmek için:
Enable-ADOptionalFeature ‘Recycle Bin Feature’ -Scope ForestOrConfigurationSet -Target corp.contoso.com

Bu işlem sonrasında domain genelinde silinen nesneler belirli süre içinde kolayca geri yüklenebilir.

Öneri: Active Directory Recycle Bin özelliğini mutlaka etkinleştirin.

Tier 1 Adminlere Silinmiş Nesneleri Geri Yükleme Yetkisi Verin

Tier 1 veya Tier 2 adminleri günlük operasyonlarda nesne oluşturur. Ancak bazen yanlışlıkla kritik bir nesne silinebilir. Varsayılan olarak yalnızca Domain Admins veya eşdeğer gruplar silinmiş nesneleri geri yükleyebilir. İyi haber şu ki bu yetkiyi delege edebiliriz. Böylece Tier 1 adminler de kendi hatalarını düzeltebilir.

Silinmiş Nesneler Konteynerinin Sahipliğini Alın

Öncelikle CN=Deleted Objects konteynerinin sahipliğini almak gerekir.
Bunun için Domain Admin ayrıcalıklarıyla PowerShell çalıştırılır:

dsacls “CN=Deleted Objects,DC=corp,DC=contoso,DC=com” /takeownership

Bu işlemden sonra Deleted Objects konteyneri üzerinde tam yetkiniz olacaktır.

Tier 1 Grubuna Yetki Devri Yapın

Şimdi, Tier 1 grubunun da bu nesneleri geri yükleyebilmesi için yetkilendirme yapıyoruz:

dsacls “CN=Deleted Objects,DC=corp,DC=contoso,DC=com” /g CORP\Tier1:LCRPWP

Bu komut ile Tier 1 grubuna List, Create, Read, Write ve Restore gibi gerekli haklar atanır.

Tier 0 Admins → Protected Users Grubu

Amaç: Tier 0 hesaplarının kimlik bilgilerinin reuse (tekrar kullanım) riskini azaltmak.
Desteklenen sürümler: Windows 8.1 ve Server 2012 ve sonrası.
Uygulama: Tier 0 kullanıcılarını doğrudan Protected Users grubuna ekleme.
Sonuç: Credential theft (kimlik bilgisi çalma) saldırılarına karşı koruma sağlanıyor.

Tier 0 Admins → “Account is sensitive and cannot be delegated”

Amaç: Tier 0 hesaplarının Kerberos Delegation ile başka servislere/hesaplara yanlışlıkla yetki devrinin engellenmesi.
Uygulama: Kullanıcı hesabı özelliklerinden “Account is sensitive and cannot be delegated” seçeneğinin işaretlenmesi.
Sonuç: Tier 0 hesaplarının kimlik bilgileri başka sistemlere devredilemez hale geliyor.

KRBTGT Parolasını Sıfırlama

KRBTGT hesabı: Active Directory’de Kerberos Ticket Granting Ticket (TGT) için kullanılan, KDC’nin (Key Distribution Center) temel servis hesabıdır.

Risk: Eğer bir saldırgan KRBTGT hesabının NTLM hash’ini ele geçirirse, Golden Ticket üretip tüm kullanıcıların kimliğine bürünebilir ve kalıcı erişim elde eder.

Çözüm:

KRBTGT parolasının iki kez arka arkaya değiştirilmesi gerekir. Bunun sebebi, Kerberos’un hem mevcut hem de önceki anahtarı saklayarak biletleri doğrulamasıdır. Parola iki defa sıfırlanırsa saldırganın sahip olduğu eski hash tamamen geçersiz olur.

Komut:

Get-ADUser krbtgt -properties passwordlastset ile parolanın en son ne zaman sıfırlandığını kontrol edebilirsiniz.

Active Directory’de Yüksek Ayrıcalıklı Grupların İzlenmesi

Domain Admins, Enterprise Admins gibi gruplar saldırganların en çok hedef aldığı gruplardır.
Ancak bunun yanında gözden kaçabilen ama yüksek yetkilere sahip gruplar da vardır:
- Built-in\Administrators
- Schema Admins
- Account Operators
- Backup Operators
- Server Operators
- Print Operators
- DnsAdmins
- Organization Management
- Exchange Trusted Subsystems
- Exchange Windows Permissions

Bu grupların tamamı saldırgan için bir geçiş noktası olabilir.

İzleme Gerekliliği

Örneğin Enterprise Admins grubuna bir kullanıcı eklendiğinde bu kritik bir olaydır.
Görselde SQL servis hesabının Enterprise Admins grubuna eklenmiş olduğu gösteriliyor. Bu yanlış yapılandırma veya ayrıcalık kötüye kullanımının göstergesi olabilir.

İzlenmesi Gereken Event ID

Event 4728 – “A member was added to a security-enabled global group”
- Bu event kritik önemdedir çünkü ayrıcalıkların kötüye kullanıldığına dair doğrudan işaret verebilir.
- Özellikle servis hesaplarının Domain Admins gibi gruplara eklenmesi tehlikelidir.

Öneriler

Yüksek ayrıcalıklı gruplar sadece Domain Admins ve Enterprise Admins ile sınırlı tutulmamalı, tüm liste düzenli olarak izlenmelidir.
SIEM veya güvenlik denetim araçlarında 4728 event ID’si yakalanmalı ve kritik olarak işaretlenmelidir.
Bu tür olaylar için otomatik alarm mekanizması kurulması önerilir.

Kerberoasting için Honey User Dağıtımı

Kerberoasting saldırısı sırasında saldırgan bir servis hesabının service ticket talebinde bulunduğunda, bu işlem Windows Güvenlik Loglarında kayıt altına alınır. Özellikle Event ID 4769 olayını takip etmek kritik öneme sahiptir.

Event 4769: A Kerberos service ticket was requested (Bir Kerberos servis bileti talep edildi)
Bu olay, saldırganın honey user hesabından ticket almaya çalıştığını gösterecektir.

Honey User Mantığı

Bu noktada oluşturduğumuz SQLAgent gibi bir kullanıcı hesabı aslında bizim “honeypot” yani bal tuzağı hesabımızdır.
Normalde hiçbir geçerli kullanıcı bu hesaptan ticket istemeyeceği için, bu hesap üzerinden gelen tüm ticket talepleri şüpheli aktivite olarak değerlendirilmelidir.

Honey user hesabından ticket isteği gelirse → Kerberoasting saldırısı teşhisi konur.
Bu saldırı girişimini tespit etmek için Event Viewer veya SIEM üzerinde Event ID 4769 için özel alarm kuralı yazılabilir.

SIEM Entegrasyonu

Daha büyük altyapılarda olayları manuel kontrol etmek zordur. Bunun için honey user kullanımı SIEM entegrasyonu ile desteklenmelidir:

Event ID 4769 honey user için tetiklendiğinde SIEM’e alarm gönderilir.
Alarm güvenlik ekibine “Kerberoasting saldırı girişimi” olarak bildirilir.
Bu sayede saldırganın kimliği (Account Name) ve hedef aldığı servis hesabı (Service Name) kolayca takip edilir.

Gerçek gibi görünen ama sahte bir service account oluşturun.
Bu hesaba sahte bir SPN (Service Principal Name) atayın.
Honey user’ı Domain Admin gibi dikkat çekici bir gruba ekleyin.
4769 Event ID’sini izleyerek, honey user üzerinden kim service ticket istiyor, bunu takip edin.

Örnek Senaryo

Domain Admins grubuna SQL DB Engine Service Account isimli bir honey user eklenmiş.
Bu kullanıcıya sahte bir SPN tanımlanmış.

setspn -s MSSQLSvc/corp.contoso.com:DBA:1334 SQLDBEngine

Çıktıda görebileceğimiz üzere artık SQLDBEngine hesabının sahte bir SPN’i var.
Saldırgan bu SPN’i sorguladığında honey user üzerinden sahte ticket üretir.
Event Log’da (4769) bu aktivite görünür hale gelir.

Örnek Event 4769 Kaydı:

Account Name: [email protected]
Service Name: SQLDBEngine
Service ID: CORP\SQLDBEngine

Bu noktada saldırgan yakalanmış olur çünkü gerçek bir hizmetle eşleşmeyen sahte bir SPN üzerinden ticket talep etmiştir.

Özet:
Honey user oluşturup sahte SPN atayarak, Kerberoasting yapan saldırganların izini sürebilir ve Event ID 4769 üzerinden yakalayabilirsiniz.

MS Administrative Tier Model Kavramı

Amaç: Kimlik ayrıcalıklarını katmanlara ayırarak (Tier 0, Tier 1, Tier 2) saldırı yüzeyini küçültmek.
Tier 0 → En kritik kaynaklara erişen Domain Admins, Azure AD, PKI, ADFS.
Tier 1 → Sunucu yöneticileri (file servers, SQL, Exchange, vb.).
Tier 2 → Helpdesk ve istemci yöneticileri.
Kural: Her yönetici yalnızca kendi tier kaynaklarına erişir, üst veya alt tier’a logon olamaz.

MS Administrative Tier Model Tasarımı

OU yapısını oluştur: Tier 0, Tier 1, Tier 2 için ayrı ayrı OU’lar.
- Accounts
- Devices
- Groups
- Service Accounts
- Servers / Workstations
Tier 0:
- Domain Admins, PKI, ADFS, Azure AD Connect.
- GPO ile yalnızca Administrator + Tier0 group local admin olur.
- Backup Operators, Power Users, Remote Desktop Users gibi gruplar boş bırakılır.
Tier 1:
- File, SQL, Exchange vb. sunucular.
- Tier 0 yöneticilerinin buraya logon olması yasaklanır.
- GPO ile “Deny log on locally / via RDP / from network” uygulanır.
Tier 2:
- Workstation / Helpdesk yöneticileri.
- Tier 1 veya Tier 0 admin’lerinin buraya erişimi engellenir.

GPO Örnek Ayarları

Local Admin üyeliği: Sadece “Administrator” + ilgili Tier Group.
Deny logon locally / network / RDP: Üst tier grupları engelle.
Empty Groups: Backup Operators, Replicators, Power Users, vb.

Tavsiyeler

Her seviyede “Service Accounts” OU oluştur.
Vendor hesaplarını da ilgili Tier altında tut.
Amaç: Bir Tier’daki hesabın başka bir Tier’a bulaşmasını önlemek.

Manage Azure AD Connect from a Tier 0 level

Azure AD Connect sunucusu kritik kimlik verilerini barındırır ve Tier 0 bileşeni olarak değerlendirilmelidir. Azure AD Connect, Tier 0 operasyonları kapsamında yönetilmektedir.

Ekran görüntüsünde, Active Directory Users and Computers konsolunda:

Tier 0 > Servers OU’su altında AADCONNECT bilgisayarı listelenmiş ve açıklaması “Azure AD Connect” olarak belirtilmiş durumda.

Azure AD Connect’i Tier 0 operasyonları kapsamında yönetin. Çünkü AAD sunucularına yerel yönetici erişimi olan saldırganlar tüm Active Directory domainini ele geçirebilir. Azure AD Connect, ikinci bir Domain Controller gibi değerlendirilmelidir. Azure AD Connect üzerine uygulanan tüm GPO’lar, yalnızca Tier 0 operasyonları tarafından yönetilmelidir. Aksi halde yetkisiz kullanıcılar kendilerini local Administrators grubuna ekleyebilir.

Manage ADFS from a Tier 0 level

ADFS temel olarak bir kimlik doğrulama sistemi olduğundan, diğer kimlik sistemleri gibi Tier 0 bileşeni olarak değerlendirilmelidir.

Öneriler:

ADFS yönetimini Tier 0 seviyesinden başlatın.
ADFS’e uygulanan tüm GPO’ların Tier 0’dan yönetildiğinden emin olun.

Azure AD Password Protection Nedir?

Kullanıcıların zayıf/kolay tahmin edilebilir parolalar seçmesini engeller.
Hem Azure ortamında hem de On-Premises (lokal Active Directory) ortamında kullanılabilir.
“Password Spraying” gibi saldırılara karşı güçlü koruma sağlar.

Gereksinimler

Azure AD Premium P1 veya P2 lisansı
Domain Controller’ların en az Windows Server 2012 olması
DC’lerde .NET Framework 4.5, proxy sunucularda .NET 4.7 kurulmuş olmalı
Azure AD Password Protection Proxy servisi kurulu olmalı
DC’ler ile proxy sunucular arasında RPC (135) ve ilgili portlara erişim olmalı
İnternete erişim için şu adreslere bağlantı gerekli:
- https://login.microsoftonline.com > Authentication
- https://enterpriseregistration.windows.net > Password Protection

Kurulum ve Çalışma Mantığı

Proxy & DC Agent kurulumu yapılır.
Azure AD portalında Password Protection policy tanımlanır.

Event Viewer üzerinden doğrulama yapılır:
- Event ID 3006 > Politika enforcement başladı.
- Event ID 3009 > Parola zayıf bulundu ama Audit modda kabul edildi.

Modlar

Audit: Zayıf parola kabul edilir ama log’a düşer (izleme amaçlı).
Enforced: Zayıf parola reddedilir, kullanıcı başka parola seçmek zorunda kalır.

Kullanıcı Senaryoları

Kullanıcı parolasını değiştirirken Password123 gibi bir parola seçerse > reddedilir.
Yeni kullanıcı oluştururken zayıf parola atanırsa > Active Directory hata verir.
Parola resetleme sırasında zayıf parola seçilirse > uyarı mesajı gelir.

Öneriler

İlk etapta Audit Mode ile başla > ortamı izle, hangi kullanıcılar zayıf parola seçiyor gör.
Daha sonra Enforced Mode’a geç > zayıf parolalar tamamen engellensin.
Önce test ortamında uygula, canlıya almadan önce hataları gör.

Set a Password for Guest & DefaultAccount Accounts

Windows işletim sistemlerinde varsayılan olarak bulunan Guest ve DefaultAccount hesapları genellikle devre dışı bırakılmış olsalar da, potansiyel güvenlik riski taşırlar. Bu hesaplara parola atanmadığı takdirde saldırganlar brute-force veya privilege escalation saldırılarında bu hesapları hedef alabilirler.

Guest ve DefaultAccount hesaplarına güçlü bir parola atayın.
Mümkünse bu hesapları tamamen devre dışı bırakın.
Grup İlkesi (GPO) üzerinden bu hesapların erişim ve kullanımını engelleyin.

PowerShell Komut Örnekleri:

Set-LocalUser -Name “Guest” -Password (Read-Host -AsSecureString “Yeni Parola”)
Set-LocalUser -Name “DefaultAccount” -Password (Read-Host -AsSecureString “Yeni Parola”)
Disable-LocalUser -Name “Guest”
Disable-LocalUser -Name “DefaultAccount”

Active Directory – Discretionary Access Control List

DACL (Discretionary Access Control List), bir nesnenin sahibi tarafından kontrol edilen erişim kontrol listesidir. Bu liste, belirli kullanıcıların veya grupların bir nesneye hangi erişim haklarına sahip olduğunu tanımlar.

ACL’nin Yapısı

Bir ACL, nesnenin sahibine bağlıdır.
ACL içindeki girdiler (ACE – Access Control Entries), hangi kullanıcı veya grubun hangi haklara sahip olduğunu gösterir.

Örnek Senaryo: