Hacker Directory — Understand what you hack.Hacker Directory — Understand what you hack.
Öğrenmeye devam et
EN
İçindekiler15 bölüm · 82 ders
DERS 05.01DERİN TEKNİK İNCELEME

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ışı

  1. Yönetici u.tunahan hesabını GG-ProjectAtlas global grubuna ekler (rol ataması).
  2. GG-ProjectAtlas, aynı domain’deki DL-Atlas-Share-RW grubuna üye yapılır. Bu nesting izin ataması değildir.
  3. 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.
  4. 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.
  5. 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.
  6. 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 HAZIRLANDI

Kim, hangi gruba, hangi üyeyi eklemiş?

Event 4732 · global grubun domain local gruba nested edilmesi

01
Kaydın hostuDC01.outreason.example

Grup değişikliğini yazan DC. Kaynak sunucudaki yeni token veya dosya erişimi burada gösterilmiyor.

02
Eklenen üyeS-1-5-21-1002233445-2244556677-3366778899-3105

Bu sentetik örnekte Global grubun SID’i. İşlemi yapan kullanıcının SID’i değildir.

03
Üyeliği değişen grupS-1-5-21-1002233445-2244556677-3366778899-3220

Bu örnekte izin için kullanılan Domain Local grubun SID’i. Bu alan tek başına grubun resource ACE’sini göstermez.

04
İşlemi yapan hesapbusra

SubjectUserName değişikliği yapan hesabı gösterir; MemberSid eklenen principal’ı gösterir.

Buradan çıkaracağın fikir

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.

  1. GG-Reports, DL-Reports-Read’e nested edilir.
  2. Tunahan hesabı GG-Reports’a üye olur.
  3. Kaynak DACL’i DL-Reports-Read SID’ine ilgili hakkı verir.

Bir ipucu

Üyelik, izin ACE’si değildir.

Cevabın gerekçesini oku
  1. Tunahan hesabı GG-Reports’a üye olur.
  2. GG-Reports, DL-Reports-Read’e nested edilir.
  3. 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ı?

Yeni sentetik pratik örneği; ders artifact’inden bağımsızdır.
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 cevap seç

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.

FS01 · Windows PowerShell 5.1ÖRNEK OTURUM
IYELABS\tunahanstudent0501 · ders çalışma alanı

Ctrl / ⌘ + Enter: çalıştır · Shift + Enter: yeni satır

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 pratikler öğrenme amaçlıdır; sertifika sınavının puanını etkilemez.

Kaynaklar / Sources