GPO neden uygulanmadı? Resultant policy, yenileme, sürüm ve kanıt okuma.

1. Core Mechanism / Temel mekanizma

Group Policy teşhisinde üç soru birbirinden ayrılır: hedef GPO için kapsamda mı, istemci GPO'nun AD tarafındaki Group Policy Container (GPC) ile SYSVOL içindeki Group Policy Template (GPT) kopyasını okuyup aynı sürümde mi görüyor, yoksa seçilen ayarı ilgili client-side extension (CSE) işlerken mi hata alıyor? Bu ders bu kanıt zinciriyle sınırlıdır; link sırası ve loopback 09.02'de, düzenleme/link izinleri 09.03'te anlatılır.

Arabirimler ve belirtimler

• GPC, Active Directory'de GPO kimliği ve özelliklerini; GPT ise SYSVOL'da policy dosyalarını taşır. Bir GPO iki depodan oluşur; yalnız birini kontrol etmek dağıtım kanıtı değildir.
• Kapsam kararı OU/link, security filtering, WMI filter, GPO ve Computer/User Configuration durumuna bağlıdır. Bir GPO'nun uygulanabilir listede olmaması ile CSE hatası farklı dallardır.
• Group Policy istemcisi arka planda yenilenir; gpupdate yalnız istemcinin işleme isteğini tetikler. DC/SYSVOL replikasyonunun yakınsadığını veya bir CSE'nin ayarı uyguladığını garanti etmez.
• Resultant Set of Policy ve gpresult, istemcinin değerlendirdiği sonuç için kanıttır. Ayrı bir ayarın işlenmesi, hata kodu veya reboot/logoff gereksinimi için CSE ve ilgili günlük kanıtı gerekir.

Önce sonucu sınıflandır

“GPO uygulanmadı” ile başlanmaz; önce hedefin GPO'nun kapsamına girip girmediği belirlenir. Hedef OU'da olmayabilir, link devre dışı olabilir, security veya WMI filter geçmeyebilir ya da doğru Computer/User yarısı kapalı olabilir. Bu dallardan biri doğruysa yenileme veya dosya erişimi aramak yanlış katmanda teşhistir.

Kapsama giren GPO için ikinci soru dağıtımdır: istemcinin kullandığı DC'de GPC okunabiliyor mu, karşılık gelen GPT SYSVOL üzerinden erişilebilir mi ve iki taraftaki sürüm mantıklı mı? GPC/GPT ayrımı önemlidir; AD replikasyonu ile SYSVOL replikasyonu ayrı gözlem yüzeyleridir. Aynı GPO adı tek başına iki kopyanın güncel olduğunu kanıtlamaz.

Sürüm bir eşleştirme kanıtıdır

GPO düzenlendiğinde istemci yalnız başlığı değil, değişiklik bilgisini ve ilgili policy tarafını değerlendirir. Bu nedenle vaka kaydında GPO GUID'i, hedef, kullanılan DC, GPC/GPT sürüm gözlemi, son başarılı işleme zamanı ve beklenen ayar ayrı alanlar olmalıdır. “SYSVOL var” veya “AD'de GPO var” gibi tek bir gözlem, sürüm uyumunun yerine geçmez.

Bir sürüm farkı görüldüğünde hemen tek bir kök neden ilan edilmez. İstemci farklı bir DC'ye yönelmiş olabilir, AD veya SYSVOL kopyası henüz yakınsamamış olabilir ya da erişim/ağ sorunu GPT'nin okunmasını engelliyor olabilir. Kanıt, hangi DC ve hangi kopya görüldüğünü zamanla bağlamalıdır.

GPO version’ının user ve computer kısımları ayrıdır: üst16 bit user, alt16 bit computer version’ını taşır. Bu Folder Redirection karşılaştırması GPC ve GPT’nin user kısmıyla ilgilidir. Yalnız computer kısmındaki artış yeni user ayarını göstermez; iki version kısmı da CSE veya local ayar başarısı kanıtı değildir.

Refresh ile işleme sonucunu ayır

Arka plan refresh ya da gpupdate, istemciyi politika işleme döngüsüne sokar; bir dağıtım onarım komutu değildir. İstemci kapsamda olmayan bir GPO'yu refresh sonrasında da uygulamaz. Benzer biçimde, GPC/GPT erişimindeki veya replikasyondaki arıza sürüyorsa ek refresh yalnız aynı koşulu yeniden dener.

GPO raporda listelenebilir ama ayar hedef durumda olmayabilir. Preferences için item-level targeting ve item action, policies için ilgili CSE'nin davranışı, ayrıca restart veya logoff gereksinimi sonucu değiştirir. Bu yüzden resultant listesi, GroupPolicy günlükleri ve ayarın hedefteki doğrulaması üç farklı kanıt türüdür.

Seçilmiş GPO henüz işlenmemiş olabilir

Aynı kullanıcı, aynı GPO ve eşleşen GPC/GPT sürümlerini sabit tutalım. Değişen yalnız processing zamanı olsun. Folder Redirection, normal background refresh’te işlenmez; user logon sırasında foreground processing gerektirir. GPO’nun kapsamda olması ve dosyalarının erişilebilirliği, bu extension’ın background’da uygulanmasını sağlamaz.

Foreground’a geçince yalnız “bu aşamada işlenebilir” sonucuna ulaşırız. Delivery koşulu eksikse veya CSE başarısızsa ayarın uygulandığını söyleyemeyiz. Synchronous/asynchronous davranışı, extension ve ilgili policy’ye göre değerlendirilir; bütün extension’ları aynı kabul etmeyiz. Karşılaştırmada foreground seç; ardından delivery failure seç. Scope ve version aynı kalırken uygulama kanıtının neden değiştiğini açıkla.

Durum ve veri akışı

1. Önce User-A için scope ve filtering sonucunu oku. Kapsam dışı GPO’yu refresh uygulayamaz.
2. Aday GPO’nun GUID’ini ve istemcinin baktığı DC-B’yi sabitle; farklı kopyaları aynı kayıt sanma.
3. GPC ile GPT user version’larını ayrı oku. Bu Folder Redirection örneği user policy yarısını karşılaştırır.
4. Version farkı delivery araştırmasına işaret eder; tek başına CSE failure değildir. Eşleşme de ayarın uygulandığını kanıtlamaz.
5. Background ile user-logon foreground’u karşılaştır. Folder Redirection foreground ister; uygun aşama yalnız bir önkoşuldur.
6. CSE işleme kanıtını oku. Gözlenmemiş sonucu başarı veya failure diye doldurma.
7. Configured ayar ile gözlenen local sonucu karşılaştır. Refresh, scope/delivery onarımı veya ayar sonucu kanıtı değildir.

2. Exploitation / İstismar

Broken trust assumption

Merkezi bir GPO'nun hedefe ulaştığı ve ayarın hedefte etkin olduğu varsayımı; GPC ve GPT'nin aynı DC görünümünde erişilebilir ve güncel kabul edilmesidir.

Technical prerequisites

• Hedef bilgisayar veya kullanıcı ilgili GPO'nun kapsamına girer; link, filtering ve configuration yarısı beklenen biçimdedir.
• İstemci, GPO için kullandığı DC'ye ve GPT'nin SYSVOL yoluna erişebilir; aradaki AD/SYSVOL replikasyon görünümü yakınsamış veya ölçülmüştür.
• İlgili CSE ve ayarın kendi önkoşulları (örneğin logoff/restart veya item-level targeting) ayrıca sağlanır.

Exploitation mechanism / İstismar mekanizması

Bu varsayımlardan birini sessizce doğru kabul eden yönetim süreci iki yönde risk yaratır: beklenen koruma uygulanmamışken uygulanmış sanılabilir veya geçici replikasyon/erişim sorununda gereksiz geniş kapsamlı değişiklik yapılabilir. Güvenlik açısından kritik olan, GPO adına değil hedefte doğrulanmış ayara ve onu taşıyan kanıt zincirine güvenmektir.

Koruma adı ile etkin koruma aynı değildir

Bir hardening GPO'sunun GPMC'de görünmesi, hedefte korumanın etkin olduğu anlamına gelmez. Kapsam dışı hedef, eski GPT kopyası veya CSE'nin atladığı item aynı adlı GPO'nun farklı fiilî sonuç üretmesine yol açabilir. Bu boşlukta karar verici yalnız merkezi tanıma bakarsa gerçek attack surface'i olduğundan küçük görür.

Bu ders bir bypass tarifi değildir. Savunma açısından çıkarım şudur: kritik ayarlarda GPO kimliğini, hedef popülasyonunu ve hedefteki fiilî ayarı birlikte doğrulamak gerekir. Tek bir “başarılı refresh” ifadesi üç kanıtın yerini tutmaz.

Kısmi yakınsama yanlış müdahaleye götürür

GPC/GPT veya farklı DC görünümleri arasında fark görüldüğünde tüm GPO'yu silmek, linki genişletmek ya da filtreyi kaldırmak güvenli ilk hamle değildir. Bu işlemler arızayı maskeleyebilir ve daha geniş bir hedef kümesine istenmeyen ayar dağıtabilir.

Daha dar yaklaşım, kullanılan DC'yi ve zaman damgasını korumak; AD ile SYSVOL gözlemlerini ayırmak; sonra CSE hatasını ayrı kanıtla incelemektir. Böylece bir dağıtım problemi yetkilendirme veya politika tasarımı problemi diye yanlış etiketlenmez.

Bu örneğin risk sınırı

Bir GPO’nun seçildiğini korumanın uygulandığına eşitlemek, saldırı olmasa da koruma boşluğu yaratabilir. Bu belirtiyi tek başına malicious GPO olarak etiketleme.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Vaka kaydında GPO display name yerine GUID, hedef kullanıcı/bilgisayar, OU yolu, kullanılan DC, GPC ve GPT erişim/sürüm gözlemi, son işleme zamanı ve beklenen ayar tutulmalıdır.
• Resultant policy raporu kapsam/değerlendirme kanıtıdır; GroupPolicy Operational günlüğü işleme yolunu, ayarın hedefteki durumu ise fiilî sonucu gösterir. Üçü aynı tür kanıt değildir.
• AD replikasyonu ile SYSVOL replikasyonunu tek bir “GPO replike oldu” cümlesinde birleştirme. Birden fazla DC varsa gözlemi DC adı ve zamanıyla ilişkilendir.

Events and relevant fields

• Group Policy olayları CSE işleme ve hata bağlamı sağlayabilir; tek bir Event ID, GPO kapsamını ve ayarın hedefteki sonucunu tek başına kanıtlamaz.
• gpresult/RSOP çıktısında listelenen applied veya denied GPO, kapsam kararını araştırmak için başlangıç kanıtıdır; GPT dosya sürümünün ya da ayar sonucunun kopyası değildir.
• SYSVOL erişim hatası incelenirken dosya yolu, kullanılan DC, ağ/kimlik bağlamı ve aynı GPO'nun AD tarafındaki GPC gözlemi birlikte tutulmalıdır.

Triage sırası bir veri modeli olsun

Blue ekip için iyi bir kayıt “policy bozuk” değildir. Hedef, GPO GUID'i, scope sonucu, kullanılan DC, GPC/GPT gözlemi, sonuç raporu, CSE olayı ve hedefte ölçülen ayar ayrı sütunlardır. Bu yapı farklı ekiplerin aynı kelimeyle farklı katmanı kastetmesini engeller.

Özellikle sürüm iddiası zaman bağlamı olmadan saklanmamalıdır. Aynı anda farklı DC'lerden alınmış iki gözlem, replikasyon ya da locator farkını açıklayabilir; bunları tek istemci denemesinin sonucu gibi karşılaştırmak yanlış kök neden üretir.

Kanıt zincirini kapat

Kritik kontrol için minimum zincir şöyledir: hedef kapsamda mı, istemci doğru ve erişilebilir GPC/GPT çiftini mi gördü, ilgili CSE işlemi ne söyledi, hedefte ayar gerçekten ne durumda? Her halka farklı bir soruyu yanıtlar.

Bu zincir başarısız olduğunda olaydan doğrudan saldırı veya yapılandırma hatası sonucu çıkarılmaz. Önce eksik kanıt tanımlanır; sonra en dar doğrulama yapılır. Böylece hem yanlış pozitif müdahale hem de uygulanmamış korumayı başarı sanma riski azalır.

Değişiklik sonrası doğrulama

Scope, GPC/GPT, processing zamanı, extension sonucu ve hedefteki gerçek ayarı sırayla doğrula. Background ve foreground gözlemlerini aynı test sonucu gibi toplama.

Detection logic · XPath

*[System[Provider[@Name='Microsoft-Windows-GroupPolicy']]]

Query assumptions

• Bu XPath yalnız GroupPolicy sağlayıcısına ait olayları seçmek için örnek bir başlangıçtır; belirli Event ID veya EventData alan şeması iddia etmez.
• Olayların kanalı, sürümü ve CSE bağlamı Windows sürümüne ve işlenen policy türüne göre değişebilir; olayı gpresult ve GPC/GPT gözlemiyle ilişkilendirmek gerekir.
• Sorgu canlı bir Windows ortamında çalıştırılmadı; ders artifact'i gerçek Windows logu değildir.

False positives

• Rutin background refresh, policy değişikliği veya hedefin normal kapsam değişimi GroupPolicy olayları üretebilir; tek başına arıza değildir.
• Bir GPO'nun denied görünmesi saldırı göstergesi değildir; security filtering veya WMI filter tasarım gereği böyle bir sonuç üretebilir.
• Negatif örnek: GPO listede görünür ve olay hatasızdır, fakat ayarın kendi restart/logoff veya preference targeting koşulu sağlanmamıştır; bu sorgu fiilî sonucu söylemez.

Hardening

• Kritik GPO'lar için hedef popülasyonu, GPO GUID'ini, beklenen ayarı ve hedef doğrulama yöntemini değişiklik kaydına ekle; display name tek kimlik değildir.
• AD ve SYSVOL sağlık/erişim kontrollerini ayrı sinyal olarak izle; DC adı ve zaman bağlamı olmayan “replikasyon tamam” ifadesini kabul etme.
• Değişiklik sonrasında örnek hedeflerde resultant policy ile hedefteki ayarı ayrı doğrula; gereken restart/logoff ve CSE koşullarını yayımla.
• Filter veya link genişletmeden önce denied/failed kararının hangi katmanda verildiğini kanıtla; geniş kapsamlı düzeltmelerin blast radius'unu sınırlı tut.
• GroupPolicy günlükleri için uygun saklama ve merkezileştirme kararı ver; yüksek hacimli rutin refresh kayıtlarını olay bağlamı olmadan alarm olarak kullanma.

Örnekler üzerinde oku / Read the examples

O:SYG:SYD:(A;;GR;;;AU)(A;;GA;;;BA)

{
  "kind": "teaching-record",
  "synthetic": true,
  "scenario": "E04",
  "GPO": "toy-GPO-9",
  "extension": "Folder Redirection",
  "scope": "allowed",
  "versionMatched": true,
  "clientA": {
    "phase": "user-logon foreground",
    "extensionProcessingEligible": true
  },
  "clientB": {
    "phase": "background refresh",
    "extensionProcessingEligible": false
  },
  "settingEffect": "Not inferred solely from processing eligibility",
  "versionScope": "user policy",
  "GPC": {
    "rawVersion": 524291,
    "userVersion": 8,
    "computerVersion": 3,
    "DC": "DC-B",
    "observedAt": "T0 / synthetic observation"
  },
  "GPT": {
    "rawVersion": 524291,
    "userVersion": 8,
    "computerVersion": 3,
    "DC": "DC-B",
    "observedAt": "T0 / synthetic observation"
  }
}

İki yanlış kanı / Two reality checks

Sanılan: gpupdate çalıştıysa GPO dağıtımı ve bütün ayarlar kesin olarak başarılıdır.

Gerçekte: Hayır. Refresh, istemcinin Group Policy işleme döngüsünü istemesidir; hedef kapsam dışı olabilir, GPC/GPT kopyası erişilemeyebilir veya güncel olmayabilir, ayrıca CSE ya da ayarın restart/logoff gibi kendi koşulu sonuç üretmeyebilir. Kapsam, dağıtım/versiyon ve işleme/fiilî ayar ayrı kanıtlarla doğrulanmalıdır.

Sanılan: gpresult'ta bir GPO'nun applied görünmesi, o GPO içindeki her ayarın hedefte etkin olduğunu kanıtlar.

Gerçekte: Hayır. Resultant policy raporu değerlendirme sonucuna dair güçlü bir işarettir, ancak CSE'nin her ayarı işlediğini, preference item-level targeting'in geçtiğini veya hedefte gereken restart/logoff'un yapıldığını tek başına söylemez. Sonuç raporu, GroupPolicy işleme bağlamı ve hedef ayar doğrulaması birlikte okunmalıdır.

Kaynaklar / Sources

• Microsoft · Group Policy processing for Windows
  GPO bileşenleri, işleme sırası, GPO/Computer/User Configuration disable durumu, security filtering, WMI filter ve client-side extension işleme bağlamı.
• Microsoft · Group Policy overview
  GPO'nun Active Directory ve SYSVOL bileşenleri; istemci işleme ve yönetim kavramları.
• AD DS replication behavior
  Replication behavior overview
• MS-GPOL Glossary
  User upper16 / computer lower16 version parts
• MS-GPOL Version Number Update
  Both GPC and GPT corresponding policy parts updated