Grup türleri, scope, nesting ve AGDLP: Etkili üyelik nasıl oluşur?
Bir kullanıcının bir kaynağa erişip erişmediğini onun tek tek üyelikleri değil, access token'ına giren düzleştirilmiş grup SID kümesi belirler. Bu ders group type (security/distribution), üç group scope (Universal, Global, Domain Local), bunların iç içe geçme (nesting) kuralları ve AGDLP modelini gerçek bir SID setine bağlayarak 'etkili üyelik' kavramını kurar. Örnek bir kullanıcı bir global gruba eklenir, o global grup bir domain local gruba nested edilir ve domain local grup bir paylaşımda izin taşır; erişim bu zincirin token içinde nasıl çözüldüğüyle açıklanır.
1. Core Mechanism / Temel mekanizma
Bu ders grupların yetkilendirmeye nasıl dönüştüğünü ele alır: security ve distribution group ayrımı, Universal/Global/Domain Local scope'ların üyelik ve nesting kuralları, AGDLP deseni ve bir logon anında access token'a hangi grup SID'lerinin girdiği. SID'in bileşenleri ve yeniden kullanılmaması 03.03'te; access token'ın yapısı ve access check adımı 05.02'de; security descriptor/DACL/ACE okuma 05.03'te; allow/deny/inheritance değerlendirmesi 05.04'te işlenir. Buradaki odak, üyeliğin kaynak erişimine dönüşmeden önce token içinde nasıl toplandığıdır.
Arabirimler ve belirtimler
- Group type: security group DACL'lerde principal olarak görünür ve izin taşır; distribution group security-enabled değildir ve DACL'e konamaz (yalnız e-posta dağıtımı içindir).
- Global group: kendi domain’indeki hesapları ve global grupları üye alır. Kendi domain’indeki global gruplara, aynı forest’taki universal gruplara ve uygun trust bağlamındaki Domain Local gruplara üye olabilir. Üyelik kapsamı ile izin verilebilecek kaynakların kapsamı aynı değildir.
- Domain Local group: kendi domain’indeki diğer Domain Local grupları; kendi veya uygun trust bağlamındaki domain’lerden hesapları, global ve universal grupları üye alabilir. Kaynak izinleri kendi domain’iyle sınırlıdır. Universal grubun kendi üyelik kapsamı yine kendi forest’ıdır; bu, onun trusted domain’deki Domain Local gruba üye olabilmesiyle farklı bir kuraldır.
- Group scope · Universal: üyeleri forest içindeki herhangi bir domain'den hesap, global ve diğer universal gruplardır; üyeliği Global Catalog'ta tutulur.
- AGDLP: Account → Global group → Domain Local group → Permission. Hesaplar global gruplarda toplanır, global gruplar izin taşıyan domain local gruplara nested edilir, izin yalnız domain local gruba verilir.
- Effective membership: token, user SID’ini ve logon bağlamında çözülen doğrudan/dolaylı grup SID’lerini içerir. Bir grup SID’inin token’da bulunması ile access check’e hangi attributes ile katılması da ayrı konudur; bu örnekte ilgili gruplar security-enabled ve etkindir.
- SID örnekleri: Domain Users = domain SID + RID 513; Built-in Users = S-1-5-32-545. Standart domain user logon’larında sık görülürler, her token için garanti değildir. primaryGroupId, token’ın oluşturulduğu host, yerel grup üyelikleri ve logon bağlamı ayrıca incelenir.
Security group ile distribution group aynı şey değildir
Active Directory iki grup türü tanır. Security group, izinleri ve user right'ları toplu atamak için kullanılır; bir kaynağın DACL'inde principal olarak görünebilir. Distribution group yalnız e-posta dağıtım listesi içindir ve security-enabled olmadığından bir DACL'e konamaz, yani hiçbir dosya/nesne erişimi vermez.
Bu ayrım pratikte önemlidir: 'gruba ekledim ama erişim gelmedi' vakalarının bir kısmı, yanlışlıkla distribution group kullanılmasıdır. Yetkilendirme yalnız security-enabled gruplar üzerinden akar; bu dersin geri kalanı security group'ların scope'una odaklanır.
Üç scope: kim üye olabilir, nerede izin verilebilir
Group scope iki ayrı soruyu sınırlar: kim bu gruba üye olabilir ve bu gruba nerede izin verilebilir? Global group kendi domain’indeki hesapları ve global grupları toplar. Buna rağmen, uygun forest/trust bağlamında başka domain’lerdeki kaynaklarda da izin taşıyabilir. Üyelerin kendi domain’iyle sınırlı olması, kaynakların da aynı domain’de olması gerektiği anlamına gelmez.
Domain Local group, kendi domain’indeki kaynak izinlerini bir arada tutmak için kullanılır. Aynı domain’deki Domain Local grupları da içine alabilir; hesaplar, global ve universal gruplar için uygun trusted-domain bağlamı da mümkündür. Burada iki yönü karıştırma: bir universal group’un kendi içine alabileceği üyeler aynı forest’la sınırlıyken, o grubun başka bir trusted domain’deki Domain Local gruba üye olması farklı bir nesting ilişkisidir. Universal membership’in Global Catalog’ta tutulması da bu kuralların yerine geçmez.
Bu üç scope birbirine dönüştürülebilir ama koşulludur: örneğin bir global grup başka bir global grubun üyesi değilse universal'a çevrilebilir; bir universal grup başka universal grup içermiyorsa global'a çevrilebilir. Ders, dönüşümün ayrıntısından çok, hangi scope'un nereye üye olabildiğini vurgular çünkü nesting kuralları buradan çıkar.
AGDLP: rol üyeliği ile kaynak iznini ayır
AGDLP, yaygın bir grup düzenleme modelidir: Account → Global group → Domain Local group → Permission. Hesaplar rollerine göre global gruplarda toplanır; bu gruplar ilgili kaynak için seçilmiş Domain Local gruba üye yapılır; izin kaynağın DACL’inde o gruba verilir. Bir kişinin rolü değiştiğinde üyeliği değiştirirsin. Her kaynağın DACL’ine tek tek kullanıcı yazmak gerekmez.
Bu desen ölçeklenir çünkü izin ile kimlik ayrışır: 'kim' sorusu global gruplarda, 'neye erişilir' sorusu domain local gruplarda cevaplanır. Ama aynı mekanizma bir güven yüzeyi de yaratır: domain local grup, kaynağın gerçek erişim kapısıdır ve içine nested edilen her global/universal grup, o kapının anahtarını dolaylı olarak dağıtır. Bu ders boyunca izlediğimiz zincir tam olarak budur.
Aynı domain’deki örneğimizde u.tunahan → GG-ProjectAtlas → DL-Atlas-Share-RW zinciri var. FS01 üzerindeki Atlas SMB paylaşımında DL grubuna Change, paylaşımın altındaki örnek dosyada ise NTFS Modify izni verilmiş. Kullanıcının adı bu iki DACL’e yazılmıyor; ilgili token DL SID’ini taşıdığı için grup ACE’siyle eşleşebilir. Share check’in geçmesi dosya işleminin sonucunu tek başına belirlemez: NTFS DACL’i de istenen hakkı vermelidir.
Etkili üyelik access token'da toplanır
Bu aynı-domain örneğinde yeni logon’un token’ında user SID’i, doğrudan GG-ProjectAtlas SID’i ve nesting üzerinden gelen DL-Atlas-Share-RW SID’i birlikte bulunabilir. Yalnız memberOf çıktısına bakmak dolaylı üyelikleri ve primary group’u göstermez. Access check, directory’deki bir isim listesini canlı sorgulamak yerine ilgili token’ın SID ve attributes bilgisini kullanır.
Önemli bir zamanlama sonucu şudur: access token logon sırasında oluşturulur. Bir kullanıcı grup üyeliği değiştiğinde hâlihazırda açık oturumun token'ı otomatik güncellenmez; yeni üyelik yeni bir token oluşturulduğunda yansır. Bu yüzden 'ekledim ama hâlâ erişemiyor/hâlâ erişebiliyor' durumlarında token'ın hangi üyeliği taşıdığı incelenmelidir.
Durum ve veri akışı
- Yönetici u.tunahan hesabını GG-ProjectAtlas global grubuna ekler (rol ataması).
- GG-ProjectAtlas, aynı domain’deki DL-Atlas-Share-RW grubuna üye yapılır. Bu nesting izin ataması değildir.
- Atlas SMB share DACL’i DL-Atlas-Share-RW için Change ACE’si taşır. Dosyanın NTFS Modify ACE’si ayrı bir security descriptor’dadır.
- Bu örneğin yeni logon token’ı user, GG-ProjectAtlas ve etkili DL-Atlas-Share-RW SID’lerini toplar. Token’ın host/logon bağlamı, başka üyeliklerin de dahil olup olmadığını belirler.
- Share check token’daki DL SID’ini Change ACE’siyle eşleştirir. Dosya işleminde NTFS DACL’i ayrıca değerlendirilir; paylaşım izni tek başına dosyada Modify başarısı değildir.
- Kullanıcı gruptan çıkarıldığında directory zinciri değişir; eski token yerinde kalır. Eski TGT’den alınan service ticket ve açık resource session’ı da ayrıca incelenir.
2. Exploitation / İstismar
Broken trust assumption
Kırılan varsayım: Grup nesting'i yalnızca düzenleme kolaylığıdır ve bir kullanıcının erişimi, onu doğrudan içinde gördüğünüz grupların toplamıdır. Gerçekte erişimi belirleyen, token'a giren transitif SID kümesidir; 'sadece bir global grup' birkaç kat aşağıda hedef kaynağın DACL'inde anlamlı permission taşıyan bir security group'a bağlı olabilir (AGDLP'de bu genellikle Domain Local permission group'tur).
Technical prerequisites
- Aktörün, transitif nesting'i sonunda hedef kaynağın DACL'inde anlamlı hakkı olan bir security-enabled group'a ulaşan gruba üye ekleyebilmesi (AGDLP'de bu genellikle Domain Local permission group'tur).
- Bu nesting zincirinin gerçekten hedef kaynak kontrolüne çıkması: token'daki grup SID'lerinden biri hedef kaynağın DACL'inde anlamlı hak taşımalıdır.
- Güncel grup üyeliğinin hedef principal için yeni bir access token oluşturulduğunda hesaba katılması.
- Grup üyeliği değişimlerinin izlenmediği veya yüksek değerli grupların nesting'inin düzenli gözden geçirilmediği bir ortam.
Exploitation mechanism / İstismar mekanizması
Access check adları değil, token'daki düzleştirilmiş SID kümesini kullanır; bu küme doğrudan ve transitif group SID'lerini içerir. Bu yüzden 'zararsız görünen' bir global gruba hesap eklemek, o grup birkaç kat nesting sonunda hedef kaynağın DACL'inde anlamlı hakkı olan security-enabled bir gruba ulaşıyorsa o erişim yolunu hesaba taşıyabilir. AGDLP'de permission group genellikle Domain Local scope'tadır. Bir grubun üyeliğini değiştirebilen kişi bu zincir üzerinden dolaylı erişim dağıtabilir; etki, değiştirebildiği gruplara, transitif üyelik yoluna, hedef ACE'ye ve principal için yeni token oluşturulmasına bağlıdır. Engelleyici kontrol, membership yönetimini least-privilege ile sınırlamak, kaynak izni taşıyan grupların nested üyeliğini gözden geçirmek ve değişimleri izlemektir.
'Sadece bir grup' neden yanıltır
Bir yönetim panelinde bir kullanıcının doğrudan üyeliklerine bakmak, onun etkili erişimini göstermez. Bir global grup, birkaç kat nesting'in ardından hedef kaynağın DACL'inde anlamlı hak taşıyan bir security group'a bağlıysa, o global gruba yapılan sıradan görünen bir ekleme, transitif küme üzerinden o erişim yolunu hesaba açabilir. AGDLP'de bu permission group genellikle Domain Local scope'tadır. Değerlendirme her zaman 'bu hesabın token'ında hangi SID'ler oluşur ve bunlardan hangileri hedef DACL'deki haklarla eşleşir?' sorusuyla yapılmalıdır.
İkinci incelik, zincirin gerçekten hedef kaynağa çıkıp çıkmadığıdır. Her nesting otomatik olarak yüksek etki demek değildir; token'daki security-enabled grup SID'lerinden biri hedef kaynağın DACL'inde anlamlı hak taşımalıdır. Bu nedenle scope ve üyelik zincirinin yanı sıra hedef ACE'nin hakkı da doğrulanır.
3. Defense & Detection / Savunma ve tespit
Telemetry scope
- Grup üyeliği değişimleri Audit Security Group Management alt kategorisinde kaydedilir; global gruplar için 4728/4729 (üye eklendi/çıkarıldı), domain local gruplar için 4732/4733, universal gruplar için 4756/4757 olayları üretilir.
- Domain local bir gruba (AGDLP'de kaynağın izin kabı) üye eklenmesi 4732 olarak kaydedilir; bu olayın alanları eklenen üyeyi (MemberSid) ve hedef grubu (TargetSid) ayrı verir, böylece 'hangi principal hangi kaynak grubuna girdi' izlenebilir.
- Access token'ın grup snapshot'ı, Audit Group Membership Success ve Audit Logon Success açıkken 4627 (Group Membership) olarak logon session'ın oluşturulduğu bilgisayarda üretilir; interactive logon'da kullanıcının bağlandığı, network logon'da ise kaynağı barındıran bilgisayardır. 4627 aynı logon'un 4624 olayıyla ilişkilendirilir ve GroupMembership alanında token'daki grup SID'lerini listeler.
- 4627 yalnız Windows Server 2016 / Windows 10 ve üzerinde bulunur ve grup listesi tek olaya sığmazsa birden çok 4627 üretilir (EventIdx/EventCountTotal alanları bunu belirtir).
Events and relevant fields
- 4732: MemberSid nested edilen grubun (ör. GG-ProjectAtlas) SID'idir; TargetSid domain local grubun (ör. DL-Atlas-Share-RW) SID'idir; SubjectUserSid değişikliği yapan principal'ı verir ve SubjectLogonId ile 4624'e korele edilir.
- 4627: TargetLogonId, aynı logon'un 4624'üyle eşleştirilir; GroupMembership alanı token'a giren SID kümesini (ör. Domain Users 513, Built-in 32-545 ve nested grup SID'leri) gösterir.
- Bir değişikliğin etkisini kanıtlamak için 4732 (üyelik değişti) ile bir sonraki 4624+4627 (token snapshot'ı değişimi içeriyor) birlikte okunur; ikisi arasındaki logon anı, değişikliğin ne zaman erişime dönüştüğünü verir.
- 4728/4732/4756 ayrımı hangi scope'un değiştiğini söyler; AGDLP'de kaynak riski en çok domain local (4732) ve universal (4756) tarafında yoğunlaşır çünkü izin genelde bu kaplarda durur.
Değişimi snapshot'la birlikte oku
Bir üyelik değişiminin token'a yansıması ile kaynağa etkisi ayrı kanıtlardır. 4732 (veya scope'a göre 4728/4756) 'üyelik değişti' der; bir sonraki ilgili 4624 ile eşleşen 4627 ise logon token'ındaki GroupMembership SID'lerini gösterir. Bu snapshot'ın hedef kaynağa erişim verip vermediği ayrıca DACL'deki ilgili ACE ve diğer access check koşullarına bağlıdır.
Bu okuma aynı zamanda yanlış alarmları da azaltır: değişiklik yapıldı ama etkilenen kullanıcı henüz yeniden logon olmadıysa erişim hâlâ eski token'a bağlıdır. 4627 snapshot'ı, 'kağıt üstündeki üyelik' ile 'token'daki etkili üyelik' arasındaki farkı kanıta bağlar.
Detection logic · XPath
*[System[EventID=4732] and EventData[Data[@Name='TargetSid']='S-1-5-21-1002233445-2244556677-3366778899-3220']]Query assumptions
- İfade tek bir Windows Event Log belgesinde, belirli bir yüksek değerli domain local grubun (burada DL-Atlas-Share-RW, RID 3220) üyeliğine yapılan eklemeleri 4732 üzerinden seçer; çok-host korelasyonu yapmaz.
- Named-field seçimi yalnız EventData/Data/@Name değerleri TargetSid/MemberSid adlarıyla düzleştiriliyorsa çalışır; SIEM'in alan eşlemesi doğrulanmalıdır.
- 4732 domain controller ve ilgili sunucularda üretilir; alarmın anlamlı olması için hangi grup SID'lerinin 'yüksek değerli' olduğu bir envanterle önceden tanımlanmalıdır.
- Sorgu bu oturumda gerçek bir DC veya SIEM üzerinde çalıştırılmadı; eşik, veri kümesi ve zaman penceresi yoktur.
False positives
- Meşru rol atamaları ve onboarding sırasında gruplara üye eklenmesi beklenen ve sık bir işlemdir; tek 4732 kötü niyet göstermez.
- Kimlik yönetimi/otomasyon araçları toplu üyelik değişikliği yaparak çok sayıda 4732 üretebilir; bunları benign baseline olarak ayırmak gerekir.
- Bağlam (kim ekledi, hedef grubun taşıdığı hak, eklenen principal'ın ayrıcalığı) olmadan olay zayıf sinyaldir.
- Olayın yokluğu güvenlik değil; Audit Security Group Management alt kategorisi kapalıysa değişiklik hiç kaydedilmez.
Hardening
- Grup üyeliğini değiştirebilen principal'ları least-privilege ile sınırla; özellikle kaynak taşıyan domain local ve universal grupların üyeliğini kimlerin değiştirebildiğini envanterle ve azalt.
- AGDLP disiplinini uygula: izinleri doğrudan hesaplara veya global gruplara değil, yalnız domain local gruplara ver; böylece 'kaynağın kapısı' tek ve denetlenebilir bir katmanda kalır.
- Yüksek değerli domain local/universal grupların nested üyeliğini düzenli gözden geçir; beklenmeyen transitif zincirleri (ör. geniş bir global grubun ayrıcalıklı bir kaba bağlanması) tespit et.
- 4728/4732/4756 üyelik değişimlerini yüksek değerli gruplar için özel izle; kontrolü uygulamadan önce pilot kapsamda gürültü ve etki ölç, geri dönüş planı tut.
Örnekler üzerinde oku / Read the examples
ÖRNEĞİ BİRLİKTE OKUYALIM
EĞİTİM İÇİN HAZIRLANDIKim, hangi gruba, hangi üyeyi eklemiş?
Event 4732 · global grubun domain local gruba nested edilmesi
DC01.outreason.exampleGrup değişikliğini yazan DC. Kaynak sunucudaki yeni token veya dosya erişimi burada gösterilmiyor.
S-1-5-21-1002233445-2244556677-3366778899-3105Bu sentetik örnekte Global grubun SID’i. İşlemi yapan kullanıcının SID’i değildir.
S-1-5-21-1002233445-2244556677-3366778899-3220Bu örnekte izin için kullanılan Domain Local grubun SID’i. Bu alan tek başına grubun resource ACE’sini göstermez.
busraSubjectUserName değişikliği yapan hesabı gösterir; MemberSid eklenen principal’ı gösterir.
4732, Global grubun Domain Local gruba eklenmesini gösterir. Üyelik kaydı, yeni token’da DL SID’i bulunduğunu veya share/NTFS erişiminin verildiğini kanıtlamaz.
Alan seçimi yalnız değişmemiş sentetik örneğe aittir. Ham kaydı değiştirirsen genel alan okumasına dönülür; gerçek event-log veya directory sorgusu çalışmaz.
Bu örneğin kapsamı
Sentetik ve parser tarafından ayrıştırılabilir bir Windows Event XML'idir; gerçek bir olaydan alınmamıştır. EventID 4732 (A member was added to a security-enabled local group) alan adları Microsoft'un yayımladığı şemadan kullanılmıştır. Öğretici nokta AGDLP zincirinin 'G→DL' adımıdır: MemberSid RID 3105 bir global grubun (GG-ProjectAtlas), TargetSid RID 3220 ise bir domain local grubun (DL-Atlas-Share-RW) SID'idir; yani bir global grup, kaynağın izin kabı olan domain local gruba nested edilmiştir. SubjectUserSid RID 1106 değişikliği yapan hesabı verir ve SubjectLogonId ile 4624'e korele edilir. Domain SID 21-1002233445-2244556677-3366778899 ve tüm RID'ler sentetiktir. Parser yalnız Event XML yapısını ve System/EventData alanlarını çıkarır; olayın gerçekten üretildiğini, SID'lerin gerçek bir domain'e ait olduğunu veya erişim sonucunu doğrulamaz.
Ham kaydı aç · EVENT-XML
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}"/><EventID>4732</EventID><Version>0</Version><Level>0</Level><Task>13826</Task><Opcode>0</Opcode><Keywords>0x8020000000000000</Keywords><TimeCreated SystemTime="2026-09-29T07:14:05.120043800Z"/><EventRecordID>482913</EventRecordID><Correlation/><Execution ProcessID="512" ThreadID="1180"/><Channel>Security</Channel><Computer>DC01.outreason.example</Computer><Security/></System><EventData><Data Name="MemberName">CN=GG-ProjectAtlas,OU=Groups,DC=outreason,DC=example</Data><Data Name="MemberSid">S-1-5-21-1002233445-2244556677-3366778899-3105</Data><Data Name="TargetUserName">DL-Atlas-Share-RW</Data><Data Name="TargetDomainName">OUTREASON</Data><Data Name="TargetSid">S-1-5-21-1002233445-2244556677-3366778899-3220</Data><Data Name="SubjectUserSid">S-1-5-21-1002233445-2244556677-3366778899-1106</Data><Data Name="SubjectUserName">busra</Data><Data Name="SubjectDomainName">OUTREASON</Data><Data Name="SubjectLogonId">0x3f8a1</Data><Data Name="PrivilegeList">-</Data></EventData></Event>İki yanlış kanı / Two reality checks
- Sanılan: Bir kullanıcıyı bir gruba eklediğim anda onun açık oturumundaki erişimi de anında değişir.
- Gerçekte: Mevcut process token’ı, directory üyeliği değişince geriye dönük yeniden yazılmaz. Kerberos tarafında da herhangi bir “yeni ticket” yeterli değildir: eski TGT’den alınan service ticket eski PAC/group snapshot’ını taşıyabilir. Güncel grup bilgisiyle alınan veya yenilenen TGT ile mevcut process token’ı ve açık resource session’ı farklı kayıtlardır. Yeni ticket almak eski token’ı güncellemez; kullanılan session’ın yeniden kurulması da gerekebilir. İlgili 4624/4627 çifti, o hosttaki logon’un grup snapshot’ını incelemeye yardım eder.
- Sanılan: Nesting sadece aynı türden gruplar arasında olur; bir global grup bir domain local gruba üye yapılamaz.
- Gerçekte: Global → Domain Local nesting AGDLP’nin temelidir. Domain Local, aynı domain’deki başka Domain Local grupları da içine alabilir. Hesap, global ve universal grup üyeleri için uygun trusted-domain bağlamı mümkündür. “Universal kendi içine yalnız aynı forest’tan üye alır” ile “universal başka bir trusted domain’deki Domain Local gruba üye olabilir” farklı yönlerdeki kurallardır. Bu üyeliklerin kaynak iznine etkisi, ilgili token ve resource DACL’iyle birlikte değerlendirilir.
SIRA SENDE
Bu hikâyeyi sen çöz.
Bilgiyi hatırlamaktan bir adım ileri: koşulu değiştir, kanıtı oku, kararın nedenini anlat.
1 / 3 · OLAYLARI SIRALA
AGDLP örneğindeki rol ve kaynak bağıntısını sırala.
- GG-Reports, DL-Reports-Read’e nested edilir.
- Tunahan hesabı GG-Reports’a üye olur.
- Kaynak DACL’i DL-Reports-Read SID’ine ilgili hakkı verir.
Bir ipucu
Üyelik, izin ACE’si değildir.
Cevabın gerekçesini oku
- Tunahan hesabı GG-Reports’a üye olur.
- GG-Reports, DL-Reports-Read’e nested edilir.
- Kaynak DACL’i DL-Reports-Read SID’ine ilgili hakkı verir.
Account → Global → Domain Local → Permission ilişkisinde rol üyeliği ile kaynak ACE’si farklıdır. Gerçek karar kullanılan token ve requested right ile verilir.
2 / 3 · KANITI OKU
Bu tablo reports dosyasına WRITE başarısını kanıtlar mı?
- Resource
- FS01 reports share / q3.xlsx file
- Share check
- Share READ allowed; share WRITE not observed
- NTFS WRITE check
- not observed
- Requested file right
- WRITE
Bir ipucu
İstenen WRITE için share ve NTFS iki ayrı izin katmanıdır.
Cevabın gerekçesini oku
Hayır; share WRITE ve NTFS WRITE sonuçları ikisi de ayrıca gerekir.
Doğru. WRITE erişimi için share ve NTFS katmanları birlikte değerlendirilir; burada yalnız share READ başarısı gösterilmiş.
3 / 3 · KENDİN ANLAT
Tunahan GG-Reports’tan çıkarıldı; eski token neden aynı SID kümesini taşıyabilir?
Bir ipucu
Directory zinciri ile oluşturulmuş context’in zamanı.
Cevabın gerekçesini oku
Üyelik kaldırma directory zincirini değiştirir; mevcut token geriye dönük yeniden yazılmaz. Eski TGT/PAC, yeni target context ve açık FS01 session’ı da ayrı kayıtlardır; kullanılan context’in gerçekten yenilendiği ayrıca gözlenmelidir.
- Eski token’ın snapshot olduğunu belirttim.
- Yeni ticket veya yeni directory görünümünü eski session yerine koymadım.
Açıklaman otomatik puanlanmaz. Kontrol noktalarını kendi cevabınla karşılaştır.
Vaka terminalini aç · PowerShell / CMD
Eğitim simülasyonu · Komutlar ve çıktılar bu vakaya aittir.
FS01 üzerindeki dosyanın DACL kaydını oku; etkin erişim hesabı ayrıca değerlendirilir.
Hazır script’i değiştirmeden çalıştırabilir veya aşağıdaki günlük komutları deneyebilirsin.
Ctrl / ⌘ + Enter: çalıştır · Shift + Enter: yeni satır
PS C:\Users\tunahan>
Uzun çıktı: terminalin içinde kaydırarak devamını oku.
Merak edersen: günlük komutları dene
Bir komuta dokun, sonra Çalıştır’a bas. Kullanıcı ve ağ bilgileri seçili örnek bilgisayara göre değişir.
Bu oturumdaki son komutlar
Bu pratikler öğrenme amaçlıdır; sertifika sınavının puanını etkilemez.
Kaynaklar / Sources
- Microsoft · Active Directory Security Groups
Security vs distribution groups; Group scope tablosu (Universal/Global/Domain Local: possible members, can grant permissions, possible member of); security groups DACL'lerde listelenir - Microsoft · Access tokens
Access token kullanıcı ve grup SID'lerini içerir; token logon sırasında oluşturulur ve access check bu SID kümesini kullanır - Microsoft · Security identifiers
Well-known SID'ler: Domain Users (RID 513), Built-in gruplar S-1-5-32 (ör. Users 545); domain SID + RID yapısı - Microsoft · 4732(S) A member was added to a security-enabled local group
Event XML ve EventData alanları (MemberName, MemberSid, TargetUserName, TargetDomainName, TargetSid, Subject* ); Audit Security Group Management alt kategorisi; Version 0 - Microsoft · 4627(S) Group membership information
4624 ile birlikte üretilir; GroupMembership token grup SID'lerini listeler; Audit Group Membership + Audit Logon Success gerekir; Min OS Windows Server 2016/Windows 10; EventIdx/EventCountTotal - Microsoft · Audit Security Group Management
Grup üyeliği değişim olaylarının (4728/4729/4732/4733/4756/4757) bağlı olduğu alt kategori - Microsoft · Audit Group Membership
Audit Group Membership Success ve Audit Logon gereksinimi; event'in logon session'ın oluşturulduğu computer'da üretilmesi; interactive/network logon için host konumu - Microsoft · Nested Groups
Native-mode Domain Local nesting and trusted-domain universal membership - Microsoft · User Security Attributes
primaryGroupId, memberOf, tokenGroups - Microsoft · Group membership changes over VPN
TGT and derived service ticket snapshot; existing resource sessions - Microsoft · Remote effective permissions
Share and file-system checks - Microsoft · Grant-SmbShareAccess
ShareAccessRight values Read, Change, Full