Active Directory (AD) ortamlarında karşılaşılan sinsi hataların büyük kısmı, aniden ortaya çıkan kritik çökmelerden ziyade, aylarca arka planda biriken replikasyon, DNS ve senkronizasyon düzensizliklerinden kaynaklanır. Bir domain controller (DC) devre dışı kaldığında veya SYSVOL klasöründeki bir grup ilkesi (GPO) istemcilere ulaşmadığında sorun genellikle o gün değil, aylar önce yapılan hatalı bir DNS konfigürasyonu veya yarıda kalmış bir replikasyon nedeniyle başlar.
Biz ITWISE bünyesinde tasarladığımız ve yönettiğimiz sistem altyapılarında, Active Directory sağlığını (Domain Health) korumayı reaktif bir sorun çözme süreci olarak değil, proaktif bir rutin olarak ele alırız. Bu kılavuzda, sahada doğrudan uygulayabileceğiniz, komut satırı ve PowerShell tabanlı doğrulamaları içeren, Windows Server Active Directory mimarisinin omurgasını oluşturan altı kritik alanı kapsayan derinlemesine bir kontrol listesi sunuyorum.
1. DNS Entegrasyonu ve Name Resolution Doğrulaması
Active Directory mimarisinin kalbi DNS servisidir. DNS çözünürlüğünde meydana gelen en ufak bir aksama, DC’lerin birbirini bulamamasına, istemcilerin domain’e dahil olamamasına ve replikasyonun tamamen durmasına yol açar. AD-integrated (Active Directory ile entegre) DNS bölgelerinde, her DC’nin kendi DNS sunucusunu birincil (Primary) olarak görmesi, ancak loopback adresinin (127.0.0.1) kullanımı konusunda doğru bir tasarım yapılması şarttır.
En sık yapılan hatalardan biri, DC’nin ağ kartı (NIC) üzerindeki birincil DNS ayarına doğrudan 127.0.0.1 yazıp, ikincil DNS alanını boş bırakmaktır. Bu durum, sunucu açılış aşamasındayken DNS servisinin henüz ayağa kalkmadığı saniyelerde DC’nin kendisini sorgulayamamasına ve AD servislerinin başlamasında gecikmelere (island state) neden olur. Doğru pratik, birincil DNS olarak başka bir güvenilir DC’nin IP adresini yazmak, ikincil DNS olarak ise loopback adresini tanımlamaktır.
DNS sağlığını doğrulamak için ilk adım, kritik SRV kayıtlarının DNS üzerinde mevcut olup olmadığını kontrol etmektir. İstemciler domain controller’ları bu SRV kayıtları üzerinden bulur. Aşağıdaki nslookup komut dizisiyle LDAP ve Kerberos servis kayıtlarının çözümlenip çözümlenmediğini doğrulamalısınız:
nslookup -type=all _ldap._tcp.dc._msdcs.itwise.localBu komutun çıktısında, ortamınızdaki tüm aktif Domain Controller’ların IP adresleri ve host isimleri (A kayıtları) listelenmelidir. Eğer eksik veya eski (tombstone süresi dolmuş ama DNS’ten silinmemiş) kayıtlar görüyorsanız, DNS dinamik güncellemelerinde (Secure Dynamic Updates) bir yetki veya senkronizasyon sorunu var demektir.
2. Replikasyon Durumu ve DC’ler Arası Senkronizasyon
Çoklu Domain Controller barındıran ortamlarda, Active Directory veritabanının (NTDS.dit) tüm DC’ler arasında tutarlı şekilde kopyalanması gerekir. Replikasyon mimarisi, KCC (Knowledge Consistency Checker) tarafından otomatik olarak oluşturulan bir topolojiye dayanır. Ancak site’lar arası (intersite) ve site içi (intrasite) replikasyonlarda oluşabilecek engellemeler zamanla veritabanı tutarsızlıklarına yol açar.
Replikasyon sağlığını denetlemek için elimizdeki en güçlü araç repadmin komutudur. Herhangi bir DC üzerinde komut satırını yönetici olarak açarak aşağıdaki komutla genel replikasyon özetini alabilirsiniz:
repadmin /replsummaryBu komutun çıktısı, domain içerisindeki tüm DC’lerin kaynak ve hedef bazlı replikasyon girişimlerini, hata sayılarını ve en son başarılı replikasyonun üzerinden geçen süreyi gösterir. Örnek bir başarılı çıktı şu şekildedir:
Source AD Node largest delta fails/total %% error
DC01 18m:42s 0 / 5 0
DC02 12m:10s 0 / 5 0
Destination AD Node largest delta fails/total %% error
DC01 12m:10s 0 / 5 0
DC02 18m:42s 0 / 5 0Eğer fails kolonunda sıfırdan farklı bir değer görüyorsanız, ayrıntılı replikasyon hatalarını ve hangi replikasyon partnerinde sorun olduğunu tespit etmek için aşağıdaki komutu çalıştırmalısınız:
repadmin /showreplEğer replikasyon hatası Access Denied (Hata Kodu: 5) veya RPC Server is Unavailable (Hata Kodu: 1722) ise, bu durum genellikle DC’ler arasındaki firewall kurallarından (RPC dinamik portları - TCP 49152-65535 veya TCP 135) ya da bilgisayar hesaplarının şifre senkronizasyonunun bozulmasından kaynaklanır.
3. FSMO Rollerinin Dağılımı ve Doğrulaması
Active Directory, multi-master bir veritabanı yapısına sahip olsa da bazı kritik işlemler tek bir sunucu tarafından yönetilmek zorundadır. Bu rollere FSMO (Flexible Single Master Operations) rolleri denir. Forest genelinde iki (Schema Master, Domain Naming Master) ve domain genelinde üç (RID Master, PDC Emulator, Infrastructure Master) olmak üzere toplam beş rol bulunur.
FSMO rollerinin hangi DC’ler üzerinde barındırıldığını bilmek ve bu rollerin erişilebilirliğini doğrulamak sistem kararlılığı için elzemdir. Özellikle zaman senkronizasyonunun (NTP) ana kaynağı olan PDC Emulator rolünün sağlığı kritik öneme sahiptir. Domain ortamındaki tüm istemciler ve diğer DC’ler zaman bilgisini PDC Emulator rolüne sahip DC’den alır.
FSMO rollerinin dağılımını hızlıca kontrol etmek için PowerShell veya geleneksel netdom aracını kullanabiliriz:
netdom query fsmoBu komut, beş rolün hangi DC’ler üzerinde olduğunu listeler. PDC Emulator rolünü barındıran DC’nin dış dünyadaki güvenilir bir NTP sunucusundan (örneğin pool.ntp.org) zamanı senkronize ettiğinden emin olmalısınız. Diğer tüm DC’ler ise zamanı hiyerarşik olarak bu PDC’den çekmelidir. PDC üzerinde NTP konfigürasyonunu doğrulamak için şu komut dizisini çalıştırabilirsiniz:
w32tm /query /sourceEğer çıktı olarak Local CMOS Clock veya Free-running System Clock görüyorsanız, zaman senkronizasyonunuz dış dünyaya kapalı demektir. Bu durum, Kerberos biletlerinin (ticket) maksimum 5 dakikalık zaman sapması (skew time) kuralı nedeniyle geçersiz kalmasına ve kimlik doğrulama hatalarına sebep olur.
4. SYSVOL ve GPO Replikasyon Sağlığı (DFSR)
SYSVOL klasörü, grup ilkelerinin (GPO) ve logon script’lerinin istemcilere dağıtıldığı, her DC’de bulunması zorunlu olan paylaşılan bir dizindir. Windows Server 2008’den bu yana SYSVOL replikasyonu için eski FRS (File Replication Service) yerine DFSR (Distributed File System Replication) kullanılmaktadır. Eğer altyapınız eski bir domain’den upgrade edildiyse ve hala FRS kullanılıyorsa, ivedilikle DFSR geçişini yapmanız gerekir.
DFSR replikasyonunun durumunu ve kuyrukta bekleyen (backlog) dosya olup olmadığını kontrol etmek, GPO değişikliklerinin tüm DC’lere yansıyıp yansımadığını anlamanın en kesin yoludur. DFSR sağlığını kontrol etmek için PowerShell üzerinde Get-DfsrBacklog komutunu veya komut satırından dfsrdiag aracını kullanabiliriz:
Get-DfsrBacklog -SourceComputerName "DC01" -DestinationComputerName "DC02" -GroupName "Domain System Volume"Eğer bu komut herhangi bir çıktı üretmiyorsa (yani backlog sıfır ise), SYSVOL replikasyonunuz tamamen güncel demektir. Eğer kuyrukta biriken dosyalar varsa, DFSR veritabanı bozulmuş veya disk alanı yetersizliği nedeniyle servis duraklatılmış olabilir.
DFSR servisinin olay günlüklerini (Event Viewer -> Applications and Services Logs -> DFS Replication) inceleyerek özellikle Event ID 2213 veya Event ID 4012 hatalarının olup olmadığını kontrol edin. Event ID 2213, beklenmeyen bir elektrik kesintisi veya sunucu kapanması sonrası DFSR’ın kendisini korumaya aldığını gösterir. Bu durumda replikasyonu manuel olarak tekrar tetiklemeniz gerekir:
wmic /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo where replicatedfoldername='SYSVOL Share' call resume replication5. Active Directory Veritabanı (NTDS.dit) ve Disk Sağlığı
Active Directory’nin fiziksel veritabanı olan ntds.dit dosyası ve bu veritabanının işlem logları varsayılan olarak C:\Windows\NTDS dizini altında saklanır. Bu dizinin bulunduğu diskin dolması, veritabanının aniden bozulmasına (corruption) ve AD servislerinin (Active Directory Domain Services - NTDS) tamamen durmasına neden olur.
Sanal platformlarda (VMware ESXi, Hyper-V) çalışan DC’lerde en büyük risklerden biri, disk genişletme veya snapshot (anlık görüntü) yönetimi sırasında yapılan hatalardır. Sanallaştırma katmanında DC’nin snapshot’ının alınması ve bu snapshot’a geri dönülmesi, USN Rollback adı verilen ve replikasyonu tamamen bozan felaket senaryolarına yol açabilir. Modern Windows Server sürümleri (Server 2012 ve sonrası) VM-GenerationID desteğiyle bu riski azaltsa da, DC sunucularında snapshot kullanımı hala önerilmemektedir.
Veritabanı bütünlüğünü kontrol etmek ve gerekirse çevrimdışı birleştirme (offline defragmentation) yapmak için ntdsutil aracı kullanılır. Ancak bu işlemleri yapmadan önce AD servisinin durdurulması gerektiğini unutmayın. Veritabanının mantıksal bütünlüğünü doğrulamak için şu adımları izleyebilirsiniz:
| Adım | Komut / İşlem | Açıklama |
|---|---|---|
| 1 | Stop-Service ActiveDirectoryDomainServices -Force |
AD Servislerini durdurun. |
| 2 | ntdsutil |
Veritabanı yönetim aracını başlatın. |
| 3 | files |
Dosya yönetimi alt modülüne geçin. |
| 4 | integrity |
NTDS.dit dosyasının fiziksel bütünlüğünü kontrol edin. |
| 5 | quit |
Modülden çıkış yapın. |
| 6 | Start-Service ActiveDirectoryDomainServices |
Servisleri tekrar başlatın. |
Bu doğrulamalar esnasında veritabanında herhangi bir hata (Jet Database Error) tespit edilirse, sunucuyu Directory Services Restore Mode (DSRM) ile başlatıp Acronis gibi yedekleme yazılımlarından aldığınız sistem durumu (System State) yedeğine geri dönmeniz veya DC’yi tamamen ortamdan kaldırıp (metadata cleanup yaparak) temiz bir kurulumla yeniden yapılandırmanız gerekir.
6. Güvenlik Sıkılaştırma, Audit ve Yetki Sürünmesi
Domain sağlığı sadece teknik replikasyon ve servis durumundan ibaret değildir; dizin ağacının güvenliği ve yetki hiyerarşisinin korunması da bu sağlığın ayrılmaz bir parçasıdır. Zaman içerisinde geçici projeler için açılan, ancak işi bittikten sonra silinmeyen “yetkili kullanıcılar” veya “aktif olmayan bilgisayar hesapları”, saldırganlar için en büyük açık kapılardır.
Özellikle AdminSDHolder nesnesi ve SDProp süreci, Active Directory içerisindeki yüksek yetkili grupların (Domain Admins, Enterprise Admins vb.) izin miras alma (inheritance) ayarlarını korur. Bu gruplara üye olan kullanıcıların izinlerinde manuel değişiklik yapılsa bile, sistem her 60 dakikada bir bu izinleri AdminSDHolder şablonuna geri döndürür. Bu mekanizmanın doğru çalışıp çalışmadığını izlemek kritik önem taşır.
Ortamdaki yetki sürünmesini (privilege creep) engellemek ve aktif olmayan hesapları temizlemek için periyodik olarak PowerShell sorguları çalıştırmalısınız. Örneğin, son 90 gün boyunca domain üzerinde oturum açmamış (inactive) bilgisayar hesaplarını tespit etmek için şu komut biçilmiş kaftandır:
Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -ComputersOnly | Select-Object Name, LastLogonDateBu listenin düzenli olarak taranması ve kullanılmayan bilgisayar hesaplarının devre dışı bırakılması (disable), ardından silinmesi gerekir. Benzer şekilde, süresi dolmuş veya şifresi hiç değişmeyen servis hesaplarının (Service Accounts) tespiti için de denetim politikalarınızı sıkılaştırmalı, Netwrix gibi Active Directory değişiklik denetimi (audit) araçlarıyla domain üzerindeki her yetki değişimini anlık olarak loglamalısınız.
Sonraki Adım: Otomatik Raporlama ve İzleme Altyapısı
Bu kontrol listesinde yer alan adımları manuel olarak gerçekleştirmek başlangıçta sisteminizin mevcut durumunu anlamak için harika bir yöntemdir. Ancak sürdürülebilir bir sistem mimarisinde bu kontrollerin otomatikleştirilmesi ve bir izleme (monitoring) platformuna bağlanması gerekir.
Bir sonraki adım olarak, burada bahsettiğimiz repadmin ve dfsrdiag komutlarının çıktılarını parse eden PowerShell betikleri yazabilir, bu betikleri Windows Task Scheduler ile günlük olarak çalıştırarak sonuçları Grafana veya InfluxDB gibi merkezi izleme ekranlarınıza metrik olarak gönderebilirsiniz. ITWISE operasyonlarında biz, bu metriklerin eşik değerlerini aşması durumunda (örneğin replikasyon gecikmesinin 30 dakikayı geçmesi) nöbetçi sistem mühendislerimize anlık alarm iletecek otomasyonları öncelikli olarak devreye alıyoruz. Altyapınızın sağlığı, aldığınız proaktif önlemlerin kalitesi kadardır.