Merhaba

Serinin ilk bölümünde bir GPO’nun (Group Policy Object) AD (Active Directory) ve SYSVOL (System Volume) içinde nasıl tutulduğunu inceledik ve ilk GPO’muzla Satış kullanıcılarının ekranını 15 dakika sonra kilitledik. O GPO’da kullandığımız ayarların hepsi Policies dalındaki Administrative Templates ayarlarıydı. Ancak her GPO’nun içinde ikinci bir büyük dal daha var: Preferences.

Policy ve Preference aynı GPO içinde durur, aynı düzenleyiciyle yapılandırılır ve aynı istemciye uygulanır. Buna rağmen davranışları çok farklıdır. Bir ayarı yanlış dalda yapılandırmak, GPO kaldırıldığında bile makinelerde kalan hayalet ayarlara, kullanıcının değiştirdiği ama her yenilemede geri gelen değerlere ya da yıllar önce SYSVOL’a yazılmış ve herkes tarafından okunabilen parolalara yol açabilir.

Bu bölümde Policy ile Preference arasındaki farkı, tattooing davranışını, GPP (Group Policy Preferences) action’larını, Common sekmesindeki seçenekleri ve Item-level targeting özelliğini ele alıyor, ardından bakicubuk.tech lab ortamımızda bir drive eşlemesi, bir registry değeri ve bir masaüstü kısayolu dağıtıyoruz. Son olarak üç farklı ayar türünün GPO kapsam dışına çıktığında nasıl davrandığını yan yana test ediyor ve GPP’nin güvenlik tarafına bakıyoruz.

1. Policy ve Preference Arasındaki Fark

Kısa formül şu: Policy zorunlu kuraldır, Preference ise yapılandırılabilir varsayılandır.

Bölüm 1‘de yaptığımız ekran kilidi ayarı tipik bir Policy örneğidir: kullanıcı ekran koruyucu süresini değiştiremez, çünkü bu bir güvenlik kuralıdır. Satış ekibinin ortak klasörünü S: sürücüsü olarak eşlemek ise tipik bir Preference örneğidir: amaç kullanıcıyı kısıtlamak değil, ona hazır bir çalışma ortamı sunmaktır.

GPP, Windows Server 2008 ile birlikte geldi. Öncesinde drive eşleme, yazıcı ekleme, registry değeri yazma ve kısayol oluşturma gibi işler logon script’leriyle yapılıyordu. GPP bu işleri GPMC (Group Policy Management Console) arayüzüne taşıdı ve script yazma ihtiyacını büyük ölçüde ortadan kaldırdı.

2. Tattooing: GPO Kaldırıldığında Ne Olur?

Policy ile Preference arasındaki en önemli pratik fark, GPO kapsam dışına çıktığında ortaya çıkar. Kapsam dışına çıkmak şu durumlardan biri olabilir: GPO silinir, link’i kaldırılır ya da devre dışı bırakılır, kullanıcı ya da bilgisayar başka bir OU’ya (Organizational Unit) taşınır ya da Security Filtering ile dışarıda kalır.

Policy ayarları registry’de özel Policies anahtarlarına yazılır. Örneğin Bölüm 1‘deki ekran koruyucu ayarları HKCU\Software\Policies\Microsoft\Windows\Control Panel\Desktop altına yazıldı (HKCU, HKEY_CURRENT_USER). Windows, GPO kapsam dışına çıktığında bu anahtarları temizler ve ayar kullanıcının kendi tercihine geri döner.

Preference ayarları ise uygulamanın normal registry konumuna, dosya sistemine ya da ilgili nesneye doğrudan yazılır. Windows bu değerin bir GPO’dan mı geldiğini, kullanıcı tarafından mı ayarlandığını ayırt edemez. GPO kapsam dışına çıktığında, özel bir seçenek işaretlenmediyse değer olduğu yerde kalır. Buna tattooing (dövme) denir: ayar makineye dövme gibi işlenir ve GPO’yu kaldırarak geri alınamaz.

Tattooing her zaman kötü bir şey değildir. Bir kullanıcıya ilk oturumda masaüstü kısayolu oluşturmak istiyorsak, GPO kaldırıldığında kısayolun da kaybolmasını istemeyebiliriz. Ancak bir drive eşlemesi, bir yerel grup üyeliği ya da bir servis yapılandırması söz konusu olduğunda, GPO kaldırıldığında ayarın da kalkmasını genellikle isteriz. Bunun için Preference öğelerinde Remove this item when it is no longer applied seçeneğini kullanıyoruz. Bu seçeneği aşağıda Common sekmesi başlığında detaylı ele alıyoruz.

3. GPP Kategorileri

Preferences dalı, hem Computer Configuration hem de User Configuration altında iki ana gruba ayrılır: Windows Settings ve Control Panel Settings. Bazı öğeler yalnızca bir tarafta bulunur.

Bu listedeki her öğe istemcide ayrı bir CSE (Client-Side Extension) tarafından işlenir. Bir GPO’ya Drive Maps öğesi eklediğimizde, Bölüm 1‘de gördüğümüz gPCUserExtensionNames özniteliğine Drive Maps CSE’sinin GUID (Globally Unique Identifier) değeri de eklenir. Preference öğeleri SYSVOL’daki GPT (Group Policy Template) klasörünün Machine\Preferences ve User\Preferences alt klasörlerinde XML (Extensible Markup Language) dosyaları olarak tutulur.

4. GPP Action’ları

Çoğu Preference öğesinin istemcide nasıl davranacağını belirleyen bir Action değeri vardır.

Günlük kullanımda en dengeli seçim çoğunlukla Update‘tir: öğe yoksa oluşturur, varsa yalnızca bizim tanımladığımız özelliklere dokunur ve kullanıcının diğer özelleştirmelerini korur. Replace her yenilemede öğeyi silip yeniden oluşturduğu için kullanıcının yaptığı özelleştirmeleri siler. Drive eşlemelerinde de her yenilemede bağlantının kısa süreliğine kopup yeniden kurulmasına yol açabilir. Create ise yalnızca öğe hiç yoksa çalışır. Kullanıcı öğeyi değiştirirse ya da silerse, Create action’ı bir dahaki yenilemede silinen öğeyi yeniden oluşturur ama değiştirilmiş öğeye dokunmaz.

CRUD (Create, Replace, Update, Delete) action’ları yalnızca gerçekten oluşturulup silinebilen nesneler için anlamlıdır: drive eşlemeleri, kısayollar, yazıcılar, registry değerleri, dosyalar. Folder Options ya da Power Options gibi yalnızca bir değer tutan bazı öğelerde Action seçeneği bulunmaz.

5. Common Sekmesi Seçenekleri

Her Preference öğesinin bir de Common sekmesi vardır. Buradaki seçenekler öğenin işlenme şeklini değiştirir.

Güvenlik bağlamı: User Configuration altındaki Preference öğeleri varsayılan olarak SYSTEM hesabının bağlamında işlenir. Bu, kullanıcının kendisinin yetkisi olmayan işleri yapabilmesini sağlar. Ancak SYSTEM hesabı, kullanıcının ağ kaynaklarına onun kimliğiyle erişemez. Kullanıcının kendi yetkileriyle erişmesi gereken bir paylaşıma bağlanan öğelerde (Drive Maps, Printers gibi) Run in logged-on user's security context seçeneğini işaretliyoruz.

Remove this item when it is no longer applied: Bu seçenek tattooing’in Preference tarafındaki çözümüdür. İşaretlendiğinde Action’ın otomatik olarak Replace moduna geçmesinin nedeni şudur: Windows’un öğenin kapsam dışına çıktığını güvenilir şekilde anlayıp kaldırabilmesi için, öğeyi her yenilemede kendisinin oluşturduğundan emin olması gerekir.

Apply once and do not reapply: Varsayılan olarak Preference öğeleri her Group Policy yenilemesinde yeniden uygulanır. Kullanıcı GPO’dan gelen bir registry değerini değiştirirse, bir sonraki yenilemede GPO’daki değer geri gelir. Bu seçenek işaretlendiğinde öğe yalnızca bir kez uygulanır ve kullanıcının sonraki değişikliklerine dokunulmaz. Remove this item when it is no longer applied ile birlikte kullanılamaz.

6. Item-level Targeting

Item-level targeting, tek bir Preference öğesini belirli koşullara göre hedeflememizi sağlar. Klasik yaklaşımda Satış kullanıcılarına S: sürücüsü, Muhasebe kullanıcılarına M: sürücüsü için iki ayrı GPO ve iki ayrı OU kullanırdık. Item-level targeting ile tek bir GPO içinde iki ayrı Drive Maps öğesi oluşturup her birini ilgili güvenlik grubuna hedefleyebiliriz.

Sık kullanılan hedefleme türleri şunlardır:

Hedefleme öğeleri And ve Or ile birleştirilebilir, Is Not ile tersine çevrilebilir ve Collection ile gruplanabilir. Örneğin “GG_Satis grubunun üyesi And Windows 11 And Not dizüstü bilgisayar” gibi bir koşul tek bir öğe üzerinde tanımlanabilir.

Item-level targeting, Bölüm 4’te işleyeceğimiz WMI (Windows Management Instrumentation) Filtering’e göre daha hafiftir: WMI filtresi bütün GPO’yu etkiler ve her yenilemede istemcide WMI sorgusu çalıştırır. Item-level targeting ise yalnızca ilgili öğeyi etkiler ve çoğu hedefleme türü WMI kullanmaz.

7. Uygulama: Lab Ortamında Preference Dağıtımı

Bu bölümün uygulama kısmında Satış kullanıcıları için yeni bir GPO oluşturuyor ve içine üç Preference öğesi ekliyoruz:

Ardından GPO’yu istemcide doğruluyor, son adımda da Bölüm 1‘deki Policy ayarıyla bu üç öğenin GPO kapsam dışına çıktığında nasıl davrandığını yan yana karşılaştırıyoruz.

Adım 1: Güvenlik grubunun ve paylaşımın hazırlanması

Drive eşlemesini ve Item-level targeting’i göstermek için önce Satış kullanıcıları için bir güvenlik grubu oluşturuyor ve test kullanıcımızı bu gruba ekliyoruz. Grup adındaki GG_ öneki, grubun Global Group türünde olduğunu gösteren yaygın bir isimlendirme alışkanlığıdır:

New-ADGroup -Name "GG_Satis" -GroupScope Global -GroupCategory Security -Path "OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech" -Description "Satış ekibi kullanıcıları"
Add-ADGroupMember -Identity "GG_Satis" -Members "nihat.cubuk"
Get-ADGroupMember -Identity "GG_Satis" | Select-Object Name, SamAccountName

Ardından eşlenecek ortak klasörü ve paylaşımı oluşturuyoruz. Lab ortamımızda ayrı bir dosya sunucusu olmadığı için paylaşımı domain controller üzerinde açıyoruz:

New-Item -Path "C:\Paylasim\Satis" -ItemType Directory
New-SmbShare -Name "Satis" -Path "C:\Paylasim\Satis" -ChangeAccess "BAKICUBUK\GG_Satis" -FullAccess "BAKICUBUK\Domain Admins"
icacls "C:\Paylasim\Satis" /grant "BAKICUBUK\GG_Satis:(OI)(CI)M"

New-SmbShare komutu SMB (Server Message Block) paylaşımını oluşturur ve paylaşım izinlerini tanımlar. icacls komutu ise klasörün NTFS (New Technology File System) izinlerine GG_Satis grubu için Modify yetkisi ekler. (OI)(CI) ifadesi bu iznin alt klasör ve dosyalara da aktarılacağını gösterir. Bir kullanıcının paylaşımdaki dosyalara erişebilmesi için hem paylaşım hem de NTFS izninin olması gerekir, geçerli olan ikisinden daha kısıtlayıcı olanıdır.

Adım 2: GPO’nun oluşturulması

Bölüm 1‘deki yaklaşımı izliyoruz: GPO’yu önce Group Policy Objects konteynerinde oluşturuyor, ayarlarını tamamlıyor ve en son link ediyoruz. GPMC’de Group Policy Objects konteynerine sağ tıklıyor, New seçiyor ve GPO’ya U - Satis - Tercihler adını veriyoruz. Source Starter GPO alanını (none) olarak bırakıp OK diyoruz. Bu GPO da yalnızca User Configuration ayarları içereceği için adın başında U var.

GPO’ya sağ tıklayıp Edit ile Group Policy Management Editor’ı açıyor ve User Configuration > Preferences dalını genişletiyoruz. Bu dalın altında Windows Settings ve Control Panel Settings gruplarını ve 3. bölümdeki tabloda gördüğümüz öğeleri görürüz.

Adım 3: Drive Maps öğesinin oluşturulması

User Configuration > Preferences > Windows Settings > Drive Maps öğesine sağ tıklıyor ve New > Mapped Drive seçiyoruz. Drive Maps seçiliyken sağ panelin farklı bir görünümde olduğuna dikkat edelim: Preferences öğelerinde düzenleyici, sol tarafta Processing ve Description kutuları, sağ tarafta da öğe listesi bulunan özel bir görünüm kullanır. Liste şu an boştur (There are no items to show in this view).

Açılan New Drive Properties penceresinde iki sekme bulunur: General sekmesi öğenin kendisini, Common sekmesi ise 5. başlıkta anlattığımız ortak seçenekleri içerir. Pencere ilk açıldığında Action alanı varsayılan olarak Update gelir. Location alanı boş olduğu için Reconnect kutusu ve sürücü harfi seçenekleri henüz pasiftir, paylaşım yolunu girdiğimizde etkinleşirler.

Connect as (optional) bölümündeki User name ve Password alanlarının gri ve kullanılamaz olduğunu da görüyoruz. Bu alanlar eskiden paylaşıma farklı bir hesapla bağlanmak için kullanılıyordu ve girilen parola SYSVOL’a yazılıyordu. MS14-025 güncellemesiyle devre dışı bırakıldılar. Nedenini güvenlik başlığında detaylı açıklıyoruz.

General sekmesinde şu alanları dolduruyoruz:

Location alanında sunucu adı yerine DFS (Distributed File System) namespace yolu da kullanılabilir. Üretim ortamında \\bakicubuk.tech\Paylasim\Satis gibi bir DFS namespace yolu kullanmak, dosya sunucusu değiştiğinde GPO’ya dokunmadan geçiş yapmayı sağlar.

Ardından Common sekmesine geçiyoruz. Varsayılan olarak buradaki seçeneklerin hiçbiri işaretli değildir. Run in logged-on user's security context (user policy option) seçeneğinin de işaretsiz geldiğine dikkat edelim.

Önce Remove this item when it is no longer applied seçeneğini işaretliyoruz. Ekrana Group Policy – Mode Change Warning başlıklı bir uyarı gelir ve bu seçeneğin öğeyi Replace moduna geçireceğini bildirir (This will cause a change to ‘Replace’ mode). Bu, 5. başlıkta anlattığımız davranışın kendisidir: Windows’un öğeyi kapsam dışına çıktığında güvenilir şekilde kaldırabilmesi için her yenilemede kendisinin oluşturması gerekir. OK diyoruz.

Ardından Run in logged-on user's security context (user policy option) seçeneğini işaretliyoruz. Bu seçenek işaretli olmazsa öğe SYSTEM hesabının bağlamında işlenir. Drive eşlemesinin ise paylaşıma kullanıcının kendi kimliğiyle bağlanması ve eşlemenin kullanıcının oturumunda görünmesi gerekir. Bu iki seçeneği işaretledikten sonra Apply once and do not reapply seçeneğinin gri ve kullanılamaz hale geldiğini görüyoruz: bir öğe hem kapsam dışında kaldır hem de yalnızca bir kez uygula olamaz.

Son olarak Item-level targeting seçeneğini işaretliyoruz. Bu kutu işaretlenince yanındaki Targeting… seçeneği etkinleşir. Targeting… seçeneğine tıklıyoruz.

Targeting Editor penceresi açılır. Üstteki New Item menüsünü açtığımızda kullanabileceğimiz tüm hedefleme türlerini görürüz: Battery Present’tan WMI Query’ye kadar 27 farklı tür bulunur. 6. başlıktaki tabloda bunların en sık kullanılanlarını özetlemiştik. Listeden Security Group seçiyoruz.

Pencerenin üst kısmına the user is a member of the security group ifadesiyle bir hedefleme öğesi eklenir. Alt kısımda öğenin ayarları bulunur: Group alanı, Primary group kutusu ve User in group ile Computer in group seçenekleri. User in group varsayılan olarak seçilidir ve koşulun oturum açan kullanıcının grup üyeliğine göre değerlendirileceğini gösterir. Computer in group seçilirse bilgisayar hesabının grup üyeliğine bakılır. Grubu seçmek için Group alanının yanındaki … düğmesine tıklıyoruz.

Açılan Select Group penceresinde Enter the object name to select alanına GG_Satis yazıyor ve OK diyoruz. Adı tam hatırlamıyorsak Check Names düğmesiyle AD’de doğrulatabiliriz.

Group alanına BAKICUBUK\GG_Satis yazılır ve hemen altındaki SID (Security Identifier) alanı da grubun SID değeriyle dolar. Hedefleme öğesi grubu adıyla değil bu SID ile tanır. Bu sayede grubun adı ileride değiştirilse bile hedefleme çalışmaya devam eder. Üstteki ifade de the user is a member of the security group BAKICUBUK\GG_Satis olarak güncellenir. OK ile Targeting Editor’ı kapatıyoruz.

Common sekmesine geri döndüğümüzde üç seçeneğin işaretli olduğunu kontrol ediyor ve Apply, ardından OK diyoruz.

Drive Maps listesinde yeni öğe S: adıyla görünür. Action sütununda Replace, Path sütununda \\W25DC\Satis ve Reconnect sütununda Yes yazar. Öğenin ikonu da Replace action’ını gösteren kırmızı işareti taşır. Öğeyi seçtiğimizde soldaki Processing kutusu, Common sekmesindeki seçeneklerin özetini gösterir:

Bu kutu, bir öğenin nasıl davranacağını her seferinde özellikler penceresini açmadan kontrol etmemizi sağlar. Pencerenin altındaki Last changed satırı da öğenin en son ne zaman değiştirildiğini gösterir.

Adım 4: Registry öğesinin oluşturulması

User Configuration > Preferences > Windows Settings > Registry öğesine sağ tıklıyor ve New > Registry Item seçiyoruz.

Burada üç seçenek bulunur:

Tek bir değer yazacağımız için Registry Item seçiyoruz.

Açılan New Registry Properties penceresinde Action varsayılan olarak Update, Hive ise HKEY_CURRENT_USER olarak gelir. User Configuration altında olduğumuz için bu mantıklı bir varsayılandır: Kullanıcıya özel ayarlar HKEY_CURRENT_USER altında tutulur. Value type ve Value data alanları henüz pasiftir, değer adını girdiğimizde etkinleşirler.

Şu değerleri giriyoruz:

Value type listesinde registry’nin desteklediği temel değer türleri bulunur:

Dikkat edersek bu anahtar Software\Policies altında değil, doğrudan Software altında. Yani bu değer bir Policy değil, sıradan bir uygulama ayarı gibi yazılacak. Bu öğenin Common sekmesinde hiçbir seçeneği işaretlemiyoruz, çünkü 9. adımdaki tattooing testinde varsayılan davranışı göreceğiz. Apply, ardından OK ile pencereyi kapatıyoruz.

Registry listesinde yeni öğe Departman adıyla görünür. Sütunlarda öğenin özeti yer alır: Action Update, Hive HKEY_CURRENT_USER, Key Software\BakicubukLab, Value Name Departman, Type REG_SZ ve Value Data Satis. Öğenin ikonundaki sarı işaret Update action’ını, ab simgesi ise değerin metin (REG_SZ) türünde olduğunu gösterir. Bu öğede Common sekmesinde hiçbir seçenek işaretlemedik, yani Remove this item when it is no longer applied kapalı. 9. adımdaki tattooing testinde bu farkın sonucunu göreceğiz.

Adım 5: Shortcuts öğesinin oluşturulması

User Configuration > Preferences > Windows Settings > Shortcuts öğesine sağ tıklıyor ve New > Shortcut seçiyoruz. Registry öğesinin aksine burada Collection Item ya da sihirbaz seçeneği yoktur, yalnızca Shortcut bulunur.

Açılan New Shortcut Properties penceresinde Action varsayılan olarak Update, Target type File System Object, Location ise <Specify full path> olarak gelir. Location alanında tam yol girmek yerine açılır listeden hazır konumlardan birini seçebiliriz. Bu konumlar her kullanıcı için doğru klasöre otomatik olarak çözülür:

buradakaldım.  – İcon resmi düzeltilecek.

Şu değerleri giriyoruz:

İkonu seçmek için Icon file path alanının yanındaki … düğmesine tıklıyoruz. Açılan Change Icon penceresi varsayılan olarak %SystemRoot%\System32\SHELL32.dll dosyasını açar ve içindeki ikonları listeler. SHELL32.dll, Windows’un klasör, sürücü, yazıcı gibi temel kabuk (shell) ikonlarını barındıran dosyadır. Listeden yeşil bağlantı çubuğu olan ağ sürücüsü ikonunu seçip OK diyoruz. Icon file path alanına dosyanın yolu, Icon index alanına da seçtiğimiz ikonun sıra numarası olan 9 kendiliğinden yazılır. Farklı bir dosyadaki ikonları görmek için pencerenin Browse düğmesi kullanılabilir.

%SystemRoot% bir ortam değişkenidir ve istemcide Windows klasörünün yoluna (genellikle C:\Windows) çözülür. Yolları sabit yazmak yerine ortam değişkenleri kullanmak, Windows’un farklı bir sürücüye kurulduğu makinelerde de öğenin doğru çalışmasını sağlar. imageres.dll Windows’un sistem ikonlarını barındıran dosyalardan biridir. Apply, ardından OK ile pencereyi kapatıyoruz.

Shortcuts listesinde yeni öğe görünür: Action sütununda Update, Target sütununda S:\ yazar. Shortcut sütununda ise %DesktopDir%\Satis Ortak Klasor değerini görüyoruz. %DesktopDir%, Location alanında Desktop seçtiğimiz için GPP’nin kullandığı bir değişkendir ve istemcide oturum açan kullanıcının masaüstü klasörüne çözülür. Böylece tek bir öğe, her kullanıcının kendi masaüstüne kısayol oluşturur. Update action’ının ikonu sarıdır.

Target path olarak S: sürücüsünü kullandığımız için kısayol, Drive Maps öğesine bağlı çalışır. Kullanıcı GG_Satis grubunda değilse S: sürücüsü eşlenmez ve kısayol açılmaz. Bu durumu önlemek için kısayola da aynı Item-level targeting koşulunu ekleyebiliriz. Lab’da kısayolu, 8. adımdaki testte bu bağımlılığı göstermek için bilerek hedeflemesiz bırakıyoruz.

Üç Preference öğesini tamamladıktan sonra Group Policy Management Editor’ı kapatıyoruz. Düzenleyicide ayrıca kaydet düğmesi yoktur, her öğede Apply ya da OK dediğimiz anda değişiklik GPO’ya yazılmıştır.

Adım 6: GPO’nun link edilmesi ve GPO Status ayarı

GPO hazır olduğuna göre artık onu kullanıcıların bulunduğu OU’ya link edebiliriz. GPMC’de LAB > Kullanicilar > Satis OU’suna sağ tıklıyor ve Link an Existing GPO seçiyoruz. Arka planda Satis OU’sunun Linked Group Policy Objects sekmesinde Bölüm 1‘de link ettiğimiz U - Satis - Ekran Kilidi GPO’sunun zaten bulunduğunu görüyoruz.

Açılan Select GPO penceresinde domain’deki tüm GPO’lar listelenir. U - Satis - Tercihler GPO’sunu seçip OK diyoruz.

GPO Status ayarı: Kullanılmayan yarının devre dışı bırakılması

Bu GPO’ya eklediğimiz üç öğenin üçü de User Configuration altında. Computer Configuration tarafında hiçbir ayar yok. Bölüm 1‘de anlattığımız gibi, kullanılmayan yarıyı devre dışı bırakmak iki fayda sağlar: istemci bu GPO’yu işlerken Computer Configuration tarafına hiç bakmaz ve gereksiz işlem yapmaz, GPO’yu inceleyen bir yönetici de GPO’nun yalnızca kullanıcı ayarları içerdiğini ilk bakışta anlar.

GPMC’nin sol panelinde Group Policy Objects konteynerini genişletiyor ve U - Satis - Tercihler GPO‘suna sağ tıklıyoruz. Sağ paneldeki Scope sekmesinde, az önce yaptığımız Satis link’inin göründüğüne dikkat edelim. Açılan menüde GPO Status seçeneğinin üzerine geldiğimizde dört seçenek görürüz:

Şu an Enabled seçeneğinin yanında onay işareti olduğunu, yani GPO’nun iki yarısının da etkin olduğunu görüyoruz. Computer Configuration Settings Disabled seçeneğini tıklıyoruz. Aynı ayara, Group Policy Objects konteynerini seçip sağ paneldeki listeden ya da GPO’yu seçip Details sekmesindeki GPO Status açılır listesinden de ulaşabiliriz.

GPO Status ayarı bir GPO ayarı değil, GPO’nun kendi özelliğidir. Bölüm 1‘de gördüğümüz GPC (Group Policy Container) nesnesinin flags özniteliğine yazılır ve GPO’nun sürüm numarasını değiştirmez. Bu ayarı link’ten sonra yapmamız sorun değildir: GPO Status link’in değil GPO’nun özelliğidir ve GPO’nun bağlı olduğu tüm link’lerde aynı anda geçerli olur. Bu GPO’da Computer Configuration tarafında zaten ayar olmadığı için, aradaki kısa sürede istemcilere uygulanan bir şey de yoktur. Değişikliğin uygulandığını aşağıda Linked Group Policy Objects listesindeki GPO Status sütunundan ve Settings raporundaki Computer Configuration (Disabled) başlığından doğruluyoruz.

Satis OU’sunun Linked Group Policy Objects sekmesinde artık iki GPO görünür: Bölüm 1‘deki U - Satis - Ekran Kilidi ve yeni link ettiğimiz U - Satis - Tercihler. Yeni link edilen GPO listenin sonuna eklenir ve Link Order değeri 2 olur. Link Order, aynı OU’ya link edilmiş GPO’ların işlenme önceliğini gösterir ve 1 en yüksek önceliktir. Bu iki GPO farklı ayarlar yapılandırdığı için aralarında çakışma yoktur ve sıra sonucu etkilemez. Link Order’ın önem kazandığı çakışma senaryolarını Bölüm 3’te işleyeceğiz. Az önce yaptığımız GPO Status ayarının sonucu olarak her iki GPO’nun da GPO Status sütununda Computer configuration settings disabled yazdığını görüyoruz.

Son olarak GPMC’de Group Policy Objects altında U - Satis - Tercihler GPO’sunu seçip Settings sekmesine geçiyoruz. GPMC, GPO’daki tüm ayarları bir HTML (HyperText Markup Language) raporu olarak gösterir. Raporun General bölümünde Details, Links, Security Filtering ve Delegation başlıkları, altında ise Computer Configuration ve User Configuration bölümleri yer alır. Computer Configuration bölümünün başlığında (Disabled) yazması, GPO Status ayarımızın uygulandığını gösterir. User Configuration altında Preferences > Windows Settings başlığı altında üç öğemizi görürüz: Drive Map (Drive: S), Registry altında Departman (Order: 1) ve Shortcuts altında Shortcut (Path: %DesktopDir%\Satis Ortak Klasor).

Her başlığın sağındaki show bağlantısı o bölümün ayrıntılarını açar, sağ üstteki show all ise tüm raporu genişletir. Örneğin Drive Map satırında show dediğimizde, eşlemenin özellikleriyle birlikte Common sekmesindeki seçenekleri ve the user is a member of the security group BAKICUBUK\GG_Satis hedefleme koşulunu da görürüz. Bu rapor, bir GPO’yu düzenleyiciyi açmadan incelemenin en hızlı yoludur. Raporu sağ tıklayıp Save Report ile HTML dosyası olarak kaydetmek de mümkündür.

Adım 7: İstemcide doğrulama

Test kullanıcısını GG_Satis grubuna yeni eklediğimiz için, istemcide oturumu kapatıp yeniden açmamız gerekiyor. Kullanıcının grup üyelikleri, oturum açarken alınan Kerberos bileti ve erişim belirtecine (access token) yazılır. Oturum açıkken gruba eklenen kullanıcı, oturumu yenilenene kadar bu üyeliği kullanamaz. Bu yüzden gpupdate /force tek başına yeterli olmaz: Item-level targeting koşulu kullanıcıyı hala grubun üyesi değilmiş gibi görür.

Nihat Cubuk ([email protected]) kullanıcısıyla oturumu kapatıp yeniden açıyoruz. Ardından normal Run as administrator (Yönetici olarak çalıştır) ile çalıştırılmayan bir PowerShell penceresinde şu komutları çalıştırıyoruz:

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

gpresult çıktısının USER SETTINGS bölümünde kullanıcının DN (Distinguished Name) bilgisinin CN=Nihat Cubuk,OU=Satis,OU=Kullanicilar,OU=LAB,DC=bakicubuk,DC=tech olduğunu, yani kullanıcının doğru OU’da bulunduğunu görüyoruz. Applied Group Policy Objects altında artık iki GPO listelenir: Bölüm 1‘deki U - Satis - Ekran Kilidi ve yeni eklediğimiz U - Satis - Tercihler. Çıktının en altındaki The user is a part of the following security groups listesinde de GG_Satis grubu yer alır.

whoami /groups komutu, kullanıcının o anki oturumunun erişim belirtecindeki grupları listeler. findstr GG_Satis ile çıktıyı yalnızca bu grubun satırına süzüyoruz. Satırda grubun adı (BAKICUBUK\GG_Satis), türü (Group), SID değeri ve özellikleri (Mandatory group, Enabled by default, Enabled group) görünür. Buradaki SID değerinin, Adım 3’te Targeting Editor’da gördüğümüz SID ile aynı olduğuna dikkat edelim: Item-level targeting koşulu tam olarak bu SID’i oturumun erişim belirtecinde arar. Grup bu listede görünmüyorsa, kullanıcı oturumu kapatıp açmamış demektir.

Şimdi üç Preference öğesinin sonucunu tek tek kontrol ediyoruz. File Explorer‘ı açıp This PC görünümüne geçiyoruz. Yerel diskler Devices and drives başlığı altında, eşlenen ağ sürücüleri ise ayrı bir Network locations başlığı altında görünür. Burada Satis Ortak (S:) sürücüsünü görüyoruz. Sürücünün adı, Drive Maps öğesinin Label as alanına yazdığımız Satis Ortak değeridir. Bu alan boş bırakılsaydı sürücü Satis (\\W25DC) (S:) biçiminde, paylaşım ve sunucu adıyla görünürdü.

Masaüstünde de Satis Ortak Klasor kısayolu oluşmuş olmalı. Kısayolun ikonu, Shortcuts öğesinde SHELL32.dll dosyasından seçtiğimiz ağ sürücüsü ikonudur. Kısayola çift tıkladığımızda S: sürücüsü açılır.

Registry değerini ve sürücü eşlemesini PowerShell ile de kontrol ediyoruz:

Get-ItemProperty -Path "HKCU:\Software\BakicubukLab" | Select-Object Departman
Get-PSDrive S

Get-ItemProperty komutu registry anahtarındaki değerleri okur. HKCU: PowerShell’in HKEY_CURRENT_USER için kullandığı kısa yoldur. Çıktıda Departman değerinin Satis olduğunu görüyoruz. Get-PSDrive S komutu ise S: sürücüsünün bilgilerini getirir: Provider sütununda FileSystem, Root sütununda ise sürücünün bağlı olduğu paylaşım \\W25DC\Satis yazar. Used ve Free sütunları paylaşımın bulunduğu diskin doluluk durumunu gösterir.

Aynı değeri grafik arayüzde görmek için regedit ile HKEY_CURRENT_USER\Software\BakicubukLab anahtarını açıyoruz. Sağ panelde Departman değerinin REG_SZ türünde ve Satis verisiyle durduğunu görüyoruz. Yanındaki (Default) satırı her registry anahtarında bulunan adsız varsayılan değerdir. Registry öğesinde Default kutusunu işaretlemediğimiz için (value not set) olarak kalır.

Preference ile Policy arasındaki farkı görmek için küçük bir deneme yapıyoruz. regedit’te Departman değerine çift tıklayıp Muhasebe olarak değiştiriyoruz. Bölüm 1‘deki ekran koruyucu ayarlarının aksine bu değeri değiştirebiliyoruz, çünkü bir Policy değil Preference ile yazıldı. Ardından PowerShell’de gpupdate /force çalıştırıp regedit’te F5 ile görünümü yeniliyoruz: değer tekrar Satis olur. Preference öğeleri varsayılan olarak her Group Policy yenilemesinde yeniden uygulanır. Kullanıcı değeri değiştirebilir, ama GPO bir sonraki yenilemede kendi değerini geri yazar.

Adım 8: Item-level targeting testi

Item-level targeting’in çalıştığını görmek için test kullanıcısını GG_Satis grubundan geçici olarak çıkarıyoruz. Komut başarılı olduğunda herhangi bir çıktı vermez, -Confirm:$false parametresi de onay sorusunu atlar:

Remove-ADGroupMember -Identity "GG_Satis" -Members "nihat.cubuk" -Confirm:$false

İstemcide oturumu kapatıp yeniden açıyoruz. İlk oturumda ilginç bir durumla karşılaşabiliriz: S: sürücüsü File Explorer’da hala görünür, ancak açmaya çalıştığımızda Windows cannot access \W25DC\Satis ve You do not have permission to access hatası alırız.

Bu ara durumun iki nedeni vardır. Birincisi, paylaşım ve NTFS izinleri GG_Satis grubuna verildiği için, yeni oturumda grup üyeliği olmayan kullanıcı paylaşıma artık erişemez. Bu kısım anında çalışır. İkincisi, Drive Maps öğesinde Reconnect işaretli olduğu için eşleme kalıcıdır: Windows, oturum açılırken kayıtlı sürücüleri Group Policy’den bağımsız olarak kendisi yeniden bağlar. Windows 10 ve 11 ayrıca varsayılan olarak Fast Logon Optimization ile çalışır: oturum, Group Policy işlenmesi beklenmeden açılır ve Preference öğeleri arka planda işlenir. Bu yüzden eşlemenin kaldırılması bir sonraki oturumda ya da arka plan yenilemesinde görünür hale gelir.

İstemcide oturumu bir kez daha kapatıp açtığımızda (ya da gpupdate /force çalıştırıp oturumu yenilediğimizde) S: sürücüsünün artık listede olmadığını görüyoruz. Kullanıcı hala Satis OU’sunda olduğu için GPO uygulanmaya devam ediyor, ancak Drive Maps öğesinin hedefleme koşulu sağlanmadığı için o öğe işlenmiyor. Remove this item when it is no longer applied seçeneği işaretli olduğu için de önceki oturumdan kalan eşleme kaldırılıyor. Registry değeri ve masaüstü kısayolu ise hedeflemesiz oldukları için yerinde duruyor. Masaüstündeki kısayolu açmayı denersek, S: sürücüsü olmadığı için hata alırız. Bu da, bağımlı öğelere aynı hedeflemeyi vermenin neden önemli olduğunu gösterir.

Testten sonra kullanıcıyı tekrar gruba ekliyoruz ve istemcide oturumu kapatıp açıyoruz:

Add-ADGroupMember -Identity "GG_Satis" -Members "nihat.cubuk"

İstemcide oturumu kapatıp açtıktan sonra S: sürücüsünün tekrar File Explorer’da göründüğünü kontrol ediyoruz. Kaldırmada olduğu gibi, sürücünün geri gelmesi de ikinci oturumu gerektirebilir.

Adım 9: Tattooing testi: Policy ve Preference yan yana

Şimdi bölümün en öğretici testini yapıyoruz: Satis OU’sundaki iki GPO’yu aynı anda kapsam dışına çıkarıyor ve dört farklı ayarın ne olduğuna bakıyoruz. GPO’ları silmek yerine link’lerini devre dışı bırakıyoruz. GPMC’de Satis OU’sunun Linked Group Policy Objects sekmesinde her iki GPO’ya sırayla sağ tıklıyor ve Link Enabled seçeneğinin işaretini kaldırıyoruz. Link Enabled sütununda iki GPO için de No yazmalı.

İstemcide gpupdate /force çalıştırıyor, ardından oturumu kapatıp açıyoruz.

Sonuç şöyle olmalı:

Bu tablo, Policy ile Preference arasındaki farkı ve Remove this item when it is no longer applied seçeneğinin etkisini tek bakışta gösteriyor. Policy ayarı kendiliğinden temizlendi. Preference öğelerinden yalnızca bu seçeneği işaretlediğimiz drive eşlemesi kaldırıldı. Diğer iki öğe ise GPO artık kullanıcıya uygulanmadığı halde makinede kaldı. GPO’yu silsek bile sonuç değişmezdi: bu değerleri temizlemenin tek yolu, istemcide elle silmek ya da yeni bir GPO ile Delete action’ı kullanmaktır.

Şimdi sonuçları tek tek kontrol ediyoruz. Önce Settings > Personalization > Lock screen > Screen saver yolundan Screen Saver Settings penceresini açıyoruz. Adım 7’deki görüntüyle karşılaştırdığımızda fark açıkça görülür: seçeneklerin hiçbiri artık gri değil, kullanıcı hepsini değiştirebiliyor. Screen saver listesinde (None) yazıyor, yani Force specific screen saver ayarıyla gelen Blank ekran koruyucu da kalktı ve ekran koruyucu artık çalışmıyor.

Wait alanında hala 15 dakika ve On resume, display logon screen kutusunun işaretli görünmesi kafa karıştırmasın. Bunlar GPO’dan gelen değerler değil, Windows’un kullanıcı profilindeki kendi varsayılan değerleridir. GPO bu ayarları Software\Policies altına yazdığı için, kaldırıldığında yalnızca o anahtarlar temizlendi ve pencere kullanıcının kendi ayarlarını göstermeye başladı. Ekran koruyucu (None) olduğu için bu değerlerin de bir etkisi yoktur.

File Explorer’da This PC görünümünü açıyoruz. Network locations bölümü ve S: sürücüsü artık görünmüyor. Remove this item when it is no longer applied seçeneği, GPO kapsam dışına çıktığında eşlemeyi kaldırdı.

Masaüstüne baktığımızda ise Satis Ortak Klasor kısayolunun hala yerinde durduğunu görüyoruz. Kısayol GPO kapsam dışına çıktığı halde silinmedi. Hedefi olan S: sürücüsü artık olmadığı için de çalışmıyor.

Son olarak regedit’te HKEY_CURRENT_USER\Software\BakicubukLab anahtarını açıyoruz. Departman değeri Satis verisiyle yerinde duruyor. GPO bu değeri artık yönetmiyor ama Windows’un bu değerin bir GPO’dan geldiğini bilmesinin bir yolu olmadığı için kendiliğinden temizlenmiyor. Tattooing tam olarak budur.

Şimdi registry öğesini düzeltiyoruz. U - Satis - Tercihler GPO’sunu düzenleyicide açıp User Configuration > Preferences > Windows Settings > Registry altındaki Departman öğesini seçiyoruz. Soldaki Processing kutusunda Remove if not applied satırının No olduğunu ve Action sütununda Update yazdığını görüyoruz. Tattooing’in nedeni de tam olarak bu.

Öğeye çift tıklayıp Common sekmesine geçiyoruz. Öğeyi oluştururken hiçbir seçeneği işaretlemediğimiz için tüm kutular boş.

Remove this item when it is no longer applied seçeneğini işaretliyoruz. Drive Maps öğesinde gördüğümüz Mode Change Warning uyarısı burada da gelir ve öğenin Replace moduna geçeceğini bildirir. OK diyoruz.

Seçenek işaretlendikten sonra Apply once and do not reapply seçeneği gri hale gelir. Apply diyoruz.

General sekmesine geçtiğimizde Action alanının Replace olduğunu ve gri, yani değiştirilemez hale geldiğini görüyoruz. Remove seçeneği işaretli kaldığı sürece Action başka bir değere çevrilemez. OK ile pencereyi kapatıyoruz.

Registry listesinde artık Action sütununda Replace yazıyor, ikon kırmızıya dönmüş ve Processing kutusunda Remove if not applied satırı Yes olmuş.

Remove seçeneğinin işe yaraması için öğenin bu seçenek işaretliyken istemciye en az bir kez uygulanması gerekir. Bu yüzden önce U - Satis - Tercihler GPO’sunun link’ini tekrar etkinleştiriyoruz: Satis OU’sunun Linked Group Policy Objects sekmesinde GPO’ya sağ tıklayıp Link Enabled seçeneğini işaretliyoruz. Ekran kilidi GPO’sunu bu testte kullanmayacağımız için onun link’ini kapalı bırakabiliriz. İstemcide gpupdate /force çalıştırıyoruz. Bu yenilemede registry öğesi Replace action’ıyla yeniden yazılır ve istemci artık bu değerin bu GPO’dan geldiğini kaydeder.

Ardından U - Satis - Tercihler GPO’sunun link’ini tekrar devre dışı bırakıyoruz (Link Enabled: No) ve istemcide yeniden gpupdate /force çalıştırıyoruz.

regedit’te HKEY_CURRENT_USER\Software\BakicubukLab anahtarını F5 ile yenilediğimizde bu kez Departman değerinin silindiğini, anahtarda yalnızca (Default) değerinin kaldığını görüyoruz. Remove seçeneği, GPO kapsam dışına çıktığında değeri temizledi. Anahtarın kendisi ise yerinde duruyor, çünkü öğe yalnızca değeri yönetiyordu.

Testi tamamladıktan sonra iki GPO’nun link’ini de tekrar etkinleştiriyoruz (Link Enabled: Yes) ve istemcide gpupdate /force çalıştırıyoruz. Böylece lab ortamı bir sonraki bölüm için başlangıç durumuna döner.

8. Preference’lar Nerede ve Nasıl Tutulur?

Bölüm 1‘de Administrative Templates ayarlarının GPT içindeki Registry.pol dosyasında tutulduğunu görmüştük. Preference öğeleri ise her öğe türü için ayrı bir XML dosyasında tutulur. Oluşturduğumuz GPO’nun GPT klasörüne bakalım:

$gpo = Get-GPO -Name "U - Satis - Tercihler"
Get-ChildItem "\\bakicubuk.tech\SYSVOL\bakicubuk.tech\Policies\{$($gpo.Id)}\User\Preferences" -Recurse | Select-Object FullName
Get-Content "\\bakicubuk.tech\SYSVOL\bakicubuk.tech\Policies\{$($gpo.Id)}\User\Preferences\Drives\Drives.xml"

Get-ChildItem çıktısında Preferences altında her öğe türü için ayrı bir klasör (Drives, Registry, Shortcuts) ve her klasörün içinde aynı adı taşıyan bir XML dosyası (Drives.xml, Registry.xml, Shortcuts.xml) görürüz. Komutta Select-Object -ExpandProperty FullName kullanmamızın nedeni, uzun yolların ekranda ... ile kısaltılmadan tam olarak görünmesidir.

Get-Content ile açtığımız Drives.xml dosyasında, Adım 3’te arayüzden yaptığımız tüm ayarları düz metin olarak görürüz.

Önemli öznitelikler şunlardır:

FilterGroup satırındaki SID değerinin, Adım 3’te Targeting Editor’da ve Adım 7’de whoami /groups çıktısında gördüğümüz SID ile aynı olduğuna dikkat edelim. İstemci hedeflemeyi bu SID’e göre değerlendirir. changed özniteliği öğenin en son değiştirildiği zamanı, uid ise öğenin benzersiz kimliğini tutar.

Bu dosyalar SYSVOL’da durur ve SYSVOL, domain’deki her kimliği doğrulanmış kullanıcı tarafından okunabilir. Yani bir Preference öğesine yazdığımız her bilgi, domain’deki herkes tarafından görülebilir. Bu gerçek, bir sonraki başlıkta ele aldığımız güvenlik sorununun temelidir.

9. Güvenlik Açısından Group Policy Preferences

GPP parolaları (cpassword) ve MS14-025

Windows Server 2008 ile gelen ilk GPP sürümünde bazı öğelere parola girilebiliyordu: Local Users and Groups (yerel kullanıcının parolasını değiştirmek), Drive Maps (Connect as alanı), Scheduled Tasks, Services ve Data Sources. Bu parolalar GPT içindeki XML dosyalarına cpassword özniteliğiyle, AES (Advanced Encryption Standard) 256 bit ile şifrelenmiş olarak yazılıyordu.

Sorun şuydu: şifrelemede kullanılan anahtar, Microsoft tarafından MSDN (Microsoft Developer Network) belgelerinde yayımlanmıştı. Her domain’de aynı anahtar kullanılıyordu ve SYSVOL’daki XML dosyalarını domain’deki her kullanıcı okuyabiliyordu. Sonuç olarak domain’e giriş yapabilen herhangi bir kullanıcı, örneğin tüm makinelerdeki yerel yönetici hesabının parolasını birkaç saniyede çözebiliyordu. Bu yöntem saldırgan araçlarına çok erken dönemde eklendi ve bugün hala iç ağ sızma testlerinin ilk kontrollerinden biridir.

Microsoft 2014’te MS14-025 (KB2962486) güncellemesiyle bu alanları GPP arayüzünden kaldırdı. Güncelleme yüklü bir makinede bu öğeleri oluştururken parola alanları devre dışıdır. Ancak güncelleme SYSVOL’daki mevcut XML dosyalarını silmedi. 2014’ten önce oluşturulmuş ve hala duran bir GPO, içindeki parolayı bugün de herkese açık şekilde saklıyor olabilir.

SYSVOL’da cpassword içeren dosya olup olmadığını şu komutlarla kontrol ediyoruz:

burada

burada

burada

===== Tablo 16: Kısaltma / Açılımı / Açıklama | Bölüm: Kısaltmalar =====

burada

burada

burada

burada