Group Policy Temelleri: Kapsam, İşlenme Sırası ve Sorun Giderme

Merhaba

Active Directory (AD) ortamlarında en sık kullanılan ama en çok yanlış anlaşılan araçlardan biri Group Policy. Bir ayarın Neden uygulanmadığı sorusu çoğu zaman GPO’nun (Group Policy Object) içeriğinden değil, nereye bağlandığından, hangi yarısında tanımlandığından ya da hangi sırayla işlendiğinden kaynaklanıyor. Üstelik Group Policy yalnızca bir yönetim aracı değil, doğru korunmadığında saldırganların domain içinde yayılmak için kullandığı en etkili yollardan biri.

Bu seride Group Policy’yi temelden başlayarak hem uygulama hem de güvenlik tarafıyla ele alıyoruz. Her bölümde önce kavramı anlatıyor, ardından Windows Server 2025 üzerinde kurduğumuz bakicubuk.tech lab ortamında adım adım uyguluyoruz. AD Sıkılaştırma ve AD Güvenlik Kontrol Listesi serilerindeki ayarların büyük bölümü GPO ile dağıtıldığı için bu seriyi o yazıların temeli olarak da düşünebilirsiniz.

Bu ilk bölümde Group Policy’nin ne olduğunu, bir GPO’nun AD ve SYSVOL (System Volume) içinde fiziksel olarak nasıl tutulduğunu, varsayılan GPO’ları ve yönetim araçlarını ele alıyor, ardından lab ortamımızda ilk GPO’muzu oluşturup arka planda neyin değiştiğini inceliyoruz.

1. Group Policy Nedir?

Group Policy, bir Windows domain’indeki işletim sistemi ayarlarını, güvenlik yapılandırmasını ve kullanıcı ortamını merkezi olarak yönetmemizi sağlayan çerçevedir. Parola politikasından firewall kurallarına, BitLocker ayarlarından masaüstü kısıtlamalarına kadar yüzlerce makinede tek tek yapılması gereken ayarları tek bir noktadan dağıtmamızı sağlar.

Sahada önerilen yaklaşım bir GPO, bir işlev ilkesidir. Güvenlik temel yapılandırması, yazıcı dağıtımı ve masaüstü kısıtlamaları ayrı GPO’larda tutulur, sonra ihtiyaç olan yerlere link edilir. Her şeyi tek GPO’ya toplamak ilk başta pratik görünse de denetimi, sorun gidermeyi ve değişikliği geri almayı ciddi şekilde zorlaştırır.

2. Bir GPO’nun Anatomisi: GPC ve GPT

GPMC (Group Policy Management Console) içinde tek bir nesne gibi görünen GPO aslında iki ayrı yerde tutulan iki parçadan oluşur.

GPC (Group Policy Container) nesnesinin sorun gidermede işimize yarayacak başlıca öznitelikleri şunlardır:

• displayName: GPMC’de gördüğümüz GPO adı.
• gPCFileSysPath: GPT (Group Policy Template) klasörünün SYSVOL içindeki yolu.
• versionNumber: GPO’nun sürüm numarası. Üst 16 bit User Configuration, alt 16 bit Computer Configuration sürümünü tutar. User tarafında yapılan her değişiklik bu değeri 65536 artırır, Computer tarafındaki değişiklik ise 1 artırır.
• flags: GPO durumu. 0 tamamen etkin, 1 User tarafı devre dışı, 2 Computer tarafı devre dışı, 3 tamamen devre dışı anlamına gelir.
• gPCMachineExtensionNames ve gPCUserExtensionNames: Bu GPO’yu işlemesi gereken CSE’lerin (Client-Side Extension) listesi. İstemci, hangi uzantıyı çalıştıracağını buradan öğrenir.

GPT klasörünün tipik yapısı ise şöyledir:

GPO’nun link bilgisi ise GPO’nun kendisinde değil, link edildiği konteynerde tutulur. Domain ve OU nesnelerinin gPLink özniteliği, o konteynere link edilmiş GPO’ların listesini [LDAP://cn={GUID},cn=policies,cn=system,DC=...;0] biçiminde saklar (LDAP, Lightweight Directory Access Protocol). Sondaki sayı link durumunu gösterir: 0 etkin, 1 link devre dışı, 2 Enforced, 3 hem devre dışı hem Enforced. Aynı konteynerdeki gPOptions özniteliğinin 1 olması ise Block Inheritance uygulandığı anlamına gelir. Bu iki özniteliğin önemi Bölüm 3’te ve özellikle Bölüm 6’da ortaya çıkacak: bir OU’nun gPLink özniteliğini değiştirebilen biri, o OU’ya istediği GPO’yu bağlayabilir.

3. Computer Configuration ve User Configuration

Her GPO birbirinden bağımsız iki yarıdan oluşur. Bir ayarı yapılandırırken vereceğimiz ilk karar, ayarın hangi yarıda olması gerektiğidir.

Computer Configuration, bilgisayar hesabının AD’deki konumuna göre; User Configuration ise kullanıcı hesabının AD’deki konumuna göre uygulanır. Yalnızca kullanıcı hesaplarının bulunduğu bir OU’ya link edilen GPO’nun Computer Configuration kısmı hiçbir makineye ulaşmaz, çünkü o OU’da bilgisayar hesabı yoktur. Tersi de geçerlidir. Bu yüzden bir kullanıcı ayar uygulanmıyor dediğinde ilk soru GPO link edilmiş mi? değil, ayar doğru yarıda mı ve o yarının hedef nesnesi gerçekten kapsamda mı? olmalıdır.

Her iki yarının altında da aynı üç ana dal bulunur:

• Software Settings: Software Installation ile MSI (Microsoft Installer) paket dağıtımı.
• Windows Settings: Script’ler, Security Settings, Folder Redirection (yalnızca User tarafında) gibi ayarlar.
• Administrative Templates: ADMX (Administrative Template XML) dosyalarından, yani XML (Extensible Markup Language) biçimindeki şablon dosyalarından gelen, registry tabanlı binlerce ayar.

Bunlara ek olarak her iki yarıda Policies ve Preferences olmak üzere iki ana bölüm vardır. Aralarındaki fark (zorunlu kural ile yapılandırılabilir varsayılan) Group Policy’nin en önemli kavramlarından biri olduğu için Bölüm 2’yi tamamen bu konuya ayırdık.

4. Local GPO ve Varsayılan Domain GPO’ları

Local Group Policy: Her Windows makinesinin kendi yerel GPO’su vardır. gpedit.msc ile düzenlenir ve C:\Windows\System32\GroupPolicy altında tutulur. İşlenme sırasında ilk sırada yer aldığı için domain GPO’ları çakışan ayarlarda her zaman onu ezer. Domain’e bağlı makinelerde yerel GPO ile yapılandırma yapmak, yönetilemeyen gizli ayarlar oluşturduğu için önerilmez. Gerekirse Turn off Local Group Policy Objects processing ayarıyla yerel GPO’ların işlenmesi tamamen kapatılabilir.

Default Domain Policy ve Default Domain Controllers Policy: Domain oluşturulduğunda otomatik olarak gelen iki GPO’dur ve sabit GUID’lere (Globally Unique Identifier) sahiptir.

Sahadaki en yaygın hatalardan biri, bu iki GPO’ya zamanla her türlü ayarın eklenmesidir. Önerilen yaklaşım bu GPO’larda yalnızca tabloda belirtilen ayarları tutmak, diğer her şeyi ayrı GPO’larla yönetmektir. Bu iki GPO bozulursa ya da hatalı düzenlenirse dcgpofix komutuyla varsayılan hallerine döndürülebilir. Ancak komut GPO’yu ilk kurulum haline getirdiği için sonradan eklenen tüm ayarlar kaybolur. Bu yüzden düzenli GPO yedeği almak şarttır (Bölüm 8).

5. Yönetim Araçları ve ADMX Central Store

Group Policy yönetimi için kullandığımız başlıca araçlar şunlardır:

Administrative Templates ayarları ADMX ve ADML (Administrative Template Language) dosyalarından gelir. Varsayılan olarak GPMC, yönetim yapılan makinenin yerel C:\Windows\PolicyDefinitions klasörünü kullanır. Farklı yöneticiler farklı sürümlerdeki makinelerden GPO düzenlediğinde ayarlar eksik ya da tutarsız görünebilir. Bunu önlemek için SYSVOL içinde Central Store oluşturuyoruz. Klasör oluştuktan sonra GPMC tüm yöneticiler için bu merkezi konumu kullanır.

Starter GPO’lar ise yalnızca Administrative Templates ayarlarını içeren şablon GPO’lardır. Sık kullanılan bir ayar setini Starter GPO olarak kaydedip yeni GPO’ları bu şablondan oluşturabiliriz.

6. Uygulama: Lab Ortamında İlk GPO

Bu bölümün uygulama kısmında lab ortamımızda sırasıyla GPMC’yi kuruyor, seri boyunca kullanacağımız OU yapısını oluşturuyor, Central Store’u hazırlıyor, ilk GPO’yu hem arayüzden hem PowerShell ile oluşturuyor ve arka planda GPC ile GPT’de neyin değiştiğini inceliyoruz.

Adım 1: GPMC kurulumu

Domain controller’larda GPMC varsayılan olarak kuruludur. Yönetimi bir üye sunucudan ya da yönetim istasyonundan yapacaksak önce aracı kuruyoruz. Sunucuda şu komutu çalıştırıyoruz:

Install-WindowsFeature GPMC

Windows 11 yönetim istasyonunda ise RSAT (Remote Server Administration Tools) bileşeni olarak ekliyoruz:

Add-WindowsCapability -Online -Name Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0

Adım 2: Lab OU yapısının oluşturulması

Seri boyunca LSDOU (Local, Site, Domain, OU), Link Order, Block Inheritance ve Loopback senaryolarını test edebilmek için kullanıcı ve bilgisayar hesaplarını ayrı OU’larda tuttuğumuz bir yapı kuruyoruz:

$dn = "DC=bakicubuk,DC=tech"
New-ADOrganizationalUnit -Name "LAB" -Path $dn
New-ADOrganizationalUnit -Name "Kullanicilar" -Path "OU=LAB,$dn"
New-ADOrganizationalUnit -Name "Bilgisayarlar" -Path "OU=LAB,$dn"
New-ADOrganizationalUnit -Name "Satis" -Path "OU=Kullanicilar,OU=LAB,$dn"
New-ADOrganizationalUnit -Name "Satis" -Path "OU=Bilgisayarlar,OU=LAB,$dn"
New-ADOrganizationalUnit -Name "Kiosk" -Path "OU=Bilgisayarlar,OU=LAB,$dn"

Ardından test için bir kullanıcıyı OU=Satis,OU=Kullanicilar,OU=LAB altına, bir Windows 11 istemcinin bilgisayar hesabını da OU=Satis,OU=Bilgisayarlar,OU=LAB altına taşıyoruz. OU isimlerinde Türkçe karakter kullanmamamızın nedeni, script ve LDAP sorgularında karakter kodlaması kaynaklı sorunlardan kaçınmaktır.

Adım 3: Central Store oluşturulması

Central Store henüz yoksa, güncel bir makinedeki (tercihen Windows 11 ya da Windows Server 2025) PolicyDefinitions klasörünü SYSVOL’a kopyalıyoruz:

Copy-Item -Path "C:\Windows\PolicyDefinitions" -Destination "\\bakicubuk.tech\SYSVOL\bakicubuk.tech\Policies\" -Recurse

Klasörde ADMX dosyalarıyla birlikte dil klasörünün (örneğin en-US) de bulunduğunu kontrol ediyoruz. Microsoft Edge ya da Microsoft 365 Apps gibi ürünlerin ADMX paketlerini de ileride aynı klasöre ekleyerek ortamı güncel tutuyoruz. Group Policy Management Editor’da herhangi bir GPO’yu açtığımızda Administrative Templates başlığının yanında Policy definitions (ADMX files) retrieved from the central store ifadesini görüyorsak Central Store devrede demektir.

Adım 4: İlk GPO’nun arayüzden oluşturulması

İlk GPO olarak Satış kullanıcılarının ekranını 15 dakika boşta kaldığında parola korumalı ekran koruyucuyla kilitleyen bir ayar yapıyoruz. Bu, sahada en sık karşılaşılan güvenlik ayarlarından biridir: kullanıcı masasından kalkıp bilgisayarını açık bıraktığında, başka birinin o oturumu kullanmasını engeller. Ayar kullanıcıya uygulanacağı için User Configuration altında yer alıyor ve GPO’yu kullanıcıların bulunduğu OU’ya link ediyoruz.

GPMC’de GPO oluşturmanın iki yolu vardır. Birincisi GPO’yu doğrudan bağlanacağı OU üzerinden Create a GPO in this domain, and Link it here seçeneğiyle oluşturmaktır. Bu yöntem GPO’yu oluşturduğu anda OU’ya da link eder. İkincisi ise GPO’yu önce Group Policy Objects konteynerinde oluşturmak, ayarlarını tamamlamak ve en son istediğimiz OU’ya Link an Existing GPO ile bağlamaktır.

Biz ikinci yolu kullanıyoruz ve bunu bir alışkanlık haline getirmenizi öneririm. Birinci yöntemde GPO oluştuğu anda OU’daki kullanıcılara ve bilgisayarlara uygulanmaya başlar. Biz ayarları yaparken araya bir Group Policy yenilemesi girerse, istemciler yarım yapılandırılmış bir GPO’yu almış olur. Üretim ortamında bu, beklenmedik kısıtlamalara ya da kesintilere yol açabilir. GPO’yu önce bağımsız olarak hazırlayıp, ayarlarını kontrol ettikten sonra link etmek daha kontrollü bir yaklaşımdır. Hangi yöntemi kullanırsak kullanalım GPO her zaman Group Policy Objects konteynerinde oluşur, OU’ya yalnızca link’i eklenir.

GPMC’de sol panelden bakicubuk.tech altındaki Group Policy Objects konteynerine sağ tıklıyor ve New seçiyoruz. Sağ panelde domain’deki mevcut GPO’ların listesi, durumları (GPO Status), bağlı WMI filtreleri, son değişiklik zamanları (Modified) ve sahipleri (Owner) görünür.

GPMC’de sol panelden bakicubuk.tech altındaki Group Policy Objects konteynerine sağ tıklıyor ve New seçiyoruz.

Açılan New GPO penceresinde Name alanına GPO’nun adını yazıyoruz: U - Satis - Ekran Kilidi. Adın başındaki U harfi GPO’nun yalnızca User Configuration ayarı içerdiğini, ortadaki bölüm GPO’nun hangi birim için olduğunu, son bölüm de ne yaptığını gösteriyor. Bu tür bir isimlendirme standardı, GPO sayısı yüzlerle ifade edilen ortamlarda bir GPO’nun ne yaptığını açmadan anlamamızı sağlar. Konuyu Bölüm 8’de detaylı ele alacağız.

Source Starter GPO alanını (none) olarak bırakıyoruz. Bu alan, yeni GPO’yu önceden hazırlanmış bir Starter GPO şablonundan türetmek için kullanılır. Bizim henüz bir şablonumuz olmadığı için boş bir GPO ile başlıyoruz ve OK düğmesine tıklıyoruz.

GPO, Group Policy Objects konteynerinin altında listelenir. Henüz hiçbir yere link edilmediği için şu an hiçbir kullanıcıya ya da bilgisayara uygulanmıyor. Şimdi GPO’nun içine ayarları ekleyeceğiz: Group Policy Objects altındaki U - Satis - Ekran Kilidi GPO’suna sağ tıklıyor ve Edit seçiyoruz.

Group Policy Management Editor açıldığında başlık satırında GPO’nun adını ve düzenlemenin yapıldığı domain controller’ı görürüz (U - Satis - Ekran Kilidi [W25DC.BAKICUBUK.TECH] Policy). GPO’lar varsayılan olarak PDC Emulator (Primary Domain Controller Emulator) rolündeki DC (Domain Controller) üzerinde düzenlenir. Bu, aynı GPO’nun iki farklı DC’de aynı anda farklı şekilde değiştirilmesini önlemek içindir.

Sol panelde şu yola gidiyoruz:

User Configuration > Policies > Administrative Templates > Control Panel > Personalization

Sağ panelde Personalization altındaki 16 ayarın tamamı Not configured durumdadır. Bir ayarın üzerine tıkladığımızda sol tarafta ayarın açıklaması, hangi Windows sürümlerinde desteklendiği (Requirements) ve ne işe yaradığı (Description) görünür. Bilmediğimiz bir ayarı yapılandırmadan önce bu açıklamayı okumak iyi bir alışkanlıktır.

Her Administrative Templates ayarının üç durumu vardır:

İlk olarak Enable screen saver ayarına çift tıklıyoruz. Açılan pencerede Enabled seçeneğini işaretliyor ve Apply düğmesine tıklıyoruz. OK diyerek açılan ayar penceresini kapatıyoruz.

Pencerenin sağ altındaki Help bölümü ayarın ne yaptığını anlatır: bu ayar ekran koruyucuyu etkinleştirir ancak çalışması için istemcide geçerli bir ekran koruyucunun seçili olması ve bir ekleme süresi tanımlanmış olması gerekir. Bu iki koşulu sonraki ayarlarla sağlayacağız. Next Setting düğmesiyle pencereyi kapatmadan bir sonraki ayara geçmek de mümkündür.

Ardından Password protect the screen saver ayarına çift tıklıyor, Enabled seçip Apply diyoruz. OK diyerek açılan ayar penceresini kapatıyoruz.

Bu ayar ekran koruyucudan çıkarken kullanıcının parolasını sormasını zorunlu kılar ve ekran koruyucu ayarlarındaki On resume, display logon screen kutusunu kullanıcının değiştiremeyeceği şekilde kilitler. Ekranı gerçekten kilitleyen ayar budur. Bu ayar olmadan ekran koruyucu yalnızca ekranı karartır, fareyi oynatan herkes oturuma geri döner.

Enabled seçip Apply diyoruz. OK diyerek açılan ayar penceresini kapatıyoruz.

Son olarak creen saver timeoutS ayarına çift tıklıyor, Enabled seçiyoruz.

Bu ayarın diğerlerinden farkı, Options bölümünde bir değer istemesidir: Seconds alanına ekran koruyucunun devreye girmesi için beklenecek süreyi saniye cinsinden giriyoruz. 15 dakika için 900 yazıp Apply diyoruz. Help bölümünde belirtildiği gibi bu değer 1 saniye ile 86.400 saniye (24 saat) arasında olabilir, 0 girilirse ekran koruyucu hiç başlamaz.

Enabled seçip Seconds alanına ekran koruyucunun devreye girmesi için beklenecek süreyi saniye cinsinden giriyoruz. 15 dakika için 900 yazıp Apply diyoruz. OK diyerek açılan ayar penceresini kapatıyoruz.

Üç ayarı yaptıktan sonra Personalization listesinde Enable screen saver, Password protect the screen saver ve Screen saver timeout ayarlarının State sütununda Enabled olarak göründüğünü kontrol ediyoruz.

Bunun için Personalization listesinde Force specific screen saver ayarını seçiyoruz. Açıklama bölümünde bu ayarın ekran koruyucu açılır listesini de kilitlediğini, yani kullanıcının farklı bir ekran koruyucu seçemeyeceğini görüyoruz. Açıklamanın sonundaki not da önemlidir: bu ayar Enable screen saver ayarına bağlıdır, o ayar Disabled yapılırsa bu ayar yok sayılır.

Ayara çift tıklıyor, Enabled seçiyoruz. Options bölümündeki Screen saver executable name alanına scrnsave.scr yazıp Apply diyoruz.

Help bölümünde belirtildiği gibi dosya %Systemroot%\System32 klasöründe değilse tam yolunun yazılması gerekir. scrnsave.scr bu klasörde bulunduğu için yalnızca dosya adını yazmamız yeterli.

Enabled seçiyoruz. Options bölümündeki Screen saver executable name alanına scrnsave.scr yazıp Apply diyoruz. OK diyerek açılan ayar penceresini kapatıyoruz.

Ayarları tamamladıktan sonra Group Policy Management Editor’ı kapatıyoruz. Düzenleyicide ayrıca kaydet düğmesi yoktur, her Apply ya da OK işlemi değişikliği anında GPO’ya yazar.

Bu GPO’da Computer Configuration tarafında hiçbir ayar olmadığı için o yarıyı devre dışı bırakıyoruz. GPMC’de sol panelden Group Policy Objects konteynerini seçiyor, sağ paneldeki listede U - Satis - Ekran Kilidi GPO’suna sağ tıklıyoruz. GPO Status menüsünün altında dört seçenek bulunur: Enabled (her iki yarı etkin), User Configuration Settings Disabled, Computer Configuration Settings Disabled ve All Settings Disabled (GPO tamamen devre dışı). Biz Computer Configuration Settings Disabled seçeneğini tıklıyoruz. Aynı ayara GPO’yu seçip Details sekmesindeki GPO Status açılır listesinden de ulaşabiliriz. Böylece istemciler bu GPO’yu işlerken Computer Configuration tarafına hiç bakmaz.

GPO hazır olduğuna göre artık onu kullanıcıların bulunduğu OU’ya link edebiliriz. GPMC’de sol panelden LAB > Kullanicilar > Satis OU’sunu buluyor ve üzerine sağ tıklıyoruz.

Açılan menüde şu seçenekleri görürüz:

Açılan Select GPO penceresinde Look in this domain alanında bakicubuk.tech seçili olarak gelir ve alt kısımda domain’deki tüm GPO’lar listelenir. Listeden U - Satis - Ekran Kilidi GPO’sunu seçiyor ve OK düğmesine tıklıyoruz.

GPO artık Satis OU’sunun sağ panelindeki Linked Group Policy Objects sekmesinde görünür.

Buradaki sütunlar, GPO link’inin durumunu özetler:

Bu sekmede GPO’ya sağ tıklayıp Edit dediğimizde de aynı düzenleyici açılır. Burada dikkat edilmesi gereken bir nokta var: link üzerinden Edit dediğimizde yalnızca bu link’i değil, GPO’nun kendisini düzenleriz. GPO başka OU’lara da link edilmişse yaptığımız değişiklik onların hepsine yansır.

Son olarak GPO’nun nereye link edildiğini GPO’nun kendisinden de kontrol ediyoruz. Group Policy Objects altında GPO’yu seçip Scope sekmesine geçiyoruz. Bu sekmenin üst kısmındaki Links bölümü GPO’nun nerelere link edildiğini, alt kısmındaki Security Filtering bölümü ise GPO’nun hangi kullanıcı ve bilgisayarlara uygulanacağını gösterir. Varsayılan olarak burada Authenticated Users grubu bulunur, yani link edildiği OU’daki tüm kullanıcılara uygulanır. En alttaki WMI Filtering bölümü ise GPO’ya bağlı bir WMI filtresi olup olmadığını gösterir, bizim GPO’muzda <none> görünüyor. Security Filtering ve WMI Filtering’i Bölüm 4’te detaylı işleyeceğiz.

Adım 5: GPO’nun istemcide doğrulanması

GPO’nun istemciye ulaştığını doğrulamak için Satis OU’sundaki test kullanıcısıyla (bizim lab’ımızda nihat.cubuk) Windows 11 istemcide oturum açıyoruz. İstemcinin bilgisayar hesabının da LAB > Bilgisayarlar > Satis altında olduğunu daha önce kontrol etmiştik.

İstemciler GPO’ları belirli aralıklarla kendiliğinden yeniler. Bu süreyi beklemeden hemen uygulamak için PowerShell ya da Command Prompt (Komut İstemi) penceresinde şu komutu çalıştırıyoruz:

gpupdate /force

Pencereyi Run as administrator (Yönetici olarak çalıştır) ile açmamıza gerek yoktur. Hatta yönetici olarak açarken farklı bir hesabın kimlik bilgilerini girersek, User Configuration yenilemesi oturum açmış kullanıcıya değil o hesaba uygulanır. Kullanıcı tarafı GPO’ları test ederken komutu normal bir pencerede, test kullanıcısının kendi oturumunda çalıştırmak en doğrusudur.

Komut çıktısında iki satır görmemiz gerekir: Computer Policy update has completed successfully bilgisayar tarafının, User Policy update has completed successfully ise kullanıcı tarafının sorunsuz yenilendiğini gösterir. Hata alırsak çıktı, ayrıntılar için Event Viewer’a bakmamızı söyler. Bu durumu Bölüm 5’te işleyeceğiz.

Ardından hangi GPO’ların uygulandığını görmek için kullanıcı tarafı özet raporunu alıyoruz:

gpresult /r /scope user

/r parametresi özet (summary) rapor üretir, /scope user ise yalnızca kullanıcı tarafını gösterir. Çıktının USER SETTINGS bölümünde şu bilgileri okuyoruz:

DN satırı, kullanıcının gerçekten Satis OU’sunda olduğunu doğrular. Kullanıcı yanlış OU’da olsaydı GPO’muz Applied listesinde görünmezdi. Filtered out bölümündeki Local Group Policy satırı ise bir hata değildir: istemcinin yerel GPO’sunda kullanıcı tarafında hiçbir ayar olmadığı için Empty (boş) nedeniyle uygulanmamış görünür. Bu bölümde görebileceğimiz diğer nedenleri (Denied (Security), Denied (WMI Filter), Disabled (GPO) gibi) Bölüm 5’te ele alacağız. Son bölümdeki grup listesinde NT AUTHORITY\Authenticated Users grubunun bulunması da önemlidir: GPO’muzun Security Filtering’inde bu grup tanımlı olduğu için GPO kullanıcıya uygulanabildi.

Son olarak ayarın kullanıcı tarafında gerçekten uygulandığını görsel olarak doğruluyoruz. Windows 11’de Settings > Personalization > Lock screen sayfasını açıyor, sayfanın altındaki Related settings bölümünde Screen saver bağlantısına tıklıyoruz. Bu bağlantı klasik Screen Saver Settings penceresini açar.

Screen Saver Settings penceresinde GPO’daki dört ayarın etkisini birlikte görüyoruz:

• Screen saver listesinde Blank seçili ve liste gri. Blank, Force specific screen saver ayarında girdiğimiz scrnsave.scr dosyasının arayüzdeki adıdır. Liste gri olduğu için kullanıcı farklı bir ekran koruyucu seçemez.
• Wait değeri 51 dakika ve gri. Screen saver timeout ayarında girdiğimiz 900 saniyenin karşılığıdır.
• On resume, display logon screen kutusu işaretli ve gri. Password protect the screen saver ayarının sonucudur, ekran koruyucudan çıkarken kullanıcının parolası sorulur.

Seçeneklerin gri görünmesi, değerlerin kullanıcı tarafından değil GPO tarafından belirlendiğini gösterir. GPO kapsam dışına çıktığında (link kaldırıldığında ya da kullanıcı başka bir OU’ya taşındığında) bu kilit de kalkar. Policy ayarlarının bu davranışını Bölüm 2’de Preferences ile karşılaştırarak detaylı işleyeceğiz.

Adım 6: Aynı GPO’nun PowerShell ile oluşturulması

Aynı yapılandırmayı PowerShell ile de kurabiliriz. Bu yaklaşım özellikle birden fazla ortamda aynı GPO’ları tekrar oluşturmamız gerektiğinde ya da GPO’ları bir script ile belgelemek istediğimizde işimize yarar. Arayüzden oluşturduğumuz GPO’nun aynısını (PS) ekiyle ayrı bir GPO olarak oluşturuyoruz:

$gpo = New-GPO -Name "U - Satis - Ekran Kilidi (PS)" -Comment "Satış kullanıcıları için 15 dk ekran kilidi"
$key = "HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop"
Set-GPRegistryValue -Name $gpo.DisplayName -Key $key -ValueName "ScreenSaveActive" -Type String -Value "1"
Set-GPRegistryValue -Name $gpo.DisplayName -Key $key -ValueName "ScreenSaverIsSecure" -Type String -Value "1"
Set-GPRegistryValue -Name $gpo.DisplayName -Key $key -ValueName "ScreenSaveTimeOut" -Type String -Value "900"
Set-GPRegistryValue -Name $gpo.DisplayName -Key $key -ValueName "SCRNSAVE.EXE" -Type String -Value "scrnsave.scr"
$gpo.GpoStatus = "ComputerSettingsDisabled"

Her Set-GPRegistryValue satırı, arayüzde yaptığımız bir ayarın registry karşılığıdır. Administrative Templates ayarlarının aslında birer registry değeri olduğunu burada açıkça görüyoruz: ScreenSaveActive Enable screen saver ayarına, ScreenSaverIsSecure Password protect the screen saver ayarına, ScreenSaveTimeOut Screen saver timeout ayarına, SCRNSAVE.EXE ise Force specific screen saver ayarına karşılık gelir.

Burada GPO’yu yalnızca oluşturuyoruz, arayüzden oluşturduğumuz GPO ile aynı işi yaptığı için link etmiyoruz. Link etmek istersek şu komutu kullanabiliriz:

New-GPLink -Name "U - Satis - Ekran Kilidi (PS)" -Target "OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech" -LinkEnabled Yes

Komutları çalıştırdıktan sonra GPMC’de Group Policy Objects konteynerini yeniliyoruz (sağ tıklayıp Refresh ya da F5). Listede U - Satis - Ekran Kilidi (PS) GPO’su görünür. GPO Status sütununda Computer configuration settings disabled yazması, script’in son satırındaki $gpo.GpoStatus = "ComputerSettingsDisabled" atamasının uygulandığını gösterir. Arayüzde sağ tık menüsünden yaptığımız işlemin PowerShell karşılığı budur.

Set-GPRegistryValue komutu ayarları doğrudan GPT içindeki User\Registry.pol dosyasına yazar. Düzenleyici de ayarları aynı dosyadan okuduğu için, PowerShell ile yazdığımız değerler arayüzde normal birer policy ayarı olarak görünür. Bunu doğrulamak için (PS) GPO’suna sağ tıklayıp Edit ile düzenleyiciyi açıyor ve User Configuration > Policies > Administrative Templates > Control Panel > Personalization yoluna gidiyoruz. Enable screen saver, Force specific screen saver, Password protect the screen saver ve Screen saver timeout ayarlarının State sütununda Enabled olarak göründüğünü, yani arayüzden oluşturduğumuz GPO ile birebir aynı olduğunu görüyoruz. Herhangi birine çift tıkladığımızda da 900 saniye ve scrnsave.scr değerlerinin Options bölümünde yer aldığını kontrol edebiliriz.

Adım 7: GPC ve GPT’nin incelenmesi

Şimdi arayüzden oluşturduğumuz GPO’nun arka planda nasıl tutulduğuna bakıyoruz. Bu adımdaki komutları domain controller üzerinde ya da RSAT (Remote Server Administration Tools) kurulu bir yönetim makinesinde, GroupPolicy ve ActiveDirectory PowerShell modüllerinin yüklü olduğu bir oturumda çalıştırıyoruz. Önce GPO’nun GUID’ini ve sürüm bilgilerini alıyoruz:

$gpo = Get-GPO -Name "U - Satis - Ekran Kilidi"
$gpo | Select-Object DisplayName, Id, GpoStatus
$gpo.User | Select-Object DSVersion, SysvolVersion
$gpo.Computer | Select-Object DSVersion, SysvolVersion

İlk satır GPO’yu bir değişkene alır, sonraki satırlar bu değişkenin farklı özelliklerini listeler.

Çıktıda şu bilgileri okuyoruz:

DSVersion (Directory Service Version) GPC’deki, SysvolVersion ise GPT’deki sürümü gösterir. İkisinin aynı olması, GPO’nun AD ve SYSVOL tarafının birbiriyle tutarlı olduğunu gösterir. Farklı olsaydı, bu DC’de replikasyonun henüz tamamlanmadığını ya da bir sorun olduğunu düşünürdük.

User tarafının sürümünün 4 olmasının nedeni basittir: GPO’yu oluşturduğumuzda sürüm 0’dı ve User Configuration altında dört ayarı (Enable screen saver, Password protect the screen saver, Screen saver timeout ve Force specific screen saver) ayrı ayrı Apply ile kaydettik. Her kaydetme işlemi ilgili yarının sürümünü 1 artırır. Computer Configuration tarafına hiç dokunmadığımız için onun sürümü 0’da kaldı. GPO Status değişikliği ise bir ayar değişikliği olmadığı için sürüm numarasını artırmaz.

İstemciler bir GPO’yu yeniden işleyip işlemeyeceğine bu sürüm numaralarına bakarak karar verir. Sürüm, istemcinin en son işlediği sürümle aynıysa ve bir zorlama yoksa, GPO’daki ayarlar yeniden uygulanmaz. Bu artımlı (incremental) işleme davranışını Bölüm 5’te detaylı işleyeceğiz.

Ardından GPC nesnesinin özniteliklerini doğrudan AD’den okuyoruz. Komut, GPO’nun GUID’ini $gpo değişkeninden aldığı için ilk satırda değişkeni yeniden tanımlıyoruz. Bu satırı atlayıp komutu yeni bir PowerShell penceresinde çalıştırırsak değişken boş olur, sorgu CN={} olarak gider ve Directory object not found hatası alırız:

$gpo = Get-GPO -Name "U - Satis - Ekran Kilidi"
Get-ADObject -Identity "CN={$($gpo.Id)},CN=Policies,CN=System,DC=bakicubuk,DC=tech" -Properties displayName, versionNumber, flags, gPCFileSysPath, gPCUserExtensionNames |
    Format-List displayName, versionNumber, flags, gPCFileSysPath, gPCUserExtensionNames

Burada versionNumber değerinin 4 değil 262144 olduğunu görürüz. AD, iki yarının sürümünü tek bir sayıda tutar: üst 16 bit User Configuration, alt 16 bit Computer Configuration sürümüdür. Hesaplama şöyledir: User sürümü × 65536 + Computer sürümü, yani 4 × 65536 + 0 = 262144. Get-GPO bu sayıyı bizim için iki ayrı değere bölerek gösterir. flags değerinin 2 olması Computer tarafının devre dışı olduğunu, gPCFileSysPath ise GPT klasörünün SYSVOL’daki yolunu gösterir. gPCFileSysPath değerinde GUID’in büyük harflerle yazılmış olması bir sorun değildir, GUID’ler büyük ve küçük harfe duyarlı değildir.

gPCUserExtensionNames alanı ise istemcinin bu GPO’nun User tarafını işlerken hangi CSE’leri (Client-Side Extension) çalıştırması gerektiğini söyler. Değer köşeli parantez içinde GUID çiftlerinden oluşur: her çiftin ilk GUID’i istemcide çalışacak CSE’yi, ikinci GUID’i ise ayarı yapılandırmak için kullanılan düzenleyici eklentisini (tool extension) gösterir. Bizim çıktımızdaki {35378EAC-683F-11D2-A89A-00C04FBBCFA2} Administrative Templates ayarlarını işleyen Registry CSE’sidir. {D02B1F73-3407-48AE-BA88-E8213C6761F1} ise User Configuration altındaki Administrative Templates düzenleyicisini temsil eder. İstemci yalnızca bu listede yer alan CSE’leri çalıştırır. GPO’ya örneğin bir Drive Maps tercihi eklesek bu listeye Drive Maps CSE’sinin GUID’i de eklenirdi. gPCMachineExtensionNames alanı ise Computer tarafında hiç ayar olmadığı için boştur.

Aynı bilgileri grafik arayüzden görmek için ADSI Edit (Active Directory Service Interfaces Editor) aracını açıyor, Default naming context altında CN=System > CN=Policies yolunu izliyor ve CN={f09607e4-0936-4fec-ae61-cb52ea39c9e4} nesnesine sağ tıklayıp Properties seçiyoruz. Attribute Editor sekmesinde aynı öznitelikleri görürüz. ADSI Edit doğrudan AD veritabanını düzenlediği için burada yalnızca görüntüleme yapıyoruz, hiçbir değeri değiştirmiyoruz.

Şimdi GPT tarafına, yani SYSVOL’daki klasöre bakıyoruz:

$gpo = Get-GPO -Name "U - Satis - Ekran Kilidi"
Get-ChildItem "\\bakicubuk.tech\SYSVOL\bakicubuk.tech\Policies\{$($gpo.Id)}" -Recurse | Select-Object FullName
Get-Content "\\bakicubuk.tech\SYSVOL\bakicubuk.tech\Policies\{$($gpo.Id)}\gpt.ini"

Klasör listesinde şu öğeleri görüyoruz:

gpt.ini dosyasındaki Version değeri 262144, yani GPC’deki versionNumber ile birebir aynı. İstemci GPO’yu işlerken bu iki değeri karşılaştırır. Aynı dosyadaki displayName=New Group Policy Object satırı ise ilk bakışta kafa karıştırabilir. GPMC, GPO’yu oluştururken bu dosyaya varsayılan bir ad yazar ve GPO’ya verdiğimiz adı yalnızca AD’deki GPC nesnesinin displayName özniteliğinde tutar. gpt.ini içindeki ad güncellenmez ve hiçbir yerde kullanılmaz. GPO’nun gerçek adı her zaman GPC’deki değerdir, bunu bir önceki adımdaki Get-ADObject çıktısında U - Satis - Ekran Kilidi olarak görmüştük.

Son olarak GPO’nun link bilgisini, link edildiği OU üzerinde okuyoruz:

Get-ADOrganizationalUnit "OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech" -Properties gPLink, gPOptions | Format-List gPLink, gPOptions

gPLink özniteliğinde GPO’nun GUID’inin [LDAP://cn={F09607E4-0936-4FEC-AE61-CB52EA39C9E4},cn=policies,cn=system,DC=bakicubuk,DC=tech;0] biçiminde yer aldığını görüyoruz. Köşeli parantez içindeki LDAP (Lightweight Directory Access Protocol) yolu, GPO’nun GPC nesnesini gösterir. Sondaki ;0 ise link’in etkin olduğunu ve Enforced olmadığını belirtir. OU’ya birden fazla GPO link edilseydi, bu öznitelikte her GPO için ayrı bir köşeli parantez bloğu yan yana dizilirdi. Satis OU’sunda Block Inheritance uygulanmadığı için gPOptions boş döner. Bu, yazının başında anlattığımız GPO’nun link bilgisi GPO’da değil OU’da tutulur ilkesinin somut karşılığıdır.

Son bir deneme olarak GPO’da ekran koruyucu süresini 900’den 600 saniyeye değiştirip Get-GPO komutlarını tekrar çalıştırırsak User tarafının sürümünün 5’e, AD’deki versionNumber değerinin ise 65536 artarak 327680 değerine çıktığını görürüz. Denemeden sonra süreyi tekrar 900 saniyeye almayı unutmuyoruz.

7. Güvenlik Açısından İlk Bakış

GPO’nun yapısını gördükten sonra güvenlik açısından önemli bir sonuca varabiliriz: bir GPO’yu düzenleyebilen kişi, o GPO’nun link edildiği tüm bilgisayar ve kullanıcılarda kod çalıştırabilir. Bir startup script’i, zamanlanmış görev ya da yerel Administrators grubuna üye ekleyen bir ayar, GPO’nun kapsamındaki her makinede SYSTEM yetkisiyle uygulanır. Domain Controllers OU’suna link edilmiş bir GPO’yu düzenleyebilen biri fiilen Domain Admin yetkisine sahiptir.

Bu yüzden Group Policy tarafında üç yetkiyi ayrı ayrı düşünmemiz gerekir:

Bir GPO’nun izinlerini görmek için GPMC’de Group Policy Objects altındaki GPO’yu seçip Delegation sekmesine geçiyoruz. Oluşturduğumuz U - Satis - Ekran Kilidi GPO’sunda varsayılan izinler şöyledir:

Inherited sütununun hepsinde No yazması, bu izinlerin GPO’ya doğrudan tanımlandığını, üst bir nesneden miras alınmadığını gösterir. GPO’yu Domain Admins üyesi bir hesapla oluşturduğumuz için listede ayrıca oluşturan kullanıcı satırı görünmez. GPO’yu Group Policy Creator Owners grubunun üyesi olan, yönetici olmayan bir hesap oluştursaydı, o hesap da bu listede düzenleme yetkisiyle yer alırdı.

Bu listeden çıkarmamız gereken en önemli sonuç şudur: düzenleme yetkisi yalnızca üç satırda var ve üçü de domain’in en yetkili kimlikleri. Sorun genellikle zaman içinde Add düğmesiyle verilen yetkilerle ortaya çıkar: bir yardım masası grubuna yazıcı GPO’sunu düzenleyebilsin diye verilen yetki, o GPO bir gün Domain Controllers OU’suna da link edildiğinde ciddi bir yetki yükseltme yoluna dönüşebilir. Sağ alttaki Advanced düğmesi ise bu özet görünümün arkasındaki ayrıntılı ACL (Access Control List) penceresini açar. Bölüm 4’te Security Filtering’i işlerken bu pencereyi kullanacağız.

8. Özet ve Sonraki Bölüm

1. GPO, Windows kullanıcı ve bilgisayar ayarlarını merkezi olarak yönetir. Kapsamı içeriği değil, link edildiği yer belirler.
2. Her GPO iki parçadan oluşur: AD’deki GPC (Group Policy Container) ve SYSVOL’daki GPT (Group Policy Template). Sürüm numaraları iki tarafta aynı olmalıdır.
3. Link bilgisi GPO’da değil, konteynerin gPLink özniteliğinde tutulur. Block Inheritance ise gPOptions özniteliğindedir.
4. Computer Configuration bilgisayar hesabının, User Configuration kullanıcı hesabının konumuna göre uygulanır.
5. Default Domain Policy ve Default Domain Controllers Policy yalnızca kendilerine özgü ayarlar için kullanılmalıdır.
6. Central Store, tüm yöneticilerin aynı ADMX sürümleriyle çalışmasını sağlar.
7. GPO düzenleme ve link etme yetkisi, kapsamdaki tüm makinelerde kod çalıştırma yetkisi anlamına gelir.

Bir sonraki bölümde Policy ayarları ile Group Policy Preferences arasındaki farkı, tattooing davranışını, Group Policy Preferences (GPP) action’larını ve Item-level targeting özelliğini ele alacak, lab ortamında drive, yazıcı ve registry dağıtımı yapacağız. Güvenlik tarafında da eski ortamlarda hala karşımıza çıkan GPP (Group Policy Preferences) parola (cpassword) sorununu ve SYSVOL taramasını işleyeceğiz.

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.