AdminSDHolder, SDProp ve adminCount: Ayrıcalıklı hesaplarda izin davranışı.

1. Core Mechanism / Temel mekanizma

Karar iki yerde birleşir: korumalı nesnenin nTSecurityDescriptor'ındaki DACL ve bu DACL'i periyodik olarak eşitleyen SDProp süreci. SDProp, domain'in PDC Emulator FSMO rolünü tutan domain controller üzerinde çalışır ve AdminSDHolder (CN=AdminSDHolder,CN=System,DC=...) nesnesinin izinlerini korumalı hesap/gruplara kopyalar. Bu dersin sınırı bu koruma döngüsüdür: ACE kapsam mekaniği 05.05'te, yönetim kimliklerinin gerçek üyelik kapsamı 05.07'de, delegasyonun genel access check'i 05.01'dedir.

Arabirimler ve belirtimler

• AdminSDHolder nesnesi: CN=AdminSDHolder,CN=System,DC=<dc>,DC=<dc>; sahibi domain'in Domain Admins grubudur; Enterprise Admins ile Administrators da değişiklik yapabilir/sahiplenebilir (Appendix C).
• SDProp: PDCE üzerinde varsayılan 60 dakikada bir çalışır; AdminSDHolder DACL'i ile korumalı nesnelerin DACL'ini karşılaştırır, farklıysa korumalı nesneyi AdminSDHolder'a göre geri yazar; inheritance'ı devre dışı bırakır.
• AdminSDProtectFrequency: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters altında DWORD; aralık 60–7200 saniye; silinirse 60 dakikaya döner; üretimde düşürülmesi PDCE'de LSASS yükünü artırır.
• Manuel çalıştırma: rootDSE üzerinde RunProtectAdminGroupsTask = 1 LDAP modify (Ldp.exe ile) SDProp'u hemen tetikler, zamanlanmış çalışmayı etkilemez.
• adminCount attribute: SDProp korumaya aldığı nesnelerde 1 olarak ayarlanır; bir nesnenin korunmuş OLDUĞUNU işaretler, üyelikten çıkınca otomatik 0'a dönmez.
• Windows Security kanalı: AdminSDHolder DACL'i veya adminCount değişimi için 5136 (uygun SACL ile), Audit Directory Service Changes; yalnız domain controller.

AdminSDHolder bir şablon, SDProp bir kopyalayıcıdır

Sıradan bir nesnede izinler, o nesneye veya üstündeki OU'ya yazılan ACE'lerle ve inheritance ile belirlenir. Korumalı hesap ve gruplarda ise araya bir düzeltici girer. AdminSDHolder, domain'in System container'ında bulunan tek bir nesnedir ve DACL'i "korumalı nesneler nasıl korunmalı" sorusunun şablonudur.

SDProp, bu şablonu uygulayan süreçtir. PDC Emulator rolündeki DC üzerinde varsayılan olarak 60 dakikada bir çalışır, AdminSDHolder'ın izinleriyle korumalı nesnelerin izinlerini karşılaştırır ve fark varsa korumalı nesnenin izinlerini AdminSDHolder'a göre geri yazar.

Bu yüzden korumalı bir nesnenin DACL'ini elle değiştirmek kalıcı değildir. Örneğimizde outreason.example'daki bir yönetici, bir Domain Admins üyesinin nesnesine bir delegasyon ACE'si ekler; en geç bir sonraki SDProp döngüsünde bu ACE AdminSDHolder şablonunda yoksa geri alınır.

Bu ders, periyodik protected-account döngüsü için Microsoft Learn Appendix C’nin SDProp adlandırmasını izler. Microsoft yayınları ilişkili descriptor propagation işlemlerini farklı adlarla ayırabilir; yalnız addan evrensel bir process-hosting veya scheduler modeli çıkarma.

Hangi nesneler korunur

Koruma keyfi değildir; Appendix C korumalı grupların listesini verir: Account Operators, Administrator, Administrators, Backup Operators, Domain Admins, Domain Controllers, Enterprise Admins, Enterprise Key Admins, Key Admins, Krbtgt, Print Operators, Read-only Domain Controllers, Replicator, Schema Admins ve Server Operators.

Protected-account taraması doğrudan üyeliğin yanında security veya distribution group üzerinden geçişli üyeliği de kapsar. Bu kapsam, hangi directory nesnelerinin korunacağını belirler; token yetkisi listesi değildir. Nested distribution group yolu, kullanıcıyı koruma kapsamına sokabilir ama parent protected-group SID’sini kullanıcının access token’ına eklemez.

Liste sürüm ve yapılandırmaya göre incelikler taşır (örneğin bazı gruplar dsHeuristics ile koruma dışına alınabilir), ama çekirdek fikir sabittir: yüksek ayrıcalıklı bir avuç grup ve onların üyeleri, sıradan delegasyon kurallarının dışında tutulur.

Inheritance korumalı nesnelerde kapalıdır

Appendix C açıkça belirtir: korumalı grup ve hesaplarda permission inheritance devre dışıdır. Nesneler dizinde farklı bir konuma taşınsa bile yeni üst nesnelerinden izin miras almazlar.

Bu, gözlemlenebilir güçlü bir yapısal göstergedir ama tek başına kanıt değildir. Sıradan bir user nesnesinin DACL'i tipik olarak "auto-inherited" (SDDL'de AI bayrağı) taşırken, korumalı bir nesnenin DACL'i "protected" (SDDL'de P bayrağı) taşır ve AI taşımaz. Ne var ki inheritance elle de kapatılabilir ve orphaned nesneler (üyelik bittikten sonra) P bayrağını korur; bu yüzden P bayrağı 'aktif SDProp koruması altında' sonucunu tek başına ispatlamaz.

Aktif korumayı doğrulamak için P bayrağı şu dört sinyalle birlikte okunur: (1) nesnenin bir korumalı gruba güncel geçişli (transitive) üyeliği, (2) nesnenin DACL'inin AdminSDHolder şablonuyla karşılaştırılması (eşleşme), (3) adminCount değeri ve değişim geçmişi, (4) 5136 üzerinden son SDProp düzeltme izleri. Bu korelasyon yapılmadan yalnız P bayrağına bakmak, elle kapatılmış inheritance'ı veya orphaned bir nesneyi 'aktif korunuyor' sanmaya yol açar.

AdminSDHolder'ın kendisinde de inheritance kapalıdır; böylece üst nesnelerdeki izin değişiklikleri şablonu bozmaz. Şablonun sabit kalması, korumanın tutarlı uygulanması için gereklidir.

adminCount bir geçmiş kaydıdır, güncel durum değil

SDProp bir nesneyi koruma altına aldığında adminCount attribute'unu 1 yapar. Bu değer, nesnenin AdminSDHolder/SDProp kapsamına girdiğini işaretler. Sorun, tersine dönüşün otomatik olmamasıdır: bir kullanıcı korumalı gruptan çıkarıldığında adminCount kendiliğinden 0'a dönmez.

Bunun iki sonucu vardır. Birincisi, adminCount=1 taşıyan bir nesne artık hiçbir ayrıcalıklı grupta olmayabilir; flag geçmişten kalmıştır. İkincisi, o nesnenin DACL'i hâlâ AdminSDHolder şablonuyla ve inheritance kapalı biçimde kalır; SDProp artık onu düzeltmez ama önceki durumu da geri almaz. Bu "orphaned adminCount" durumudur.

Üç gözlemi ayır: güncel protected-group üyeliği, geride kalmış adminCount/DACL koruması ve access check’in kullandığı gerçek caller token’ı. O bağlamdaki etkin security-group SID’leri ile istenen işlem authorization kararında kullanılır. Geride kalmış flag ne ayrıcalığı ne başarılı erişimi kanıtlar.

Örnekte protected DACL'i okumak

İzlediğimiz nesne bir Domain Admins üyesidir. DACL'i, sıradan bir kullanıcıdan iki noktada ayrılır: DACL protected'tır (inheritance kapalı) ve içeriği AdminSDHolder şablonuyla eşleşir. Artifact'teki SDDL'de bunu D:P bayrağı ve şablon ACE'leriyle görürüz.

Bu okuma pratik bir soruyu yanıtlar: "neden bu nesneye eklediğim delegasyon kayboldu?" Cevap, SDProp'un nesneyi AdminSDHolder'a göre geri yazmasıdır. Eklenen ACE şablonda yoksa döngüde silinir; korumayı anlamadan yapılan delegasyon sessizce geri alınır.

Tersi de doğrudur: AdminSDHolder şablonuna bir ACE eklenirse, o ACE bir sonraki döngüde tüm korumalı nesnelere yayılır. Bu güçlü ve tehlikeli bir kaldıraçtır; şablonu değiştirmek tek tek nesneleri değiştirmekten çok daha geniş etkilidir.

Durum ve veri akışı

1. Bir kullanıcı Domain Admins grubuna eklenir; bu grup Appendix C'ye göre korumalıdır.
2. En geç bir sonraki SDProp döngüsünde (PDCE'de varsayılan 60 dk) kullanıcının nesnesi koruma kapsamına alınır.
3. SDProp kullanıcının DACL'ini AdminSDHolder şablonuna göre yazar, inheritance'ı kapatır (P) ve adminCount'u 1 yapar.
4. Bir yönetici bu nesneye elle bir delegasyon ACE'si ekler; ACE AdminSDHolder şablonunda yoktur.
5. Sonraki SDProp döngüsü nesnenin DACL'ini AdminSDHolder ile karşılaştırır, farkı görür ve nesneyi şablona göre geri yazar; elle eklenen ACE silinir.
6. Kullanıcı daha sonra Domain Admins'ten çıkarılır; üyelik biter fakat adminCount 1 olarak kalır ve DACL protected olarak kalır.
7. SDProp artık bu nesneyi aktif düzeltmez; ama önceki protected durumu da geri almaz (orphaned adminCount).
8. Denetimde koruma kapsamını güncel doğrudan/geçişli üyelikten, koruma geçmişini adminCount/DACL’den, etkin yetkiyi gerçek token ve access-check bağlamından oku. Bu gözlemler birbirinin yerine geçmez.

2. Exploitation / İstismar

Broken trust assumption

Kırılan varsayım şudur: "adminCount=1 olan her hesap ayrıcalıklıdır ve korunur; adminCount=0 olan güvenlidir." Gerçekte adminCount bir geçmiş işaretidir: geride kalmış olabilir (üyelik bitti ama flag kaldı) veya bir hesap AdminSDHolder şablonu üzerinden dolaylı olarak kontrol edilebilir. İki yönlü karışıklık, hem gerçek Tier-0 yüzeyini gözden kaçırmaya hem de olmayan ayrıcalığı varsaymaya yol açar.

Technical prerequisites

• AdminSDHolder şablonunu değiştirebilmek için: nesnenin sahibi olan Domain Admins, ya da Enterprise Admins/Administrators düzeyinde yetki. Bu zaten yüksek ayrıcalıktır; mekanizma bir yükseltme değil, kalıcılık kaldıracıdır.
• Orphaned adminCount senaryosu için: geçmişte korumalı bir gruba girmiş, sonra çıkarılmış bir hesap. Ek yetki gerekmez; bu bir hijyen/görünürlük sorunudur.
• SDProp'un çalışıyor olması: PDCE erişilebilir olmalı; rol taşıyan DC devre dışıysa döngü gecikir ve manuel/otomatik düzeltme uygulanmaz.
• Şablon değişikliğinin yayılması için en az bir SDProp döngüsü (varsayılan 60 dk) veya RunProtectAdminGroupsTask ile manuel tetik.

Exploitation mechanism / İstismar mekanizması

İki ayrı yanlış-okuma mekanizması vardır. Birincisi kalıcılık: AdminSDHolder DACL'i tek bir şablondur ve SDProp onu tüm korumalı nesnelere geri yazar; şablona eklenen bir ACE, tek tek nesnelere dokunmadan tüm korumalı hesaplarda kalıcı bir erişim bırakır ve elle temizlenen nesne ACE'leri bir sonraki döngüde şablona göre yeniden şekillenir. İkincisi görünürlük: adminCount=1 bir nesnenin korunmuş olduğunu işaretler ama üyelik bittiğinde 0'a dönmediği için 'ayrıcalıklı hesap' envanterini şişirir; ters yönde, koruma dışına alınmış veya yeni eklenmiş bir hesap ile flag arasındaki gecikme, gerçek durumu adminCount'a bakarak okumayı yanıltır. Her ikisinde de protokol doğru çalışır; yanlış olan, flag'i güncel yetkiyle ve şablonu tek tek nesnelerle eşitlemektir.

Şablon değişikliği neden geniş etkilidir

AdminSDHolder tek nesnedir ama etkisi tüm korumalı hesaplardır. SDProp döngüsü şablonu her korumalı nesneye kopyaladığı için, şablona eklenen bir ACE dağıtılmış ve kendini onaran bir erişime dönüşür.

Bu yüzden korumalı bir nesnede beklenmedik bir ACE görüldüğünde ilk bakılacak yer o nesne değil, AdminSDHolder'dır. Nesnede silinen ACE geri geliyorsa, kaynak neredeyse kesinlikle şablondadır.

Aynı özellik meşru yönetim için de geçerlidir: korumalı nesnelere toplu bir izin uygulamanın doğru yolu tek tek nesneleri değil AdminSDHolder'ı düzenlemektir. Kaldıracın gücü, onu hem güçlü bir yönetim aracı hem de yüksek değerli bir hedef yapar.

Orphaned adminCount'un iki yüzü

adminCount=1 taşıyan ama hiçbir korumalı grupta olmayan hesaplar, ayrıcalıklı hesap envanterini yanlış şişirir. Bu hesaplar aslında ayrıcalıklı değildir; sadece bir zamanlar öyleydi. Onları hâlâ Tier-0 sanmak, gerçek risk odağını dağıtır.

Ters taraf daha inceliklidir: bu hesapların DACL'i hâlâ protected (inheritance kapalı) kalır. Yani sıradan delegasyon ve inheritance kuralları bu nesnelerde beklendiği gibi işlemez; bir yönetici inheritance yoluyla izin vermeye çalışırsa sonuç sürpriz olabilir.

Doğru okuma iki kaynağı ayırır: güncel ayrıcalık geçerli grup üyeliğinden, koruma geçmişi adminCount ve DACL protected bayrağından okunur. Bir hesabın gerçekten Tier-0 olup olmadığına adminCount'a değil üyeliğe bakarak karar verilir.

Nerede etkisiz veya sınırlı kalır

AdminSDHolder şablonunu değiştirmek zaten çok yüksek ayrıcalık gerektirir; bu bir privilege escalation değil, elde edilmiş ayrıcalığın kalıcılaştırılmasıdır. Tehdit modeli "nasıl Domain Admin olunur" değil, "Domain Admin olduktan sonra nasıl gizli kalınır"dır.

SDProp yalnız korumalı nesnelerde çalışır; sıradan hesap ve gruplar bu döngünün dışındadır ve onların delegasyonu 05.05'teki normal kurallara tabidir. Koruma, tüm dizini değil, Appendix C listesindeki yüzeyi kapsar.

adminCount'un kendisi bir erişim vermez; sadece bir işarettir. Onu 0/1 yapmak ayrıcalık eklemez veya silmez. Gerçek yetki her zaman DACL ve üyelikte olduğu için, temizlik adminCount'u düzeltmekle değil, DACL'i ve üyeliği doğrulamakla tamamlanır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Audit Directory Service Changes Success, açık bir domain controller’da, değişen attribute için ilgili nesnenin SACL’inde eşleşen Write auditing varsa AdminSDHolder DACL’i veya adminCount değişimini 5136 olarak kaydeder.
• AdminSDHolder tek ve yüksek değerli bir nesne olduğu için SACL'i öncelikle onun üzerine koymak, şablon değişikliklerini yakalamanın en doğrudan yoludur.
• adminCount değişimi (0->1 veya elle 1->0) korumalı-nesne yaşam döngüsünü izlemek için ayrı bir sinyaldir; korumalı gruplara üyelik değişiklikleriyle (4728/4732/4756, 05.07) birlikte okunur.
• Tüm bu kayıtlar yalnız domain controller'da oluşur; PDCE rolündeki DC, SDProp'un çalıştığı yer olduğu için özellikle önemlidir.
• 5136 kaydı tek başına “SDProp çalıştı” demez; kapsama alınmış değişimlerden, örneğin korumalı nesne DACL’inin şablona dönmesinden veya adminCount’un 1 olmasından döngü çıkarılır.

Events and relevant fields

• 5136 / ObjectDN: değişen nesne. AdminSDHolder için DN CN=AdminSDHolder,CN=System,DC=... ile başlar; bu değeri filtrelemek şablon değişikliklerini izole eder.
• 5136 / AttributeLDAPDisplayName: değişen attribute. Şablon izlemede nTSecurityDescriptor, koruma-durumu izlemede adminCount aranır.
• 5136 / AttributeValue: yeni değer. nTSecurityDescriptor için ham SDDL, adminCount için 1 veya 0. SDDL'i ayrıştırmadan hangi ACE eklendiği görülmez.
• 5136 / OperationType: %%14674 Value Added, %%14675 Value Deleted. adminCount ve DACL değişiklikleri tipik olarak ikili (sil/ekle) çift üretir.
• 5136 / SubjectUserName ve SubjectUserSid: değişikliği yapan principal. AdminSDHolder değişikliği beklenen çok az kişi tarafından yapılmalıdır; bu alan beyaz listeyle karşılaştırılır.
• Directory’den okunan adminCount: 1 koruma geçmişinin işaretidir, güncel authorization kanıtı değildir. Güncel protected-group üyeliği ile etkin token SID’lerini ayrı karşılaştır.

Elle eklenen ACE neden kaybolur

Korumalı bir nesneye eklenen ve AdminSDHolder şablonunda karşılığı olmayan bir ACE, bir sonraki SDProp döngüsünde silinir. Bu bir hata değil, tasarlanmış davranıştır: SDProp korumalı nesneyi şablona eşitler.

Bu yüzden 'delegasyonum kayboldu' şikayetinin kök nedeni çoğu zaman nesnenin korumalı olmasıdır. Çözüm nesneye tekrar ACE yazmak değil; ya nesneyi koruma dışına almak (mümkün ve uygunsa) ya da izni şablon düzeyinde ele almaktır.

Gözlem tarafında bu döngü, aynı ACE'nin eklenip (yönetici) silindiği (SDProp) 5136 çiftleri olarak görünür. Deseni tanımak, koruma davranışını 'garip bir bug' sanmaktan kurtarır.

adminCount'u üyelikle birlikte okumak

Üç gözlemi ayır: güncel protected-group üyeliği, geride kalmış adminCount/DACL koruması ve access check’in kullandığı gerçek caller token’ı. O bağlamdaki etkin security-group SID’leri ile istenen işlem authorization kararında kullanılır. Geride kalmış flag ne ayrıcalığı ne başarılı erişimi kanıtlar.

Bu ikisini ayırmak, iki yönlü hatayı önler: adminCount=1 diye olmayan ayrıcalığı varsaymak, ya da adminCount'a bakıp gerçek bir Tier-0 hesabını (üyeliği yeni, flag henüz yazılmamışsa) gözden kaçırmak.

Pratik denetim sorgusu iki listeyi çakıştırır: (1) korumalı gruplarda güncel üyeler, (2) adminCount=1 taşıyan nesneler. İkinci listede olup birincide olmayanlar 'orphaned', birincide olup henüz işaretlenmemiş olanlar ise SDProp gecikmesidir.

Detection logic · Sigma

title: AdminSDHolder sablonu (nTSecurityDescriptor) veya adminCount degisti
id: 6b2f4a17-9c3d-4e21-bb0a-0d5f7c9e1a44
status: experimental
description: >
  AdminSDHolder nesnesinin security descriptor'inin veya herhangi bir nesnenin
  adminCount attribute'unun degistigi 5136 kayitlarini arar. Sablon degisikligi tum
  korumali hesaplara yayilabilecegi icin yuksek onceliklidir; adminCount degisikligi
  koruma yasam dongusunu izler. Tek basina kotu niyet kaniti degildir.
logsource:
  product: windows
  service: security
detection:
  adminsdholder_acl:
    EventID: 5136
    ObjectDN|startswith: 'CN=AdminSDHolder,CN=System,'
    AttributeLDAPDisplayName: 'nTSecurityDescriptor'
  admincount_change:
    EventID: 5136
    AttributeLDAPDisplayName: 'adminCount'
  condition: adminsdholder_acl or admincount_change
fields:
  - ObjectDN
  - AttributeLDAPDisplayName
  - AttributeValue
  - SubjectUserName
falsepositives:
  - Mesru Tier-0 yonetimi: AdminSDHolder sablonunun planli guncellenmesi
  - Korumali gruplara uye ekleme/cikarma sonrasi SDProp kaynakli adminCount degisimi
level: high

Query assumptions

• 5136 yalnızca ilgili nesnenin SACL'inde Write auditing varsa üretilir. AdminSDHolder ve korumalı nesnelerde bu SACL yapılandırılmamışsa kural hiçbir şey görmez.
• AttributeValue nTSecurityDescriptor için ham SDDL'dir; hangi trustee/hak eklendiği backend'de ayrıştırılmalıdır. adminCount için değer 1/0'dır.
• ObjectDN|startswith filtresi AdminSDHolder'ı hedefler; farklı bir dil/normalizasyon kullanan backend'de DN biçimi doğrulanmalıdır.
• adminCount değişimleri hem SDProp kaynaklı (0->1) hem de elle temizlik kaynaklı (1->0) olabilir; kural ikisini de görür, ayrımı SubjectUserName ve bağlam yapar.
• Bu kural gerçek bir SIEM üzerinde çalıştırılmamıştır; alan adları ve olay anlamı birincil kaynağa göre hazırlanmıştır ve kullanılan sürümün şemasına göre doğrulanmalıdır.

False positives

• Planlı Tier-0 yönetimi: AdminSDHolder şablonunun meşru güncellenmesi bu kaydı üretir ve beklenen bir değişikliktir.
• Korumalı gruplara üyelik değişikliği sonrası SDProp'un yeni üyeye adminCount=1 yazması normaldir.
• Ayrıcalıklı hesap temizliği sırasında yönetici tarafından adminCount 1->0 yapılması beklenen bir bakım işidir.
• Negatif örnek: Domain Admins üyeliği eklendiği halde SACL yoksa 5136 hiç üretilmez; alarm yokluğu 'değişiklik olmadı' anlamına gelmez. Kural bir görünürlük katmanıdır, kanıt değil.

Hardening

• AdminSDHolder nesnesinin SACL'ine Write auditing ekle; şablon değişikliklerini görmeden onları yönetemezsin. Bu, korumalı-yüzey denetiminin ön koşuludur.
• AdminSDHolder DACL'ini bilinen-iyi bir temel olarak kaydet ve düzenli karşılaştır; şablona eklenen her ACE tüm korumalı hesaplara yayıldığı için sapmalar yüksek öncelikle incelenir.
• Güncel protected-group üyelik envanteri ile etkin token yetkilerini ayrı tut. Koruma kapsamı dışında adminCount=1 taşıyan nesneleri geride kalmış koruma olarak incele; flag’in hak verdiğini varsaymadan DACL/inheritance durumunu değerlendir.
• SDProp aralığını (AdminSDProtectFrequency) üretimde düşürme; varsayılan 60 dakikayı test dışında değiştirmek PDCE'de LSASS yükünü artırır. Hızlı doğrulama gerektiğinde RunProtectAdminGroupsTask ile manuel tetikle.
• Doğrulama adımı: bir test hesabını korumalı bir gruba ekle, SDProp döngüsünden (veya manuel tetikten) sonra hesabın DACL'inin protected olduğunu, inheritance'ın kapandığını ve adminCount'un 1 olduğunu 5136 ve attribute sorgusuyla gör; sonra çıkar ve orphaned adminCount davranışını gözlemle.
• Korumalı nesnelere doğrudan delegasyon yapma; kalıcı olması gereken bir izin varsa AdminSDHolder şablonu üzerinden ve gerekçeli biçimde uygula, aksi halde bir sonraki döngüde geri alınır.

Örnekler üzerinde oku / Read the examples

O:DAG:DAD:P(A;;GA;;;DA)(A;;GA;;;EA)(A;;GA;;;BA)(A;;RPRPLCLORC;;;AU)

İki yanlış kanı / Two reality checks

Sanılan: Bir hesabın adminCount attribute'u 1 ise o hesap ayrıcalıklıdır ve korunmaktadır.

Gerçekte: adminCount=1 yalnızca nesnenin bir zamanlar AdminSDHolder/SDProp kapsamına alındığını işaretler. Bir kullanıcı korumalı gruptan çıkarıldığında bu değer otomatik 0'a dönmez ve DACL protected kalır (orphaned adminCount). Bu yüzden güncel ayrıcalık adminCount'tan değil, geçerli grup üyeliğinden okunur; adminCount=1 taşıyan bir hesap bugün hiçbir ayrıcalıklı grupta olmayabilir.

Sanılan: Korumalı bir hesaba yazdığım delegasyon ACE'si kalıcıdır; ACL'i ben değiştirdim.

Gerçekte: AdminSDHolder korumasındaki nesnelerde SDProp, DACL'i PDCE üzerinde varsayılan 60 dakikada bir AdminSDHolder şablonuna göre geri yazar ve inheritance'ı kapalı tutar. Şablonda karşılığı olmayan elle eklenmiş bir ACE bir sonraki döngüde silinir. Kalıcı bir izin isteniyorsa nesne değil AdminSDHolder şablonu ele alınmalıdır; aksi halde delegasyon sessizce geri alınır.

Kaynaklar / Sources

• Microsoft · Appendix C: Protected Accounts and Groups in Active Directory
  Protected Groups listesi; AdminSDHolder (CN=AdminSDHolder,CN=System,DC=...), Domain Admins sahipliği; SDProp PDCE'de varsayılan 60 dk; korumalı nesnelerde inheritance devre dışı; AdminSDProtectFrequency 60–7200 sn (HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters); RunProtectAdminGroupsTask ile manuel tetik.; korumalı gruptan çıkarılınca adminCount elle temizlenene kadar 1 kalır
• Microsoft · ACE strings (SDDL)
  DACL bayrakları (P = SE_DACL_PROTECTED, AI = SE_DACL_AUTO_INHERITED) ve ACE alan sırası; GA hak kısaltması.
• Microsoft · 5136(S) A directory service object was modified
  Subcategory Audit Directory Service Changes; SACL Write auditing ön koşulu; EventData alanları ObjectDN, AttributeLDAPDisplayName, AttributeValue, OperationType, SubjectUserName.; DC’de Audit Directory Service Changes Success; Failure olayı yok
• Microsoft · Active Directory Attack Surface’ünü Azaltma
  Doğrudan/transitive protected-group üyeliği, adminCount=1, gruptan çıkarılınca kalan flag ve SDProp/ACL davranışı.
• AdminSDHolder and SDProp terminology
  First-party terminology distinctions; lesson follows Learn Appendix C for its bounded cycle.
• Access Tokens
  Token SID context versus directory membership/protection state.