Active Directory nedir, kurumsal ağda ne işe yarar? Domain, OU, GPO ve kullanıcı yönetimi kavramlarını sahadan örneklerle ele alıyoruz.
Active Directory Neyi Çözer?
On kişilik bir ofiste her bilgisayarın kendi kullanıcı hesabını taşıması sorun yaratmaz. Yüz kişiye çıktığınızda ise aynı yaklaşım sürdürülemez hale gelir: parola değişikliği yüz makineye tek tek gitmek, işten ayrılan birinin erişimini kesmek ise unutulan bir makinede açık kalan bir kapı demektir.
Active Directory (AD), kullanıcıları, bilgisayarları ve yetkileri tek bir merkezde toplayan dizin hizmetidir. Bir kullanıcıyı bir kez tanımlarsınız; o kullanıcı ağdaki tüm kaynaklara aynı kimlikle erişir. Devre dışı bırakmak da tek bir işleme iner.
Aşağıdaki tablo, aynı işin iki yaklaşımda ne kadar sürdüğünü kabaca özetliyor. Sayılar 100 kullanıcılı tipik bir ortam içindir.
| İşlem | Dağıtık (yerel hesaplar) | Active Directory |
|---|---|---|
| Yeni çalışan tanımlama | Her makinede ayrı hesap | Tek nesne, tüm ağda geçerli |
| İşten ayrılan erişimi kesme | Makine makine dolaşmak | Hesabı devre dışı bırakmak |
| Parola politikası uygulama | Makine başına ayar | Tek GPO, tüm domain |
| Yazılım dağıtımı | Elle kurulum | GPO ya da dağıtım aracı |
| Kim neye erişiyor? | Cevaplanması zor | Grup üyeliğinden okunur |
Buradaki asıl kazanç zamandan tasarruf değil, hesap verebilirlik. Dağıtık yapıda "bu klasöre kimler erişebiliyor" sorusunun güvenilir bir cevabı yoktur.
Domain, Forest ve Domain Controller
Domain, ortak bir güvenlik sınırını paylaşan nesneler kümesidir. Forest ise bir veya daha fazla domain'i kapsayan en dış sınırdır. Güvenlik açısından asıl sınır forest'tır: iki domain aynı forest içindeyse, birinde yönetici olan kişi diğerini de etkileyebilecek yollara sahiptir.
Domain Controller (DC), AD veritabanını barındıran ve kimlik doğrulama isteklerini karşılayan sunucudur. Tek DC ile çalışmak mümkündür ama risklidir: o sunucu düştüğünde kimse oturum açamaz. Bu yüzden üretim ortamlarında en az iki DC bulundurulur.
Kurulumun kendisi grafik arayüzden yapılabilir, ancak PowerShell hem tekrarlanabilir hem de belgelenebilir olduğu için tercih edilir:
# Rolü kur (henüz domain oluşmaz)
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
# Yeni bir orman ve ilk domain'i oluştur
Install-ADDSForest `
-DomainName "bapati.local" `
-DomainNetbiosName "BAPATI" `
-InstallDns `
-DomainMode WinThreshold `
-ForestMode WinThreshold
# İkinci DC'yi mevcut domain'e ekle (ayrı sunucuda)
Install-ADDSDomainController `
-DomainName "bapati.local" `
-InstallDns `
-Credential (Get-Credential)Domain adı seçimi sonradan değiştirilmesi en zor kararlardan biridir. .local gibi uydurma bir uzantı yerine, sahip olduğunuz bir alan adının alt bölümünü kullanmak (ic.bapati.com gibi) sertifika ve dış entegrasyon işlerini yıllar sonra kolaylaştırır.
AD ve DNS Ayrılmaz İkilidir
Active Directory'nin DNS'e bağımlılığı çoğu zaman hafife alınır. İstemciler, hangi sunucunun Domain Controller olduğunu DNS üzerindeki SRV kayıtlarından öğrenir. Bu kayıtlar yoksa AD, çalışıyor olmasına rağmen bulunamaz.
Sorunun belirtisi genellikle "domain'e katılamıyorum" ya da "oturum açma çok yavaş" olur; kaynağı ise neredeyse her zaman ad çözümlemesidir. İlk bakılacak yer şudur:
# DC'yi ilan eden SRV kaydı gerçekten var mı?
nslookup -type=SRV _ldap._tcp.dc._msdcs.bapati.local
# İstemcinin gördüğü DNS sunucusu hangisi?
Get-DnsClientServerAddress -AddressFamily IPv4
# DC'nin kendi sağlık kontrolü
dcdiag /test:dns /vPratik kural: domain üyesi makineler birincil DNS olarak her zaman Domain Controller'ı göstermelidir, doğrudan bir public DNS'i değil. Dış adlara erişim, DC üzerindeki yönlendirici (forwarder) ayarıyla çözülür.
Organizational Unit (OU): Sadece Klasör Değil
OU'lar ilk bakışta düzen amaçlı klasörler gibi görünür. Asıl işlevleri ise Group Policy'nin uygulanma noktası ve yetki devrinin sınırı olmalarıdır. Bu yüzden OU yapısını departmanlara göre değil, uygulanacak politikalara ve yetki devrine göre tasarlamak daha sağlıklı sonuç verir.
Departman temelli bir ağaç ilk yıl düzenli görünür; şirket büyüyüp bir kişi iki departmanda çalışmaya başladığında ya da politika bir departmanın yalnızca yarısına uygulanması gerektiğinde çatlar.
# Kullanıcı ve bilgisayar nesnelerini ayrı tutan basit bir iskelet
New-ADOrganizationalUnit -Name "Bapati" -Path "DC=bapati,DC=local"
New-ADOrganizationalUnit -Name "Kullanicilar" -Path "OU=Bapati,DC=bapati,DC=local"
New-ADOrganizationalUnit -Name "Bilgisayarlar" -Path "OU=Bapati,DC=bapati,DC=local"
New-ADOrganizationalUnit -Name "Servis Hesaplari" -Path "OU=Bapati,DC=bapati,DC=local"Varsayılan Users ve Computers birer container'dır, OU değildir; onlara Group Policy bağlayamazsınız. Domain'e yeni katılan bilgisayarların doğrudan doğru OU'ya düşmesi için varsayılan hedefi değiştirmek gerekir:
redircmp "OU=Bilgisayarlar,OU=Bapati,DC=bapati,DC=local"
redirusr "OU=Kullanicilar,OU=Bapati,DC=bapati,DC=local"Gruplar ve AGDLP Kuralı
AD'de üç grup kapsamı bulunur ve hangisinin nerede kullanılacağı, özellikle çok domain'li yapılarda kritiktir.
| Kapsam | Üye alabildiği | Tipik kullanım |
|---|---|---|
| Global | Kendi domain'indeki hesaplar | Rolü/görevi temsil eder: "Muhasebe" |
| Domain Local | Her domain'den hesap ve global grup | Kaynağa izin verilen yer: "Muhasebe-Klasor-Yazma" |
| Universal | Forest'taki her domain'den | Çok domain'li yapılarda köprü |
Yaygın kabul gören yaklaşım AGDLP kısaltmasıyla anılır: hesapları (Account) global gruplara koyun, global grupları (Global) domain local gruplara (Domain Local) üye yapın, izinleri (Permission) domain local gruplara verin.
# A: hesap -> G: rol grubu
New-ADGroup -Name "GG-Muhasebe" -GroupScope Global -Path "OU=Kullanicilar,OU=Bapati,DC=bapati,DC=local"
Add-ADGroupMember -Identity "GG-Muhasebe" -Members "ayse.yilmaz","mehmet.demir"
# DL: kaynak grubu -> P: izin
New-ADGroup -Name "DL-Muhasebe-Yazma" -GroupScope DomainLocal -Path "OU=Kullanicilar,OU=Bapati,DC=bapati,DC=local"
Add-ADGroupMember -Identity "DL-Muhasebe-Yazma" -Members "GG-Muhasebe"
# NTFS izni yalnızca DL gruba verilir, kullanıcıya asla
$yol = "D:\Paylasim\Muhasebe"
$acl = Get-Acl $yol
$kural = New-Object System.Security.AccessControl.FileSystemAccessRule(
"BAPATI\DL-Muhasebe-Yazma","Modify","ContainerInherit,ObjectInherit","None","Allow")
$acl.AddAccessRule($kural)
Set-Acl $yol $aclBu zincire uyulduğunda bir kişinin erişimini değiştirmek tek bir grup üyeliğine iner ve yetki yapısı yıllar sonra bile okunabilir kalır. Uyulmadığında ise "kim neye neden erişiyor" sorusu kısa sürede cevaplanamaz hale gelir.
Group Policy ile Merkezi Yönetim
Group Policy (GPO), ayarları tek noktadan tanımlayıp binlerce makineye uygulamanızı sağlar. Parola politikası, ekran kilidi, yazıcı dağıtımı, yazılım kurulumu ve klasör yönlendirmesi bunların yalnızca birkaçıdır.
GPO'lar dört seviyede işler ve çakışma olduğunda en son uygulanan kazanır. Sıralamayı bilmemek, "ayarı yaptım ama uygulanmıyor" sorununun en yaygın nedenidir.
| Sıra | Seviye | Not |
|---|---|---|
| 1 | Local | Makinenin kendi politikası, en zayıf |
| 2 | Site | Ağ konumuna göre |
| 3 | Domain | Tüm domain geneli |
| 4 | OU (en içteki en son) | En güçlü — çakışmada bu kazanır |
İki istisna bu sırayı bozar: Enforced işaretlenmiş bir GPO alttakiler tarafından ezilemez, Block Inheritance uygulanmış bir OU üsttekileri almaz. İkisini birden kullanmak ortamı kısa sürede takip edilemez hale getirdiği için, ikisini de istisnai tutmak gerekir.
Bir ayarın neden uygulanmadığını tahmin etmek yerine ölçmek mümkündür:
# Politikayı hemen yenile
gpupdate /force
# Bu makine/kullanıcı hangi GPO'ları aldı, hangileri neden elendi?
gpresult /h C:\rapor.html /f
# Uzaktan, belirli bir kullanıcı için modelleme
Get-GPResultantSetOfPolicy -User BAPATI\ayse.yilmaz -Computer PC-042 -ReportType Html -Path C:\rsop.htmlEn Az Yetki Prensibi
Her işi Domain Admin hesabıyla yapmak pratik görünür ama kurumsal güvenliğin en zayıf halkasıdır. Bu hesabın ele geçirilmesi, tüm ortamın ele geçirilmesi anlamına gelir — ve bu genellikle sofistike bir saldırıyla değil, yönetici hesabıyla açılmış bir oturumda tıklanan bir ekle olur.
Uygulaması kolay, etkisi yüksek üç alışkanlık:
| Alışkanlık | Neyi engeller |
|---|---|
| Günlük iş için standart hesap, yönetim için ayrı hesap | Yönetici oturumunda çalışan zararlının tüm ortamı ele geçirmesini |
| Yardım masasına Delegation of Control ile sınırlı yetki | Parola sıfırlamak için Domain Admin verilmesini |
| Yönetici hesaplarıyla iş istasyonlarına oturum açmamak | Kimlik bilgisinin uç noktada bellekte kalmasını |
Delegation, grafik arayüzde sihirbazla yapılabildiği gibi betikle de tanımlanabilir. Örneğin yardım masasına yalnızca belirli bir OU'da parola sıfırlama yetkisi vermek:
$ou = "OU=Kullanicilar,OU=Bapati,DC=bapati,DC=local"
$grup = "BAPATI\GG-YardimMasasi"
# Yalnızca "Reset Password" genişletilmiş hakkı, yalnızca bu OU altında
dsacls $ou /I:S /G "${grup}:CA;Reset Password;user"
dsacls $ou /I:S /G "${grup}:WP;pwdLastSet;user"Yetki devrinin sınırı OU olduğu için, OU tasarımını politika ve yetkiye göre yapma önerisi burada karşılığını buluyor.
Yedekleme Olmadan Hiçbiri Anlamlı Değil
AD'nin geri dönüşü, düzgün alınmış bir System State yedeğine bağlıdır. Bu yedek AD veritabanını (ntds.dit), SYSVOL'ü ve registry'yi kapsar. Sanal makinenin anlık görüntüsü bunun yerini tutmaz: eski bir anlık görüntüye dönmek çoğaltmayı bozabilir.
# System State yedeği (Windows Server Backup kurulu olmalı)
wbadmin start systemstatebackup -backupTarget:E: -quiet
# Geri Dönüşüm Kutusu'nu etkinleştir (bir kez açılır, kapatılamaz)
Enable-ADOptionalFeature "Recycle Bin Feature" `
-Scope ForestOrConfigurationSet `
-Target "bapati.local"
# Yanlışlıkla silinen bir kullanıcıyı üyelikleriyle birlikte geri getir
Get-ADObject -Filter 'Name -like "*Yilmaz*"' -IncludeDeletedObjects |
Restore-ADObjectAD Recycle Bin, silinen nesneyi grup üyelikleriyle birlikte dakikalar içinde geri getirir ve gündelik hataların büyük kısmını çözer. Ancak bir DC'nin donanım arızası, veritabanı bozulması ya da fidye yazılımı gibi durumlarda tek çare System State yedeğidir.
Son bir hatırlatma: test edilmemiş yedek, yedek değildir. Geri dönüş provasını izole bir ortamda yılda en az bir kez yapmak, felaket anında öğrenilecekleri sakin bir günde öğrenmenizi sağlar.
Nereden Başlamalı?
Sıfırdan kuran biri için makul bir sıra şudur: önce tek DC ve DNS ile çalışan bir laboratuvar kurun, ardından OU iskeletini ve bir parola politikası GPO'sunu ekleyin, sonra AGDLP ile bir paylaşımı yetkilendirin. Bu üç adım AD'nin günlük kullanımının büyük kısmını kapsar. İkinci DC, DHCP ve yedekleme bunun üzerine rahatça oturur.
Daha fazlası: Bu konuların tamamını uygulamalı olarak anlattığımız Active Directory eğitim serisi 26 bölümden oluşuyor: kurulumdan GPO'ya, DHCP'den yedeklemeye kadar adım adım ilerliyoruz.
Videoyu sitemizde izle · YouTube'da aç · Kanala abone ol
Daha fazlası: Active Directory kurulumunu ve yönetimini sıfırdan anlattığımız seriyle konuyu uygulamalı takip edebilirsiniz.
Videoyu sitemizde izle · YouTube'da aç · Bapati kanalına abone ol
