GPO Düzenleme Hatası – Access is Denied (0x80070005)

Group Policy Management Console (GPMC) üzerinden bir GPO üzerinde değişiklik yaparken Access is denied (0x80070005 / E_ACCESSDENIED) hatası alınabiliyor. İlk bakılması gereken alanlardan biri ilgili GPO’nun SYSVOL üzerindeki izinleri. Ancak bu hata tek başına NTFS izinlerinin bozuk olduğunu kanıtlamaz. Önce hangi GPO’nun, hangi domain controller üzerinden ve hangi hesapla düzenlenmeye çalışıldığını belirlemek gerekiyor.

Güncelleme notu (Ekim 2026): Bu makalenin orijinali 2021 yılında SYSVOL klasöründe kalıtım açılarak çözülen bir vakayı anlatıyordu. Orijinal ekran görüntülerini korudum. Kalıtımı tüm GPO klasörlerine uygulamak veya SYSVOL ACL’lerini topluca sıfırlamak güvenli bir genel çözüm değildir; üstelik GPO’nun Active Directory bölümüyle SYSVOL bölümü arasında yeni izin tutarsızlıkları oluşturabilir.

1. GPO kimliğini (GUID) ve yönetilen domain controller’ı bulma

GPMC üzerinde sorunlu GPO’yu seçip Details sekmesindeki Unique ID değerini not edelim. Aynı bilgiyi GroupPolicy PowerShell modülüyle de alabiliriz. GPMC’nin hangi domain controller’a bağlandığını ayrıca kontrol edelim; varsayılan olarak PDC Emulator kullanılabilir, fakat konsoldan DC değiştirilebilir.

Get-GPO -Name "Ornek GPO" | Select-Object DisplayName,Id,Owner,GpoStatus
Get-GPO -Name "Ornek GPO" | Select-Object -ExpandProperty Id

Şablon dosyalarının yolu genellikle aşağıdaki gibidir. Burada klasör adı GPO GUID değeridir ve süslü parantezleri içerir:

\\ornek.local\SYSVOL\ornek.local\Policies\{GPO-GUID}

SYSVOL paylaşımı üzerinden gerçek domain ve DC adlarıyla kontrol yapmak daha doğrudur. Yerel diskteki C:\Windows\SYSVOL\sysvol\... yolu bazı ortamlarda kullanılabilse de SYSVOL’un fiziksel konumu değişebilir.

2. Önce GPO Delegation ve Security Filtering ayarlarını kontrol etme

GPO’nun Delegation sekmesinde ilgili hesabın düzenleme yetkisi olup olmadığını inceleyelim. Edit settings, Edit settings, delete, modify security ve yalnızca Read hakları aynı değildir. GPO bağlantısını (link) yönetebilmek, GPO içeriğini otomatik olarak düzenleme hakkı vermez.

• Hata tek bir GPO’da mı, yoksa aynı hesapla tüm GPO’larda mı ortaya çıkıyor?
• Yönetim hesabı ilgili GPO’nun ACL’sinde yeterli hakka sahip mi?
• Farklı bir yetkili yönetim hesabıyla davranış değişiyor mu?
• GPMC farklı domain controller’a yönlendirildiğinde aynı sorun oluşuyor mu?

3. SYSVOL klasöründeki ACL’leri görüntüleme

Orijinal vakada GUID klasörünün izinleri incelenerek sorun giderilmişti. Güvenlik sekmesinden önce mevcut izinleri belgeleyelim; doğrudan Enable inheritance seçeneğini açmayalım. AD içindeki GPO izinleriyle SYSVOL klasörünün izinleri tutarlı olmalı.

icacls "\\ornek.local\SYSVOL\ornek.local\Policies\{GPO-GUID}"

Buradaki ACL çıktısı yalnızca inceleme amacıyla alınır; otomatik bir düzeltme komutu değildir. ACL’de kimlerin hangi düzeyde erişim hakkına sahip olduğunu ve üst klasörden izin alınıp alınmadığını kontrol edelim.

4. Active Directory ve SYSVOL izin tutarsızlığı

Bir GPO’nun Active Directory tarafında Group Policy Container (GPC), SYSVOL tarafında ise Group Policy Template (GPT) bileşeni bulunur. Microsoft, “Permissions for this GPO in the SYSVOL folder are inconsistent with those in Active Directory” uyarısının nedenleri arasında SYSVOL klasöründe miras alınan izinleri ve elle değiştirilmiş ACL’leri sayıyor. Bu nedenle kalıtımı açmak, her GPO için otomatik önerilebilecek bir onarım değildir.

GPMC bu uyarıyı gösterir ve hesabın gerekli izinleri varsa, uyarıdaki önerilen onarım SYSVOL ACL’lerini AD tarafındaki GPO izinleriyle eşitler. Bu işlem bazı durumlarda SYSVOL klasörünün izin kalıtımını kapatır. İşlemi başlatmadan önce GPO yedeği ve mevcut izinler mutlaka kontrol edilmelidir.

Önemli: Uyarıyı görmüyorsak, sorun yalnızca düzenleme sırasında 0x80070005 şeklinde ortaya çıkıyorsa ve neden henüz belli değilse, kalıtımı açıp bütün alt öğelerin izinlerini üst klasörden yeniden yazmak doğru bir ilk adım değildir.

5. Orijinal laboratuvarda uygulanan işlem ve güncel değerlendirme

2021 tarihli örnekte ilgili GPO GUID klasöründe Enable inheritance açılarak üst klasörden izinler alınmış ve hata giderilmişti. Daha sonra kalıtım Disable inheritance > Convert seçeneğiyle kapatılarak devralınmış izinler açık ACL girdilerine dönüştürülmüştü. Aşağıdaki görsel bu işlemin bir parçasıdır.

Bu yöntem ilgili laboratuvarda işe yaramış olsa da güncel ortamlarda genel düzeltme reçetesi olarak kullanılmamalı. Özellikle özel delegasyonlar, güvenlik filtreleri ve düzenlenmiş ACL’ler varsa değişiklikler beklenmeyen erişim sonuçlarına yol açabilir. Çözüm, tutarsızlığın gerçek sebebine göre planlanmalıdır.

6. SYSVOL ve replikasyon sağlığını denetleme

Birden fazla domain controller varsa, aynı GPO GUID klasörünün tüm DC’lerde bulunup bulunmadığı ve GPT.ini dosyasına erişilip erişilemediği kontrol edilmeli. Farklı DC’lerdeki içerik uyuşmazlıkları veya DFS Replication problemleri GPO düzenleme ve uygulama hatalarını etkileyebilir.

dcdiag /test:advertising /test:sysvolcheck
repadmin /replsummary
repadmin /showrepl

Bu komutlar tek başına DFSR içerik tutarlılığını bütünüyle kanıtlamaz; gerekli durumlarda DFS Replication olay günlükleri ve ilgili replikasyon grubu ayrıca değerlendirilir. GPMC üzerinde Change Domain Controller seçeneğiyle hangi DC’de hata alındığını karşılaştırmak yararlıdır.

7. Hata devam ederse: kontrollü sorun giderme sırası

• Sorunlu GPO’nun mevcut yedeğini alın ve GUID, sahiplik, delegasyon ile Security Filtering ayarlarını kaydedin.
• Yönetim hesabının AD tarafındaki GPO düzenleme yetkilerini doğrulayın.
• İlgili GPO’nun SYSVOL GUID klasörünün erişimini ve ACL’lerini inceleyin.
• GPMC’nin AD–SYSVOL izin uyuşmazlığı uyarısı varsa, uyarıyı ve Microsoft’un önerdiği eşitleme işlemini değerlendirin.
• Birden fazla DC’de aynı sorunun oluşup oluşmadığını karşılaştırın; SYSVOL/DFSR ve AD replikasyonunu kontrol edin.
• Ancak sebep doğrulanıp değişiklik etkileri belgelendikten sonra ilgili GPO için sınırlı bir ACL onarımı yapın ve erişimi tekrar test edin.

Üretim ortamı uyarısı: icacls /reset, takeown veya SYSVOL üzerinde toplu kalıtım/izin değişikliklerini gelişigüzel uygulamayın. dcgpofix aracı da normal GPO düzenleme hataları için değildir; yalnızca iki varsayılan GPO’yu yeniden oluşturabilen bir felaket kurtarma aracıdır ve diğer GPO’ları onarmaz.

8. SYSVOL kök izinleri için önemli not

Eski makaledeki Authenticated Users, Server Operators, Administrators, CREATOR OWNER ve SYSTEM izinleri bir dönemin örnek ACL listesiydi. Bu listeyi farklı domain ve Windows Server sürümlerinde otomatik olarak uygulanacak eksiksiz bir ACL şablonu olarak değerlendirmiyoruz. Mevcut izinlerin kuruluşun güvenlik modeliyle ve Microsoft’un desteklenen yapılandırmasıyla uyumlu olup olmadığı, üretim ortamında ayrıca doğrulanmalıdır.

GPO düzenlenemediğinde asıl hedef yalnızca hatayı geçici olarak ortadan kaldırmak değil, izin sorununu hangi nesnede ve hangi domain controller üzerinde yaşadığımızı kesin olarak tespit etmektir. Bu sayede diğer GPO’ların yetki yapısını bozmadan doğru onarımı yapabiliriz.