Merhaba

İlk iki bölümde tek tek GPO’lar (Group Policy Object) oluşturduk: Bölüm 1‘de Satış kullanıcılarının ekranını 15 dakikada kilitleyen bir Policy, Bölüm 2‘de de drive, registry ve kısayol dağıtan Preference öğeleri. Bu GPO’ların hiçbiri birbiriyle çakışmıyordu. Gerçek bir domain’de ise durum farklıdır: domain’e link edilmiş güvenlik GPO’ları, departman OU’larına (Organizational Unit) link edilmiş özel GPO’lar, bilgisayarın kendi Local GPO’su ve bazen site’a link edilmiş GPO’lar aynı kullanıcıya ya da bilgisayara aynı anda uygulanır. Bunlardan ikisi aynı ayarı farklı değerlerle yapılandırdığında hangisinin kazanacağını belirleyen kesin kurallar vardır.

Ayar GPO’da doğru ama istemcide başka bir değer görünüyor sorununun büyük kısmı bu kuralların bilinmemesinden kaynaklanır. Aynı kurallar güvenlik açısından da kritiktir: domain seviyesinde tanımladığımız bir güvenlik ayarı, alt OU’daki bir GPO ya da tek bir onay kutusuyla etkisiz hale getirilebilir.

Bu bölümde Group Policy’nin işlenme sırasını (LSDOU: Local, Site, Domain, OU), aynı konteynere link edilmiş GPO’lar arasındaki önceliği belirleyen Link Order’ı, kalıtımı kesen Block Inheritance’ı ve bu kesmeyi aşan Enforced seçeneğini ele alıyoruz. Ardından bakicubuk.tech lab ortamımızda beş farklı seviyede aynı ayarı farklı değerlerle yapılandırıyor ve her adımda kazananı gpresult raporuyla doğruluyoruz.

1. LSDOU: Group Policy’nin İşlenme Sırası

Bir istemci Group Policy’yi işlerken GPO’ları rastgele bir sırayla değil, her zaman aynı sırayla uygular. Bu sıranın kısaltması LSDOU’dur:

Temel kural şudur: Aynı ayar birden fazla GPO’da yapılandırılmışsa, en son işlenen GPO kazanır. Her yeni GPO, kendinden önce yazılmış değerin üzerine yazar. Bu yüzden LSDOU sırasında en sonda kalan, yani nesneye en yakın OU’ya link edilmiş GPO’nun en yüksek önceliği vardır.

Bizim lab’ımızda nihat.cubuk kullanıcısı OU=Satis,OU=Kullanicilar,OU=LAB altında. Bu kullanıcı için işlenme sırası şöyledir:

1. Windows 11 istemcinin Local GPO’su
2. İstemcinin bulunduğu site’a (Default-First-Site-Name) link edilmiş GPO’lar
3. bakicubuk.tech domain’ine link edilmiş GPO’lar
4. LAB OU’suna link edilmiş GPO’lar
5. Kullanicilar OU’suna link edilmiş GPO’lar
6. Satis OU’suna link edilmiş GPO’lar (en son işlenir, en yüksek önceliğe sahiptir)

Kullanıcı ve bilgisayar ayrı ayrı değerlendirilir. User Configuration ayarları kullanıcının bulunduğu OU zincirine göre, Computer Configuration ayarları ise bilgisayar hesabının bulunduğu OU zincirine göre belirlenir. Bizim lab’ımızda kullanıcı Kullanicilar\Satis, bilgisayar ise Bilgisayarlar\Satis altında olduğu için iki taraf farklı GPO zincirlerinden beslenir. Site seviyesi ise her iki taraf için de bilgisayarın bulunduğu site’a göre belirlenir.

Not Configured, Enabled ve Disabled

Bölüm 1‘de Administrative Templates ayarlarının üç durumu olduğunu görmüştük.

Çakışma açısından bu üç durumun davranışı farklıdır:

Sık yapılan hata, bir ayarı alt OU’da kapatmak için Not Configured bırakmaktır. Not Configured hiçbir şeyi kapatmaz, yalnızca karar vermeyi üstteki GPO’lara bırakır. Üstten gelen bir ayarı alt seviyede gerçekten kapatmak için ayarı Disabled yapmak gerekir.

2. Link Order: Aynı Konteynerdeki GPO’ların Önceliği

LSDOU, farklı seviyeler arasındaki sırayı belirler. Aynı domain’e ya da aynı OU’ya birden fazla GPO link edildiğinde ise aralarındaki sırayı Link Order belirler. Bölüm 1 ve Bölüm 2‘de bu sütunu Linked Group Policy Objects sekmesinde görmüştük.

Link Order 1 en yüksek önceliktir. İlk bakışta ters gibi görünür ama mantığı son işlenen kazanır kuralının aynısıdır: istemci aynı konteynerdeki GPO’ları en büyük numaradan başlayarak işler ve Link Order 1’i en son uygular. Bu yüzden çakışma olduğunda Link Order 1 kazanır.

Yeni link edilen GPO her zaman listenin sonuna eklenir, yani en düşük önceliği alır. Sırayı GPMC’de (Group Policy Management Console) Linked Group Policy Objects sekmesinin solundaki ok düğmeleriyle ya da PowerShell’de Set-GPLink -Order ile değiştirebiliriz.

LSDOU ve Link Order birlikte düşünüldüğünde öncelik sırası şöyle özetlenebilir: önce seviye (OU domain’i, domain site’ı, site Local’i ezer), aynı seviyede ise Link Order (küçük numara büyük numarayı ezer).

3. Block Inheritance: Kalıtımı Kesmek

Varsayılan olarak bir OU, üstündeki domain’den ve üst OU’lardan gelen tüm GPO’ları devralır. Block Inheritance, bir domain ya da OU üzerinde işaretlendiğinde üst seviyelerden gelen GPO’ların o konteynere akmasını engeller. Konteynerin kendi GPO’ları ve altındaki OU’lara link edilmiş GPO’lar çalışmaya devam eder.

Block Inheritance, GPO’nun değil konteynerin özelliğidir. Bir OU’da Block Inheritance açıksa, o OU’nun altındaki tüm alt OU’lar da üstten gelen GPO’ları almaz, çünkü kalıtım zinciri o noktada kesilmiştir.

Block Inheritance’ın tipik kullanım alanı, domain genelindeki ayarların uygulanmaması gereken özel bir OU’dur: örneğin test bilgisayarları ya da tamamen farklı bir yapılandırma gerektiren kiosk makineleri. Ancak bu seçenek, domain’de uygulanmasını istediğimiz güvenlik ayarlarını da kestiği için dikkatli kullanılmalıdır. Bu konuya güvenlik başlığında döneceğiz.

4. Enforced: Engellenemeyen Link

Enforced (eski adıyla No Override), bir GPO link’ine verilen bir özelliktir. Enforced olarak işaretlenen link iki şey yapar:

1. Block Inheritance’ı aşar. Alt OU’larda Block Inheritance açık olsa bile Enforced link’in GPO’su uygulanır.
2. Çakışmada kazanır. Enforced link’in GPO’su, LSDOU sırasında kendisinden sonra gelen (yani normalde onu ezecek olan) alt seviye GPO’lara karşı üstün gelir.

Enforced GPO’lar, normal GPO’lar işlendikten sonra ayrıca ve ters sırayla uygulanır. Bu yüzden birden fazla Enforced link çakışırsa, en üst seviyedeki kazanır: domain’e link edilmiş Enforced bir GPO, OU’ya link edilmiş Enforced bir GPO’yu ezer. Normal kuralın tam tersidir ve bu bilinçli bir tasarımdır: domain yöneticisi, OU yöneticilerinin değiştiremeyeceği bir ayarı Enforced ile zorlayabilir.

Enforced, GPO’nun değil link’in özelliğidir. Aynı GPO bir yerde Enforced, başka bir yerde normal olarak link edilebilir. Bölüm 1‘de gördüğümüz gPLink özniteliğindeki her GPO girişinin sonundaki sayı bu bilgiyi tutar:

5. GPMC’de Önceliği Görmek: Group Policy Inheritance Sekmesi

GPMC’de bir domain ya da OU seçildiğinde sağ paneldeki Group Policy Inheritance sekmesi, o konteynere uygulanacak tüm GPO’ları öncelik sırasıyla listeler. Bu liste LSDOU’yu, Link Order’ı, Block Inheritance’ı ve Enforced’ı hesaba katarak hesaplanır. Precedence sütunundaki 1 numaralı GPO en yüksek önceliğe sahiptir.

Bu sekme bir başlangıç noktasıdır ama istemcide gerçekte ne olacağını tam göstermez:

İstemcide gerçekte hangi GPO’nun hangi ayarı kazandığını görmenin kesin yolu, istemcide üretilen RSoP (Resultant Set of Policy) raporudur. Lab’da bunu gpresult /h ile yapacağız.

6. Uygulama: Lab Ortamında Çakışan GPO’lar

Bu bölümün uygulama kısmında tek bir ayarı, Screen saver timeout‘u, beş farklı seviyede farklı değerlerle yapılandırıyoruz. Bu ayarı seçmemizin nedeni, sonucunun istemcide hem registry’de hem de Screen Saver Settings penceresinin Wait alanında dakika cinsinden kolayca görülebilmesidir. Her seviyeye farklı bir süre veriyoruz, böylece istemcide gördüğümüz süreye bakarak hangi GPO’nun kazandığını hemen anlayabiliyoruz:

GPO adlarındaki LSDOU Test ifadesi, bu GPO’ların yalnızca bu bölümün testi için oluşturulduğunu ve test sonunda silineceğini gösterir.

Adım 1: Başlangıç durumunun kontrolü

Bölüm 2‘nin sonunda Satis OU’sundaki iki GPO’nun link’ini tekrar etkinleştirmiştik. Teste başlamadan önce bu durumu ve Satis OU’sunun kalıtım bilgisini PowerShell ile kontrol ediyoruz:

Get-GPInheritance -Target "OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech"

Get-GPInheritance komutu bir konteynerin kalıtım bilgisini getirir. Çıktıda Name ve Path alanlarının küçük harflerle (satis, ou=satis,ou=kullanicilar,...) görünmesi normaldir, komut DN (Distinguished Name) değerini küçük harfe çevirerek döndürür.

Çıktıdaki önemli alanlar şunlardır:

Aynı bilgiyi GPMC’de görmek için LAB > Kullanicilar > Satis OU’sunu seçip sağ paneldeki Group Policy Inheritance sekmesine geçiyoruz. Precedence sütununda 1 ve 2 numarada Satis OU’sunun kendi GPO’ları, 3 numarada ise domain’den gelen Default Domain Policy görünür. Location sütunu her GPO’nun nereye link edildiğini, GPO Status sütunu Bölüm 1 ve Bölüm 2’de yaptığımız GPO Status ayarını, WMI Filter sütunu ise GPO’ya bağlı bir WMI (Windows Management Instrumentation) filtresi olup olmadığını gösterir. Listenin üstündeki This list does not include any GPOs linked to sites uyarısına dikkat edelim: GPMC, bu sekmenin site’a link edilmiş GPO’ları göstermediğini kendisi de belirtiyor. Bu konuya Adım 6’da döneceğiz.

İstemcinin hangi site’ta olduğunu da kontrol ediyoruz. Windows 11 istemcide bir PowerShell penceresinde şu komutu çalıştırıyoruz:

nltest /dsgetsite

Çıktıda Default-First-Site-Name yazmalı. Bu, AD (Active Directory) kurulduğunda otomatik oluşturulan varsayılan site’ın adıdır. Lab’ımızda başka site tanımlamadığımız için tüm makineler bu site’tadır.

Adım 2: Test GPO’larının oluşturulması

Site, domain ve Kullanicilar OU’su için üç test GPO’sunu PowerShell ile oluşturuyoruz. Arayüzden GPO oluşturmayı ve Administrative Templates ayarı yapmayı Bölüm 1‘de detaylı gördüğümüz için burada aynı işi script ile yapıyoruz.

Komutları domain controller’da Run as administrator (Yönetici olarak çalıştır) ile açılmış bir PowerShell penceresinde çalıştırıyoruz:

$key = "HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop"
$testler = @(
    @{ Ad = "U - LSDOU Test - Site 25dk";         Saniye = "1500" },
    @{ Ad = "U - LSDOU Test - Domain 10dk";       Saniye = "600"  },
    @{ Ad = "U - LSDOU Test - Kullanicilar 20dk"; Saniye = "1200" }
)
foreach ($t in $testler) {
    $gpo = New-GPO -Name $t.Ad -Comment "Bölüm 3 LSDOU testi, test sonunda silinecek"
    Set-GPRegistryValue -Name $gpo.DisplayName -Key $key -ValueName "ScreenSaveTimeOut" -Type String -Value $t.Saniye
    $gpo.GpoStatus = "ComputerSettingsDisabled"
}
Get-GPO -All | Where-Object DisplayName -like "U - LSDOU Test*" | Select-Object DisplayName, GpoStatus

Script, her test GPO’su için üç iş yapar: GPO’yu oluşturur, Bölüm 1‘de gördüğümüz ScreenSaveTimeOut registry değerini yazar ve GPO yalnızca kullanıcı ayarı içerdiği için Computer Configuration tarafını devre dışı bırakır. Son satır, oluşturulan GPO’ları ve GPO Status değerlerini listeler.

Script çalışırken ekranda her GPO için uzun bir bilgi bloğu (DisplayName, Owner, Id, GpoStatus, UserVersion gibi alanlar) görünür. Bunun nedeni, Set-GPRegistryValue komutunun işini bitirdikten sonra güncellediği GPO nesnesini ekrana yazmasıdır. Bu bloklarda GpoStatus alanının AllSettingsEnabled görünmesi kafa karıştırmasın: blok, GPO Status değişikliğini yapan satırdan önce yazdırılır. Bloklardaki UserVersion : AD Version: 1, SysVol Version: 1 satırı ise User Configuration tarafına tek bir değişiklik (registry değeri) yazıldığını gösterir. Bölüm 1’de gördüğümüz gibi her değişiklik sürüm numarasını bir artırır, ComputerVersion ise hiç dokunulmadığı için 0 kalır. Asıl kontrolü script’in son satırındaki liste sağlar: üç GPO’nun da GpoStatus değeri ComputerSettingsDisabled olmalı. Bu bilgi bloklarını görmek istemiyorsak Set-GPRegistryValue satırının sonuna | Out-Null eklememiz yeterli.

Test GPO’larında yalnızca süreyi yapılandırıyoruz. Ekran koruyucuyu açan Enable screen saver ve Force specific screen saver ayarları Satis OU’sundaki U - Satis - Ekran Kilidi GPO’sundan gelmeye devam ediyor. Ayarlar çakışmadığı için birleşir: ekran koruyucu Satis GPO’sundan açılır, süresi ise kazanan GPO’dan gelir.

Adım 3: Domain ve OU link’leri

Domain ve Kullanicilar OU’su GPO’larını PowerShell ile link ediyoruz:

New-GPLink -Name "U - LSDOU Test - Domain 10dk" -Target "DC=bakicubuk,DC=tech" -LinkEnabled Yes
New-GPLink -Name "U - LSDOU Test - Kullanicilar 20dk" -Target "OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech" -LinkEnabled Yes

New-GPLink komutunun çıktısında GPO’nun GUID (Globally Unique Identifier) değeri, link’in hedefi (Target), etkin olup olmadığı (Enabled), Enforced durumu (Enforced) ve Link Order değeri (Order) görünür. Domain’e link ettiğimiz GPO’nun Order değeri 2’dir, çünkü domain’de zaten Link Order 1 olarak Default Domain Policy bulunuyor.

GPMC’de bakicubuk.tech domain’ini seçip Linked Group Policy Objects sekmesine baktığımızda Default Domain Policy (Link Order 1) ve U - LSDOU Test - Domain 10dk (Link Order 2) görünür.

Adım 4: Site link’i

Site’a GPO link etmek için GPMC kullanıyoruz, çünkü site’lar GPMC’de varsayılan olarak görünmez ve bu adımı bir kez arayüzden görmek faydalıdır. Site’a GPO link etme yetkisi varsayılan olarak yalnızca Enterprise Admins grubundadır. Lab’da domain’in Administrator hesabını kullandığımız için bu yetkiye sahibiz.

GPMC’nin sol panelinde forest altındaki Sites düğümüne sağ tıklıyor ve Show Sites… seçiyoruz.

Açılan Show Sites penceresinde forest’taki tüm site’lar listelenir. Default-First-Site-Name kutusunu işaretleyip OK diyoruz. Site artık Sites düğümünün altında görünür.

Default-First-Site-Name site’ına sağ tıklıyor ve Link an Existing GPO… seçiyoruz.

Menüde domain ve OU menüsünden farklı olarak Create a GPO in this domain, and Link it here seçeneğinin bulunmadığına dikkat edelim: site’a yalnızca var olan bir GPO link edilebilir.

Site’lar forest seviyesinde bir nesne olduğu için açılan Select GPO penceresinin üstünde Look in this domain listesi bulunur. Bir site’a forest’taki herhangi bir domain’in GPO’su link edilebilir. Listede bakicubuk.tech seçiliyken U - LSDOU Test - Site 25dk GPO’sunu seçip OK diyoruz.

Site seçiliyken sağ paneldeki Linked Group Policy Objects sekmesinde GPO’nun Link Order 1 ile göründüğünü kontrol ediyoruz.

Adım 5: Local GPO’nun yapılandırılması

Son seviye istemcinin kendi Local GPO’su. Local GPO’yu düzenlemek için istemcide yerel yönetici yetkisi gerekir. Test kullanıcımız nihat.cubuk yönetici olmadığı için Windows 11 istemcide Başlat menüsünde Command Prompt‘a sağ tıklayıp Run as administrator (Yönetici olarak çalıştır) ile açıyor, yönetici hesabının bilgilerini giriyor ve şu komutu çalıştırıyoruz:

gpedit.msc

Local Group Policy Editor açılır. Arayüz, Bölüm 1‘de kullandığımız Group Policy Management Editor’ın aynısıdır, yalnızca sol paneldeki kök düğümün adı Local Computer Policy‘dir ve Preferences dalı bulunmaz. User Configuration > Administrative Templates > Control Panel > Personalization yoluna gidip Screen saver timeout ayarına çift tıklıyoruz.

Ayarı Enabled yapıp Seconds alanına 300 yazıyor, Apply ve OK diyoruz.

Local GPO’nun User Configuration tarafı, bu bilgisayarda oturum açan tüm kullanıcılara uygulanır: yerel hesaplara, domain kullanıcılarına ve yöneticilere. Bu yüzden testten sonra bu ayarı geri almayı unutmamalıyız. Local GPO dosyaları istemcide C:\Windows\System32\GroupPolicy klasöründe, Bölüm 1‘de SYSVOL’da (System Volume) gördüğümüz GPT (Group Policy Template) yapısıyla aynı şekilde (Machine, User, gpt.ini) tutulur.

Adım 6: İstemcide sonucun doğrulanması

Artık Screen saver timeout ayarı beş farklı yerde yapılandırılmış durumda. LSDOU kuralına göre kazanan, kullanıcıya en yakın OU olan Satis OU’sundaki U - Satis - Ekran Kilidi GPO’su olmalı, yani süre 15 dakika.

Önce GPMC’de Satis OU’sunun Group Policy Inheritance sekmesini yeniliyoruz (F5). Listeye U - LSDOU Test - Kullanicilar 20dk ve U - LSDOU Test - Domain 10dk eklenmiş olmalı. Sıralama LSDOU’nun tersidir: Precedence 1 ve 2 Satis’in kendi GPO’ları, 3 Kullanicilar OU’sunun GPO’su, 4 ve 5 domain’in GPO’ları. Domain’deki iki GPO arasında Link Order 1 olan Default Domain Policy, Link Order 2 olan test GPO’sundan önce gelir. Site GPO’sunun ve Local GPO’nun bu listede görünmediğine dikkat edelim. 5. başlıkta anlattığımız gibi bu sekme site ve Local seviyelerini göstermez.

Windows 11 istemcide nihat.cubuk kullanıcısıyla oturum açıyor ve normal (yönetici olmayan) bir PowerShell penceresinde şu komutları çalıştırıyoruz:

gpupdate /force
gpresult /r /scope user

gpresult çıktısının Applied Group Policy Objects bölümünde artık şu GPO’ları görmeliyiz: Satis OU’sunun iki GPO’su, U - LSDOU Test - Kullanicilar 20dk, U - LSDOU Test - Domain 10dk, U - LSDOU Test - Site 25dk ve Local Group Policy. Liste, istemcide gerçekten uygulanan GPO’ları gösterdiği için GPMC’deki Group Policy Inheritance sekmesinden farklı olarak site ve Local GPO’larını da içerir. Listenin sırasına dikkat edelim: GPO’lar öncelik sırasıyla, en yüksek öncelikli olan en üstte listelenir. Yani liste, LSDOU işlenme sırasının tam tersidir: en üstte en son işlenen Satis OU’sunun GPO’ları, en altta ilk işlenen Local Group Policy yer alır. Default Domain Policy ise listede hiç görünmez, çünkü kullanıcı tarafında hiçbir ayar içermez ve istemcinin kullanıcı ayarları için işleyeceği bir şey yoktur.

Çıktının üst kısmındaki Site Name satırında N/A yazması kafa karıştırmasın. Site bilgisi bilgisayara ait bir bilgidir ve /scope user ile yalnızca kullanıcı tarafını istediğimiz için bu satır doldurulmaz. Site GPO’sunun uygulandığını Applied Group Policy Objects listesinden ve birazdan üreteceğimiz HTML raporundan görüyoruz.

gpresult /r hangi GPO’ların uygulandığını gösterir ama bir ayarı hangisinin kazandığını göstermez. Bunun için HTML (HyperText Markup Language) raporu üretiyoruz:

gpresult /h "$env:USERPROFILE\Desktop\gpo-rapor.html" /scope user /f
Start-Process "$env:USERPROFILE\Desktop\gpo-rapor.html"

/h parametresi raporu HTML dosyası olarak kaydeder, /f aynı adlı dosya varsa üzerine yazar. /scope user yalnızca kullanıcı tarafını raporlar. Bu parametre olmadan komut bilgisayar tarafını da raporlamaya çalışır ve yönetici olmayan bir kullanıcıda hata verir.

Rapor tarayıcıda açılır. User Details başlığının altındaki Applied GPOs bölümünde her GPO’nun adı ve Link Location satırında nereye link edildiği yazar. Site GPO’sunun link konumu, site’ların forest seviyesindeki Configuration bölümünde tutulduğunu gösterecek şekilde bakicubuk.tech/Configuration/Sites/Default-First-Site-Name, Local GPO’nun konumu ise Local olarak görünür. Raporun en altındaki Denied GPOs bölümü, uygulanmayan GPO’ları ve nedenlerini listeler. Bizim raporumuzda bu bölüm boştur.

Raporda Settings > Policies > Administrative Templates > Control Panel/Personalization başlığına indiğimizde, her ayarın yanında Winning GPO sütununu görürüz. Screen saver timeout satırında Setting sütununda Enabled, Winning GPO sütununda U - Satis - Ekran Kilidi yazmalı. Satırın hemen altında ayarın değeri Seconds: 900 olarak görünür. Diğer dört GPO aynı ayarı yapılandırmış olsa da LSDOU sırasında en son Satis OU’sunun GPO’su işlendiği için onun değeri kazandı.

Son olarak sonucu registry’de ve arayüzde kontrol ediyoruz:

Get-ItemProperty -Path "HKCU:\Software\Policies\Microsoft\Windows\Control Panel\Desktop" | Select-Object ScreenSaveTimeOut

Çıktıda 900 görünür. Registry, Group Policy işlendikten sonra kalan son değeri tutar. Arada yazılan 300, 1500, 600 ve 1200 değerleri sırayla üzerine yazılmış ve en son 900 kalmıştır. Settings uygulamasından Screen Saver Settings penceresini açtığımızda da Wait alanında gri olarak 15 dakika görünür.

Adım 7: Link Order testi

Şimdi aynı OU içindeki önceliği test ediyoruz. U - LSDOU Test - Satis 30dk GPO’sunu oluşturup Satis OU’suna link ediyoruz:

$gpo = New-GPO -Name "U - LSDOU Test - Satis 30dk" -Comment "Bölüm 3 Link Order testi, test sonunda silinecek"
Set-GPRegistryValue -Name $gpo.DisplayName -Key "HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop" -ValueName "ScreenSaveTimeOut" -Type String -Value "1800"
$gpo.GpoStatus = "ComputerSettingsDisabled"
New-GPLink -Name $gpo.DisplayName -Target "OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech" -LinkEnabled Yes

Yeni link listenin sonuna eklendiği için New-GPLink çıktısında Order değeri 3’tür. GPMC’de Satis OU’sunun Linked Group Policy Objects sekmesinde üç GPO görünür: U - Satis - Ekran Kilidi (1), U - Satis - Tercihler (2) ve U - LSDOU Test - Satis 30dk (3).

İstemcide gpupdate /force çalıştırıp raporu yeniden üretiyoruz (Adım 6’daki gpresult /h ve Start-Process komutları).

gpresult /h "$env:USERPROFILE\Desktop\gpo-rapor.html" /scope user /f
Start-Process "$env:USERPROFILE\Desktop\gpo-rapor.html"

Screen saver timeout satırında Winning GPO hala U - Satis - Ekran Kilidi ve değer Seconds: 900 olmalı. İki GPO aynı OU’da ve aynı ayarı yapılandırıyor, Link Order 1 olan Ekran Kilidi GPO’su en son işlendiği için kazanıyor.

Şimdi sırayı değiştiriyoruz. GPMC’de Satis OU’sunun Linked Group Policy Objects sekmesinde U - LSDOU Test - Satis 30dk satırını seçiyor ve listenin solundaki düğmelerden en üstteki Move link to top (çift yukarı ok) düğmesine tıklıyoruz. Diğer düğmeler sırasıyla bir yukarı (Move link up), bir aşağı (Move link down) ve en alta (Move link to bottom) taşır.

GPO artık Link Order 1’de, diğer iki GPO ise 2 ve 3’e kaydı. Aynı değişikliği aşağıdaki PowerShell ile

Set-GPLink -Name "U - LSDOU Test - Satis 30dk" -Target "OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech" -Order 1

komutuyla da yapabilirdik.

İstemcide gpupdate /force çalıştırıp raporu yeniden üretiyoruz (Adım 6’daki gpresult /h ve Start-Process komutları).

gpresult /h "$env:USERPROFILE\Desktop\gpo-rapor.html" /scope user /f
Start-Process "$env:USERPROFILE\Desktop\gpo-rapor.html"

Bu kez Screen saver timeout satırında Winning GPO U - LSDOU Test - Satis 30dk, değer ise Seconds: 1800 olmalı. GPO’ların içeriğine dokunmadık, yalnızca link sırasını değiştirdik ve kazanan değişti.

Adım 8: Block Inheritance testi

Şu an Satis OU’su, üstteki Kullanicilar OU’sundan, domain’den ve site’tan GPO devralıyor. Satis OU’sunda Block Inheritance’ı açıyoruz. GPMC’de LAB > Kullanicilar > Satis OU’suna sağ tıklıyor ve Block Inheritance seçeneğini tıklıyoruz.

Satis OU’sunun ikonunun üzerinde mavi bir ünlem işareti belirir. Group Policy Inheritance sekmesine baktığımızda listede yalnızca Satis OU’sunun kendi üç GPO’su kalmıştır. Kullanicilar OU’sundan ve domain’den gelen GPO’lar, Default Domain Policy dahil, artık listede yok.

Aynı değişikliği PowerShell’de doğrulamak için Get-GPInheritance komutunu tekrar çalıştırıyoruz:

Get-GPInheritance -Target "OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech"

Bu kez GpoInheritanceBlocked değeri Yes olur ve InheritedGpoLinks listesinde yalnızca Satis’in kendi GPO’ları kalır. Aynı ayarı PowerShell ile açmak için Set-GPInheritance -Target "<OU DN>" -IsBlocked Yes komutu kullanılır.

İstemcide gpupdate /force ve ardından gpresult /r /scope user çalıştırıyoruz. Applied Group Policy Objects listesinde Kullanicilar, domain ve site test GPO’ları artık yok. Listede Satis’in üç GPO’su ve Local Group Policy kaldı. Engellenen üç test GPO’su ise bu kez The following GPOs were not applied because they were filtered out bölümünde, Filtering: Not Applied (Unknown Reason) gerekçesiyle listelenir. gpresult, bir GPO’nun Block Inheritance nedeniyle uygulanmadığını ayrıca belirtmez ve gerekçeyi Unknown Reason olarak gösterir. Bu yüzden bir GPO’nun neden uygulanmadığını araştırırken GPMC’deki Group Policy Inheritance sekmesine ve OU’daki mavi ünlem işaretine de bakmak gerekir. Local GPO hala uygulanıyor, çünkü Block Inheritance yalnızca AD’deki üst konteynerlerden gelen GPO’ları engeller, istemcinin kendi Local GPO’suna etki etmez.

Kazanan değer değişmedi: hala 1800 saniye, çünkü kazanan zaten Satis OU’sunun kendi GPO’suydu. Block Inheritance burada sonucu değil, sonuca katılan GPO’ları değiştirdi. Şimdi bunun neden tehlikeli olabileceğini Enforced ile görelim.

Adım 9: Enforced testi

Domain yöneticisi olarak, ekran koruyucu süresinin domain’deki hiçbir OU’da 10 dakikadan uzun olmamasını istediğimizi düşünelim. Domain’e link ettiğimiz U - LSDOU Test - Domain 10dk GPO’su şu an iki nedenle Satis kullanıcılarına ulaşmıyor: Satis OU’sunda Block Inheritance açık ve açık olmasaydı bile Satis OU’sundaki GPO’lar onu ezerdi.

GPMC’de bakicubuk.tech domain’inin altında U - LSDOU Test - Domain 10dk link’ine sağ tıklıyor ve Enforced seçeneğini tıklıyoruz. Burada GPO’nun kendisine değil, domain’in altında görünen link’ine sağ tıkladığımıza dikkat edelim. Group Policy Objects konteynerindeki GPO’ya sağ tıkladığımızda Enforced seçeneği çıkmaz, çünkü Enforced GPO’nun değil link’in özelliğidir.

Link’in ikonunda küçük bir kilit simgesi belirir ve domain’in Linked Group Policy Objects sekmesinde bu GPO’nun Enforced sütununda Yes yazar.

Satis OU’sunun Group Policy Inheritance sekmesini yenilediğimizde, Block Inheritance açık olmasına rağmen U - LSDOU Test - Domain 10dk GPO’sunun listeye geri döndüğünü ve Precedence 1 sırasına, yani Satis’in kendi GPO’larının da önüne yerleştiğini görürüz. Bu sekmede ayrı bir Enforced sütunu yoktur, durum Precedence sütununda 1 (Enforced) olarak gösterilir. GPO’nun ikonunda da kilit simgesi bulunur.

İstemcide gpupdate /force çalıştırıp raporu yeniden üretiyoruz (Adım 6’daki gpresult /h ve Start-Process komutları).

gpresult /h "$env:USERPROFILE\Desktop\gpo-rapor.html" /scope user /f
Start-Process "$env:USERPROFILE\Desktop\gpo-rapor.html"

Screen saver timeout satırında Winning GPO U - LSDOU Test - Domain 10dk, değer ise Seconds: 600 olmalı. Satis OU’sundaki Link Order 1 GPO’su da, Block Inheritance da domain’in Enforced link’ini durduramadı. Raporun Applied GPOs bölümünde U - LSDOU Test - Domain 10dk tekrar listelenir. Block Inheritance nedeniyle engellenen U - LSDOU Test - Kullanicilar 20dk ve U - LSDOU Test - Site 25dk ise Adım 6’da boş olan Denied GPOs bölümünde görünür.

Screen Saver Settings penceresini açtığımızda Wait alanında gri olarak 10 dakika görünür.

Bu testte dört kuralı arka arkaya gördük:

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

Testi tamamladıktan sonra lab’ı Bölüm 2 sonundaki duruma döndürüyoruz. Domain controller’da şu komutları çalıştırıyoruz:

$satisOU = "OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech"
$site = "CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=bakicubuk,DC=tech"

Set-GPInheritance -Target $satisOU -IsBlocked No
Remove-GPLink -Name "U - LSDOU Test - Site 25dk" -Target $site
Remove-GPLink -Name "U - LSDOU Test - Domain 10dk" -Target "DC=bakicubuk,DC=tech"
Remove-GPLink -Name "U - LSDOU Test - Kullanicilar 20dk" -Target "OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech"
Remove-GPLink -Name "U - LSDOU Test - Satis 30dk" -Target $satisOU
Get-GPO -All | Where-Object DisplayName -like "U - LSDOU Test*" | ForEach-Object { Remove-GPO -Guid $_.Id }
Get-GPInheritance -Target $satisOU

Komutlar sırasıyla Satis OU’sundaki Block Inheritance’ı kapatır, dört test link’ini kaldırır, ardından dört test GPO’sunu siler. Remove-GPLink komutları, link’i kaldırılan GPO’nun bilgilerini (DisplayName, Id, GpoStatus gibi) ekrana yazar. Bu çıktılar hata değildir, Remove-GPO ise başarılı olduğunda çıktı vermez. Link’leri GPO’dan önce ayrıca kaldırmamızın nedeni, site link’inin forest seviyesindeki Configuration bölümünde tutulmasıdır: GPO’yu silmek, site’taki link’i her zaman otomatik olarak temizlemez ve geride sahipsiz bir link kalabilir. Domain’deki Enforced link’i ayrıca geri almamıza gerek yok, link’i kaldırdığımızda Enforced bilgisi de onunla birlikte silinir.

Son Get-GPInheritance çıktısında GpoInheritanceBlocked değeri No olmalı ve InheritedGpoLinks listesinde Adım 1’deki gibi U - Satis - Ekran Kilidi, U - Satis - Tercihler ve Default Domain Policy kalmalı. Satis’in iki GPO’sunun Link Order’ı da, 30dk GPO’su kaldırıldığı için kendiliğinden 1 ve 2’ye döner.

İstemcide Local GPO’yu da geri alıyoruz: gpedit.msc‘yi, Command Prompt’a sağ tıklayıp Run as administrator (Yönetici olarak çalıştır) ile açtığımız pencereden çalıştırıyor ve User Configuration > Administrative Templates > Control Panel > Personalization > Screen saver timeout ayarını Not Configured yapıyoruz. Ardından nihat.cubuk oturumunda gpupdate /force çalıştırıyoruz. Screen Saver Settings penceresinde Wait değeri tekrar 15 dakika olmalı.

7. Güvenlik Açısından İşlenme Sırası

Block Inheritance ile güvenlik ayarlarından kaçmak

Adım 8’de gördüğümüz gibi Block Inheritance, domain seviyesindeki tüm GPO’ları tek bir onay kutusuyla keser. Domain’e link ettiğimiz parola dışı güvenlik ayarları (ekran kilidi, audit politikası, SMB (Server Message Block) imzalama, firewall kuralları) Enforced değilse, Block Inheritance açılmış bir OU’daki makinelere hiç ulaşmaz. Bir OU’da Block Inheritance açabilmek için o OU’nun gPOptions özniteliğine yazma yetkisi yeterlidir. Bu yetki çoğu zaman “kendi OU’sunu yönetsin” diye yardım masasına ya da departman yöneticilerine devredilir.

Domain’deki Block Inheritance açık konteynerleri şu komutla bulabiliriz:

Get-ADOrganizationalUnit -Filter * -Properties gPOptions | Where-Object gPOptions -eq 1 | Select-Object DistinguishedName
Get-ADObject (Get-ADDomain).DistinguishedName -Properties gPOptions | Select-Object DistinguishedName, gPOptions

İlk komut Block Inheritance açık OU’ları, ikincisi domain’in kendisinde Block Inheritance açık olup olmadığını gösterir. Her sonucun bir gerekçesi olmalı ve belgelenmiş olmalıdır.

Kritik güvenlik ayarları için Enforced

Domain genelinde istisnasız uygulanması gereken güvenlik ayarlarını, örneğin Bölüm 7’de işleyeceğimiz security baseline GPO’larını, domain’e Enforced olarak link etmek bu kaçış yolunu kapatır. Ancak Enforced’ı her GPO’ya vermek de çözüm değildir: Enforced GPO’lar alt seviyelerde istisna tanımlamayı imkansız hale getirir ve sorun gidermeyi zorlaştırır. Doğru yaklaşım, Enforced’ı az sayıda ve yalnızca gerçekten zorunlu güvenlik ayarlarını içeren GPO’larda kullanmaktır. Domain’deki Enforced link’leri şu komutla listeleyebiliriz:

Get-ADObject -LDAPFilter "(gPLink=*)" -Properties gPLink -SearchBase (Get-ADDomain).DistinguishedName |
    Where-Object { $_.gPLink -match ';[23]\]' } | Select-Object DistinguishedName, gPLink

Komut, gPLink özniteliğinde ;2 ya da ;3 bulunan, yani en az bir Enforced link içeren domain ve OU nesnelerini listeler. LDAP (Lightweight Directory Access Protocol) filtresi gPLink değeri dolu olan nesneleri getirir, PowerShell tarafındaki -match ise 4. başlıktaki tabloda gördüğümüz Enforced değerlerini arar.

Link yetkisi, düzenleme yetkisi kadar güçlüdür

Bir OU’ya GPO link edebilen kişi, o OU’daki makinelere hangi GPO’nun uygulanacağını ve Link Order ile hangisinin kazanacağını belirler. Kötü niyetli ya da ele geçirilmiş bir hesap, kendi düzenleyebildiği bir GPO’yu yüksek değerli bir OU’ya Link Order 1 olarak link ederek, o OU’daki tüm kullanıcılara ya da sunuculara ayar, script ya da zamanlanmış görev dağıtabilir. Bu yüzden gPLink ve gPOptions özniteliklerine yazma yetkisi (GPMC’deki karşılığı Link GPOs izni), GPO düzenleme yetkisi kadar sıkı denetlenmelidir. Delegasyon denetimini Bölüm 6’da detaylı ele alacağız.

Local GPO’yu kapatmak

Local GPO, LSDOU’nun ilk halkasıdır ve domain GPO’ları tarafından ezilir. Ancak domain GPO’larının yapılandırmadığı bir ayarı istemcide yerel yönetici yetkisi olan herkes Local GPO ile değiştirebilir. Yüksek güvenlik gerektiren ortamlarda Computer Configuration > Administrative Templates > System > Group Policy > Turn off Local Group Policy Objects processing ayarı domain GPO’su ile Enabled yapılarak istemcilerin Local GPO’yu işlemesi tamamen engellenebilir. Bu ayarı açmadan önce Local GPO ile yönetilen bir yapılandırma olmadığından emin olmak gerekir.

8. Özet ve Sonraki Bölüm

1. Group Policy, LSDOU sırasıyla işlenir: Local, Site, Domain ve üstten alta OU’lar. Aynı ayar birden fazla yerde yapılandırılmışsa en son işlenen, yani nesneye en yakın GPO kazanır.
2. Ayarlar çakışmadıkça birleşir. Not Configured hiçbir değeri ezmez, Disabled ise bir değerdir ve ezer.
3. Aynı konteynerdeki GPO’lar arasında Link Order 1 en son işlenir ve kazanır. Yeni link her zaman listenin sonuna eklenir.
4. Block Inheritance konteynerin özelliğidir, üst seviyelerden gelen GPO’ları keser ama Local GPO’yu ve Enforced link’leri kesmez.
5. Enforced link’in özelliğidir, Block Inheritance’ı aşar ve alt seviyelerdeki çakışan GPO’ları ezer. Enforced link’ler çakışırsa en üst seviyedeki kazanır.
6. GPMC’deki Group Policy Inheritance sekmesi site ve Local GPO’larını, filtrelemeyi göstermez. Kesin sonuç için istemcide gpresult /h raporundaki Winning GPO sütununa bakılır.
7. Block Inheritance açık OU’lar ve Enforced link’ler düzenli olarak denetlenmeli, gPLink ve gPOptions yazma yetkisi GPO düzenleme yetkisi kadar sıkı korunmalıdır.

Bir sonraki bölümde GPO’nun kime uygulanacağını link’in ötesinde daraltan yöntemleri işleyeceğiz: Security Filtering, WMI Filtering, MS16-072 güncellemesinin Security Filtering’e getirdiği değişiklik ve kullanıcı ayarlarının bilgisayarın konumuna göre uygulanmasını sağlayan Loopback Processing. Lab’da Kiosk OU’su için bir kiosk senaryosu kuracağız.

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.