RSAT Kurulumu: Windows 11'de GPMC ve ADUC Konsolları

Sunucu yönetiminde en sık tekrarlanan alışkanlık, her iş için sunucuya uzak masaüstüyle bağlanmaktır. Oysa Windows tarafındaki yönetim araçlarının tamamı, sunucuya hiç dokunmadan kendi bilgisayarınızdan çalışacak şekilde tasarlanmıştır. Bu rehber o araçların nasıl kurulduğunu, nereden çalıştırılması gerektiğini ve tam olarak neyi yönettiğini ele alıyor. Yalnızca kurulum adımlarını arıyorsanız doğrudan Windows 10 ve 11 kurulumuna geçebilirsiniz.

RSAT Nedir? Sunucuya Bağlanmadan Yönetmek

RSAT (Remote Server Administration Tools), Windows Server rollerini yöneten konsolların istemci bir Windows’a kurulabilen halidir. Kurduğunuz anda bilgisayarınızda Active Directory kullanıcısı açan, Group Policy yazan, DNS zone’u düzenleyen, DHCP havuzu tanımlayan pencereler belirir. Hiçbiri veriyi sizin makinenizde tutmaz. Hepsi ağ üzerinden sunucudaki dizine bağlanır ve işi orada yapar.

Serinin otel benzetmesinde domain controller ön bürodur: oda kartları orada kodlanır, misafir listesi orada durur. Kaybolan bir kartı iptal etmek için personel ön büro masasına oturmaz, arka ofisteki terminalden aynı sisteme bağlanır. RSAT o terminaldir: DC’ye uzak masaüstüyle girmeden aynı dizini kendi bilgisayarınızdan yönetirsiniz.

Windows Server bu konsolları kendi içinde taşır, çünkü rol zaten üstündedir. İstemci Windows taşımaz, çünkü sıradan bir kullanıcının makinesinde domain yönetim aracının işi yoktur. RSAT tam olarak bu boşluğu kapatan, isteğe bağlı kurulan pakettir. Windows Server’ın rol mimarisine ve hangi rolün ne iş yaptığına Windows Server rehberimizden bakabilirsiniz.

Aracın adındaki “sunucu” kelimesi bir noktada yanıltıcıdır ve bu yazının en çok düzeltmek istediği kavram hatası orada: RSAT bir sunucu işletim sistemini değil, bir dizini yönetir. Bunun pratik sonucu düşündüğünüzden geniş, aşağıda ayrı bir bölümde ele alıyoruz.

Son olarak kurulum yönteminin bir tarihi var ve bugün karşınıza çıkan rehberlerin çoğu o tarihin eski bir noktasında durmuş durumda. Windows 10’un 1809 sürümüne kadar RSAT, Microsoft’un sitesinden indirilen ayrı bir paketti ve her Windows sürümü için ayrı yayınlanırdı. 1809’dan itibaren işletim sisteminin içine Optional features (isteğe bağlı özellik, Microsoft belgelerindeki adıyla Features on Demand) olarak taşındı. Hâlâ “önce şu paketi indirin” diyen bir rehber okuyorsanız, o rehber güncel Windows’ta çalışmayacak bir yolu tarif ediyor.

RSAT Kurulumu: Windows 10 ve Windows 11

Tek bir ön koşul var ve kurulumun tökezlediği yerlerin başında geliyor: RSAT, Windows’un Home sürümlerine kurulmaz. Pro, Enterprise ve Education sürümlerinde çalışır. Makinenizin sürümünü bilmiyorsanız kuruluma başlamadan önce bakın, çünkü Home’da özellik listesinde arattığınızda hiçbir sonuç çıkmaz ve bu, “kurulum bozuk” gibi görünen ama aslında hiç başlamamış bir durumdur.

Lab’da bir Windows 11 Pro istemciye (İngilizce arayüz) Group Policy konsolunu arayüzden kurdum. Kurulum yönetici yetkisi ister, ben makinenin yerel yönetici hesabıyla oturum açtım:

1. Settings → System → Optional features sayfasını açın.
2. View features düğmesine basın. Pencere UAC onayı ister.
3. Açılan View features penceresinde See available features bağlantısına basın ve arama kutusuna rsat yazın. Lab’da 19 bileşen listelendi, çünkü bu liste yalnız kurulmamış bileşenleri gösterir. İstemcide Active Directory araçları ve onunla gelen Server Manager zaten kuruluydu.
4. RSAT: Group Policy Management Tools satırını işaretleyin ve Add (1) düğmesine basın.

Aynı işi PowerShell ile yapmak hem daha hızlı hem de tekrarlanabilir. Önce hangi bileşenlerin mevcut olduğuna ve hangilerinin zaten kurulu olduğuna bakın:

Get-WindowsCapability -Online -Name RSAT* | Select-Object Name, State | Format-Table -AutoSize

Bu komutu yönetici olarak açılmış bir PowerShell penceresinde çalıştırın. Yalnız okuma yapan bu komut bile yükseltilmemiş oturumda çalışmıyor:

Get-WindowsCapability : The requested operation requires elevation.

Hiç RSAT kurulmamış bir Windows 11 Pro makinede çıktı şöyle görünüyor:

Name                                                          State
----                                                          -----
Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0             NotPresent
Rsat.AzureStack.HCI.Management.Tools~~~~0.0.1.0          NotPresent
Rsat.BitLocker.Recovery.Tools~~~~0.0.1.0                 NotPresent
Rsat.CertificateServices.Tools~~~~0.0.1.0                NotPresent
Rsat.DHCP.Tools~~~~0.0.1.0                               NotPresent
Rsat.Dns.Tools~~~~0.0.1.0                                NotPresent
Rsat.FailoverCluster.Management.Tools~~~~0.0.1.0         NotPresent
Rsat.FileServices.Tools~~~~0.0.1.0                       NotPresent
Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0             NotPresent
Rsat.IPAM.Client.Tools~~~~0.0.1.0                        NotPresent
Rsat.LLDP.Tools~~~~0.0.1.0                               NotPresent
Rsat.NetworkController.Tools~~~~0.0.1.0                  NotPresent
Rsat.NetworkLoadBalancing.Tools~~~~0.0.1.0               NotPresent
Rsat.RemoteAccess.Management.Tools~~~~0.0.1.0            NotPresent
Rsat.RemoteDesktop.Services.Tools~~~~0.0.1.0             NotPresent
Rsat.ServerManager.Tools~~~~0.0.1.0                      NotPresent
Rsat.StorageMigrationService.Management.Tools~~~~0.0.1.0 NotPresent
Rsat.StorageReplica.Tools~~~~0.0.1.0                     NotPresent
Rsat.SystemInsights.Management.Tools~~~~0.0.1.0          NotPresent
Rsat.VolumeActivation.Tools~~~~0.0.1.0                   NotPresent
Rsat.WSUS.Tools~~~~0.0.1.0                               NotPresent

Bu tablodan üç sonuç çıkıyor ve üçü de kurulumu kolaylaştırıyor.

Birincisi, “RSAT” diye tek bir paket yok. Yirmi bir ayrı bileşen var ve her biri bağımsız kuruluyor. “RSAT’ı kurdum ama Group Policy konsolu gelmedi” diye bir sorunla karşılaşırsanız sebebi neredeyse her zaman budur: paket değil, bileşen kurulur.

İkincisi, State sütunu makinenin gerçek halini gösterir. Yukarıdaki çıktıda hepsi NotPresent, yani bu makinede hiçbir RSAT bileşeni kurulu değil. Kurduklarınız Installed olarak görünmeye başlar. Lab istemcisinde iki bileşeni kurduktan sonra aynı komut üç satırı Installed gösterdi:

Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0                  Installed
Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0                  Installed
Rsat.ServerManager.Tools~~~~0.0.1.0                           Installed

Üçüncü satırı ben seçmedim: Server Manager bileşeni (82,8 MB) Active Directory araçlarıyla birlikte geldi. Kurulumu doğrularken listede beklemediğiniz bir Installed satırı görürseniz sebebi bu tür bağımlılıklardır.

Pencere ile komut aynı sayıyı verir, yalnız iki listeye böler. Bu üç bileşen kuruluyken View features penceresinde rsat araması kurulu listede 3, See available features listesinde 18 bileşen gösterdi. Toplam, komutun 21 satırıyla aynı. Kurulum adımındaki 19 da bu bölünmeden gelir, o sırada iki bileşen kurulu listedeydi.

Üçüncüsü, adları ezberden yazmayın. Her adın sonunda ~~~~0.0.1.0 biçiminde bir sürüm soneki var ve bu sonek Windows sürümüne göre değişebilir. Adı çıktıdan kopyalayın.

Listedeki bileşenlerin çoğu, çoğu kurumun hiç çalıştırmadığı rollere ait: Rsat.IPAM.Client.Tools, Rsat.StorageReplica.Tools, Rsat.NetworkController.Tools gibi. Active Directory yönetimi için gereken ikisi şunlar: kullanıcı, grup ve bilgisayar nesneleri için Rsat.ActiveDirectory.DS-LDS.Tools, Group Policy için Rsat.GroupPolicy.Management.Tools.

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

Kurulu olmayan her şeyi tek seferde eklemek de mümkün:

Get-WindowsCapability -Online -Name RSAT* |
  Where-Object State -eq 'NotPresent' |
  Add-WindowsCapability -Online

Optional features bileşenleri fabrika ayarında Windows Update üzerinden indirir. Makineleriniz güncellemeleri bir WSUS sunucusundan alıyorsa ya da internete kapalı bir ağdaysanız kurulum ilerlemez. Teşhisi aşağıdaki hatalar bölümünde ele alıyoruz.

Windows Server’da RSAT: Capability Değil Feature

Windows Server tarafında aynı araçlar var ama kurulum mekanizması farklı ve bu fark sık sık zaman kaybettirir. İstemci Windows’ta bunlar birer capability (Optional features), Windows Server’da ise birer feature’dır. İkisi ayrı defterde tutulur ve ayrı komutlarla sorgulanır.

Bunu ölçmek için ayrı bir kuruluma gerek yok, istemci tarafının sorgusunu sunucuda çalıştırmak yetiyor. Lab’daki dc01’de (Windows Server 2025) yükseltilmiş PowerShell’de denediğimde komut ne çıktı ne hata verdi, yeni komut satırına döndü:

Get-WindowsCapability -Online -Name RSAT*

Hiçbir satır dönmemesi bir arıza değil, hatta doğru cevap. Sunucuda RSAT bileşenleri capability defterinde kayıtlı değil. Orada oldukları yer feature defteri. Bu yüzden istemcide işe yarayan Add-WindowsCapability komutu sunucuda karşılığını bulamaz. Doğru komut şu:

Install-WindowsFeature -Name GPMC, RSAT-AD-Tools, RSAT-AD-PowerShell

Kurulumun gerçekten oturup oturmadığını aynı yerden sorabilirsiniz. dc01’de üç bileşeni sorduğumda aldığım çıktı şu:

Get-WindowsFeature RSAT-AD-Tools, GPMC, RSAT-AD-PowerShell |
  Format-Table Name, DisplayName, InstallState

Name               DisplayName                                    InstallState
----               -----------                                    ------------
GPMC               Group Policy Management                           Installed
RSAT-AD-Tools      AD DS and AD LDS Tools                            Installed
RSAT-AD-PowerShell Active Directory module for Windows PowerShell    Installed

Bakılacak sütun InstallState ve üç değer alır. Installed bileşenin kurulu olduğunu, Available kurulabilir durumda beklediğini, Removed ise ikili dosyalarının makineden tamamen çıkarıldığını söyler. Sonuncusu kurulum sırasında ayrıca bir kaynak göstermenizi gerektirir, dolayısıyla “komutu çalıştırdım ama kurulmadı” durumunda ilk bakılacak yer burasıdır.

Çıktıdaki DisplayName sütunu ayrıca kullanışlı bir ayrıntı taşıyor: bileşenin adı RSAT-AD-Tools ama görünen adı AD DS and AD LDS Tools. Arayüzde ararken bileşen adını değil bu görünen adı göreceksiniz.

Arayüzden yapmak isterseniz Server Manager → Manage → Add Roles and Features yolunu izleyip Features adımında Remote Server Administration Tools ağacını açın. Roller ve araçlar burada ayrı ayrı listelenir.

İki tarafı lab’daki iki makinede yan yana koyunca fark şöyle:

İki davranışı bilmek işinizi kolaylaştırır:

1. DC’de araçlar rolle birlikte gelir. dc01’e RSAT bileşenlerini ayrıca kurmadım, rolü Install-WindowsFeature AD-Domain-Services -IncludeManagementTools ile kurdum. DC olarak promote ettikten sonra RSAT ile başlayan sekiz feature Installed’dı, aralarında Active Directory Administrative Center ve DNS araçları da var. GPMC bu süzgeçte görünmez, çünkü adı RSAT ile başlamıyor.
2. Üye sunucuda rol, konsolu getirmeyebilir. Rolü kurarken -IncludeManagementTools parametresini vermezseniz rol gelir ama onu yöneten konsol gelmez. Rol kurulu olduğu hâlde konsolun bulunamaması genellikle bu unutulmuş parametredir.

Server Core kurulumlarında konsolların yeri yoktur, çünkü grafik arayüz yoktur. Server Core’u yönetmenin yolu zaten budur: araçları başka bir makineye kurup oradan bağlanmak. Core ve Desktop Experience arasındaki seçimi Windows Server kurulumu yazımızda ayrıntılı ele aldık.

RSAT ile Gelen Konsollar: GPMC, ADUC ve Diğerleri

Örnekteki arka ofiste terminal kuruldu, sıra ekranındaki programları tanımaya geldi: hangisi misafir kaydını, hangisi oda ayarlarını açıyor. RSAT’ta bunlar bir konsol takımıdır ve takımın her parçasının bir dosya adı vardır.

Kurulum bittiğinde konsollar Start menüsünde Windows Tools klasörü altında toplanır. Ama sahada kimseyi oradan açarken görmezsiniz: herkes konsolun dosya adını yazar. Win + R ile Run kutusunu açıp dsa.msc yazmak, Active Directory Users and Computers’ı açmanın en kısa yoludur ve bu adlar her Windows’ta aynıdır. Bir belgede ya da bir meslektaşınızın mesajında gpmc.msc gördüğünüzde kastedilen şey budur: kurulu bir konsolu adıyla çağırmak.

Tablodaki her konsol her makinede yoktur, konsolu kendi bileşeni getirir. İstemcide Active Directory ve Group Policy bileşenleri kuruluyken System32 altında tablonun ilk beş satırı vardı: dsa.msc, gpmc.msc, domain.msc, dssite.msc, adsiedit.msc. DNS, DHCP ve sertifika konsolları kendi bileşenleri kurulunca gelir.

Bu tablo bir envanterdir, kullanım kılavuzu değil. Her konsolun kendi derinliği var ve büyük kısmını ayrı yazılarda ele aldık: GPMC ile policy oluşturma, linkleme ve LSDOU sırası Group Policy yönetimi yazımızda, ADUC ile kullanıcı, grup ve birim açma kullanıcı ve OU yönetimi yazımızda, domain.msc üzerinden UPN soneki eklemek ise UPN suffix yazımızda anlatılıyor.

Konsolların yanında bir de PowerShell modülü gelir ve uzun vadede asıl kazancınız orada. RSAT-AD-PowerShell bileşeni kurulduğunda Get-ADUser, Get-ADComputer, New-ADUser gibi komutlar kullanılabilir hale gelir. Tek bir kullanıcıyı ararken konsol daha hızlıdır. İki yüz kullanıcıyı bir birimden diğerine taşırken konsol tek başına bir gün yer, aynı iş komutla birkaç satırdır. Domaine katılmış bir bilgisayarın dizinde gerçekten oluşup oluşmadığını Get-ADComputer ile doğrulamayı domaine bilgisayar ekleme yazımızda örnekledik.

Kurulumdan sonra standart bir domain kullanıcısıyla, ayse.demir ile oturum açtım. Hesap yönetici değil. dsa.msc ve gpmc.msc UAC istemeden açıldı ve ikisi de domain’i okudu:

Bu son ayrıntı istemciden çalışmanın küçük ama gerçek bir kazancı. GPO yönetimi lab turunda dc01’de açılan GPMC’nin Settings sekmesi, sunucudaki IE ESC yüzünden önce boş bir uyarı gösterdi ve adres güvenilen sitelere eklenene kadar raporu açmadı. Windows 11 istemcide bu engel yok.

Okumak ise yazmak değil. ayse.demir ADUC’ta mert.kaya’nın Properties penceresini açabildi, ama Description alanı yazı kabul etmedi ve Apply düğmesi gri kaldı. Bir hata penceresi çıkmadı, çünkü değişiklik hiç başlamadı: konsol hesabın yazma iznini okuyup alanları kilitli açtı.

Yönetim Araçları Nereden Çalıştırılmalı?

Kural tek cümleye sığıyor: yönetim araçları yönetilen makinede değil, yöneticinin makinesinde çalışır. Ama bu cümlenin iki yarısı var ve sahada ikisi ayrı ayrı ihmal ediliyor: hangi makineden çalıştığınız ve hangi hesapla çalıştığınız. Bu bölüm birincisini ele alıyor, hemen ardından gelen bölüm ikincisini.

Sahada en sık karşılaştığım manzara şu: sırf bir kullanıcı açmak için domain controller’a uzak masaüstüyle bağlanılıyor. İş iki dakika sürüyor, kimse rahatsız olmuyor, ertesi gün aynısı tekrarlanıyor. Zararsız göründüğü için de kimse durup bunun neye mal olduğunu sormuyor.

Bu alışkanlığın bedeli tek kalemde ödenmiyor. Üç ayrı yerden ödeniyor ve üçü birbirinden bağımsız: birini kapatsanız diğer ikisi işlemeye devam eder.

Birinci katman: güvenlik kaydınız. Microsoft’un ayrıcalıklı erişim rehberi bunu açıkça yazıyor: bir domain controller’a yapılan her etkileşimli ve uzak oturum açma yüksek hassasiyetli bir olaydır ve onaylı liste dışındaki her giriş alarm üretmelidir. Günlük yönetimi sunucuya bağlanarak yapan kurumda bu alarm her gün çalar. Her gün çalan alarm, bir süre sonra alarm olmaktan çıkar. Gerçek bir saldırgan aynı kapıdan girdiğinde onun oturumu da kalabalığın içinde sıradan görünür. Yani buradaki kayıp yalnızca risk değil, kurumun kendi erken uyarı sisteminin körelmesidir.

İkinci katman: zamanınız. Güvenliği tamamen bir kenara bırakıp sadece iş yükünü sayın, aynı yere çıkıyorsunuz. Bir kullanıcı açmak için DC’ye bağlanmak beş kişilik bir yerde zahmetsiz görünür: günde bir kez olur, birkaç dakika sürer. Beş yüz kişilik bir yerde aynı alışkanlık günün tamamını yer. İşin kendisi zorlaşmaz, yalnızca sayısı artar ve arkasında hiçbir şey birikmez. Ertesi sabah aynı yerden başlarsınız.

Google’ın SRE ekibi bu tür işe bir ad vermiş: toil. Tanımın belirleyici maddesi de tam bizim durumumuz, işin sistem büyüdükçe doğrusal artması. Elle yapılan bir işin tehlikesi zor olması değil, kurum büyüdükçe sizi daha meşgul edip daha yetkin yapmamasıdır.

Üçüncü katman: oturumun taşıdığı yetki. DC’ye bağlanan hesap çoğu zaman ihtiyacından kat kat fazlasını taşır ve o yetki oturum açık kaldığı sürece makinenin üstünde durur. Bu üçüncüsü aslında bir sonraki bölümün konusu: hangi hesapla bağlandığınız, nereden bağlandığınız kadar belirleyicidir.

Aynı disiplinin protokol tarafındaki karşılığını başka yazılarda ölçtüm. LDAP şifresiz bağlantıda parolayı ağda okunur halde taşıyor, HTTP aynısını web girişinde yapıyor, Telnet ise bunu doğrudan cihaz yönetiminde yapıyor. Üçünde de soru aynı: bu kimlik nereden geçiyor ve yolda kim görebiliyor? Yönetim aracını sunucudan indirip kendi makinenize almak da aynı sorunun bir başka cevabıdır. Kimliğin dolaştığı yüzeyi daraltırsınız.

Pratik bir not: yönetim makineniz domaine üye değilse konsolu kendi oturumunuzla açmak yetmez, çünkü konsol sizin oturumunuzun kimliğiyle bağlanmaya çalışır. Bu durumda konsolu yönetim hesabının kimliğiyle başlatın:

runas /netonly /user:SISTEMKUSU\yonetim.hesabi "mmc dsa.msc"

/netonly parametresi, verdiğiniz kimliğin yalnızca ağ bağlantılarında kullanılacağını söyler. Yerel oturumunuz değişmez. Parolayı yanlış yazarsanız komut hata vermez, konsol açılır ve domaine bağlanamaz. Bu yüzden bağlantı kurulmadığında ilk şüphelenilecek yer parolanın kendisidir.

Yönetim Araçlarını Hangi Hesapla Çalıştırmalı?

Doğru makineden çalışmak işin yarısı. Diğer yarısı, o araçları çalıştıran hesabın günlük işlerinizi yaptığınız hesap olmaması.

Aynı disiplinin gündelik hali, kullanıcı bilgisayarlarında karşınıza çıkan UAC penceresidir. Sıradan bir kullanıcı yönetici yetkisi gerektiren bir şey yapmaya kalktığında Windows User Account Control penceresini açar ve bir yönetici hesabı ister. Oraya domain yönetici hesabınızı yazmak en kolay yoldur ve tam olarak yapılmaması gereken şeydir: o kimlik artık kullanıcının makinesinden geçmiştir.

Ben bunun yerine her zaman o makinenin yerel yönetici hesabını kullandım. O ortamlarda LAPS yoktu, parola klasik yerel yönetici parolasıydı. Pencere yine açıldı, iş yine yapıldı, ama domain hesabı o klavyeye hiç dokunmadı.

Klasik parolanın da kendi riski var: aynı parola birden fazla makinede kullanılıyorsa, bir makinede açığa çıkan parola hepsini açar. LAPS bu açığı her makineye ayrı ve kendini yenileyen bir parola vererek kapatır.

Sahada bu ayrımı çoğu yerde bulamıyorum. DC’ye bağlanan ya da UAC penceresine parola yazan hesap çoğu zaman Enterprise Admins ya da Schema Admins üyesi oluyor. Ömründe belki bir kez, forest genelinde bir değişiklik yaparken gerekecek yetkiler, her sabah açılan sıradan bir oturumun üstünde taşınıyor.

Bu hesapların helpdesk işlerinde kullanıldığını da görüyorum. Kullanıcının makinesine gidilir, UAC penceresi açılır ve oraya forest düzeyinde yetkisi olan bir hesabın parolası yazılır. O parola üç yoldan açığa çıkabilir:

1. Omuz üstünden: kullanıcı yazarken bakıyordur.
2. Klavye dinleyiciyle: makinede zaten bir keylogger vardır.
3. Kimlik iziyle: hiç kimsenin parolayı görmesine gerek kalmaz. O hesapla açılan oturum makinenin üstünde bir kimlik izi bırakır ve makineyi elinde tutan biri, parolayı hiç öğrenmeden o kimliği yeniden kullanabilir.

Üçüncüsü en sinsisidir, çünkü hiçbir aşamada “parola çalındı” diyebileceğiniz bir an yoktur.

İlk ikisi yukarıdaki çocukluk hikayesiyle birebir aynı olay, yalnız bedeli farklı. Orada bir sosyal medya hesabı gidiyordu. Burada kurumun tamamı gidiyor.

Peki doğrusu ne? Bir kullanıcının parolasını sıfırlamak için Domain Admins üyeliği gerekmez. Active Directory’nin devretme mekanizması, “şu birimdeki hesapların parolasını sıfırlayabilir” kadar dar bir yetkiyi tek başına vermeye izin verir. Helpdesk’teki bir kişiye ihtiyacı olan tek yetkiyi vermek ile domainin tamamını vermek arasındaki fark, bir kutucuk kadar iş ve bir olay müdahalesi kadar sonuç doğurur. Devretme, ADUC içinde bir birime sağ tıklayınca açılan sihirbazdan yapılır ve çoğu kurumda o sihirbaz hiç açılmamıştır.

Binin üzerinde cihazı olan bir Active Directory geçişinde bu yapıyı tam olarak böyle kurduk: şubelerdeki BT personeline araçları kendi makinelerine kurduk, yetkileri de yalnızca kendi birimleriyle sınırlı olacak şekilde devrettik. Sonuç, merkeze bağımlı olmayan ama kimsenin domain controller’a girmediği bir düzen oldu. Vakanın tamamı Active Directory modernizasyon projesi sayfasında.

RSAT Hangi Dizinleri Yönetir? Windows AD ve Samba AD

Yaygın bir varsayım var: bu araçlar Windows’a özgüdür, dolayısıyla yalnızca Windows Server üzerinde çalışan bir Active Directory’yi yönetirler. Varsayımın ilk yarısı yanlış, ikinci yarısı eksik. İkisini birden düzeltmek, bu araçların ne olduğunu anlamanın da en kısa yolu.

GPMC ya da ADUC bir domaine bağlanırken karşı taraftaki işletim sistemini hiç sormaz. Dört şey konuşur:

1. DNS. _ldap._tcp gibi SRV kayıtlarını sorup domain controller’ın kim olduğunu ve nerede durduğunu bulur.
2. Kerberos. Kimliğinizi doğrulatıp bilet alır, yani parolanız ağda hiç dolaşmaz.
3. LDAP. Dizindeki nesneleri okur ve yazar. Bir kullanıcı açtığınızda giden şey budur.
4. SMB. SYSVOL paylaşımına erişip Group Policy dosyalarını okur ve yazar.

Dördü de kendi başına birer protokol ve her birinin nasıl çalıştığını ayrı yazılarda ele aldık. Buradaki mesele hangisinin ne yaptığı değil, dördünün birlikte ne anlama geldiği.

Bu dördünü Active Directory’nin beklediği şekilde konuşan her sunucu bu konsollarla yönetilir. İşletim sistemi ölçüt değildir.

Bunu lab ortamımızda ölçtüm. Ubuntu üzerinde çalışan bir Samba AD DC ile ayrı bir domain kuruldu, o domainin bir GPO’su yalnızca samba-tool ile, yani Linux komut satırından oluşturuldu ve Windows tarafındaki GPMC o domaine bağlanıp aynı GPO’yu açtı, ayarlarını gösterdi ve düzenlenebilir halde sundu. Konsolun tarafında hiçbir özel yapılandırma yapılmadı. Kurulumun tamamı ve ölçüm kayıtları Samba AD DC kurulumu yazımızda.

Ekranda dikkat çeken şey, dikkat çeken hiçbir şeyin olmaması. Konsol bir uyumluluk uyarısı vermiyor, kısıtlı bir kipe düşmüyor, ilkeyi “yabancı” diye işaretlemiyor. Ağaçta Forest yazıyor ve altındaki domain Ubuntu üzerinde çalışıyor. Bunu ekrandan anlamanın hiçbir yolu yok, çünkü konsol açısından anlaşılacak bir fark yok.

Ama bu araçlar “evrensel” de değil ve sınır tam olarak şurada: bunlar genel amaçlı bir LDAP istemcisi değildir. OpenLDAP ya da FreeIPA gibi dizinlere doğrultulamazlar. Sebebi eksik bir özellik değil, farklı bir yapı. O dizinler Active Directory’nin şemasını uygulamaz ve SYSVOL diye bir paylaşım sunmaz. ADUC’un okumaya çalıştığı nesne sınıfları orada yoktur. GPMC’nin yazacağı policy dosyasının duracağı yer yoktur. Konsol bir eksiklik bildirmez, sadece bağlanamaz.

Ölçüt bu yüzden “Windows mu?” değil, “Active Directory mi?”. Bunu bir kez yerine oturttuğunuzda, yönetim makinenizin Active Directory ile Windows’un aynı şey olmadığını gösteren en somut kanıt olduğunu görürsünüz.

RSAT Sık Yapılan Hatalar ve Teşhis

Örnekteki arka ofis terminali kurulurken tökezlenen yerler bellidir ve neredeyse hiçbiri terminalin kendisinde değildir. Arızaların çoğu terminali ön büroya bağlayan hatta çıkar. Paket nereden geliyor, isim nasıl çözülüyor, hangi kimlikle bağlanılıyor. Aşağıdakiler sahada en sık karşılaştıklarım.

Optional features listesinde RSAT hiç çıkmıyor. Neredeyse her zaman sürüm meselesidir: makine Windows Home’dur. Kurumsal bir cihazda beklenmedik bir durumsa, cihazın gerçekten kurumsal imajla kurulup kurulmadığı sorusunu da sormaya değer.

İndirdiğim RSAT paketi kurulmuyor. Eski yöntemi anlatan bir rehberi izliyorsunuz demektir. Güncel Windows 10 ve 11 sürümlerinde ayrı paket indirilmez, indirilen eski paket de kurulmaz. Doğru yol yukarıdaki Optional features yoludur.

Kapalı ağda ya da WSUS’lu ortamda kurulum ilerlemiyor. Buradaki cevap Windows sürümüne göre değişir ve bu ayrımı yapmayan bir rehber sizi artık var olmayan bir ayarı aramaya gönderir.

Mekanizma şu: Windows 10 sürüm 1709’dan itibaren WSUS, Features on Demand içeriğini yerel olarak barındıramıyor. Sebep bir eksiklik değil, mimari fark. Bu içerik tek tek dosya indirmeye dayanır, WSUS ise servis paketleri dağıtır. Microsoft’un kendi belgesine göre bu iki dosya biçimi birbiriyle uyumlu değildir. Bozulan tek bir dosyayı onarmak için birkaç kilobaytlık parçayı indirmek gerekir, WSUS’un dağıttığı paket ise bunun için tasarlanmamıştır.

Windows 10 1709 ile Windows 11 21H2 arasındaysanız çözüm, isteğe bağlı bileşenlerin doğrudan Windows Update’ten alınmasına izin veren ilkeyi açmaktır: Computer Configuration → Administrative Templates → System → Specify settings for optional component installation and component repair. İnternet erişimi hiç yoksa aynı ilkedeki Alternate source file path alanına bir \sources\sxs klasörü ya da WIM: önekiyle bir WIM dosyası gösterilebilir.

Windows 11 22H2 ve sonrasındaysanız bu ilkeye hiç ihtiyacınız yok. Şirket içi UUP güncellemeleriyle birlikte Features on Demand içeriği WSUS üzerinden yeniden sunulmaya başladı. Dahası, o ilkenin içindeki ilgili kutucuklar Windows 11 24H2’de tamamen kaldırıldı. Sürüm sınırlarını Microsoft’un FoD ve dil paketleri belgesi açıkça yazıyor. Hâlâ o kutucuğu tarif eden bir rehber okuyorsanız, o rehber eskimiştir.

Konsol açılıyor ama domaini bulamıyor. Kurulum değil isim çözümü sorunudur. Yönetim makinesi domainin DNS sunucusunu kullanmıyorsa konsol DC’yi bulamaz. Buradaki tuzak, hatanın sessiz olabilmesidir: dış dünyaya bakan bir çözümleyici, sorduğunuz iç isme “bulunamadı” demek yerine alakasız bir adres döndürebilir ve o zaman elinizde kendinden emin bir yanlış cevap olur. Kurumsal DNS tasarımını Active Directory DNS yapılandırması yazımızda ele aldık.

Konsol açılıyor, nesneleri görüyorum ama alanlar kilitli. Bu bir kurulum sorunu değil, yetki sonucudur ve sistemin doğru çalıştığının işaretidir. Dizini okumak için sıradan bir domain kullanıcısı yeterlidir, yazmak ayrı yetki ister. Lab’da standart kullanıcı ayse.demir’in açtığı Properties penceresinde alanlar düzenlenmedi ve Apply gri kaldı. Konsolu hangi hesapla açtığınıza bakın.

Sunucudaki bir ayarı konsolda hiç göremiyorum. Yönetim makineniz sunucudan eski bir Windows sürümü çalıştırıyor olabilir. Yeni sunucu sürümleriyle gelen özelliklerin arayüz karşılığı eski konsollarda bulunmaz. Kural basit: yönetim makinesini yönettiğiniz en yeni sunucu kadar güncel tutun.

Sonuç: RSAT Kurmak Kolay, Sunucuya Bağlanmayı Bırakmak Zor

Yönetim araçlarını kurmak birkaç komutluk bir iştir, beklenen tek şey indirmedir: lab’da Group Policy bileşeni 20, Active Directory bileşeni 50 dakika sürdü. Asıl iş, sunucuya bağlanma alışkanlığından vazgeçmektir ve o daha uzun sürer, çünkü uzak masaüstü tanıdıktır ve her seferinde çalışır.

Girişteki benzetmeye dönersek, hesap net: arka ofisteki terminali kurmanın bedeli bir kereliktir. DC’ye her gün bağlanmanın bedeli ise her gün ödenir:

1. DC’ye açılan her oturum, gerçek bir saldırıyı fark etmenizi sağlayacak kaydın içine bir gürültü satırı daha ekler.
2. Elle tekrarlanan her iş, sistem büyüdükçe biraz daha uzar.
3. Gereğinden geniş yetkiyle açılan her oturum, o makinede bir şey ters gittiğinde kaybedeceğiniz şeyi büyütür.

Terminal zaten kutunun içinde geliyor. Yapılması gereken tek şey onu kurmak ve ön büro masası yerine oraya oturmak.

Bu yazı Active Directory rehberimizin yönetim konsolları adımıdır. Sıradaki adım, kurduğunuz GPMC ile ilk policy’yi yazmak: Active Directory GPO yönetimi.

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