İ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: Büyük ortamlarda istemci DNS sorguları, doğrudan DC’lere değil önce ayrı bir DNS proxy katmanına yönlendirilebilir. Bu bir derinlemesine savunma (defense-in-depth) tercihidir; ayrıntılarını Active Directory Güvenliği ve Sertleştirme (Hardening) yazısında ele alıyoruz.

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. DNS kayıtları
Sunucular için
statik A + PTR"]
    C --> D["4. 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. Ardından DNS’te statik A kayıtları: Sunucular DNS’te adlarıyla güvenilir biçimde çözümlenmeden üzerine kurulan servisler çalışmaz. Bu adım en sık atlanan adımdır ve faturası doğrudan CA’ya çıkar — çünkü sertifika talepleri CA’ya IP ile değil, adıyla gider.
4. 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 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.

⚠️ PowerShell bloklarını çalıştırmadan önce mutlaka okuyun

Kurulum sırasında sunucular yeniden başlar ve bu, scripti keser. Rename-Computer -Restart ve Add-Computer -Restart komutları makineyi o anda yeniden başlatır; konsola yapıştırdığınız geri kalan satırlar hiç çalışmaz.

Bu yüzden aşağıdaki PowerShell kodlarını BÖLÜM 1/2, BÖLÜM 2/2 şeklinde ayırdık. Her bölümü ayrı ayrı, bir öncekinin yeniden başlatması tamamlandıktan sonra çalıştırın. Tümünü tek seferde yapıştırırsanız — özellikle 2. ve 3. sunucuda — IP ve DNS ayarlanmadan terfi/katılma adımına geçilir ve şu hatayı alırsınız:

The specified domain "hogwarts.local" either does not exist or could not be contacted.

Ayrıca tüm blokları yönetici olarak (Run as Administrator) açılmış bir PowerShell penceresinde çalıştırın.

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:

BÖLÜM 1/2 — Ağ ve sunucu adı (bu bölümün sonunda sunucu yeniden başlar):

# 0) Ağ adaptörünün GERÇEK adını öğrenin — "Ethernet0", "Ethernet 2" olabilir
Get-NetAdapter | Select-Object Name, InterfaceDescription, Status
$NIC = "Ethernet"   # ← yukarıdaki çıktıdan kendi adaptör adınızı yazın

# 1) Varsa DHCP'yi kapat, eski IP ve varsayılan ağ geçidini temizle
#    (bu yapılmazsa New-NetIPAddress "Instance MSFT_NetIPAddress already exists" hatası verir)
Set-NetIPInterface -InterfaceAlias $NIC -Dhcp Disabled
Get-NetIPAddress -InterfaceAlias $NIC -AddressFamily IPv4 -ErrorAction SilentlyContinue |
  Remove-NetIPAddress -Confirm:$false
Get-NetRoute -InterfaceAlias $NIC -DestinationPrefix "0.0.0.0/0" -ErrorAction SilentlyContinue |
  Remove-NetRoute -Confirm:$false

# 2) Statik IP ve DNS yapılandırması (ilk DC kendi DNS'ini kullanır)
New-NetIPAddress -InterfaceAlias $NIC -IPAddress 192.168.1.231 `
  -PrefixLength 24 -DefaultGateway 192.168.1.1
Set-DnsClientServerAddress -InterfaceAlias $NIC -ServerAddresses 127.0.0.1

# 3) Sunucu adını ayarla  ← DİKKAT: BU KOMUT MAKİNEYİ ANINDA YENİDEN BAŞLATIR
Rename-Computer -NewName "DUMBLEDORE-DC01" -Restart

BÖLÜM 2/2 — Rol kurulumu ve Forest oluşturma (yeniden başlatma bittikten sonra çalıştırın):

# Ön kontrol: ad ve IP doğru oturdu mu?
hostname                                    # DUMBLEDORE-DC01 dönmeli
Get-NetIPConfiguration -InterfaceAlias $NIC  # IPv4 192.168.1.231, DNS 127.0.0.1 olmalı

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

# 5) 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.

Devam etmeden önce: DC02’ye geçmeden bu sunucunun yeniden başlatmayı tamamlamasını ve Get-ADDomain komutunun hatasız çalışmasını bekleyin. AD DS servisleri tam ayağa kalkmadan ikinci DC’yi terfi ettirmeye çalışırsanız bağlantı hatası alırsınız.

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:

BÖLÜM 1/2 — Ağ ve sunucu adı (bu bölümün sonunda sunucu yeniden başlar):

# 0) Ağ adaptörünün GERÇEK adını öğrenin
Get-NetAdapter | Select-Object Name, InterfaceDescription, Status
$NIC = "Ethernet"   # ← yukarıdaki çıktıdan kendi adaptör adınızı yazın

# 1) Varsa DHCP'yi kapat, eski IP ve varsayılan ağ geçidini temizle
Set-NetIPInterface -InterfaceAlias $NIC -Dhcp Disabled
Get-NetIPAddress -InterfaceAlias $NIC -AddressFamily IPv4 -ErrorAction SilentlyContinue |
  Remove-NetIPAddress -Confirm:$false
Get-NetRoute -InterfaceAlias $NIC -DestinationPrefix "0.0.0.0/0" -ErrorAction SilentlyContinue |
  Remove-NetRoute -Confirm:$false

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

# 3) Sunucu adını ayarla  ← DİKKAT: BU KOMUT MAKİNEYİ ANINDA YENİDEN BAŞLATIR
Rename-Computer -NewName "MCGONAGALL-DC02" -Restart

BÖLÜM 2/2 — Rol kurulumu ve terfi (yeniden başlatma bittikten sonra çalıştırın):

# ÖN KONTROL — üçü de başarılı olmadan devam etmeyin
Resolve-DnsName -Name "hogwarts.local" -Type SRV     # SRV kayıtları dönmeli (DNS doğru mu?)
nltest /dsgetdc:hogwarts.local                       # DUMBLEDORE-DC01 bulunmalı (DC erişilebilir mi?)
w32tm /stripchart /computer:192.168.1.231 /samples:1 /dataonly   # saat farkı 5 dk'yı geçmemeli

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

# 5) Var olan Domain'e ek DC olarak terfi ettir
#    Not: UPN biçimi (Administrator@hogwarts.local) NetBIOS biçimine göre daha güvenilirdir;
#    NetBIOS adı henüz çözülemiyorsa "HOGWARTS\Administrator" başarısız olabilir.
Install-ADDSDomainController `
  -DomainName "hogwarts.local" `
  -InstallDns `
  -Credential (Get-Credential "Administrator@hogwarts.local") `
  -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 — DNS’e Sunucuların Statik A Kayıtlarını Girin

Bu, kurulum rehberlerinde en sık atlanan ama faturası CA aşamasında kesilen adımdır. Teoride domain’e katılan her makine kendi A kaydını DNS’e dinamik olarak yazar (AD entegre bölgelerde varsayılan güncelleme modu “Secure only”). Pratikte ise bu kayıt çoğu zaman ya hiç oluşmaz ya da yanlış oluşur:

• Sunucuda birden fazla ağ adaptörü vardır ve DNS’e yanlış adaptörün IP’si yazılmıştır,
• Adaptör özelliklerinde “Register this connection’s addresses in DNS” kapalıdır,
• Bölgede dinamik güncelleme güvenlik gerekçesiyle “None” olarak sertleştirilmiştir,
• Sunucu adı Rename-Computer ile değiştirilmiştir; DNS’te eski isim kalmış, yenisi yazılmamıştır,
• Scavenging (temizleme) eski kaydı silmiştir.

Bunun CA ile ne ilgisi var? Sertifika altyapısı baştan sona isimle çalışır, IP ile değil:

• Domain Controller’lar ve istemciler sertifika talebini CA’ya RPC/DCOM üzerinden MINISTRY-CA01.hogwarts.local adıyla gönderir.
• CA’nın ürettiği her sertifikanın içine gömülen CDP (CRL dağıtım noktası) ve AIA (yetkili bilgi erişimi) adresleri de bu ada işaret eder — yani ad çözümlenmezse sertifika üretilse bile doğrulanamaz.

A kaydı yoksa certutil -pulse sessizce hiçbir şey yapmaz, kayıt “The RPC server is unavailable (0x800706ba)” ile düşer, LDAPS için beklediğiniz DC sertifikası hiç gelmez. Bu yüzden CA’ya geçmeden önce her üç sunucunun A kaydını DNS’e elle, statik olarak girin.

PowerShell ile (herhangi bir DC üzerinde, HOGWARTS\Administrator ile çalıştırın):

# 1) Mevcut durumu görün — hangi kayıt var, hangisi eksik, IP'ler doğru mu?
Get-DnsServerResourceRecord -ZoneName "hogwarts.local" -RRType A |
  Select-Object HostName, @{n="IP";e={$_.RecordData.IPv4Address}}, Timestamp

# 2) Ters (reverse) arama bölgesi yoksa oluşturun — PTR kayıtları için gerekli
#    Zaten varsa "already exists" hatası verir; yok sayabilirsiniz.
Add-DnsServerPrimaryZone -NetworkID "192.168.1.0/24" -ReplicationScope "Domain" `
  -DynamicUpdate "Secure"

# 3) Yanlış veya eski bir kayıt varsa ÖNCE silin (yoksa bu satırları atlayın)
# Remove-DnsServerResourceRecord -ZoneName "hogwarts.local" -RRType A `
#   -Name "MINISTRY-CA01" -Force

# 4) Üç sunucuyu da statik A + PTR kaydı olarak ekleyin
Add-DnsServerResourceRecordA -ZoneName "hogwarts.local" `
  -Name "DUMBLEDORE-DC01" -IPv4Address "192.168.1.231" -CreatePtr
Add-DnsServerResourceRecordA -ZoneName "hogwarts.local" `
  -Name "MCGONAGALL-DC02" -IPv4Address "192.168.1.232" -CreatePtr
Add-DnsServerResourceRecordA -ZoneName "hogwarts.local" `
  -Name "MINISTRY-CA01"   -IPv4Address "192.168.1.233" -CreatePtr

-Name alanına FQDN yazmayın. MINISTRY-CA01 yeterlidir; bölge adı (hogwarts.local) otomatik eklenir. MINISTRY-CA01.hogwarts.local yazarsanız MINISTRY-CA01.hogwarts.local.hogwarts.local gibi kullanılamaz bir kayıt oluşur.

“MINISTRY-CA01 henüz domain’e katılmadı, kaydını şimdi girmek doğru mu?” Evet. DNS kaydı ile domain üyeliği birbirinden bağımsızdır; kaydı önceden (pre-create) girmek tamamen normaldir ve tavsiye edilir. Sunucu Adım 4’te domain’e katıldığında adı ilk andan itibaren çözümlenir — sonradan “acaba kendi kaydını yazdı mı?” diye uğraşmazsınız. Domain’e katılma işlemi bu kayda ihtiyaç duymaz; o iş hogwarts.local bölgesindeki SRV kayıtlarıyla yürür.

DNS Manager (arayüz) ile:

1. Bir DC’de dnsmgmt.msc açın (veya Server Manager → Tools → DNS).
2. Sol ağaçta Forward Lookup Zones → hogwarts.local’e gelin; boş alana sağ tıklayıp New Host (A or AAAA)… deyin.
3. Name alanına yalnızca sunucu adını (MINISTRY-CA01), IP address alanına 192.168.1.233 girin.
4. Create associated pointer (PTR) record kutusunu işaretleyin → Add Host. (Ters bölge yoksa PTR oluşturulamaz; önce Reverse Lookup Zones üzerine sağ tıklayıp New Zone → Primary + AD entegre ile 192.168.1.x bölgesini yaratın.)
5. Aynısını DUMBLEDORE-DC01 (192.168.1.231) ve MCGONAGALL-DC02 (192.168.1.232) için tekrarlayın. Kayıt zaten varsa Data sütunundaki IP’nin doğru olduğunu kontrol edin; yanlışsa silip yeniden ekleyin.

Doğrulama — üçü de doğru IP’yi dönmelidir:

Resolve-DnsName DUMBLEDORE-DC01.hogwarts.local   # 192.168.1.231
Resolve-DnsName MCGONAGALL-DC02.hogwarts.local   # 192.168.1.232
Resolve-DnsName MINISTRY-CA01.hogwarts.local     # 192.168.1.233

# Ters çözümleme (PTR) — ad dönmeli
Resolve-DnsName 192.168.1.233                    # MINISTRY-CA01.hogwarts.local

Statik kayıt ne demek, neden tercih ediyoruz? Elle oluşturulan kayıtta zaman damgası (timestamp) bulunmaz; bu yüzden scavenging bu kaydı asla silmez ve sunucu bir süre kapalı kalsa bile adı çözümlenmeye devam eder. Bedeli şudur: “Secure only” bir bölgede kaydın sahibi, onu oluşturan yönetici hesabıdır — makinenin kendisi artık o kaydı dinamik olarak güncelleyemez. IP’leri statik verdiğimiz için bu bizim lehimizedir; ancak bir sunucunun IP’sini değiştirirseniz A ve PTR kaydını elle güncellemeyi unutmayın.

A kaydı, DC’lerin SRV kayıtlarının yerine geçmez. Domain’i bulmayı sağlayan _ldap._tcp... gibi SRV kayıtlarını Netlogon servisi yazar. Eksik görünüyorlarsa makinenin kendi kayıtlarını yeniden yazdırın:

nltest /dsregdns        # DC'lerde: SRV + A kayıtlarını yeniden kaydeder
ipconfig /registerdns   # üye sunucularda: A kaydını yeniden kaydeder

Adım 4 — 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:

Bu sunucuda iki ayrı yeniden başlatma vardır (ad değişikliği ve domain’e katılma), bu yüzden kod üç bölüme ayrılmıştır.

BÖLÜM 1/3 — Ağ ve sunucu adı (bu bölümün sonunda sunucu yeniden başlar):

# 0) Ağ adaptörünün GERÇEK adını öğrenin
Get-NetAdapter | Select-Object Name, InterfaceDescription, Status
$NIC = "Ethernet"   # ← yukarıdaki çıktıdan kendi adaptör adınızı yazın

# 1) Varsa DHCP'yi kapat, eski IP ve varsayılan ağ geçidini temizle
Set-NetIPInterface -InterfaceAlias $NIC -Dhcp Disabled
Get-NetIPAddress -InterfaceAlias $NIC -AddressFamily IPv4 -ErrorAction SilentlyContinue |
  Remove-NetIPAddress -Confirm:$false
Get-NetRoute -InterfaceAlias $NIC -DestinationPrefix "0.0.0.0/0" -ErrorAction SilentlyContinue |
  Remove-NetRoute -Confirm:$false

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

# 3) Sunucu adını ayarla  ← DİKKAT: BU KOMUT MAKİNEYİ ANINDA YENİDEN BAŞLATIR
Rename-Computer -NewName "MINISTRY-CA01" -Restart

BÖLÜM 2/3 — Domain’e katılma (yeniden başlatma bittikten sonra çalıştırın; bu bölüm de yeniden başlatır):

# ÖN KONTROL — ikisi de başarılı olmadan devam etmeyin
Resolve-DnsName -Name "hogwarts.local" -Type SRV     # SRV kayıtları dönmeli
nltest /dsgetdc:hogwarts.local                       # bir DC bulunmalı

# 4) Domain'e üye sunucu olarak kat  ← DİKKAT: BU KOMUT DA MAKİNEYİ YENİDEN BAŞLATIR
Add-Computer -DomainName "hogwarts.local" `
  -Credential (Get-Credential "Administrator@hogwarts.local") -Restart

BÖLÜM 3/3 — AD CS kurulumu ve yapılandırması. Bu bölümü çalıştırmadan önce sunucuda mutlaka HOGWARTS\Administrator (domain hesabı) ile oturum açın — yerel MINISTRY-CA01\Administrator hesabında Enterprise Admins yetkisi olmadığı için Enterprise Root CA yapılandırması başarısız olur:

# ÖN KONTROL — doğru hesapla mı çalışıyoruz?
whoami                                              # HOGWARTS\... dönmeli, MINISTRY-CA01\... DEĞİL
whoami /groups | Select-String "Enterprise Admins"  # bu satır boş dönmemeli

# 5) AD CS ROL HİZMETİNİ kur
#    DİKKAT: "AD-Certificate" yalnızca rol kapsayıcısıdır; Install-WindowsFeature alt rol
#    hizmetlerini kendiliğinden kurmaz. Kurulması gereken rol hizmeti ADCS-Cert-Authority'dir;
#    bu olmadan Install-AdcsCertificationAuthority çalışmaz.
Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools

# 6) 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ı (kısaltıldı — kritik satırlar)

CA name: HOGWARTS-Root-CA
CA type: 0 -- Enterprise Root CA
    ENUM_ENTERPRISE_ROOTCA -- 0
CA cert[0]: 3 -- Valid
CRL[0]: 3 -- Valid
DNS Name: MINISTRY-CA01.hogwarts.local
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

Hiçbir sertifika gelmediyse önce DNS’e bakın. certutil -pulse hata bile vermeden sessizce dönüyorsa neredeyse her zaman sebep, DC’nin CA’yı adıyla bulamamasıdır. DC üzerinde Resolve-DnsName MINISTRY-CA01.hogwarts.local ve certutil -config "MINISTRY-CA01.hogwarts.local\HOGWARTS-Root-CA" -ping komutlarını çalıştırın; ad çözümlenmiyorsa Adım 3’teki A kaydını girin.

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.

Sık Karşılaşılan Kurulum Hataları ve Çözümleri

Kurulum sırasında en çok takılınan noktalar ve nedenleri. Hataların büyük çoğunluğu üç şeyden birine dayanır: yanlış DNS, eksik çalıştırılmış script ve yanlış hesapla oturum açma.

1. “The specified domain either does not exist or could not be contacted”

En sık görülen hata. Install-ADDSDomainController (DC02) veya Add-Computer (CA01) çalıştırıldığında gelir.

Nedenleri, en olasıdan başlayarak:

2. “Instance MSFT_NetIPAddress already exists”

New-NetIPAddress çalıştırıldığında gelir. Adaptörde zaten bir IPv4 adresi (genelde DHCP’den gelmiş) vardır.

# Önce DHCP'yi kapatıp mevcut adresi ve varsayılan rotayı temizleyin
Set-NetIPInterface -InterfaceAlias $NIC -Dhcp Disabled
Get-NetIPAddress -InterfaceAlias $NIC -AddressFamily IPv4 -ErrorAction SilentlyContinue |
  Remove-NetIPAddress -Confirm:$false
Get-NetRoute -InterfaceAlias $NIC -DestinationPrefix "0.0.0.0/0" -ErrorAction SilentlyContinue |
  Remove-NetRoute -Confirm:$false

Aynı komut -DefaultGateway yüzünden de patlayabilir (0.0.0.0/0 rotası zaten varsa) — yukarıdaki Remove-NetRoute satırı bunu da çözer.

3. “No matching interface found” / adaptör bulunamıyor

Scriptlerde "Ethernet" yazıyor ama sizin adaptörünüzün adı Ethernet0, Ethernet 2 veya Ethernet Instance 0 olabilir (özellikle VMware/Hyper-V’de).

Get-NetAdapter | Select-Object Name, InterfaceDescription, Status
$NIC = "Ethernet0"   # ← çıktıdaki gerçek adı yazın

4. Install-AdcsCertificationAuthority hata veriyor / rol bulunamıyor

İki ayrı sebebi vardır:

• Rol hizmeti kurulmamış. Install-WindowsFeature AD-Certificate yalnızca rol kapsayıcısını kurar; Install-WindowsFeature alt rol hizmetlerini varsayılan olarak kurmaz. Kurulması gereken ADCS-Cert-Authority‘dir:

  Get-WindowsFeature ADCS-Cert-Authority        # Install State "Installed" olmalı
  Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
  

• Script yarıda kesilmiş. Add-Computer ... -Restart makineyi yeniden başlattığı için, aynı blokta yer alan AD CS satırları hiç çalışmamıştır. Yeniden başlatmadan sonra BÖLÜM 3/3’ü elle çalıştırın.

5. “Enterprise CA” seçilemiyor / -CAType EnterpriseRootCA reddediliyor

Yerel hesapla (MINISTRY-CA01\Administrator) oturum açmışsınızdır. Enterprise CA yapılandırmasını AD’ye yazdığı için Enterprise Admins üyeliği şarttır.

whoami                                              # HOGWARTS\... olmalı
whoami /groups | Select-String "Enterprise Admins"  # boş dönmemeli

Oturumu kapatıp HOGWARTS\Administrator ile girin. Sunucu domain’e yeni katıldıysa üyelik token’ının oturması için bir kez yeniden başlatın.

6. Sertifika dağıtılamıyor — “The RPC server is unavailable (0x800706ba)”

CA kurulmuş, certutil -cainfo sorunsuz çalışıyor, ama DC’ler ve istemciler sertifika alamıyor; certutil -pulse sessizce dönüyor veya yukarıdaki RPC hatasını veriyor. Application günlüğünde CertificateServicesClient-AutoEnrollment kaynaklı Event ID 13 / 6 olayları görünür.

Sebep neredeyse her zaman DNS’tir: İstemci CA’ya IP ile değil, MINISTRY-CA01.hogwarts.local adıyla bağlanır. Kaydın var olduğunu CA’nın kendisinden değil, talebi yapan makineden (bir DC’den) test edin:

# DUMBLEDORE-DC01 üzerinde çalıştırın
Resolve-DnsName MINISTRY-CA01.hogwarts.local          # 192.168.1.233 dönmeli
certutil -config "MINISTRY-CA01.hogwarts.local\HOGWARTS-Root-CA" -ping

Kaydı düzelttikten sonra istemci tarafındaki DNS önbelleğini temizleyip kaydı yeniden tetikleyin:

Clear-DnsClientCache
gpupdate /force
certutil -pulse

7. Kurulum yarıda kaldı — baştan başlamak istiyorum

Terfi başarısız olduysa sunucu genelde temiz durumdadır; ön koşulları düzeltip Install-ADDSDomainController‘ı tekrar çalıştırmanız yeterlidir. Terfi tamamlanmış ama yanlışsa, önce DC’yi indirin:

# DC'yi üye sunucuya indir (demote) — sonra yeniden terfi ettirebilirsiniz
Uninstall-ADDSDomainController -DemoteOperationMasterRole -Force

⚠️ CA kurulmuş bir sunucuda bunu yapamazsınız. Yazının başında belirttiğimiz gibi, AD CS kurulu bir makine domain’den çıkarılamaz — bu yüzden CA’yı ayrı bir sunucuya kuruyoruz.

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. Sunucu ve altyapı makinelerinin (DC, CA, dosya sunucusu, yazıcı sunucusu vb.) A kayıtlarını statik tutun; dinamik kayda bırakmayı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. Built-in Administrator’ın yönetimi (break-glass) ve tiering ayrıntıları için AD güvenliği yazısına bakı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 AD güvenliği yazısındaki LDAP güvenliği 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ç, AD güvenliği yazısında 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 olayları (2886, 2887, 2889, 3074/3075), ilgili sertleştirme adımlarıyla birlikte AD güvenliği yazısında ele alınıyor.

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.

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,
• Sunucuların DNS’te statik A (ve PTR) kayıtlarıyla tanımlanması gerektiğini — aksi halde CA sertifika dağıtamaz,
• Doğru sıranın önce AD DS + DNS, sonra ikincil DC, ardından DNS kayıtları, 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.

Serinin devamı olarak: Active Directory Kullanımı: OU, Kullanıcı ve Grup Yönetimi yazısında bu boş yapının içini kullanıcılar, gruplar ve OU’larla dolduruyor; Active Directory Güvenliği ve Sertleştirme (Hardening) yazısında ise ortamı LDAP sertleştirme, DNS proxy ve hesap güvenliğiyle saldırılara karşı güçlendiriyoruz. 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.