Windows SMB (C$) Erişim Sorunu ve Kalıcı Çözümü

Windows ortamlarında sistem yöneticilerinin en sık karşılaştığı sorunlardan biri uzak bir makinenin C$ veya Admin$ gibi yönetim paylaşımlarına SMB üzerinden erişememektir.

Özellikle sanal makineler (VM), domain’e dahil olmayan sunucular ve yedekleme/otomasyon araçlarının hedef aldığı sistemlerde bu sorun çok sık karşımıza çıkar.

Sonuç çoğu zaman aynıdır.

"Access is denied"

"Erişim reddedildi"

İlginç olan bu hatanın yerel yönetici (Local Administrator) yetkisine sahip bir hesap kullanıyor olsanız bile ortaya çıkmasıdır.

Bu makalemde sorunun neden kaynaklandığını hangi Windows mekanizmasının devreye girdiğini ve LocalAccountTokenFilterPolicy kayıt defteri (registry) anahtarı ile nasıl kalıcı olarak çözülebileceğini adım adım açıklıyoruz.

Sorunun Belirtileri

Aşağıdaki durumlardan biri veya birkaçıyla karşılaşıyorsanız büyük olasılıkla bu makalenin konusu olan UAC kaynaklı kısıtlamaya takılıyorsunuz;

• \\VMNAME\C$ veya \\SUNUCU\Admin$ paylaşımlarına bağlanılamıyor.
• Local Administrator grubuna üye bir hesapla bağlandığınız hâlde “Access is denied” hatası alıyorsunuz.
• Domain üyesi olmayan (workgroup) makinelerde SMB bağlantısı başarısız oluyor.
• Veeam, Zerto, SCCM, PowerShell Remoting veya kendi yazdığınız scriptler uzak makineye bağlanırken yetki hatası veriyor.
• WMI çağrıları (Get-WmiObject -ComputerName ...) uzaktan yetki hatasıyla düşüyor.

Aynı kullanıcı hesabıyla yerel (konsol veya RDP üzerinden) oturum açtığınızda her şey normal çalışıyorsa, bu bulmacanın anahtarı şu kelimededir: uzaktan.

Sorunun Kök Nedeni: UAC Remote Token Filtering

Windows Vista’dan itibaren Microsoft User Account Control (UAC) mekanizmasının bir parçası olarak “Remote Token Filtering” adı verilen bir güvenlik katmanı getirdi.

Bu mekanizmanın çalışma şekli şudur:

Bir yerel yönetici hesabı uzaktan bağlandığında (SMB, WMI, WinRM gibi protokollerle) Windows o hesabın güvenlik token’ından yönetici (elevated) ayrıcalıklarını çıkarır ve hesap, uzak makinede sıradan bir kullanıcı gibi davranır. Yani hesap teknik olarak Administrators grubunda olsa bile, uzaktan yapılan istek standart kullanıcı yetkisiyle işlenir. Bu da C$, Admin$, IPC$ gibi gizli yönetim paylaşımlarına erişimi otomatik olarak engeller.

Önemli bir ayrıntı bu davranış domain hesapları için geçerli değildir.

Domain Administrator veya domain ortamındaki yetkili bir hesap uzaktan tam yetkiyle çalışmaya devam eder. Sorun özellikle yerel hesaplarda ve özellikle workgroup makinelerinde belirgin biçimde ortaya çıkar çünkü domain yokken Windows’un başka bir kimlik doğrulama yolu yoktur.

Bu davranışı kontrol eden kayıt defteri anahtarı:

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
    └── LocalAccountTokenFilterPolicy   (REG_DWORD)

Kalıcı Çözüm: LocalAccountTokenFilterPolicy

Bağlanmak istediğiniz hedef makinede (kaynak makinede değil!) yönetici yetkisiyle açtığınız bir Komut İstemi veya PowerShell penceresinde aşağıdaki komutu çalıştırmanız yeterlidir:

reg add "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

PowerShell tercih edenler için eşdeğeri.

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" `
                 -Name "LocalAccountTokenFilterPolicy" `
                 -Value 1 -PropertyType DWORD -Force

Anahtarın aldığı değerler

Değer	Davranış
0 (varsayılan)	UAC, uzaktan bağlanan yerel yönetici hesaplarının token’ını filtreler. C$ / Admin$ erişimi engellenir.
1	Filtreleme devre dışı kalır. Yerel yönetici hesapları uzaktan tam yetkiyle çalışır; SMB ve WMI üzerinden yönetim paylaşımlarına erişim açılır.

Komut Sonrası Ne Değişir?

• \\HEDEF\C$ ve \\HEDEF\Admin$ paylaşımlarına Local Administrator hesabıyla erişim açılır.
• WMI çağrıları, uzak PowerShell oturumları ve SMB tabanlı dosya işlemleri tam yetkiyle çalışır.
• Veeam, Zerto, SCCM, PDQ Deploy, CA PAM, Ansible (winrm), kendi yedekleme scriptleriniz gibi uzak yönetim araçları sorunsuz çalışmaya başlar.
• Çoğu durumda yeniden başlatma (restart) gerekmez değişiklik anında devreye girer. Yine de üretim ortamlarında, açık oturumların temiz şekilde yenilenmesi için planlı bir restart önerilir.

Tek Tek Değil, Toplu Yapmak Gerekirse

Bu ayarı tek bir sunucuda yapmak basittir. Ancak onlarca veya yüzlerce hedef sunucu varsa elle gitmek pratik değildir. İki yaygın toplu yöntem vardır:

1. Group Policy (GPO) ile Dağıtım

Domain ortamında en temiz yol budur.

Group Policy Management Editor içinde;

Computer Configuration
  └── Preferences
        └── Windows Settings
              └── Registry  →  New → Registry Item

yolundan aşağıdaki değerleri girin:

• Action: Update
• Hive: HKEY_LOCAL_MACHINE
• Key Path: SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
• Value name: LocalAccountTokenFilterPolicy
• Value type: REG_DWORD
• Value data: 1

GPO’yu yalnızca ihtiyacınız olan sunucuların bulunduğu bir Organizational Unit’e (OU) bağlamanız ayarın istemeden tüm domain’e yayılmasını önler.

2. PowerShell Remoting ile Toplu Uygulama

Domain dışı veya hızlı dağıtım gereken senaryolarda:

$servers = @("VM01", "VM02", "VM03")
Invoke-Command -ComputerName $servers -ScriptBlock {
    New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" `
                     -Name "LocalAccountTokenFilterPolicy" `
                     -Value 1 -PropertyType DWORD -Force
}

Not: Bu komutun çalışması için zaten bir uzak yönetim kanalına (WinRM) erişiminiz olması gerekir. Hiçbir uzak kanal çalışmıyorsa ilk makinede ayarı manuel açıp oradan zincirleme dağıtım yapmak kaçınılmaz olabilir.

Doğrulama

Ayarın gerçekten uygulandığını doğrulamak için hedef makinede:

reg query "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System" /v LocalAccountTokenFilterPolicy

Çıktıda LocalAccountTokenFilterPolicy REG_DWORD 0x1 görmelisiniz.

Ardından kaynak makineden bağlantıyı test edin:

net use \\HEDEF\C$ /user:HEDEF\Administrator
dir \\HEDEF\C$

Hâlâ “Access is denied” alıyorsanız, sıradaki bölümdeki diğer olası sebepleri kontrol ediniz.

Güvenlik Açısından Dikkat Edilmesi Gerekenler

Bu ayarın amacı Microsoft’un bilinçli olarak getirdiği bir güvenlik katmanını gevşetmektir. Dolayısıyla körü körüne tüm makinelerde açılması doğru bir yaklaşım değildir. Riski azaltmak için:

• Sadece ihtiyaç duyulan sunucularda açın. Özellikle internete açık veya DMZ’deki makinelerde tekrar düşünün.
• Yerel yönetici parolalarını güçlendirin. Token filtering kaldırıldığı an, yerel admin parolası tek savunma hattınız hâline gelir. LAPS (Local Administrator Password Solution) kullanmak burada altın standarttır.
• Yerel yönetici hesap sayısını minimumda tutun. Mümkün olan her yerde domain hesaplarıyla çalışın.
• Ağ segmentasyonu uygulayın. SMB (445) ve WMI portlarının yalnızca yönetim ağlarından erişilebilir olması, bu ayarın açık olduğu ortamlarda kritik önem taşır.

Bu Çözüm İşe Yaramazsa Sırada Ne Var?

LocalAccountTokenFilterPolicy = 1 ayarı sorunların büyük çoğunluğunu çözer ancak hâlâ erişim sorunu yaşıyorsanız aşağıdakileri kontrol edin:

• Windows Defender Firewall: “File and Printer Sharing” ve “Windows Management Instrumentation (WMI)” kuralları gelen bağlantılar için açık olmalı.
• Network Profile: Hedef makinede ağ profili “Public” olarak işaretliyse SMB varsayılan olarak engellidir; “Private” veya “Domain” olmalı.
• SMB protokol sürümü: Modern Windows sürümlerinde SMBv1 devre dışıdır. Eski cihazlarla uyum sorunu yaşıyorsanız SMBv2/SMBv3 kullanın, SMBv1’i tekrar açmayın.
• “Network access: Sharing and security model for local accounts” politikası: Eğer “Guest only” olarak ayarlıysa, kimliğinizi doğrulamış olsanız bile Guest yetkisiyle bağlanmaya çalışırsınız. Bu “Classic” olmalıdır (secpol.msc → Local Policies → Security Options).
• Kullanıcı hesabının fiilen Administrators grubunda olduğunu doğrulayın: net localgroup Administrators çıktısında hesabın yer aldığından emin olun.