İyi Bir Active Directory Yapısı Nasıl Kurulur? Roller ve Kurulum Sırası

Bir kuruma “Active Directory kuralım” demek kolaydır; ancak sağlam, ölçeklenebilir ve hata toleranslı bir AD yapısı kurmak planlama gerektirir. Yanlış kurgulanmış bir Active Directory ortamı; tek bir sunucu çöktüğünde tüm oturum açma işlemlerinin durması, sertifika altyapısının çökmesi veya DNS sorunları yüzünden kullanıcıların ağa erişememesi gibi ciddi problemlere yol açar.

Bu yazıda iyi bir Active Directory yapısının nasıl kurulacağını, olmazsa olmaz rolleri, her rolün kaç makineye dağıtılması gerektiğini, kurumsal bir ortamda en az kaç Domain Controller bulunması gerektiğini ve doğru kurulum sırasını ele alacağız. Örnek senaryomuzu Windows Server 2019 ve 192.168.1.231, 192.168.1.232, 192.168.1.233 IP adreslerine sahip 3 sunucu üzerinde kuracağız.

Active Directory’nin ne olduğunu ve neden gerektiğini henüz okumadıysanız, başlamadan önce Active Directory Nedir ve Neden Gereklidir? yazısına göz atmanızı öneririm.

İyi Bir Active Directory Yapısının Temel İlkeleri

Sağlam bir AD tasarımı birkaç temel ilkeye dayanır:

• Yedeklilik (Redundancy): Hiçbir kritik servis tek bir sunucuya bağımlı olmamalıdır. Tek Domain Controller, tek hata noktası (single point of failure) demektir.
• Rol ayrımı (Separation of roles): Sertifika Yetkilisi (CA) gibi güvenlik açısından kritik roller, mümkünse Domain Controller’lardan ayrı sunuculara kurulmalıdır.
• Sağlam DNS: Active Directory tamamen DNS üzerine inşa edilmiştir. DNS düzgün çalışmıyorsa AD de çalışmaz.
• Doğru kurulum sırası: Önce dizin ve isim çözümleme (AD DS + DNS), sonra bu altyapıya bağımlı servisler (DHCP, CA vb.) kurulur.

Olmazsa Olmaz Roller ve Açıklamaları

Aşağıdaki tablo, kurumsal bir Active Directory ortamında bulunması gereken temel rolleri, görevlerini ve kaç makineye dağıtılması gerektiğini özetliyor.

1. AD DS — Active Directory Domain Services

AD DS, Active Directory’nin kalbidir. Kullanıcıları, bilgisayarları, grupları ve grup politikalarını tutar; kimlik doğrulamayı (authentication) ve yetkilendirmeyi (authorization) yürütür. AD DS’nin kurulu olduğu sunucuya Domain Controller (DC) denir.

Kritik kural: Kurumsal bir ortamda asla tek bir Domain Controller ile çalışmayın. En az 2 DC olmalıdır; biri çökerse diğeri kimlik doğrulamaya devam eder.

2. DNS — Domain Name System

Active Directory, servislerini ve Domain Controller’larını SRV kayıtları üzerinden DNS’te yayınlar. İstemciler “hangi sunucu beni doğrulayacak?” sorusunun cevabını DNS’ten alır. Bu yüzden DNS, AD DS ile birlikte ve genellikle aynı Domain Controller üzerinde kurulur.

En iyi uygulama: Her DC’ye DNS kurun ve DNS adreslerini çapraz yapılandırın (her DC öncelikli olarak diğerini, ikincil olarak kendini gösterir).

🛡️ İleri seviye / güvenlik notu — DNS proxy (koşullu yönlendirme): Büyük ortamlarda istemciler, DNS sorgularını doğrudan Domain Controller’lara değil, önce ayrı bir DNS proxy‘ye (örn. Linux üzerinde BIND veya ayrı bir Windows DNS) gönderir. Bu proxy yalnızca AD bölgesine ait sorguları DC’lere koşullu yönlendirir (BIND’de type forward; forward only; forwarders { 192.168.1.231; 192.168.1.232; };), kalan trafiği internete çıkarır. Faydası: DNS yönetimi merkezîleşir ve DC’ler DNS sorgu katmanında doğrudan tüm istemcilere açık durmaz; bu da derinlemesine savunmanın (defense-in-depth) bir parçasıdır.

Önemli sınır — gizleme değil, katman: Bu yöntem DC’lerin IP adresini tamamen gizlemez. Kimlik doğrulama (Kerberos/LDAP) ve dinamik DNS kaydı, tasarım gereği DC’ye doğrudan bağlanır; ayrıca dönen SRV/A kayıtları DC’nin IP’sini içerir. Dolayısıyla DNS proxy’yi bir “IP gizleme” aracı değil, DNS mimarisini sadeleştiren ve sorgu yüzeyini azaltan bir adım olarak görün. Gerçek izolasyon için firewall, VLAN segmentasyonu ve katmanlı yönetim (tiering) gerekir. Bu kurguda DC’ler kendi DNS ayarlarında yine birbirini/loopback’i gösterir; AD bölgesi DC’lerde AD-entegre kalır (proxy’ye kopyalanmaz).

3. AD CS — Active Directory Certificate Services (Sertifika Yetkilisi)

AD CS, kurum içi PKI (Public Key Infrastructure) altyapısını sağlar; HTTPS, akıllı kart, kod imzalama, LDAPS ve Wi-Fi kimlik doğrulaması gibi senaryolar için sertifika üretir.

Güvenlik açısından en önemli tavsiye: CA rolünü Domain Controller üzerine kurmayın. CA, kendi başına ayrı bir üye sunucuda çalışmalıdır. Bunun nedeni, CA kurulan bir sunucunun Domain’den (etki alanı) çıkarılamaması — yani demote edilememesi — ve güvenliğinin son derece kritik olmasıdır. Bu yüzden örneğimizde CA’yı 3. ayrı bir sunucuya kuruyoruz.

AD CS kurulurken karşınıza birden fazla rol hizmeti (role service) çıkar. Bizim senaryomuzda yalnızca Certification Authority‘yi kuruyoruz; diğerleri ihtiyaç büyüdükçe eklenir. Hepsinin ne işe yaradığı:

4. FSMO Rolleri

Active Directory’de çoğu işlem tüm DC’lerde eşitlenir (multi-master), ancak 5 özel rol yalnızca tek bir DC tarafından sahiplenilir (single-master). Bunlara FSMO (Flexible Single Master Operations) rolleri denir:

• Forest genelinde: Schema Master, Domain Naming Master
• Domain genelinde: RID Master, PDC Emulator, Infrastructure Master

Varsayılan olarak bu 5 rol, Forest içindeki ilk Domain Controller üzerine yerleşir. Küçük ve orta ölçekli ortamlarda hepsini tek DC’de tutmak sorun değildir; ancak DC arızalanırsa bu roller diğer DC’ye taşınmalıdır (seize/transfer).

Kurumsal Ortamda En Az Kaç Domain Controller Olmalı?

Kısa cevap: En az 2.

💡 Peki “Domain Controller” tam olarak ne demek, neden iki tane?

Domain Controller (DC), kullanıcı adı/parola doğrulayan, “bu kişi gerçekten o mu, bu bilgisayar ağa ait mi?” sorusuna cevap veren sunucudur. Active Directory veritabanının (kullanıcılar, gruplar, parolalar, GPO’lar) bir kopyasını tutar — yani kimlik denetiminin beynidir.

Tek DC, tek hata noktasıdır (single point of failure): o sunucu çökerse kimse oturum açamaz, paylaşımlara/yazıcılara erişemez, kısacası tüm şirket durur. İki DC ise veritabanını replication (eşitleme) ile sürekli birbirine kopyalar; biri düşse bile diğeri kimlik doğrulamaya kesintisiz devam eder, kullanıcı yükünü paylaşır ve canlı yedek görevi görür.

Basit benzetme: Tek kapılı bir binada o kapı bozulunca kimse giremez; iki kapı varsa biri arızalansa bile giriş-çıkış sürer. DC’ler de Domain’in giriş kapılarıdır — bu yüzden örneğimizde DUMBLEDORE-DC01 ve MCGONAGALL-DC02 olmak üzere iki tane var.

Tek bir Domain Controller, tüm kimlik doğrulama altyapısı için bir hata noktasıdır. O sunucu çöktüğünde:

• Kullanıcılar oturum açamaz,
• Grup politikaları uygulanmaz,
• DNS çözümlemesi (eğer aynı sunucudaysa) durur.

İkinci bir DC; veritabanını replication (eşitleme) yoluyla kopyalayarak yük dengeleme ve felaket kurtarma sağlar. Büyük ve çok lokasyonlu kurumlarda her AD Site (örneğin her şube) için ayrıca yerel bir DC bulundurmak en iyi uygulamadır.

Bu yazıdaki örnek senaryomuzda 2 Domain Controller + 1 CA olmak üzere toplam 3 sunucu kullanacağız ki bu, küçük-orta ölçekli bir kurum için ideal başlangıç yapısıdır.

Örnek Senaryo: 3 Sunucu ile Topoloji

Domain adı olarak hogwarts.local kullanacağız.

    
graph TD
    subgraph "hogwarts.local Domain"
        Dumbledore["DUMBLEDORE-DC01 - 192.168.1.231
AD DS + DNS
FSMO + Global Catalog"]
        Mcgonagall["MCGONAGALL-DC02 - 192.168.1.232
AD DS + DNS
Global Catalog"]
        Ministry["MINISTRY-CA01 - 192.168.1.233
AD CS
Enterprise Root CA"]
    end

    Dumbledore <-->|"Replication (Eşitleme)"| Mcgonagall
    Ministry -->|"Domain'e üye"| Dumbledore
    Istemciler["İstemciler / Üye Sunucular"] -->|"Kimlik Doğrulama + DNS"| Dumbledore
    Istemciler -->|"Yedek yol"| Mcgonagall
    Istemciler -->|"Sertifika talebi"| Ministry

Doğru Kurulum Sırası

Active Directory bileşenleri arasında bağımlılıklar vardır. Bu yüzden kurulum sırası önemlidir: önce dizin ve isim çözümleme katmanı, ardından buna bağımlı servisler gelir.

    
graph LR
    A["1. DUMBLEDORE-DC01
AD DS + DNS
Forest oluştur"] --> B["2. MCGONAGALL-DC02
İkincil DC olarak
terfi ettir"]
    B --> C["3. MINISTRY-CA01
Domain'e kat
AD CS kur"]

Neden bu sıra?

1. Önce AD DS + DNS (DUMBLEDORE-DC01): Domain’i ve isim çözümlemeyi oluşturmadan hiçbir şey çalışmaz. Her şeyin temeli budur.
2. Sonra ikinci DC (MCGONAGALL-DC02): Yedeklilik için. Bu sunucu, var olan bir Domain’e katılarak terfi ettirilir.
3. En son CA (MINISTRY-CA01): Sertifika Yetkilisi, Enterprise modunda kurulduğunda yapılandırmasını AD’ye yazar. Bu nedenle AD DS hazır olmadan CA kurulamaz.

Adım Adım Kurulum (Windows Server 2019)

Her sunucuda işletim sistemi kurulu, statik IP atanmış ve en güncel yamalar uygulanmış olmalıdır. Aşağıdaki her adımı iki yöntemle veriyoruz: hızlı ve tekrarlanabilir olan PowerShell ile, bir de grafik arayüzü tercih edenler için Server Manager (Sunucu Yöneticisi) sihirbazı ile. İkisi de aynı sonucu üretir; birini seçmeniz yeterlidir.

Adım 1 — DUMBLEDORE-DC01: İlk Domain Controller (AD DS + DNS)

192.168.1.231 adresli sunucuda başlıyoruz. İlk DC, kendi DNS’ini kullanacağı için DNS sunucusu olarak kendi loopback adresini (127.0.0.1) gösterebiliriz.

PowerShell ile:

# 1) Sunucu adını ayarla ve yeniden başlat
Rename-Computer -NewName "DUMBLEDORE-DC01" -Restart

# 2) Statik IP ve DNS yapılandırması (InterfaceIndex'i kendi ortamınıza göre düzenleyin)
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.1.231 `
  -PrefixLength 24 -DefaultGateway 192.168.1.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 127.0.0.1

# 3) AD DS rolünü kur
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

# 4) Yeni bir Forest (orman) oluştur — Domain ve DNS de bununla birlikte kurulur
Install-ADDSForest `
  -DomainName "hogwarts.local" `
  -DomainNetbiosName "HOGWARTS" `
  -ForestMode "WinThreshold" `
  -DomainMode "WinThreshold" `
  -InstallDns `
  -Force

Install-ADDSForest komutu sizden bir DSRM (Directory Services Restore Mode) parolası isteyecektir. Bu parolayı güvenli bir yerde saklayın; felaket kurtarma senaryolarında gereklidir. İşlem bittikten sonra sunucu otomatik olarak yeniden başlar.

Server Manager (arayüz) ile:

1. Statik IP’yi Denetim Masası → Ağ ve Paylaşım Merkezi → Bağdaştırıcı ayarları üzerinden verin; tercih edilen DNS olarak 127.0.0.1 girin.
2. Server Manager → Manage → Add Roles and Features ile sihirbazı açın; Before You Begin ekranını Next ile geçin.
3. Installation Type ekranında Role-based or feature-based installation seçin → Next.
4. Server Selection ekranında hedef sunucuyu seçin → Next.
5. Server Roles menüsünden Active Directory Domain Services‘i işaretleyin; açılan pencerede Add Features deyin → Next.
6. Select Features ekranında ek bir şey gerekmez → Next.
7. AD DS ekranı gelir. Bu yalnızca bilgilendirme ekranıdır; rolü tanıtır ve birkaç önemli hatırlatma yapar: bir Domain’de en az iki Domain Controller bulundurun, AD DS DNS’e ihtiyaç duyar ve rol kurulduktan sonra sunucunun ayrıca Domain Controller’a terfi ettirilmesi gerekir. Burada seçilecek bir şey yoktur; okuyup Next deyin.
8. Confirmation ekranında Install ile kurun. Buradaki Restart the destination server automatically if required kutusunu işaretlemeniz gerekmez — rol kurulumu yeniden başlatma istemez; asıl reboot, terfi (Promote) sırasında otomatik olur. (DNS bu aşamada değil, terfi sırasında gelir.)
9. Kurulum bitince Server Manager’daki sarı bayrak (notification) simgesine tıklayın → Promote this server to a domain controller.
10. Deployment Configuration ekranında Add a new forest seçeneğini işaretleyin ve Root domain name olarak hogwarts.local yazın.
11. Domain Controller Options ekranında Forest ve Domain functional level alanlarını varsayılan gelen Windows Server 2016‘da bırakın (2019’un ayrı bir işlevsel düzeyi yoktur; en yüksek seviye budur — düşürmeyin). DNS server kutusu işaretli olsun; Global Catalog ilk DC’de zaten işaretli ve pasif gelir (zorunludur). Tek yapmanız gereken aşağıda DSRM parolasını belirlemektir → Next.
12. DNS Options ekranı gelir; üstte Create DNS delegation kutusu vardır. Yeni bir forest kurduğunuz (ve .local gibi üst/parent bölgesi olmayan bir ad kullandığınız) için bu kutuyu işaretlemeyin. Ekrandaki “a delegation for this DNS server cannot be created…” sarı uyarısı normaldir, hata değildir; yok sayıp Next deyin.
13. Additional Options ekranında NetBIOS adı HOGWARTS olarak doğrulanır; Paths ekranında veritabanı, log ve SYSVOL yollarını varsayılan bırakın.
14. Prerequisites Check geçtikten sonra Install deyin; sunucu otomatik yeniden başlar.

Doğrulama: Yeniden başlatma sonrası Get-ADDomain ve Get-DnsServerResourceRecord -ZoneName "hogwarts.local" komutlarıyla Domain’in ve SRV kayıtlarının oluştuğunu kontrol edin.

Hızlı bir özet için Domain bilgilerini ve DNS servis durumunu tek seferde yazdırabilirsiniz:

# Domain bilgisi (ad, NetBIOS, mod, FSMO sahibi) + DNS servis durumu
Get-ADDomain | Select-Object DNSRoot, NetBIOSName, DomainMode, InfrastructureMaster
Get-Service DNS | Select-Object Name, Status, StartType

# Örnek Çıktı
DNSRoot        NetBIOSName        DomainMode InfrastructureMaster
-------        -----------        ---------- --------------------
hogwarts.local HOGWARTS    Windows2016Domain DUMBLEDORE-DC01.hogwarts.local

Adım 2 — MCGONAGALL-DC02: İkinci Domain Controller (Yedeklilik)

192.168.1.232 adresli sunucuyu, var olan hogwarts.local Domain’ine ikinci bir DC olarak ekliyoruz. Bu sunucunun DNS’i DUMBLEDORE-DC01’i (192.168.1.231) göstermelidir; aksi halde Domain’i bulamaz.

PowerShell ile:

# 1) Sunucu adını ayarla ve yeniden başlat
Rename-Computer -NewName "MCGONAGALL-DC02" -Restart

# 2) Statik IP — DNS olarak DUMBLEDORE-DC01'i göster (KRİTİK)
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.1.232 `
  -PrefixLength 24 -DefaultGateway 192.168.1.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 192.168.1.231

# 3) AD DS rolünü kur
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

# 4) Var olan Domain'e ek DC olarak terfi ettir
Install-ADDSDomainController `
  -DomainName "hogwarts.local" `
  -InstallDns `
  -Credential (Get-Credential "HOGWARTS\Administrator") `
  -SiteName "Default-First-Site-Name" `
  -Force

Terfi tamamlandıktan sonra DNS adreslerini çapraz yapılandırmak en iyi uygulamadır:

• DUMBLEDORE-DC01: Öncelikli DNS 192.168.1.232, ikincil 127.0.0.1
• MCGONAGALL-DC02: Öncelikli DNS 192.168.1.231, ikincil 127.0.0.1

Böylece bir DC çökse bile DNS çözümlemesi kesintisiz devam eder.

Server Manager (arayüz) ile:

1. Statik IP’yi verirken tercih edilen DNS olarak DUMBLEDORE-DC01’i (192.168.1.231) gösterin.
2. Add Roles and Features sihirbazını açın: Before You Begin (Next) → Installation Type’ta Role-based or feature-based installation (Next) → Server Selection (Next).
3. Server Roles menüsünden Active Directory Domain Services‘i işaretleyin; Add Features deyin → Select Features (Next) → Confirmation ekranında Install (buradaki Restart the destination server automatically if required kutusunu işaretlemeniz gerekmez; reboot, terfi sırasında otomatik gelir).
4. Kurulum bitince sarı bayrak simgesi → Promote this server to a domain controller.
5. Deployment Configuration ekranında bu kez Add a domain controller to an existing domain seçeneğini işaretleyin; Domain alanına doğrudan hogwarts.local yazın. (Yanındaki Select… butonu yalnızca forest’taki domain’leri listeden seçmek için bir kolaylıktır — kullanman şart değil; hatta DNS henüz oturmamışsa boş gelebilir, bu normaldir. Elle yazıp geçmen yeterli.) Ardından Change ile HOGWARTS\Administrator kimlik bilgilerini girin → Next.
6. Domain Controller Options’ta DNS server ve Global Catalog işaretli olsun; Site olarak Default-First-Site-Name seçin; DSRM parolasını belirleyin.
7. DNS Options ekranında Update DNS delegation kutusunu işaretlemeyin; .local adında delege edilecek üst bölge olmadığı için çıkan sarı uyarı normaldir, yok sayıp Next deyin.
8. Additional Options ekranında Replicate from olarak DUMBLEDORE-DC01 (veya “Any domain controller”) seçili olsun → Next; Paths ekranını varsayılan bırakın.
9. Sihirbazı tamamlayıp Install deyin. Terfiden sonra DNS adreslerini yukarıdaki gibi çapraz yapılandırmayı unutmayın.

Doğrulama: Get-ADDomainController -Filter * komutu her iki DC’yi de listelemeli, repadmin /replsummary ise replication’da hata olmadığını göstermelidir.

Hızlı bir özet için DC listesini ve replication durumunu yazdırabilirsiniz:

# Tüm DC'ler (IP, Site, GC mi?) + replication özeti
Get-ADDomainController -Filter * | Select-Object Name, IPv4Address, Site, IsGlobalCatalog
repadmin /replsummary

# Örnek Çıktı 
Name            IPv4Address   Site                    IsGlobalCatalog
----            -----------   ----                    ---------------
DUMBLEDORE-DC01 192.168.1.231 Default-First-Site-Name            True
MCGONAGALL-DC02 192.168.1.232 Default-First-Site-Name            True

Adım 3 — MINISTRY-CA01: Sertifika Yetkilisi (AD CS)

192.168.1.233 adresli sunucu bir Domain Controller değildir. Önce Domain’e üye sunucu olarak katılır, ardından üzerine AD CS kurulur. DNS’i bir DC’yi göstermelidir.

PowerShell ile:

# 1) Sunucu adını ayarla
Rename-Computer -NewName "MINISTRY-CA01" -Restart

# 2) Statik IP — DNS olarak her iki DC'yi göster (231 öncelikli, 232 yedek)
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.168.1.233 `
  -PrefixLength 24 -DefaultGateway 192.168.1.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 192.168.1.231, 192.168.1.232

# 3) Domain'e üye sunucu olarak kat
Add-Computer -DomainName "hogwarts.local" `
  -Credential (Get-Credential "HOGWARTS\Administrator") -Restart

# 4) AD CS rolünü kur
Install-WindowsFeature AD-Certificate -IncludeManagementTools

# 5) Enterprise Root CA olarak yapılandır
Install-AdcsCertificationAuthority `
  -CAType EnterpriseRootCA `
  -CACommonName "HOGWARTS-Root-CA" `
  -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" `
  -KeyLength 4096 `
  -HashAlgorithmName SHA256 `
  -ValidityPeriod Years `
  -ValidityPeriodUnits 10 `
  -Force

Enterprise CA seçildiğinde, CA otomatik olarak Active Directory’ye entegre olur ve sertifika şablonlarını Domain içindeki istemcilere yayınlayabilir. Daha büyük ve güvenlik odaklı ortamlarda iki katmanlı (two-tier) PKI tercih edilir: çevrimdışı (offline) bir kök CA + çevrimiçi bir yayınlayıcı (issuing) CA. Başlangıç için tek katmanlı Enterprise Root CA yeterlidir.

Server Manager (arayüz) ile:

1. Önce sunucuyu Domain’e katın: sysdm.cpl → Computer Name sekmesi → Change… butonuna basın. Açılan pencerede bilgisayar adını değiştirmeyin (zaten MINISTRY-CA01); alttaki Member of bölümünde Workgroup yerine Domain‘i seçip kutuya hogwarts.local yazın → OK. Sorulan kimlik bilgisine HOGWARTS\Administrator girip onaylayın ve yeniden başlatın. (Üye sunucunun DNS’i DC’leri göstermelidir: tercih edilen 192.168.1.231, alternatif 192.168.1.232 — böylece bir DC kapalıysa diğeri ad çözümlemeyi sürdürür. DNS boş/yanlışsa domain bulunamaz.)
2. Add Roles and Features sihirbazını açın: Before You Begin (Next) → Installation Type (Role-based, Next) → Server Selection (Next).
3. Server Roles menüsünden Active Directory Certificate Services‘i işaretleyin; Add Features deyin → Select Features (Next).
4. Role Services ekranında Certification Authority‘yi işaretleyin (diğer rol hizmetlerinin ne işe yaradığı için yukarıdaki AD CS rol hizmetleri tablosuna bakın) → Confirmation ekranında Install deyin. (Buradaki Restart the destination server automatically if required kutusunu işaretlemeniz gerekmez; AD CS rol kurulumu ve yapılandırması yeniden başlatma istemez.)

⚠️ Kurulum iki aşamalıdır — en sık karıştırılan nokta: Buradaki Install, yalnızca rol dosyalarını yükler; CA’yı yapılandırmaz. Bu yüzden Install bittiğinde Setup Type / CA Type / Private Key ekranları gelmez — bunlar bir sonraki adımdaki ayrı “Configure AD CS” sihirbazında çıkar. Kurulum bitince mutlaka sarı bayrağa tıklayıp yapılandırmayı başlatın.

5. Kurulum bitince sağ üstteki sarı bayrak simgesi → Configure Active Directory Certificate Services → Credentials ekranında yetkili (Enterprise Admins üyesi, ör. HOGWARTS\Administrator) kimlik bilgisini girin.
6. Role Services ekranında Certification Authority işaretli olsun.
7. Setup Type: Enterprise CA → CA Type: Root CA → Private Key ekranında Create a new private key seçin. (Not: Enterprise CA seçeneğinin aktif gelmesi için sunucu domain’e üye olmalı ve oturum açtığınız hesap Enterprise Admins üyesi olmalıdır; aksi halde yalnızca Standalone CA seçilebilir.)
8. Cryptography ekranında sağlayıcı RSA#Microsoft Software Key Storage Provider, anahtar uzunluğu 4096, hash algoritması SHA256.
9. CA Name ekranında CA adı olarak HOGWARTS-Root-CA; Validity Period ekranında geçerlilik süresi olarak 10 yıl girin.
10. Confirmation ekranını onaylayıp Configure deyin.

⚠️ Sık karşılaşılan sorun — “Enterprise CA” seçeneği gri/pasif geliyor: Bunun nedeni neredeyse her zaman, yapılandırmayı yerel hesapla (MINISTRY-CA01\Administrator) yapıyor olmanızdır. Enterprise CA, ayarlarını AD’ye yazdığı için oturum açan hesabın Enterprise Admins üyesi olmasını şart koşar; yerel hesapta bu yetki yoktur ve yalnızca Standalone CA seçilebilir.

Çözüm: Oturumu kapatıp HOGWARTS\Administrator ile (forest kök domain’inin built-in yöneticisi — varsayılan olarak Enterprise Admins üyesidir) yeniden giriş yapın, sonra Configure AD CS sihirbazını tekrar çalıştırın. Kontrol için:

whoami                                              # HOGWARTS\... olmalı, MINISTRY-CA01\... değil
whoami /groups | Select-String "Enterprise Admins"  # Bu gruba üye olmalısınız

Hesap doğru olduğu hâlde hâlâ griyse: sunucu domain’e yeni katıldıysa bir kez yeniden başlatın (üyelik token’ı otursun) ve bir DC’ye ulaşımı doğrulayın (nltest /dsgetdc:hogwarts.local).

Doğrulama: certutil -ping ve Certification Authority (certsrv.msc) konsolu ile CA’nın çalıştığını; certutil -config -ping ile Domain’den erişilebildiğini kontrol edin.

Hızlı bir özet için CA servis durumunu ve yapılandırma bilgisini yazdırabilirsiniz:

# CA servis durumu + CA bilgisi (ad, tip, sertifika)
Get-Service CertSvc | Select-Object Name, Status, StartType
certutil -cainfo

# Örnek Çıktı

Exit module count: 1
CA name: HOGWARTS-Root-CA
Sanitized CA short name (DS name): HOGWARTS-Root-CA
CA type: 0 -- Enterprise Root CA
    ENUM_ENTERPRISE_ROOTCA -- 0
CA cert count: 1
KRA cert count: 0
KRA cert used count: 0
CA cert[0]: 3 -- Valid
CA cert version[0]: 0 -- V0.0
CA cert verify status[0]: 0
CRL[0]: 3 -- Valid
CRL Publish Status[0]: 5
    CPF_BASE -- 1
    CPF_COMPLETE -- 4
Delta CRL Publish Status[0]: 6
    CPF_DELTA -- 2
    CPF_COMPLETE -- 4
DNS Name: MINISTRY-CA01.hogwarts.local
Advanced Server: 1
CA locale name: en-US
Subject Template OIDs: 1.2.840.113549.1.9.1
2.5.4.3
2.5.4.11
2.5.4.10
2.5.4.7
2.5.4.8
0.9.2342.19200300.100.1.25
2.5.4.6

CertUtil: -CAInfo command completed successfully.
Name     Status StartType
----     ------ ---------
CertSvc Running Automatic

CA sonrası: DC’lere sertifika dağıtımı (LDAPS için)

Enterprise CA ayağa kalktıktan sonra, Domain Controller’lar otomatik kayıt (autoenrollment) ile kendi Domain Controller / Kerberos Authentication sertifikalarını alır; LDAPS (LDAP over SSL, 636) bu sertifikayla aktifleşir. Genelde kendiliğinden gelir, ancak hemen tetiklemek için her iki DC’de (DUMBLEDORE-DC01 ve MCGONAGALL-DC02) şunu çalıştırın:

# DUMBLEDORE-DC01 ve MCGONAGALL-DC02 üzerinde ayrı ayrı çalıştırın
gpupdate /force
certutil -pulse      # autoenrollment'ı tetikler

# Sertifika geldi mi? "Domain Controller" / "Kerberos Authentication" görünmeli
Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, NotAfter, EnhancedKeyUsageList

Bağlantı testi (kendi bilgisayarınızdan): Aşağıdaki tek satırlık komutlarla her iki DC’ye hem şifresiz LDAP (389) hem de şifreli LDAPS (636) bağlanabildiğinizi doğrulayabilirsiniz.

# --- LDAP (şifresiz, port 389): port açık ve dinliyor mu? ---
$tcp = New-Object Net.Sockets.TcpClient("192.168.1.231", 389)
if ($tcp.Connected) { "DC1 LDAP (389) OK" }; $tcp.Close()

$tcp = New-Object Net.Sockets.TcpClient("192.168.1.232", 389)
if ($tcp.Connected) { "DC2 LDAP (389) OK" }; $tcp.Close()

# --- LDAPS (SSL, port 636): SSL el sıkışması başarılı mı? ---
$tcp = New-Object Net.Sockets.TcpClient("192.168.1.231", 636)
$ssl = New-Object Net.Security.SslStream($tcp.GetStream(), $false, { $true })
$ssl.AuthenticateAsClient("hogwarts.local"); "DC1 LDAPS OK"; $ssl.Close(); $tcp.Close()

$tcp = New-Object Net.Sockets.TcpClient("192.168.1.232", 636)
$ssl = New-Object Net.Security.SslStream($tcp.GetStream(), $false, { $true })
$ssl.AuthenticateAsClient("hogwarts.local"); "DC2 LDAPS OK"; $ssl.Close(); $tcp.Close()

Not: LDAPS testindeki { $true } geri çağırması, sertifikayı doğrulamadan kabul eder — yani bu test SSL el sıkışmasının ve 636 portunun çalıştığını gösterir, sertifika güvenini değil. Sertifika güvenini de sınamak için ldp.exe (Connection → Connect → SSL) kullanın veya gerçek bir bind yapın. Domain dışı bir istemciden bağlanıyorsanız, güven doğrulamasının geçmesi için istemcinin HOGWARTS-Root-CA kök sertifikasına güvenmesi gerekir.

LDAP Güvenliği: Channel Binding ve Signing

LDAP/LDAPS’i NTLM relay saldırılarına karşı sertleştirmek için iki ayar birlikte kullanılır: LDAP channel binding ve LDAP signing (Microsoft ADV190023 sertleştirme tavsiyesi). İkisi birden, çalınan bir kimlik doğrulamanın başka bir servise relay edilmesini engeller.

1) Channel binding — LdapEnforceChannelBinding: Kimlik doğrulamayı, üzerinde aktığı TLS kanalına bağlar; böylece bir LDAPS oturumu çalınıp başka yere relay edilemez. Her DC’de şu registry değeriyle ayarlanır:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding

# Her iki DC'de (DUMBLEDORE-DC01 ve MCGONAGALL-DC02) — tek satır
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters" -Name "LdapEnforceChannelBinding" -Value 1 -PropertyType DWORD -Force

Güvenli geçiş (rollout): Doğrudan 2‘ye atlamayın — 2, CBT desteklemeyen (eski Windows, Linux/Java LDAP istemcileri, bazı appliance’lar) istemcileri reddeder. Önce 1 yapın; bir süre Directory Service olay günlüğünde Event ID 3074/3075 (uyumsuz istemci) olup olmadığını izleyin; hiç çıkmıyorsa 2‘ye yükseltin. Bu ayar reboot gerektirmez ve yalnızca LDAPS/TLS bağlantıları için geçerlidir.

2) LDAP signing: Channel binding’i tamamlar (relay’in diğer yarısını kapatır). GPO ile zorlayın:

• Domain controller: LDAP server signing requirements → Require signing
• Network security: LDAP client signing requirements → Require signing

Bu iki ayarı da kademeli uygulayın: önce denetim/uyumluluk modunda istemcileri gözleyin, imzalamayı desteklemeyen istemci kalmadığından emin olduktan sonra Require signing’e geçin.

Kurulum Sonrası En İyi Uygulamalar

• Saat senkronizasyonu: PDC Emulator rolünü taşıyan DC’yi (DUMBLEDORE-DC01) güvenilir bir dış NTP kaynağına yönlendirin. Kerberos kimlik doğrulaması, saat farkına 5 dakikadan fazla tahammül etmez.
• Yedekleme: Düzenli System State yedekleri alın; en az bir DC’nin yedeği her zaman güncel olsun.
• DNS sağlığı: dcdiag /test:dns komutuyla periyodik kontrol yapın.
• FSMO farkındalığı: netdom query fsmo ile rollerin hangi DC’de olduğunu bilin; bir DC’yi kaldırmadan önce rolleri taşıyın.
• Yönetici hesabı disiplini: Günlük işler için Domain Admin hesabı kullanmayın; ayrı yetkili hesaplar ve katmanlı yönetim modeli (tiering) uygulayın.
• Site ve subnet tanımları: Çok lokasyonlu kurumlarda Active Directory Sites and Services üzerinde site/subnet tanımlayarak istemcilerin en yakın DC’ye yönlenmesini sağlayın.
• LDAP sertleştirme: NTLM relay’e karşı LDAP channel binding (LdapEnforceChannelBinding) ve LDAP signing‘i uygulayın; ayrıntılar ve güvenli geçiş sırası için yukarıdaki LDAP Güvenliği: Channel Binding ve Signing bölümüne bakın.

Zaman Senkronizasyonu (NTP): AD İçin Neden Kritik?

Active Directory’de doğru saat, isteğe bağlı bir lüks değil, çalışma şartıdır. Bunun nedeni kimlik doğrulamada kullanılan Kerberos protokolüdür: Kerberos, “replay” (tekrar) saldırılarını önlemek için her bilete bir zaman damgası koyar ve istemci ile sunucunun saatleri arasında varsayılan olarak en fazla 5 dakika fark olmasına izin verir. Bu sınır aşılırsa bilet geçersiz sayılır ve kimlik doğrulama reddedilir: kullanıcılar oturum açamaz, GPO uygulanmaz, DC’ler arası replication ve domain’e katılma işlemleri başarısız olur. Pratikte “saat kaymış bir makine = domain’den kopmuş makine” demektir.

Önemli: Bunun için ayrı bir “NTP sunucusu” rolü kurmanıza gerek yoktur. Windows’un yerleşik Windows Time servisi (w32time) bu işi yapar; yalnızca doğru hiyerarşiyi kurmanız yeterlidir.

AD’de zaman hiyerarşisi nasıl işler?

AD, saati tek bir otoriteden aşağıya doğru dağıtır:

1. PDC Emulator (FSMO rolü; bizde DUMBLEDORE-DC01) → tüm domain için otoriter saat kaynağıdır. Bu DC’yi güvenilir bir dış NTP kaynağına yönlendirin (ör. pool.ntp.org veya kurumsal/donanımsal bir saat kaynağı).
2. Diğer DC’ler (MCGONAGALL-DC02) → saatlerini PDC Emulator’dan alır.
3. Üye sunucular ve istemciler (MINISTRY-CA01 dâhil) → saatlerini domain hiyerarşisi üzerinden otomatik alır; ayrıca yapılandırma gerektirmez.

Yani sadece PDC Emulator’ı dışarıya doğru ayarlamanız, geri kalan tüm makinelerin doğru saati otomatik almasını sağlar.

PDC Emulator’ı dış NTP’ye yönlendirme (DUMBLEDORE-DC01)

# Dış NTP kaynaklarını ayarla ve servisi yeniden başlat
w32tm /config /manualpeerlist:"0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org" `
  /syncfromflags:manual /reliable:yes /update
Restart-Service w32time

# Hemen senkronize et ve durumu kontrol et
w32tm /resync
w32tm /query /status        # Source satırı dış NTP'yi göstermeli

Doğrulama: Üye makinelerde w32tm /query /source komutu, kaynağın PDC Emulator (DUMBLEDORE-DC01) ya da bir DC olduğunu göstermelidir. Tüm makinelerde saat farkı birkaç saniyeyi geçmemelidir.

Sanal ortam uyarısı: DC’ler sanal makineyse, hipervizörün (VMware Tools / Hy-V Integration Services) host ile saat senkronizasyonu özelliğini DC’ler için kapatın. Aksi halde host saati ile AD hiyerarşisi çakışır ve saat sürekli ileri-geri zıplayabilir.

AD İçi Trafik Akışı, Loglar ve Önemli Event ID’leri

Sunucular kendi aralarında nasıl konuşur?

Yaygın bir yanılgının aksine, DC’ler ve üye sunucular birbirine “LDAP/LDAPS ile” bağlanmaz; AD farklı protokoller kullanır ve bu trafik zaten şifrelidir:

Çıkarım: DC’ler arası replication RPC’dir, LDAP değildir ve Kerberos ile şifrelidir. Üye sunucuların (MINISTRY-CA01 dâhil) yaptığı LDAP sorguları port 389’da gitse bile düz metin değildir — Kerberos ile imzalanıp şifrelenir. Bu yüzden iç AD trafiği için LDAPS’e zorlamaya gerek yoktur; LDAPS asıl Kerberos kullanmayan dış/üçüncü taraf istemciler içindir. İç güvenlik için doğru kaldıraç, yukarıda anlatılan LDAP signing + channel binding’tir.

İlgili portları firewall kurallarında açık tutmayı unutmayın: DC’ler arası RPC (135 + dinamik aralık), LDAP (389/636), GC (3268/3269), Kerberos (88), DNS (53), SMB (445), NTP (123).

Logları nereden izlersiniz?

Olay günlüklerine Event Viewer (eventvwr.msc) veya PowerShell ile bakılır. AD için kritik günlükler:

• Applications and Services Logs → Directory Service → AD DS, replication, LDAP signing/channel binding olayları
• Applications and Services Logs → DNS Server → DNS bölge/SRV sorunları
• Applications and Services Logs → DFS Replication → SYSVOL eşitleme
• Windows Logs → Security → oturum açma, Kerberos, hesap/grup değişiklikleri (denetim)
• Windows Logs → System → Netlogon, W32Time (saat), servis hataları

PowerShell ile hızlı okuma:

# Directory Service günlüğünden son 20 hata/uyarı
Get-WinEvent -LogName "Directory Service" -MaxEvents 20 |
  Where-Object { $_.LevelDisplayName -in "Error","Warning" } |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

# Replication sağlığı + tanılama (komut satırı araçları)
repadmin /replsummary
repadmin /showrepl
dcdiag /v

Bilinmesi gereken önemli Event ID’leri

LDAP güvenliği (Directory Service günlüğü)

Replication (Directory Service günlüğü)

DNS ve SYSVOL

Kimlik doğrulama ve hesap (Security günlüğü)

İpucu: Bir kullanıcının neden kilitlendiğini (4740) bulmak için PDC Emulator’ın Security günlüğüne bakın; kilitlenme olayı oradan kaynak makineyle birlikte gelir.

Güvenlik: Administrator Hesabının Yönetimi

İlk Domain Controller’ı kurarken built-in Administrator hesabını kullanmak kaçınılmazdır; makine henüz Domain’e dahil değilken tek yetkili hesap budur. Install-ADDSForest çalıştığında bu hesap otomatik olarak Domain Administrator‘a (HOGWARTS\Administrator) dönüşür. Buraya kadar her şey normaldir.

Asıl mesele kurulum sonrasıdır: built-in Administrator (SID’i ...-500 ile biten) hesabını günlük yönetim için kullanmak kötü bir pratiktir, çünkü:

• Kilitlenmez (lockout uygulanmaz) → brute-force saldırıları için ideal hedeftir.
• SID’i bilinir (-500); saldırganların ilk denediği hesaptır.
• Herkes aynı hesabı kullanırsa denetlenebilirlik (auditing) kaybolur; log’larda kimin ne yaptığı belli olmaz.

Devre dışı bırakmadan ÖNCE yapılması gerekenler

Kritik: Administrator’ı devre dışı bırakmadan önce, yerine geçecek ayrı yönetici hesaplarını oluşturup test edin. Aksi halde kendinizi Domain’den kilitleyebilirsiniz.

1. Kendinize ayrı bir yönetici hesabı açın ve Domain Admins grubuna ekleyin:

New-ADUser -Name "Murat Admin" -SamAccountName "murat.admin" `
  -UserPrincipalName "murat.admin@hogwarts.local" `
  -AccountPassword (Read-Host -AsSecureString "Parola") `
  -Enabled $true
Add-ADGroupMember -Identity "Domain Admins" -Members "murat.admin"

2. Yeni hesapla oturum açıp DC yönetimi, GPO gibi işlerin çalıştığını doğrulayın.
3. DSRM parolasını güvenli sakladığınızdan emin olun; Administrator devre dışı olsa bile felaket kurtarmada DSRM gerekir.
4. Ancak bundan sonra built-in Administrator’ı devre dışı bırakın:

Disable-ADAccount -Identity "Administrator"

Devre dışı bırakmak mı, “break-glass” mı?

Tamamen devre dışı bırakmak yerine, birçok kurum Administrator’ı “kırılması gereken cam” (break-glass) hesabı olarak saklar:

• Çok uzun ve karmaşık bir parola verilir, fiziksel kasada veya parola kasasında (vault) tutulur.
• Normalde hiç kullanılmaz, sadece acil durumda (örn. tüm yetkili hesaplara erişim kaybı) açılır.
• Üzerine denetim/alarm kurulur; her oturum açma denemesi SIEM’e bildirilir.

İki yaklaşım da kabul edilebilir; önemli olan hesabın günlük işlerde asla kullanılmamasıdır.

Bir adım ileri: katmanlı yönetim (tiering)

• Domain Admin hesaplarını yalnızca DC yönetimi için kullanın; internet, e-posta veya iş istasyonu oturumları için asla kullanmayın.
• Günlük işleriniz için standart (yetkisiz) bir hesap kullanın; yönetim gerektiğinde runas ile ayrı admin hesabına yükselin.
• Bu, Tier 0 / Tier 1 / Tier 2 modelinin temelidir ve bir saldırganın iş istasyonundan Domain Controller’a sıçramasını (lateral movement) ciddi biçimde zorlaştırır.

Sonuç

İyi bir Active Directory yapısının özü; yedeklilik, rol ayrımı ve doğru kurulum sırasıdır. Bu yazıda:

• Kurumsal ortamda en az 2 Domain Controller bulunması gerektiğini,
• DNS’in AD DS ile birlikte, CA’nın ise ayrı bir üye sunucuda kurulması gerektiğini,
• Doğru sıranın önce AD DS + DNS, sonra ikincil DC, en son CA olduğunu

3 sunuculu (192.168.1.231/232/233) somut bir senaryo üzerinden Windows Server 2019 ile adım adım ele aldık. Bu temel yapı, kurumunuz büyüdükçe ek Domain Controller’lar, DHCP failover ve iki katmanlı PKI ile genişletilebilir.

Bir sonraki adım olarak Group Policy (GPO) ile merkezi yapılandırma yönetimini öğrenmek, bu altyapıdan tam verim almanızı sağlayacaktır.