Merhaba

Bölüm 3‘te bir GPO’nun (Group Policy Object) hangi sırayla işlendiğini ve çakışmada hangisinin kazandığını gördük. Ancak tüm bu kuralların temelinde tek bir varsayım vardı: GPO’yu bir OU’ya (Organizational Unit) link ettiğimizde, o OU’daki her kullanıcıya ve bilgisayara uygulanır. Gerçek hayatta bu çoğu zaman yeterli değildir. Satış OU’sundaki kullanıcıların yalnızca bir kısmına kısıtlama uygulamak, bir ayarı yalnızca Windows 11 makinelere göndermek ya da bir kiosk bilgisayarında oturum açan herkese, hangi OU’dan gelirse gelsin, aynı kullanıcı ayarlarını vermek isteyebiliriz.

Bu bölümde link’in kapsamını daraltan ve değiştiren üç mekanizmayı ele alıyoruz: GPO’yu belirli kullanıcı, grup ya da bilgisayarlarla sınırlayan Security Filtering, istemcide bir WMI (Windows Management Instrumentation) sorgusuna göre karar veren WMI Filtering ve kullanıcı ayarlarının kullanıcının değil bilgisayarın konumuna göre uygulanmasını sağlayan Loopback Processing. Security Filtering başlığında, 2016’dan beri pek çok ortamda GPO’m neden uygulanmıyor sorusunun cevabı olan MS16-072 güncellemesinin getirdiği değişikliği de lab’da bilerek bozarak ve düzelterek göreceğiz.

1. Security Filtering: GPO’yu Kime Uygulayacağız?

Bir GPO’nun bir kullanıcıya ya da bilgisayara uygulanabilmesi için iki şart vardır: GPO o nesnenin bulunduğu konteynere (ya da üstüne) link edilmiş olmalı ve nesnenin GPO üzerinde iki izni olmalıdır.

Varsayılan olarak her yeni GPO’da Authenticated Users grubu bu iki izne birlikte sahiptir. Authenticated Users, domain’de kimliği doğrulanmış tüm kullanıcıları ve bilgisayar hesaplarını kapsar. Bu yüzden link ettiğimiz her GPO, link’in kapsamındaki herkese uygulanır.

GPMC’de (Group Policy Management Console) bir GPO’nun Scope sekmesindeki Security Filtering bölümü, Apply Group Policy iznine sahip olanları gösterir. Bu listeye bir grup eklediğimizde GPMC arka planda o gruba hem Read hem Apply Group Policy izni verir. Listeden Authenticated Users’ı çıkarıp yerine belirli bir güvenlik grubu koyduğumuzda, GPO yalnızca o grubun üyelerine uygulanır.

Security Filtering link’in yerini tutmaz, onu daraltır. Grubun üyesi olan ama link kapsamının dışında, örneğin başka bir OU’da duran bir kullanıcıya GPO yine uygulanmaz.

MS16-072: Security Filtering’in sessizce bozulması

Haziran 2016’da yayımlanan MS16-072 (KB3163622) güvenlik güncellemesi, istemcinin kullanıcı GPO’larını okuma şeklini değiştirdi. Güncellemeden önce istemci, kullanıcıya ait GPO’ları kullanıcının kendi kimliğiyle okuyordu. Ağ trafiğini araya girerek (man-in-the-middle) değiştirebilen bir saldırganın istemciye sahte GPO verebildiği bir açık nedeniyle Microsoft bu davranışı değiştirdi: artık kullanıcı GPO’ları da bilgisayar hesabının kimliğiyle okunur.

Bunun pratik sonucu şudur: Security Filtering’de Authenticated Users’ı kaldırıp yalnızca bir kullanıcı grubu bıraktığımızda, bilgisayar hesabının GPO üzerinde Read izni kalmaz. İstemci GPO’yu okuyamaz ve GPO, grubun üyesi olan kullanıcıya bile uygulanmaz. Hiçbir hata mesajı da çıkmaz.

Çözüm, bilgisayar hesaplarına GPO üzerinde yalnızca Read izni vermektir. Bunu GPO’nun Delegation sekmesinden Authenticated Users ya da Domain Computers grubuna Read izni ekleyerek yaparız. Read izni GPO’nun okunmasını sağlar ama Apply Group Policy olmadığı için GPO’yu herkese uygulamaz. Uygulama kararı hala Security Filtering’deki gruba bağlıdır.

Deny ile hariç tutmak

Security Filtering’in tersi de mümkündür: GPO’yu herkese uygulayıp belirli bir grubu hariç tutmak. Bunun için GPO’nun Delegation sekmesinde Advanced düğmesine tıklayıp ilgili gruba Apply Group Policy: Deny veriyoruz. Deny, Allow’dan önce değerlendirildiği için grubun üyelerine GPO uygulanmaz. Bu yöntem GPMC’nin Scope sekmesinde görünmediği için gözden kaçar. Sorun giderirken Delegation sekmesinin Advanced penceresine bakmayı alışkanlık haline getirmek gerekir.

2. WMI Filtering: İstemcinin Özelliklerine Göre Karar Vermek

Security Filtering kim sorusunu cevaplar. WMI Filtering ise hangi makine sorusunu, istemcinin kendisine bir soru sorarak cevaplar. Bir WMI filtresi, istemcide çalıştırılan bir WQL (WMI Query Language) sorgusudur. Sorgu en az bir sonuç döndürürse filtre doğru kabul edilir ve GPO uygulanır, hiç sonuç döndürmezse GPO uygulanmaz.

Sık kullanılan WMI filtreleri şunlardır:

ProductType değeri 1 iş istasyonu, 2 domain controller, 3 üye sunucu anlamına gelir. Windows 11’in sürüm numarası Windows 10 gibi 10.0 ile başlar, iki işletim sistemini ayıran şey build numarasıdır: Windows 11 build’leri 22000 ve üzeridir. Ancak Windows Server 2022’nin build numarası da 20348 olduğu için 10.0.2% tek başına yeterli değildir. Sorgudaki ProductType = "1" koşulu sunucuları dışarıda bırakır.

WMI filtreleri hakkında bilinmesi gerekenler:

3. Loopback Processing: Kullanıcı Ayarları Bilgisayara Göre

Normalde kullanıcı ayarları (User Configuration) kullanıcının bulunduğu OU’ya göre belirlenir. Satış OU’sundaki bir kullanıcı hangi bilgisayarda oturum açarsa açsın aynı kullanıcı ayarlarını alır. Bazı senaryolarda bu istenen davranış değildir:

• Mağaza ya da lobi kiosk bilgisayarları: oturum açan her kullanıcıya aynı kısıtlı ortam verilmelidir.
• RDS (Remote Desktop Services) sunucuları: sunucuda oturum açan kullanıcılara masaüstü bilgisayarlarındakinden farklı ayarlar gerekir.
• Eğitim ve laboratuvar bilgisayarları: kullanıcının kendi masaüstü ayarları burada istenmez.

Loopback Processing, bilgisayar tarafında açılan bir ayardır ve bu bilgisayarda oturum açan kullanıcılar için, bilgisayarın bulunduğu OU’daki GPO’ların User Configuration ayarlarını da uygula der.

Ayar Computer Configuration > Policies > Administrative Templates > System > Group Policy > Configure user Group Policy loopback processing mode yolunda bulunur ve iki modu vardır:

Loopback’in iki önemli ayrıntısı vardır. Birincisi, Loopback ayarı bilgisayar tarafında olduğu için bilgisayarın bulunduğu OU’ya link edilmiş bir GPO’da açılmalıdır. İkincisi, bilgisayarın OU’sundaki GPO’ların kullanıcı ayarları kullanıcıya uygulanacağı için, bu GPO’larda kullanıcının da Read ve Apply Group Policy izni olmalıdır. Varsayılan Authenticated Users izni bu şartı karşılar, Security Filtering’i bilgisayar grubuyla daraltılmış bir GPO’da ise kullanıcı ayarları uygulanmaz.

4. Uygulama: Lab Ortamında Filtreleme ve Loopback

Bu bölümün uygulama kısmında üç senaryo kuruyoruz:

Loopback GPO’sunun adındaki CU öneki, GPO’nun hem Computer hem User Configuration ayarı içerdiğini gösterir. Bu yüzden bu GPO’da GPO Status ile hiçbir yarıyı devre dışı bırakmıyoruz.

Adım 1: Grubun ve GPO’nun oluşturulması

Security Filtering için yeni bir güvenlik grubu oluşturuyor, test kullanıcımızı bu gruba ekliyor ve Denetim Masası kısıtlamasını içeren GPO’yu oluşturup Satis OU’suna link ediyoruz. Komutları domain controller’da Run as administrator (Yönetici olarak çalıştır) ile açılmış bir PowerShell penceresinde çalıştırıyoruz:

New-ADGroup -Name "GG_Satis_Kisitli" -GroupScope Global -GroupCategory Security -Path "OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech" -Description "Denetim Masası kısıtlaması uygulanan Satış kullanıcıları"
Add-ADGroupMember -Identity "GG_Satis_Kisitli" -Members "nihat.cubuk"

$gpo = New-GPO -Name "U - Satis - Denetim Masasi Kisitlama" -Comment "Bölüm 4 Security Filtering testi"
Set-GPRegistryValue -Name $gpo.DisplayName -Key "HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer" -ValueName "NoControlPanel" -Type DWord -Value 1 | Out-Null
$gpo.GpoStatus = "ComputerSettingsDisabled"
New-GPLink -Name $gpo.DisplayName -Target "OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech" -LinkEnabled Yes

Kendi ortamınıza uyarlarken:

NoControlPanel değeri, User Configuration > Policies > Administrative Templates > Control Panel altındaki Prohibit access to Control Panel and PC settings ayarının registry karşılığıdır. Değer 1 olduğunda kullanıcı Denetim Masası’nı ve Windows Ayarlar uygulamasını açamaz. Bu anahtar Software\Policies altında olmasa da Windows’un eski bir Policy anahtarıdır ve Bölüm 2‘de gördüğümüz tattooing davranışını göstermez, GPO kaldırıldığında temizlenir.

Komutlardan ilk dördü çıktı vermez. Son komut olan New-GPLink, link’in bilgilerini yazar: Target satırında Satis OU’su, Order satırında ise 3 görünür. Satis OU’sunda Bölüm 1 ve Bölüm 2‘den kalan iki GPO bulunduğu için yeni link listenin sonuna, üçüncü sıraya eklendi. Bu GPO’nun ayarı diğer iki GPO ile çakışmadığı için Link Order sonucu etkilemez.

Adım 2: Security Filtering’in yapılandırılması

GPMC’de Group Policy Objects altında U - Satis - Denetim Masasi Kisitlama GPO’sunu seçip Scope sekmesine geçiyoruz. Sekme üç bölümden oluşur: Links bölümü GPO’nun nereye link edildiğini (bakicubuk.tech/LAB/Kullanicilar/Satis), Security Filtering bölümü GPO’nun kime uygulanacağını, en alttaki WMI Filtering bölümü de GPO’ya bağlı bir WMI filtresi olup olmadığını gösterir. Security Filtering bölümünde varsayılan olarak yalnızca Authenticated Users vardır, WMI Filtering bölümünde ise <none> yazar.

Önce grubu ekliyoruz. Security Filtering bölümünün altındaki Add… düğmesine tıklıyoruz. Açılan Select User, Computer, or Group penceresinde From this location alanında domain’imiz (bakicubuk.tech) seçilidir. Enter the object name to select alanına GG_Satis_Kisitli yazıp Check Names düğmesine tıklıyoruz. Ad AD’de (Active Directory) bulunduğunda altı çizili hale gelir. OK diyoruz.

Security Filtering listesinde artık iki kayıt görünür: GG_Satis_Kisitli (BAKICUBUK\GG_Satis_Kisitli) ve Authenticated Users. Bu durumda GPO hala herkese uygulanır, çünkü Authenticated Users listede durduğu sürece grup eklemek kapsamı daraltmaz.

Şimdi listede Authenticated Users satırını seçip Remove düğmesine tıklıyoruz.

GPMC önce Do you want to remove this delegation privilege? sorusuyla silme işlemini onaylamamızı ister. Ekranda delegation privilege ifadesinin geçmesi tesadüf değildir: Security Filtering listesi aslında GPO’nun izin listesinin bir görünümüdür ve buradan bir kaydı silmek, o grubun GPO üzerindeki iznini kaldırmak demektir. OK diyoruz.

Ardından GPMC, MS16-072 ile ilgili bir uyarı penceresi gösterir. Uyarıda, kullanıcı Group Policy ayarlarının uygulanabilmesi için her bilgisayar hesabının GPO verisini domain controller’dan okuma iznine sahip olması gerektiği, Authenticated Users grubunu kaldırmanın kullanıcı GPO’larının işlenmesini engelleyebileceği yazar. Çözüm olarak Domain Computers ya da Authenticated Users grubuna en az salt okunur (read-only) izin verilmesi önerilir ve 1. başlıkta andığımız KB3163622 makalesine bağlantı verilir. Yani GPMC, birazdan yaşayacağımız sorunu bize önceden söylüyor.

Bu uyarıyı bilerek dikkate almıyor ve OK diyoruz, çünkü bir sonraki adımda sorunun kendisini istemcide görmek istiyoruz.

Security Filtering bölümünde artık yalnızca GG_Satis_Kisitli (BAKICUBUK\GG_Satis_Kisitli) grubu görünür.

Aynı işi arayüz yerine PowerShell ile yapmak istersek Set-GPPermission komutunu kullanırız:

Set-GPPermission -Name "U - Satis - Denetim Masasi Kisitlama" -TargetName "GG_Satis_Kisitli" -TargetType Group -PermissionLevel GpoApply
Set-GPPermission -Name "U - Satis - Denetim Masasi Kisitlama" -TargetName "Authenticated Users" -TargetType Group -PermissionLevel None -Replace
Get-GPPermission -Name "U - Satis - Denetim Masasi Kisitlama" -All | Select-Object @{n="Trustee";e={$_.Trustee.Name}}, Permission

Kendi ortamınıza uyarlarken:

İlk komut gruba GpoApply seviyesinde izin verir. Bu seviye Read ve Apply Group Policy izinlerinin ikisini birden içerir, yani Security Filtering listesine eklemenin karşılığıdır. İkinci komut Authenticated Users’ın iznini None seviyesine indirir. -Replace parametresi, mevcut izni yeni seviyeyle değiştirmek için gereklidir, aksi halde komut daha düşük bir seviyeye inmeyi reddeder. Üçüncü komut GPO üzerindeki tüm izinleri listeler ve sonucu kontrol etmemizi sağlar. Lab’da bu adımı arayüzden yaptığımız için bu komutları çalıştırmıyoruz.

Adım 3: MS16-072 sorununun istemcide görülmesi

Test kullanıcısını GG_Satis_Kisitli grubuna yeni eklediğimiz için Windows 11 istemcide nihat.cubuk ile oturumu kapatıp yeniden açıyoruz. Bölüm 2‘de gördüğümüz gibi grup üyeliği oturum açılırken alınan erişim belirtecine yazılır. Ardından normal (yönetici olmayan) bir PowerShell penceresinde şu komutları çalıştırıyoruz:

whoami /groups | findstr GG_Satis_Kisitli
gpresult /r /scope user

Kendi ortamınıza uyarlarken:

whoami çıktısında BAKICUBUK\GG_Satis_Kisitli grubu, SID (Security Identifier) değeri ve Enabled group özelliğiyle görünür, yani kullanıcı grubun üyesi ve Security Filtering şartını karşılıyor. Aynı grup gpresult çıktısının en altındaki The user is a part of the following security groups listesinde de görünür. Buna rağmen Applied Group Policy Objects listesinde yalnızca U - Satis - Ekran Kilidi ve U - Satis - Tercihler vardır, U - Satis - Denetim Masasi Kisitlama yoktur. Daha da dikkat çekici olanı, GPO’nun The following GPOs were not applied because they were filtered out bölümünde de bulunmamasıdır. Bölüm 3’te Block Inheritance ile engellenen GPO’lar en azından bu bölümde Unknown Reason gerekçesiyle listeleniyordu. Burada ise istemci GPO’yu hiç okuyamadığı için onun varlığından bile haberdar değildir ve GPO raporda hiçbir yerde görünmez. MS16-072 sorununu bu kadar sinsi yapan da budur.

Filtered out bölümündeki Local Group Policy satırı bu testle ilgili değildir. Bölüm 3’ün sonunda Local GPO’daki Screen saver timeout ayarını Not Configured yaptığımız için Local GPO’nun kullanıcı tarafında artık hiçbir ayar yoktur ve gpresult onu Not Applied (Unknown Reason) olarak gösterir. Başlat menüsünden Denetim Masası’nı açmayı denediğimizde de normal şekilde açılır.

Sorun kullanıcıda değil bilgisayardadır. MS16-072 sonrası istemci, kullanıcının GPO’sunu bilgisayar hesabının kimliğiyle okumaya çalışır. GPO üzerinde artık yalnızca GG_Satis_Kisitli grubunun izni var ve bilgisayar hesabı bu grubun üyesi olmadığı için GPO’yu okuyamaz.

Adım 4: Delegation sekmesinden Read izninin verilmesi

GPMC’de GPO’yu seçip Delegation sekmesine geçiyoruz. Bu sekme GPO üzerindeki tüm izinleri gösterir: Security Filtering’deki gruplar burada Read (from Security Filtering) olarak görünür. Add… düğmesine tıklıyor, açılan pencereye Authenticated Users yazıp OK diyoruz.

Listede bilgisayar hesaplarını kapsayan bir grubun olmadığına dikkat edelim. Adım 3’te yaşadığımız sorunun nedeni tam olarak budur.

Add… düğmesine tıklıyoruz.

Açılan Select User, Computer, or Group penceresinde Enter the object name to select alanına Authenticated Users yazıp OK diyoruz. Authenticated Users bir AD grubu değil, Windows’un yerleşik bir güvenlik kimliği (built-in security principal) olduğu için Check Names ile altı çizilmese de doğrudan kabul edilir.

Ardından Add Group or User penceresi açılır. Group or user name alanında Authenticated Users görünür.

Permissions açılır listesinde üç seçenek bulunur:

Read seçeneğini seçiyoruz. Diğer iki seçenek GPO’yu düzenleme yetkisi verir ve domain’deki tüm kullanıcılara verilmeleri, Bölüm 1‘in güvenlik başlığında anlattığımız gibi bu GPO’nun kapsamındaki her makinede kod çalıştırma yetkisi vermek anlamına gelir.

Permissions alanında Read seçiliyken OK diyoruz.

Delegation listesinde Authenticated Users artık Read izniyle görünür. Scope sekmesindeki Security Filtering listesine baktığımızda ise Authenticated Users’ın orada olmadığını görürüz. Read izni GPO’nun okunmasını sağlar, uygulanmasını değil. GPO hala yalnızca GG_Satis_Kisitli üyelerine uygulanır.

İstemcide gpupdate /force çalıştırıp gpresult /r /scope user çıktısına yeniden bakıyoruz. Applied Group Policy Objects listesinde artık üç GPO vardır: U - Satis - Ekran Kilidi, U - Satis - Tercihler ve U - Satis - Denetim Masasi Kisitlama. Bilgisayar hesabı Authenticated Users üzerinden GPO’yu okuyabildi, kullanıcı da GG_Satis_Kisitli grubunun üyesi olduğu için GPO uygulandı.

Başlat menüsünden Denetim Masası’nı açmayı denediğimizde Restrictions başlıklı bir pencere çıkar ve This operation has been cancelled due to restrictions in effect on this computer. Please contact your system administrator. mesajını gösterir. Aynı pencere Windows Ayarlar uygulaması açılmaya çalışıldığında da görünür.

Adım 5: WMI filtresinin oluşturulması ve bağlanması

Şimdi aynı GPO’yu yalnızca Windows 11 makinelere uygulanacak şekilde daraltıyoruz. Filtreyi oluşturmadan önce sorgunun istemcide sonuç döndürüp döndürmediğini Windows 11 istemcide test ediyoruz:

Get-CimInstance -Query 'SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.0.2%" AND ProductType = "1"' | Select-Object Caption, Version, ProductType

Kendi ortamınıza uyarlarken:

Çıktıda işletim sisteminin adı (Caption), sürümü ve ProductType değeri 1 görünür. Sorgu sonuç döndürdüğüne göre filtre bu makinede doğru kabul edilecek. Sorgu boş dönseydi GPO bu makineye uygulanmazdı.

GPMC’de sol paneldeki WMI Filters düğümüne sağ tıklayıp New… seçiyoruz.

Açılan New WMI Filter penceresinde Name alanına Windows 11 Istemciler, Description alanına filtrenin amacını yazıyor ve Queries bölümünde Add düğmesine tıklıyoruz.

Açılan WMI Query penceresinde Namespace alanı varsayılan olarak root\CIMv2 gelir. Bu alanın yanındaki Browse… düğmesi, bilgisayardaki diğer WMI namespace’lerini (ad alanlarını) listeler. Windows 11 işletim sistemi bilgisi root\CIMv2 altındaki Win32_OperatingSystem sınıfında durduğu için bu örnekte namespace’i değiştirmiyoruz. Query alanına yalnızca WQL (WMI Query Language) sorgusunu yapıştırıp OK diyoruz:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "10.0.2%" AND ProductType = "1"

Browse ile Görülen Namespace’ler

Browse düğmesine tıkladığınızda çıkan liste Windows sürümüne, yüklü rollere ve özelliklere göre değişir. Sizin listenizde bazıları eksik ya da fazladan başka satırlar olabilir.

Aşağıdaki tablo, Windows 11 ve Windows Server sistemlerinde sık karşılaşılan namespace’leri ve ne işe yaradıklarını özetler:

Özetle, işletim sistemi sürümü, bilgisayar modeli, bellek ya da disk gibi sıradan sorgular için root\CIMv2 seçili kalır. Başka bir namespace seçerseniz, hedef makinelerde o namespace ve içindeki sınıf bulunmalıdır. Bulunmayan bir namespace’e yazılan sorgu hata verir ve WMI filtresi o makinede False sayılır, yani GPO uygulanmaz. Bir sınıfın hangi namespace’te durduğunu önceden test etmek için istemcide şu komut kullanılabilir:

Get-CimInstance -Namespace "root\StandardCimv2" -ClassName "MSFT_NetAdapter" | Select-Object Name, Status

Kendi ortamınıza uyarlarken:

Save ile filtreyi kaydetmeden önce Queries listesinde satırın göründüğünü doğruluyoruz.

Kaydedilen filtre, GPMC’de WMI Filters altında listelenir. Linked GPO sütunu <none> görünür, çünkü filtre henüz hiçbir GPO’ya bağlanmadı. Author sütununda filtreyi oluşturan hesap yer alır.

Filtreyi GPO’ya bağlamak için U - Satis - Denetim Masasi Kisitlama GPO’sunun Scope sekmesinin en altındaki WMI Filtering bölümünde açılır listeden Windows 11 Istemciler filtresini seçiyoruz. Çıkan Would you like to change the WMI filter to Windows 11 Istemciler? onay penceresine Yes diyoruz.

İstemcide gpupdate /force çalıştırıp gpresult /r /scope user çıktısına bakıyoruz. Filtre bu makinede doğru olduğu için GPO uygulanmaya devam eder. Applied Group Policy Objects listesinde U - Satis - Denetim Masasi Kisitlama yine görünür, filtered out bölümünde yalnızca Local Group Policy kalır.

Şimdi filtreyi bilerek bozuyoruz. GPMC’de WMI Filters altında Windows 11 Istemciler filtresini seçip sağ paneldeki Edit Filter… düğmesiyle sorguyu aşağıdaki ile değiştiriyoruz. Query alanını düzenledikten sonra OK, ardından Save diyoruz. Bu sorgu yalnızca üye sunucularda sonuç döndürür.

SELECT * FROM Win32_OperatingSystem WHERE ProductType = "3"

İstemcide tekrar gpupdate /force çalıştırıp gpresult /r /scope user çıktısına bakıyoruz. GPO bu kez Applied Group Policy Objects listesinde değildir. The following GPOs were not applied because they were filtered out bölümünde Filtering: Denied (WMI Filter) gerekçesiyle ve altında WMI Filter: Windows 11 Istemciler satırıyla listelenir. Bölüm 3’te Block Inheritance için gördüğümüz Unknown Reason ifadesinin aksine, gpresult burada gerekçeyi açıkça yazar. Denetim Masası da tekrar açılır.

Testten sonra filtrenin sorgusunu tekrar Windows 11 sorgusuna çeviriyoruz. Filtre ve GPO’yu Adım 7’deki temizlikte birlikte sileceğiz.

Adım 6: Loopback Processing ile kiosk senaryosu

Kiosk senaryosu için Windows 11 istemcimizi Bölüm 1’de oluşturduğumuz Kiosk OU’suna taşıyoruz. Domain controller’da şu komutu çalıştırıyoruz:

Get-ADComputer "W11CLIENT" | Move-ADObject -TargetPath "OU=Kiosk,OU=Bilgisayarlar,OU=LAB,DC=bakicubuk,DC=tech"
Get-ADComputer "W11CLIENT" | Select-Object Name, DistinguishedName

Kendi ortamınıza uyarlarken:

İkinci komutun çıktısında bilgisayarın DN (Distinguished Name) değerinin OU=Kiosk içerdiğini görüyoruz. Kullanıcı nihat.cubuk ise yerinde, Kullanicilar\Satis OU’sunda kalıyor.

Şimdi Loopback GPO’sunu oluşturuyoruz. GPO’yu doğrudan Kiosk OU’suna değil, önce Group Policy Objects konteynerinde oluşturuyor, ayarları yaptıktan sonra OU’ya link ediyoruz. Bu sırayla GPO, yarım ayarlarla istemcilere ulaşmaz. GPMC’de Group Policy Objects konteynerine sağ tıklayıp New seçiyoruz.

Açılan New GPO penceresinde Name alanına CU - Kiosk - Loopback yazıyor, Source Starter GPO alanını (none) bırakıp OK diyoruz.

GPO listede görününce üzerine sağ tıklayıp Edit ile Group Policy Management Editor’ü açıyoruz. GPO Status sütununda Enabled yazar, çünkü CU önekiyle bu GPO’da hem Computer hem User Configuration kullanacağız ve hiçbir yarıyı devre dışı bırakmıyoruz.

Düzenleyicide omputer Configuration > Policies > Administrative Templates > System > Group PolicyC yoluna gidiyoruz. Sağ paneldeki listede Configure user Group Policy loopback processing mode ayarı Not configured durumundadır. Ayara çift tıklıyoruz.

Açılan pencerede ayarı Enabled yapıyor, Mode listesinden Replace seçip Apply ve ardından OK diyoruz.

Pencereyi kapattığımızda ayarın durumu listede Enabled olarak görünür.

Aynı GPO’da bu kez kullanıcı tarafına geçiyoruz: User Configuration > Policies > Administrative Templates > System. Listede Prevent access to the command prompt ayarı Not configured durumundadır. Ayara çift tıklıyoruz.

Ayarı Enabled yapıyor, Disable the command prompt script processing also seçeneğini No olarak bırakıp Apply ve OK diyoruz. Bu seçenek Yes yapılırsa .bat ve .cmd script’leri de çalışmaz, bu da oturum açma script’lerini bozabilir.

Pencereyi kapattığımızda ayarın durumu listede Enabled olarak görünür.

Düzenleyiciyi kapatıp GPO’yu link ediyoruz. GPMC’de LAB > Bilgisayarlar > Kiosk OU’suna sağ tıklayıp Link an Existing GPO… seçiyoruz. Kiosk OU’sunun Linked Group Policy Objects sekmesi bu aşamada boştur.

Açılan Select GPO penceresinde CU - Kiosk - Loopback GPO’sunu seçip OK diyoruz.

Kiosk OU’sunun Linked Group Policy Objects sekmesinde GPO artık Link Order 1, Enforced No, Link Enabled Yes, GPO Status Enabled ve WMI Filter None değerleriyle listelenir.

Bilgisayar yeni bir OU’ya taşındığı ve Loopback bir bilgisayar ayarı olduğu için istemciyi yeniden başlatıyoruz. Bilgisayar açılışta yeni OU’sundaki GPO’ları işler ve Loopback’i etkinleştirir. Ardından nihat.cubuk ile oturum açıyoruz.

Önce kiosk ayarının geldiğini kontrol ediyoruz. Başlat menüsünden Command Prompt‘u açtığımızda pencere açılır ama içinde he command prompt has been disabled by your administrator.T mesajı görünür ve komut yazılamaz. Bu kullanıcı ayarı, kullanıcının kendi OU’sundan değil, bilgisayarın Kiosk OU’sundan geldi.

PowerShell’in hala açıldığına dikkat edelim. Bu ayar yalnızca cmd.exe‘yi engeller. Kiosk senaryosunda PowerShell’i de engellemek için AppLocker ya da App Control for Business gibi uygulama kısıtlama mekanizmaları gerekir.

Açık kalan PowerShell penceresinde gpresult /r /scope user çalıştırıyoruz.

Applied Group Policy Objects listesinde yalnızca CU - Kiosk - Loopback görünür. Local Group Policy ise The following GPOs were not applied because they were filtered out bölümünde Not Applied (Unknown Reason) ile listelenir. Satis OU’sundaki U - Satis - Ekran Kilidi, U - Satis - Tercihler ve U - Satis - Denetim Masasi Kisitlama GPO’ları ise hiçbir bölümde yoktur. Replace modu, kullanıcının kendi OU’sundaki GPO’ları tamamen devre dışı bıraktı. Güvenlik grupları listesinde GG_Satis_Kisitli ve GG_Satis hala görünür, yani kullanıcının grup üyeliği değişmedi, yalnızca hangi GPO’ların işleneceği değişti.

Bunun sonucunu arayüzde de görürüz: File Explorer’da S: sürücüsü yoktur ve Satış departmanına özel diğer ayarlar bu bilgisayarda devre dışı kalmıştır.

Şimdi Merge modunu test ediyoruz. GPMC’de CU - Kiosk - Loopback GPO’sunu düzenleyip Loopback ayarındaki Mode değerini Merge yapıyor, Apply ve OK diyoruz. İstemcide gpupdate /force çalıştırıyor, ardından oturumu kapatıp yeniden açıyoruz.

gpresult /r /scope user çıktısında bu kez hem Satis OU’sunun GPO’ları (U - Satis - Ekran Kilidi, U - Satis - Tercihler, U - Satis - Denetim Masasi Kisitlama) hem de CU - Kiosk - Loopback Applied listesinde görünür. Local Group Policy filtered out bölümünde bu kez iki kez listelenir. İkinci satır, Loopback modunun ikinci işleme geçişinden gelir ve bir sorun değildir. U - Satis - Denetim Masasi Kisitlama Adım 5’te filtreyi geri çevirdiğimiz için filtered out bölümünde görünmez. Görünüyorsa WMI filtresinin sorgusu hala eski haline dönmemiş demektir.

Arayüzde de fark görünür. S: sürücüsü geri gelir, Denetim Masası tekrar kısıtlanır ve komut istemi kısıtlaması da devam eder. Merge modu kullanıcının kendi ayarlarını korudu ve kiosk ayarını bunlara ekledi.

Loopback testinin sonuçlarını özetlersek:

Adım 7: Lab ortamının temizlenmesi

Testi tamamladıktan sonra lab’ı Bölüm 3 sonundaki duruma döndürüyoruz.

Domain controller’da şu komutları çalıştırıyoruz:

Get-ADComputer "W11CLIENT" | Move-ADObject -TargetPath "OU=Satis,OU=Bilgisayarlar,OU=LAB,DC=bakicubuk,DC=tech"
Remove-GPO -Name "U - Satis - Denetim Masasi Kisitlama"
Remove-GPO -Name "CU - Kiosk - Loopback"
Get-ADObject -SearchBase "CN=SOM,CN=WMIPolicy,CN=System,DC=bakicubuk,DC=tech" -Filter 'msWMI-Name -eq "Windows 11 Istemciler"' | Remove-ADObject -Confirm:$false
Remove-ADGroup -Identity "GG_Satis_Kisitli" -Confirm:$false
Get-GPInheritance -Target "OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech"

Kendi ortamınıza uyarlarken:

Komutlar sırasıyla bilgisayarı eski OU’suna geri taşır, iki test GPO’sunu siler, WMI filtresini AD’den kaldırır ve test grubunu siler. GroupPolicy PowerShell modülünde WMI filtresi için hazır bir silme komutu olmadığı için filtreyi doğrudan AD nesnesi olarak siliyoruz. Aynı işi GPMC’de WMI Filters altında filtreye sağ tıklayıp Delete ile de yapabiliriz. Son komutun çıktısında Satis OU’sunun InheritedGpoLinks listesinde Bölüm 3 sonundaki gibi U - Satis - Ekran Kilidi, U - Satis - Tercihler ve Default Domain Policy kalmalıdır.

İstemciyi yeniden başlatıp nihat.cubuk ile oturum açtığımızda S: sürücüsü, ekran kilidi ve komut istemi Bölüm 3 sonundaki haline döner.

5. Güvenlik Açısından Filtreleme ve Loopback

Okunamayan GPO’ları bulmak

MS16-072 sorunu sessizdir: GPO hata vermeden uygulanmaz ve çoğu zaman aylarca fark edilmez. Bu sorun bir güvenlik GPO’sunda yaşanırsa, örneğin ekran kilidi ya da USB (Universal Serial Bus) kısıtlaması uygulandığı sanılırken hiç uygulanmıyorsa, kağıt üzerinde var olan bir kontrol gerçekte yoktur. Domain’deki tüm GPO’lar içinde Authenticated Users ya da Domain Computers grubunun hiçbir izni olmayanları şu komutla bulabiliriz:

Get-GPO -All | ForEach-Object {
    $izinler = Get-GPPermission -Guid $_.Id -All
    $okuma = $izinler | Where-Object { $_.Trustee.Name -in "Authenticated Users", "Domain Computers" }
    if (-not $okuma) { $_.DisplayName }
}

Kendi ortamınıza uyarlarken:

Komut her GPO’nun izin listesini okur ve iki gruptan hiçbirinin izni yoksa GPO’nun adını yazar. Çıktıda görünen her GPO, MS16-072 nedeniyle kullanıcılara uygulanmıyor olabilir ve incelenmelidir.

Deny ile GPO’yu gizlemek

Delegation sekmesinde verilen bir Deny Read izni, GPO’yu ilgili hesaplar için görünmez hale getirir: bu hesaplar GPMC’de GPO’nun ayarlarını göremez ve gpresult raporlarında GPO’nun içeriği eksik görünür. GPO düzenleme yetkisini ele geçirmiş bir saldırgan, değişikliğini denetçilerin ya da izleme hesaplarının gözünden saklamak için bu yöntemi kullanabilir. GPO izinlerinde Deny içeren her kayıt, gerekçesi bilinen ve belgelenmiş bir istisna olmalıdır.

WMI filtreleri ve yetki

WMI filtresini düzenleyebilen bir kişi, filtrenin bağlı olduğu her GPO’nun kapsamını değiştirebilir. Adım 5’te gördüğümüz gibi sorguyu bozan tek bir değişiklik, bir güvenlik GPO’sunu tüm makinelerde devre dışı bırakır ve GPO’nun kendisinde hiçbir değişiklik görünmez. WMI filtresi oluşturma ve düzenleme yetkisi varsayılan olarak Domain Admins ve Group Policy Creator Owners gruplarındadır. Bu yetki GPMC’de WMI Filters düğümünün Delegation sekmesinden denetlenmelidir.

Loopback ve paylaşılan bilgisayarlar

Kiosk ve terminal sunucu gibi paylaşılan makinelerde Replace modu, kullanıcının normalde aldığı güvenlik ayarlarını da devre dışı bırakır. Adım 6’da ekran kilidinin kalkması bunun bir örneğidir. Loopback kullanılan OU’larda, kullanıcıların OU’larından gelen güvenlik ayarlarının (ekran kilidi, kısıtlamalar) loopback GPO’sunda da yeniden tanımlandığından emin olunmalıdır.

6. Özet ve Sonraki Bölüm

1. Bir GPO’nun uygulanması için link’in kapsamında olmak yetmez, nesnenin GPO üzerinde Read ve Apply Group Policy izni olmalıdır. Security Filtering bu iki izni yönetir.
2. MS16-072 sonrası kullanıcı GPO’ları bilgisayar hesabının kimliğiyle okunur. Security Filtering’den Authenticated Users’ı çıkarırken Delegation sekmesinde Authenticated Users’a Read izni geri verilmelidir.
3. Deny izni Scope sekmesinde görünmez, yalnızca Delegation sekmesinin Advanced penceresinde görünür.
4. WMI filtresi istemcide çalışan bir sorgudur, GPO’nun tamamına uygulanır ve her yenilemede çalıştığı için hızlı olmalıdır. gpresult, WMI filtresi nedeniyle uygulanmayan GPO’yu Denied (WMI Filter) ile açıkça gösterir.
5. Loopback Processing, kullanıcı ayarlarını bilgisayarın OU’suna göre uygular. Replace kullanıcının kendi GPO’larını tamamen kaldırır, Merge ise onları korur ve bilgisayarın ayarlarını ekler.
6. Okunamayan GPO’lar, Deny izinleri ve WMI filtresi düzenleme yetkisi düzenli olarak denetlenmelidir.

Bir sonraki bölümde Group Policy’nin ne zaman ve nasıl yenilendiğini (arka plan yenilemesi, senkron ve asenkron işleme, Fast Logon Optimization) ve bir GPO uygulanmadığında izlenecek sorun giderme yolunu işleyeceğiz: gpresult, GPMC’deki Group Policy Results ve Modeling sihirbazları, Group Policy event log’ları ve SYSVOL (System Volume) replikasyon kontrolü.

Kısaltmalar

Yazıda geçen kısaltmaların açılımlarını ve kısa açıklamalarını aşağıdaki tabloda bir arada bulabilirsiniz.