Active Directory GPO Yönetimi: Group Policy Rehberi

Bir kurumun yüzlerce bilgisayarını tek tek dolaşıp her birinde aynı ayarı elle yapmak, trafik kurallarını her sürücüye ayrı ayrı sözlü anlatmaya benzer: yorucu, tutarsız ve sürdürülemez. Karayolları bunu tek bir yönetmelik ve her kavşağa dikilmiş ortak tabelalarla çözer; sürücü hangi şehirde olursa olsun kırmızı ışığın ne demek olduğunu bilir. Group Policy, Active Directory ortamında tam olarak bu ortak yönetmelik ve tabela sistemidir.

Bu rehber, GPO’nun ne olduğunu, nasıl oluşturulup hangi seviyeye bağlandığını, uygulama sırasının neden kritik olduğunu ve sahada en çok karşılaşılan GPO sorunlarının nasıl çözüldüğünü adım adım ele alır. Active Directory’yi yeni kurmuş bir sistem yöneticisinden, mevcut domain’de policy karmaşası yaşayan deneyimli bir mühendise kadar her seviyeye hitap eder.

Kim tarafından, neden yapıldığı belirsiz GPO’ların gerçek bir ortamda nasıl titizlikle tarandığını ve temizlendiğini Active Directory modernizasyon vaka çalışmasında okuyabilirsiniz.

Bu makale BT sistem yönetimi ana hizmetinin Active Directory koluna bağlı bir derinleşmedir; AD’nin genel mimarisi ve kurulumu için Active Directory Rehberi başlangıç noktasıdır.

Group Policy Nedir?

Büyük bir şirket düşünün: 500 çalışanı var ve İnsan Kaynakları her yeni işe başlayana tek tek oturup “mesai saatin 09.00-18.00, izin talebini şu formla yap, şirket aracını şu kurallarla kullan” diye anlatmak zorunda olsaydı, departman hiçbir zaman büyüyemezdi. Gerçekte böyle çalışmaz; kurum bir Personel Yönetmeliği hazırlar, imzalatır, ve o yönetmelik o andan itibaren her çalışan için otomatik bağlayıcı olur. Yeni biri işe girdiğinde tek tek anlatmaya gerek kalmaz, yönetmelik zaten oradadır ve onu otomatik kapsar.

Group Policy, Active Directory ortamında bu yönetmeliğin dijital karşılığıdır. Bir GPO (Group Policy Object) belirli ayarların toplandığı bir pakettir ve Group Policy Management Console (GPMC) üzerinden oluşturulup Site, Domain veya OU seviyesine bağlanır. O seviyeye giren her kullanıcı veya bilgisayar, oturum açtığı anda bu paketteki kuralları otomatik miras alır; sistem yöneticisinin tek tek makineye gidip ayar girmesine gerek kalmaz.

GPO, GPC ve GPT: Policy’nin Anatomisi

Bir binanın iki farklı kaydı vardır: tapu sicilindeki soyut kayıt (kim sahip, hangi ada-parsel) ve belediye arşivindeki somut inşaat projesi dosyası (statik hesaplar, kat planları, malzeme listesi). Biri “bu bina var ve şuraya ait” der, diğeri binanın gerçek içeriğini taşır. İkisi ayrı sistemlerde durur ama aynı binayı tanımlar.

GPO da aynı ikiliyle çalışır. GPC (Group Policy Container), Active Directory veritabanında tutulan, GPO’nun varlığını ve hangi nesnelere bağlı olduğunu gösteren soyut kayıttır; tapu sicili gibi. GPT (Group Policy Template) ise gerçek ayarların, script’lerin ve yönetim şablonlarının metin dosyaları halinde durduğu yerdir; her Domain Controller’ın SYSVOL paylaşımı altında, GPO’nun benzersiz GUID’i ile adlandırılmış bir klasördür. Bir GPO replikasyon sorunu yaşıyorsa, çoğu zaman bu iki kayıt arasında senkron kayması vardır; GPC güncel ama GPT eski (veya tersi).

Group Policy Management Console (GPMC)

E-Devlet Kapısı’ndan önce vatandaşın nüfus müdürlüğüne, vergi dairesine, SGK’ya ayrı ayrı gitmesi gerekiyordu; tek bir işlem için üç farklı kuruma, üç farklı kuyruğa girilirdi. E-Devlet bunu tek pencereye indirdi: aynı giriş, aynı arayüz, farklı işlemler.

GPMC, Active Directory’de GPO yönetimi için bu tek pencereyi sağlar. Konsol, mevcut tüm GPO’ları, hangi OU’lara bağlı olduklarını, Security Filtering ayarlarını ve raporlama araçlarını bir arada sunar. Windows Server’da “Group Policy Management” rolü olarak yüklenir; istemci tarafında ise RSAT (Remote Server Administration Tools) paketiyle bir yönetici makinesinden de açılabilir.

Saha pratiği: GPO değişikliklerini doğrudan Domain Controller üzerinde oturum açıp yapmak yerine, ayrı bir yönetim makinesinden RSAT ile çalışmak; DC’yi gereksiz oturum trafiğinden ve riskten korur. RSAT’ın nasıl kurulduğunu, hangi konsolları getirdiğini ve nereden çalıştırılması gerektiğini RSAT kurulumu rehberimizde ele alıyoruz.

GPO Oluşturma ve Linkleme

Bir düzenleme Resmi Gazete’de yayınlanmadan, ve hangi ile uygulanacağı belirtilmeden bağlayıcı olmaz. Önce metin hazırlanır (GPO oluşturulur), sonra hangi idari sınıra uygulanacağı belirlenir (Site, Domain veya OU’ya linklenir). Metni yazıp çekmecede bırakmak hiçbir şeyi değiştirmez; GPO da link edilmeden hiçbir makineye uygulanmaz.

GPMC’de bir GPO iki yoldan oluşturulur. “Create a GPO in this domain, and Link it here” seçeneği, hem yeni GPO’yu oluşturur hem de seçili OU’ya anında bağlar; tek seferlik, hedefli bir policy için en hızlı yoldur.

“Link an Existing GPO” ise zaten var olan bir GPO’yu başka bir OU’ya da bağlamak için kullanılır; örneğin “USB Kısıtlaması” GPO’su hem Muhasebe hem Satış OU’sunda geçerli olacaksa, GPO bir kez oluşturulur, iki yere linklenir. Aynı ayarı iki kez yazmak yerine tek GPO’yu çoğaltmadan paylaştırmak, yönetim yükünü ciddi şekilde azaltır.

Örnek: USER_ARKA_PLAN GPO’su ile Uçtan Uca Uygulama

Anlatılan teoriyi tek bir somut örnekte baştan sona görmek, parça parça okunan teoriden çok daha kalıcıdır. Bu yüzden burada gerçek bir lab domain’inde (ad.sercebilisim.com), tek bir GPO ile baştan sona bir policy yayalım: hedef, Kullanıcılar OU’sundaki herkesin masaüstünü siyaha çevirmek. Sonucu göz ile doğrulayabileceğimiz için, GPO’nun gerçekten çalıştığını “uygulandı sanıyorum” yerine “uygulandığını gördüm” diyebilecek netlikte kanıtlayabiliriz.

Kullanıcılar OU’suna sağ tıklanıp “Create a GPO in this domain, and Link it here…” seçilir; açılan New GPO penceresinde GPO’ya bir isim verilir: USER_ARKA_PLAN.

Önce siyah bir görsel hazırlanır (siyah.png, düz siyah, 1920×1080) ve her domain üyesinin zaten erişebildiği NETLOGON paylaşımına kopyalanır: \\ad.sercebilisim.com\netlogon\siyah.png. Bu adımı yukarıdaki bilgi kutusundaki ölçütle seçtik: tek bir küçük dosya, tek lokasyon, ayrı bir dosya sunucusu kurmaya değmez.

Görsel yerinde olduğuna göre artık GPO’yu yapılandırabiliriz. Kullanıcılar OU’sunda daha önce oluşturulup linklenmiş USER_ARKA_PLAN GPO’su sağ tıklanıp Edit seçilir; bu, GPMC’nin GPO’yu Group Policy Management Editor’de açmasını sağlar.

Editör açıldığında ayar şu yolda durur: User Configuration → Policies → Administrative Templates → Desktop → Desktop → Desktop Wallpaper. Bu ayara sağ tıklanıp Edit seçilir.

Açılan pencerede ayar Enabled yapılır, Wallpaper Name alanına \\ad.sercebilisim.com\netlogon\siyah.png yazılır, Wallpaper Style olarak Center seçilir.

Default Domain Policy ve Default Domain Controllers Policy

AD kurulumuyla birlikte gelen bu iki GPO, anayasaya benzer: değiştirilebilir ama değiştirilmesi ciddi sonuç doğurur ve sık değiştirilmemesi beklenir. Default Domain Policy, domain genelindeki password policy’yi, hesap kilitleme eşiğini ve Kerberos policy’sini taşır. Default Domain Controllers Policy ise yalnızca DC’lere özel güvenlik ayarlarını (kullanıcı hakları ataması gibi) içerir.

Saha pratiği açıkça şunu gösteriyor: bu iki GPO’ya yazıcı dağıtımı, drive mapping veya yazılım kısıtlaması gibi sıradan ayarları eklemek, anayasaya trafik cezası maddesi eklemek gibi bir karmaşa yaratır. Her ihtiyaç için ayrı, isimlendirilmiş, hedefli bir GPO açmak; sorun olduğunda “hangi GPO bunu yapıyor?” sorusuna dakikalar içinde cevap verme imkânı sağlar.

Aynı disiplin, Tier 0 hesaplarını alt seviye makinelerden men eden bir Deny Logon GPO’su için de geçerlidir: bu ayrı, hedefli bir GPO olarak kurulur ve asla Default Domain Controllers Policy’nin içine gömülmez; kurulumu Active Directory Güvenlik Sıkılaştırması Rehberi makalesinde adım adım ele alınıyor.

GPO Uygulama Sırası: LSDOU

Türkiye’de bir trafik düzenlemesi kademeli işler: önce ülke çapında bağlayıcı bir kararname çıkar, ardından il düzeyinde Vilayet Trafik Komisyonu kendi yerel kararını alır, en sonunda ilçe belediyesi kendi mahallesi için özel bir uygulama getirebilir. Çoğu zaman en yerel karar, en spesifik ihtiyacı karşıladığı için sahada geçerli olan kuraldır; bir ilçenin getirdiği özel düzenleme, ilin genel kararını pratikte gölgede bırakabilir.

Active Directory’de GPO’lar tam olarak bu kademeli mantıkla uygulanır; sıralama LSDOU kısaltmasıyla anılır:

1. Local Policy: makinenin kendi local policy, en içteki katman.
2. Site: fiziksel/ağ konumuna bağlı GPO.
3. Domain: domain genelinde geçerli GPO.
4. OU: kullanıcı veya bilgisayarın bulunduğu OU’ya (parent’tan child’a doğru) bağlı GPO, en dıştaki ve en güçlü katman.

Aynı ayar birden fazla seviyede tanımlıysa, zincirin en sonundaki (en yerel, en spesifik) GPO kazanır. Bir Domain GPO’su ekran kilidini 15 dakika olarak ayarlamışsa ama Muhasebe OU’sundaki GPO bunu 5 dakikaya çekmişse, Muhasebe kullanıcıları 5 dakikada kilitlenir; OU seviyesindeki karar, Domain seviyesindekini geçersiz kılar.

Enforced ve Block Inheritance

Normal şartlarda bir ilçe belediyesi kendi yerel kararını serbestçe alabilir; ama merkezi hükümet bir Olağanüstü Hal Kararnamesi çıkarırsa, yerel makamların aksi kararı geçersiz kalır, merkezin kararı zorla uygulanır. Bazı durumlarda da bir ilçe “biz bu ilin genel uygulamasına tabi değiliz” diyerek kendini izole edebilir.

GPO dünyasında bu iki istisna mekanizması Enforced ve Block Inheritance’tır. Bir GPO Enforced olarak işaretlenirse, normalde onu override edecek olan alt seviyedeki (daha yerel) GPO’lar bile bu GPO’yu geçersiz kılamaz; OHAL kararnamesi gibi davranır. Block Inheritance ise bir OU’nun üst seviyelerden (Domain, Site) gelen tüm GPO mirasını reddetmesini sağlar; ancak Enforced olarak işaretlenmiş bir GPO, Block Inheritance’ı bile delip geçer. Bu iki ayarı aynı OU’da aynı anda kullanırsanız, “GPO neden uygulanmıyor?” bilmecesinin kaynağını büyük ihtimalle burada bulursunuz.

Security Filtering ve WMI Filtering

Bir havalimanı VIP salonuna girmek için iki farklı kontrol uygulanır. Birincisi isim listesi: yalnızca davetli olanlar, yaka kartı kontrolünden geçer. İkincisi bilet sınıfı koşulu: ekonomi sınıfı bileti olan, davetli olsa bile sadece belirli bir bilet tipine sahipse içeri alınır.

GPO’da bu ikiliye Security Filtering ve WMI Filtering denir. Security Filtering, bir GPO’nun yalnızca belirli kullanıcı veya güvenlik gruplarına uygulanmasını sağlar; varsayılan olarak “Authenticated Users” grubuna uygulanan bir GPO, bu grup değiştirilerek örneğin sadece “Muhasebe Kullanıcıları” grubuna daraltılabilir.

WMI Filtering ise donanım veya işletim sistemi koşuluna göre çalışır; “yalnızca dizüstü bilgisayarlara”, “yalnızca Windows 11 makinelere” gibi bir sorgu (WQL) yazılır ve GPO sadece bu koşulu sağlayan bilgisayarlara uygulanır. WMI Filtering’in saha maliyeti unutulmamalı: her oturum açılışında ek bir sorgu çalıştığından, çok sayıda WMI filtreli GPO, oturum açma süresini uzatabilir.

Sık Kullanılan GPO Ayarları

Yeni işe başlayan bir çalışana kurum genelde aynı oryantasyon paketini verir: e-posta hesabı, kartvizit, masaüstü kısayolları, yazıcı tanımı. Tek tek özel talep beklemeden, herkese aynı temel paket otomatik tanımlanır. GPO’da da sahada en sık tekrar eden, “her domain’de mutlaka birinin sorduğu” ayar grubu vardır:

GPO Sorun Giderme

Bir hasta, hangi şikayetle geldiğini anlatmadan doktor ona ilaç yazamaz; önce semptom dinlenir, sonra gerekiyorsa tahlil istenir, tahlil sonucuna göre teşhis konur. GPO sorunlarında da sırayı atlamak, rastgele “gpupdate /force” çalıştırıp şans aramaktan ibaret kalır.

Doğru sıra istemci tarafında başlar:

gpresult /h C:\Temp\GPResult.html
gpresult /r
gpupdate /force

gpresult /h en değerli “tahlil” aracıdır; hangi GPO’ların uygulandığını, hangilerinin Security Filtering veya WMI Filtering nedeniyle filtrelendiğini, hatta hangi ayarın hangi GPO’dan geldiğini okunaklı bir HTML raporunda gösterir. gpresult /r komut satırında hızlı bir özet verir, derin teşhis için yeterli değildir. Sorun istemci tarafında çözülmüyorsa, DC üzerinde Event Viewer’daki Group Policy operasyonel logu ve SYSVOL replikasyon durumu (repadmin /replsummary) kontrol edilir; çoğu “GPO bazı makinelerde uygulanıyor, bazılarında uygulanmıyor” şikayetinin kökeninde SYSVOL replikasyonunun gecikmesi yatar.

Daha önce kurduğumuz USER_ARKA_PLAN örneğine dönelim. Bu testi tekrarlayacaksanız önemli bir nokta: oturum, GPO’nun linklendiği Kullanıcılar OU’sunun içinde bulunan bir kullanıcı hesabıyla açılmalıdır; Domain Admins gibi başka bir OU’daki bir hesapla denenirse GPO hiç uygulanmaz, bu bir hata değil, LSDOU’nun beklenen sonucudur. Kullanıcılar OU’sundaki bir kullanıcı hesabıyla oturum açıp gpresult /h çalıştırdığımızda, rapordaki Applied GPOs listesinde USER_ARKA_PLAN’ın göründüğünü görürüz. Bu, teorinin (“GPO OU’ya linklendi, uygulanacak”) araçla doğrulandığı andır; raporu okumadan “uygulandı sanıyorum” demek yerine, raporda gerçekten göründüğünü görmüş oluruz.

Rapor GPO’nun uygulandığını doğruladıktan sonra geriye tek bir şey kalır: gözle görülen sonuç. Ama burada bir teşhis tuzağına dikkat çekmek gerekir: aşağıdaki ekran görüntüsünde masaüstünün siyah olması, tek başına “bu GPO çalıştı” anlamına gelmez. Masaüstü zaten varsayılan olarak siyah olabilir, kullanıcı kendi tercihiyle siyah bir resim seçmiş olabilir veya ekran kartı sürücüsü görseli yükleyemiyor olabilir; sahada “ekran siyah, demek ki GPO uygulandı” diye düşünüp orada durmak, tam da yanlış teşhise giden kestirme yoldur.

Nedenselliği kuran şey tek bir görsel değil, üç farklı verinin aynı noktada kesişmesidir:

• Hangi GPO: gpresult raporu Applied GPOs listesinde isim isim USER_ARKA_PLAN’ı gösterir.
• Hangi değer: bu GPO’nun Wallpaper Name değeri spesifik olarak \\ad.sercebilisim.com\netlogon\siyah.png dosyasını işaret eder.
• Ne zaman değişti: gpupdate /force ile policy yenilenip oturum tazelendiği anda masaüstü tam bu işlemin hemen ardından siyaha döner.

Üçü birlikte, “ekran zaten siyahtı” ihtimalini eler ve siyahlığın kaynağını spesifik olarak bu GPO’ya bağlar. Bu üçlü zincir (oluştur/linkle → gpresult ile doğrula → gözle kanıtla) GPO’da “muhtemelen çalışıyor” ile “çalıştığını kanıtladım” arasındaki farkı yapan adımdır.

Zincirin son halkası, kullanıcının bu ayarı değiştiremeyeceğinin kanıtıdır. Settings → Personalization → Background ekranı açıldığında artık şu uyarı görünür: “Some of these settings are managed by your organization.” GPO sadece masaüstünü siyaha çevirmekle kalmaz, aynı ayarı kullanıcı müdahalesine de kapatır; bu, Administrative Templates’in Group Policy Preferences’a karşı bir başka avantajıdır, çünkü Preferences kullanıcıya değiştirme özgürlüğü bırakır, Administrative Templates ise ayarı kilitler.

Buradaki her adım Windows Server üzerinde, GPMC ile yapıldı. Merak edenler için not: aynı GPO’yu, aynı adla ve aynı ayarla bir Linux domain controller üzerinde de kurdum. Sonuç birebir aynı çıktı; masaüstü siyaha döndü ve ayar kullanıcıya kapandı. Değişen tek şey ilkeyi oluşturan araçtı, ilkenin kendisi değil. Ölçümleri ve komutları Samba AD DC kurulum rehberimizde bulabilirsiniz.

Loopback Processing

Bir banka şubesindeki gişe bilgisayarını düşünün: o gün hangi memur otursa, ekranda aynı uygulamalar açılır, aynı kısayollar durur. Memurun kendi kullanıcı profili değil, o bilgisayarın bulunduğu rol baskın gelir.

GPO’da bu davranışı Loopback Processing sağlar. Normal şartlarda bir kullanıcının GPO’su hem kendi kullanıcı hesabından hem oturum açtığı bilgisayarın bilgisayar hesabından gelen ayarları birleştirir. Loopback Processing Replace modunda devreye girdiğinde, kullanıcının kendi GPO’ları tamamen göz ardı edilir ve sadece bilgisayarın bulunduğu OU’nun kullanıcı ayarları uygulanır; Merge modunda ise ikisi birleşir ama bilgisayar OU’sununki öncelikli sayılır. Kiosk bilgisayarları, ortak kullanım terminalleri ve Remote Desktop Session Host sunucuları için bu ayar, kullanıcı kim olursa olsun ortamın tutarlı kalmasını garanti eder.

Sonuç: Doğru Kurgulanan GPO Görünmez Bir Omurgadır

Group Policy doğru kurgulandığında görünmez bir omurga gibi çalışır; her sabah yüzlerce makineyi sessizce hizaya sokar. Yanlış kurgulandığında ise teşhisi zor yavaşlamaların ve tutarsız davranışların kaynağı olur. GPO’nun üzerine kurulduğu temel altyapıyı henüz tamamlamadıysanız Active Directory Kurulum Rehberi ve Active Directory DNS Yapılandırması makaleleri başlangıç noktasıdır; kullanıcıların farklı bir UPN ile oturum açması gerekiyorsa UPN Suffix Yapılandırması makalesi konuyu ele alır.

Bu makalede sürekli referans verdiğimiz OU ağacının nasıl tasarlanacağı, hangi kullanıcı ve grupların hangi OU’da yer alacağı Active Directory Kullanıcı, Grup ve OU Yönetimi makalesinde ele alınır; GPO’yu doğru hedefe linklemek, önce o hedefin doğru kurulmuş olmasını gerektirir. Active Directory Rehberi ana eksende konuyu çevreleyen kullanıcı, grup ve güvenlik katmanlarına bütün halinde bakmanızı öneririz.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn