Windows Server 2019'da Active Directory Domain Kurulumu

Domain Controller (DC), Microsoft'un Active Directory teknolojisinin temel bir bileşeni olarak, kurumsal Network'ler üzerinde kullanıcı hesaplarını ve Network kaynaklarını yönetmek için tasarlanmış bir sunucudur. DC'ler, Network üzerindeki güvenlik ve erişim politikalarını merkezi bir noktadan kontrol etme yeteneği sağlayarak, büyük ve karmaşık Network yapılarında düzeni ve güvenliği sağlar. DC'nin ana görevi, kullanıcıların kimlik doğrulaması, yetkilendirme işlemleri ve politika uygulamaları gibi kritik işlevleri yerine getirmektir.

Domain Controller (DC), Authentication ve Authorization (kimlik doğrulama ve yetkilendirme) ile Network'teki her kullanıcı ve bilgisayar için kimlik doğrulaması sürecini yönetir. Bu süreç, kullanıcıların sistemlere ve kaynaklara erişim taleplerinde bulunduğunda başlar. Kullanıcı adı ve şifre gibi kimlik bilgileri, DC'ye iletilir ve burada, Active Directory'de saklanan bilgilerle karşılaştırılır. Eğer bilgiler eşleşirse, kullanıcı sisteme başarılı bir şekilde giriş yapar. DC, bu süreci sadece yerel Network (LAN) içinde değil, VPN üzerinden uzaktan bağlanan kullanıcılar için de gerçekleştirir, böylece güvenli bir kullanıcı doğrulaması sağlanmış olur.

Domain Controller (DC), güvenlik politikaları ve Access Control (erişim kontrolü) ile güvenlik politikalarının tanımlandığı ve uygulandığı merkezi bir noktadır. Erişim kontrolü, kullanıcıların veya grupların bilgi kaynaklarına, Network'lere veya sistemlere erişimlerini yönetmek ve sınırlamak için kullanılan güvenlik tekniklerinin ve prosedürlerin bir bütünüdür. Bu kontrol mekanizmaları, yetkisiz erişimi önlemek, verilerin bütünlüğünü korumak ve bilgi güvenliğini sağlamak amacıyla tasarlanmıştır. Bu politikalar, hangi kullanıcının hangi kaynaklara erişebileceğini, hangi Network hizmetlerini kullanabileceğini ve hangi verilere ulaşabileceğini tanımlar. Örneğin, bazı kullanıcılara belirli dosya dizinlerine erişim izni verilirken, başkalarının erişimi kısıtlanabilir. Bu erişim kontrolleri, Access Control Lists (ACL) kullanılarak yönetilir ve her nesne üzerinde kimin ne tür eylemler gerçekleştirebileceğini detaylı bir şekilde belirtir.

Domain Controller (DC), politika uygulama ve yönetim ile Network politikalarını uygulamak için Group Policy nesneleri (GPO) kullanır. Bu politikalar, yazılım yüklemelerinden, güvenlik ayarlarına, kullanıcı arayüzü konfigürasyonlarına kadar geniş bir yelpazede düzenlemeler sağlar. GPO'lar yardımıyla tüm kullanıcı ve bilgisayarlar için merkezi bir noktadan politikaları uygulanabilir. Örneğin, bir güvenlik güncellemesinin tüm bilgisayarlara otomatik olarak yüklenmesini sağlayabilir veya belirli uygulamaların kullanımını kısıtlayabilirler.

Domain Controller (DC), Network yapısının yönetimi ve optimizasyonu açısından da önemli roller üstlenir. Active Directory'nin yapılandırma ayarları, Network topolojisini ve trafik akışını etkileyebilir. DC'ler, kullanıcıların ve kaynakların fiziksel veya lojistik olarak yer aldığı yerlere göre replikasyon ve veri senkronizasyonu gibi işlemleri yönetir. Bu işlemler, Network'ün verimliliğini artırmak ve veri tutarlılığını sağlamak için kritik öneme sahiptir.

Domain Controller (DC) Özellikleri

Active Directory altyapısının temelini oluşturan Domain Controller'lar (DC), organizasyonların kimlik doğrulama, yetkilendirme ve güvenlik politikalarını merkezi olarak yönetmelerini sağlar. Bu sunucular, kullanıcı hesaplarının, grup politikalarının ve güvenlik ayarlarının tüm organizasyon genelinde tutarlı bir şekilde uygulanmasını temin eder. DC'ler, Active Directory veritabanını (NTDS.dit) barındırarak, organizasyonun dijital varlıklarının güvenli ve tutarlı bir şekilde yönetilmesini mümkün kılar. Özellikle büyük ve karmaşık IT yapılarında, DC'lerin doğru yapılandırılması, sistemin güvenli, tutarlı ve yüksek performanslı çalışması açısından kritik önem taşır.

Authentication (Kimlik Doğrulama) talepleri ve kaynak erişim istekleri, DC'ler üzerinden yönetilir. Kullanıcıların ve cihazların sisteme güvenli bir şekilde erişimini sağlamak için LDAP (Lightweight Directory Access Protocol) ve Kerberos gibi protokoller kullanılır. Bu doğrulama süreçleri, güvenlik risklerini en aza indirirken, organizasyon genelinde tutarlı bir güvenlik politikası uygulanmasını sağlar.

Replikasyon süreçlerinde de merkezi bir rol üstlenen DC'ler, bir sunucu üzerinde yapılan değişikliklerin diğer tüm DC'ler ile senkronize edilmesini sağlar. Özellikle büyük ve coğrafi olarak dağılmış yapılarda, replikasyonun başarılı bir şekilde yönetilmesi, veri tutarlılığının sağlanması açısından büyük önem taşır. Bu süreçlerin optimize edilmesi, veri erişim sürelerini kısaltır ve genel sistem performansını artırır.

Güvenlik açısından, DC'ler organizasyonun dijital omurgasını oluşturur. Tüm oturum açma istekleri, parola doğrulamaları ve erişim kontrolleri bu sunucular üzerinden gerçekleştirilir. Güvenlik politikalarının merkezi olarak uygulanması, organizasyon genelinde tutarlı bir güvenlik duruşu oluşturur. Ayrıca, denetim politikaları ile sistemdeki tüm etkinliklerin izlenmesi ve raporlanması sağlanır, bu da güvenlik ihlallerinin hızlı bir şekilde tespit edilmesine olanak tanır.

Kaynak paylaşımı ve yönetimi açısından da DC'ler önemli işlevler üstlenir. Dosya paylaşımları, yazıcılar ve diğer kaynaklar, tanımlanmış erişim hakları ile merkezi olarak yönetilir. Bu kaynaklara erişim, kullanıcıların ve grupların güvenlik politikalarına uygun şekilde kontrol edilmesini sağlar, böylece veri bütünlüğü ve güvenliği korunur.

Kaynak yönetiminin yanı sıra, DC'lerin sunduğu diğer kritik işlevler de sistemin güvenli ve tutarlı bir şekilde çalışmasını sağlar. Bu bağlamda, tüm yönetim süreçlerinin Domain Controller'lar üzerindeki işleyişine daha yakından bakalım.

1- Authentication (Kimlik Doğrulama) ve Authorization (Yetkilendirme)

Authentication, bir kullanıcının ya da servisin gerçekten iddia ettiği kimlikte olup olmadığını doğrulama sürecidir. Bu aşamada şifreler, sertifikalar, biyometrik veriler veya akıllı kartlar gibi farklı mekanizmalar devreye girer. Modern sistemlerde en yaygın kullanılan yöntemlerden biri Kerberos olup, Ticket Granting Ticket (TGT) mekanizması ile güvenilir bir doğrulama süreci sunar. NTLM ise daha eski bir protokol olmasına rağmen bazı senaryolarda hala kullanılmaktadır. Multi-Factor Authentication (MFA) gibi ek güvenlik katmanları, saldırı yüzeyini daraltarak yetkisiz erişimleri engeller.

Authorization, başarılı bir Authentication sonrasında, kullanıcının hangi kaynaklara erişebileceğini belirleyen süreçtir. Access Control List (ACL) ve Group Policy Object (GPO) gibi mekanizmalar, kaynak seviyesinde erişim kontrolü sağlarken, Role-Based Access Control (RBAC) modeline sahip sistemlerde yetkilendirme süreçleri daha esnek ve yönetilebilir hale gelir. Kullanıcılar ve gruplar için belirlenen yetkiler, gereksiz erişimleri minimize ederek güvenliği artırır.

Bu iki süreç birbiriyle doğrudan bağlantılıdır ve yanlış yapılandırıldığında ciddi güvenlik risklerine yol açabilir. Güçlü bir Authentication ve Authorization stratejisi olmadan, kaynaklara yetkisiz erişimler kaçınılmaz hale gelir. Güvenli bir Network ortamı sağlamak için, kimlik doğrulama mekanizmalarının güncel tutulması ve erişim kontrollerinin düzenli olarak gözden geçirilmesi gerekir.

2- Active Directory Directory Services

Active Directory Directory Services (AD DS), merkezi kimlik yönetimi sağlayarak Network üzerindeki kaynakları organize eden ve yöneten bir yapıdır. Kullanıcı hesaplarından gruplara, bilgisayarlardan yazıcılara kadar birçok nesneyi kapsayan bu sistem, LDAP tabanlı bir veritabanı kullanarak kimlik bilgilerini ve ilişkili yetkilendirme verilerini saklar.

Domain Controller (DC), AD DS’in çekirdeğini oluşturur ve kimlik doğrulama ile yetkilendirme işlemlerini gerçekleştirir. Kerberos ve NTLM protokolleri ile kullanıcı doğrulaması sağlanırken, Group Policy Object (GPO) aracılığıyla Client konfigürasyonları merkezi olarak yönetilir. AD DS içinde Organization Unit (OU) yapısı kullanılarak nesneler gruplandırılır ve hiyerarşik bir düzen oluşturulur.

Replikasyon mekanizması sayesinde, birden fazla DC arasında sürekli veri senkronizasyonu gerçekleştirilerek tutarlılık korunur. Bu sayede herhangi bir DC devre dışı kaldığında, diğer DC’ler devreye girerek kesintisiz hizmet sunar. Global Catalog (GC) rolüne sahip DC’ler, farklı Domain ’lerdeki nesneler hakkında bilgi sağlayarak çapraz kaynak erişimlerini hızlandırır.

AD DS’in düzgün çalışabilmesi için zaman senkronizasyonu, replikasyon sağlığı ve Schema bütünlüğü gibi unsurların düzenli olarak kontrol edilmesi gerekir. Yanlış yapılandırılmış ya da güncellenmemiş bir AD DS ortamı, kimlik doğrulama hatalarına, replikasyon sorunlarına ve güvenlik açıklarına neden olabilir. Bu yüzden, altyapının sürekli izlenmesi ve optimize edilmesi büyük önem taşır.

3- DNS Entegrasyonu

Active Directory Directory Services (AD DS) ile Domain Name System (DNS) arasındaki entegrasyon, kimlik doğrulama ve kaynak erişimi için kritik bir yapı taşır. AD DS ortamında, Client'ların ve servislerin Domain Controller (DC) ile iletişim kurabilmesi için DNS kayıtlarının doğru bir şekilde yapılandırılması gerekir. Özellikle SRV kayıtları, Kerberos Authentication, LDAP sorguları ve Group Policy dağıtımı gibi işlemler için DC’lerin yerini belirlemede hayati rol oynar.

Dynamic DNS (DDNS) desteği sayesinde, DC’ler ve Client'lar IP adreslerini otomatik olarak DNS’e kaydederek manuel müdahale ihtiyacını ortadan kaldırır. Bu yapılandırma, replikasyon süreçleriyle senkronize çalışarak ortamın güncel ve erişilebilir kalmasını sağlar. Forward Lookup Zone, Client'ların isim çözümleme işlemlerini yürütürken, Reverse Lookup Zone IP adreslerinden isim çözümlemesi yaparak tersine sorgular için destek sağlar.

Birden fazla DC ve DNS sunucusunun bulunduğu ortamlarda, replikasyon sürecinin tutarlılığını sağlamak için doğru topoloji belirlenmelidir. Integrated DNS Zones, Active Directory Replikasyonu ile senkronize çalışarak, Zone verilerinin otomatik olarak güncellenmesine olanak tanır. Bu, manuel DNS yönetiminin getirdiği hata risklerini ortadan kaldırırken, yük dengelemesi ve kesintisiz hizmet sağlamak için önemli bir avantaj sunar.

Yanlış yapılandırılmış veya hatalı çalışan bir DNS altyapısı, Authentication gecikmelerine, kaynaklara erişim problemlerine ve Kerberos hatalarına yol açabilir. DNS replikasyon sağlığının düzenli olarak kontrol edilmesi, gereksiz kayıtların temizlenmesi ve Time-To-Live (TTL) değerlerinin optimize edilmesi, sistemin stabilitesini korumak için kritik öneme sahiptir.

4- Replication

Replication, birden fazla Domain Controller (DC) arasında Active Directory Directory Services (AD DS) verilerinin senkronize edilmesini sağlayan temel mekanizmadır. Kullanıcı hesapları, grup üyelikleri, Group Policy Object (GPO) ayarları ve diğer dizin nesneleri, replikasyon sayesinde tüm DC’lerde tutarlı bir şekilde saklanır.

Çok DC’li bir ortamda, değişikliklerin hızlı ve güvenilir şekilde yayılmasını sağlamak için Multi-Master Replication modeli kullanılır. Bu modelde, herhangi bir DC üzerinde yapılan değişiklikler, diğer DC’lere belirlenen zaman dilimleri içinde iletilir. Replikasyon trafiği, aynı Site içindeki DC’ler için daha sık gerçekleşirken, farklı Site’lar arasında bant genişliği tüketimini optimize etmek için belirli aralıklarla senkronizasyon yapılır. Bu süreç, Knowledge Consistency Checker (KCC) tarafından yönetilir ve replikasyon bağlantıları otomatik olarak oluşturulur.

AD DS replikasyonu, Intersite ve Intrasite olmak üzere iki temel kategoriye ayrılır. Intrasite Replication, aynı fiziksel konumdaki DC’ler arasında düşük gecikmeli, sık gerçekleşen veri aktarımı sağlarken Intersite Replication, uzak lokasyonlardaki DC’ler arasında belirlenen zaman dilimlerinde ve sıkıştırılmış veri formatında gerçekleştirilir. Bu model, Bandwidth (bant genişliği) kullanımını minimize ederek WAN üzerindeki yükü azaltır.

Replikasyon hataları, veri tutarsızlıklarına ve Authentication gecikmelerine yol açabilir. Özellikle USN Rollback, Lingering Objects ve Tombstone Lifetime gibi kavramlar, hatalı yapılandırılmış veya uzun süre replikasyon almayan DC’lerde ciddi sorunlara neden olabilir. Düzgün bir replikasyon sağlamak için Event Log takibi, bağlantı topolojisinin düzenli olarak kontrol edilmesi ve sağlıklı bir zaman senkronizasyonunun sağlanması gerekir.

5- Group Policy Yönetimi

Group Policy, Active Directory Directory Services (AD DS) ortamında Client'ların, kullanıcıların ve sistemlerin merkezi olarak yönetilmesini sağlayan bir mekanizmadır. Group Policy Object (GPO) üzerinden uygulanan ayarlar sayesinde güvenlik politikalarından yazılım dağıtımına, Network yapılandırmalarında kullanıcı kısıtlamalarına kadar geniş bir kontrol sağlanır.

GPO’lar, Domain Controller (DC) üzerinden Client'lara uygulanır ve Computer Configuration ve User Configuration olmak üzere iki temel seviyede yönetilir. Computer Configuration, makine bazında ayarlamalar yaparak işletim sistemi, güvenlik politikaları ve Network bağlantılarını düzenlerken; User Configuration, oturum açan kullanıcılara özel masaüstü politikaları, uygulama izinleri ve şifre kuralları gibi ayarlamaları içerir.

Organizational Unit (OU) hiyerarşisi içinde GPO’ların doğru şekilde bağlanması, politikaların sağlıklı çalışmasını sağlar. Default Domain Policy ve Default Domain Controllers Policy gibi varsayılan GPO’lar kritik Security ve Authentication ayarlarını barındırırken, organizasyonel gereksinimlere göre özel GPO’lar oluşturularak daha detaylı yapılandırmalar yapılabilir.

GPO’ların uygulanma sırası Local, Site, Domain ve OU seviyelerinde belirli bir hiyerarşiye sahiptir. Conflict durumlarında, OU'ya bağlı olan en alt seviyedeki GPO geçerli olur. Bunun yanında, Group Policy Inheritance ve Group Policy Precedence gibi kavramlar, politikaların nasıl uygulandığını ve hangi ayarların öncelikli olduğunu belirler.

GPO uygulamalarının beklendiği gibi çalıştığını doğrulamak için Group Policy Results (GPResult) ve Group Policy Modeling gibi araçlarla test edilmesi gerekir. Yapılandırmaların etkisini değerlendirmek ve yönetmek için düzenli denetimler yapılmalı, gereksiz veya fazla yük bindiren politikalar optimize edilerek sistem performansı korunmalıdır.

6- FSMO (Flexible Single Master Operations) Roles

Active Directory Directory Services (AD DS) ortamında veri bütünlüğünü sağlamak ve çakışmaları önlemek için belirli kritik işlemler tek bir Domain Controller (DC) üzerinde gerçekleştirilir. Bu özel görevleri yöneten mekanizma, Flexible Single Master Operations (FSMO) olarak adlandırılır. FSMO, Domain ve Forest düzeyinde olmak üzere toplamda beş farklı role sahiptir ve bu rollerin doğru konumlandırılması, dizin hizmetlerinin sağlıklı çalışması için gereklidir.

Forest seviyesinde çalışan Schema Master ve Domain Naming Master, Active Directory yapısının temel bileşenlerini yönetir. Schema Master, tüm Active Directory Object ve Attribute tanımlarını içerdiği için, Schema değişiklikleri yalnızca bu rolü tutan DC üzerinden yapılabilir. Domain Naming Master ise Forest içine yeni Domain ’lerin eklenmesi veya kaldırılması işlemlerini yönetir ve Global Catalog (GC) ile koordineli çalışır.

Domain seviyesinde bulunan RID Master, PDC Emulator ve Infrastructure Master rolleri, kullanıcı hesapları, güvenlik tanımlayıcıları ve zaman senkronizasyonu gibi görevleri yerine getirir. RID Master, her DC’ye benzersiz bir RID havuzu atayarak Security Identifier (SID) çakışmalarını önler. PDC Emulator, eski NT4 sistemleriyle uyumluluk sağlamanın yanı sıra, şifre değişikliklerini ve Group Policy güncellemelerini yönetir. Ayrıca Domain içindeki tüm sistemlerin zaman kaynağı olarak görev yapar. Infrastructure Master, Domain içindeki nesne referanslarını güncelleyerek, özellikle çok Domain ’li yapılarda Global Catalog (GC) ile veri tutarlılığını sağlar.

FSMO rollerinin doğru DC’lere atanması, performans ve güvenilirlik açısından önemlidir. Küçük ortamlarda tüm roller tek bir DC üzerinde tutulabilirken, büyük yapılarda yükü dengelemek için rollerin farklı DC’lere dağıtılması daha sağlıklı bir yapı oluşturur. Rollerin taşınması gerektiğinde NTDSUtil veya PowerShell gibi araçlar kullanılarak sorunsuz bir geçiş sağlanabilir. Beklenmedik bir durumda FSMO rollerini zorla devralmak (Seize) mümkündür ancak bu işlem yalnızca eski DC’nin geri dönmeyeceği durumlarda uygulanmalıdır.

7- Güvenlik Özellikleri

Active Directory Directory Services (AD DS) ortamında güvenlik; Authentication, Authorization ve veri bütünlüğünü koruma süreçleriyle doğrudan ilişkilidir. Domain Controller (DC) seviyesinde alınan güvenlik önlemleri, Network üzerindeki tüm Client'ların ve kaynakların korunmasını sağlar. Kerberos Authentication, NTLM’in yerine kullanılan daha güvenli bir doğrulama yöntemi olup, Ticket Granting Ticket (TGT) mekanizması ile kimlik doğrulama süreçlerini güvenli hale getirir.

Fine-Grained Password Policies, belirli kullanıcı gruplarına özel parola politikaları uygulamaya olanak tanırken, Privileged Access Management (PAM) modeliyle yüksek yetkili hesapların kullanım süresi sınırlandırılarak saldırı yüzeyi daraltılır. Bunun yanında, Role-Based Access Control (RBAC) kullanımı ile gereksiz yetkilendirmeler engellenir ve asgari yetki prensibi korunur.

LDAP Signing ve LDAP Channel Binding mekanizmaları, DC ile Client'lar arasındaki veri aktarımını güvenli hale getirerek, kimlik doğrulama bilgilerini içeren paketlerin değiştirilmesini veya ele geçirilmesini engeller. Secure LDAP (LDAPS) kullanımı zorunlu hale getirilerek, Client ve Server arasındaki bağlantının şifrelenmesi sağlanabilir.

Security Identifier (SID) Filtering ve AdminSDHolder gibi mekanizmalar, saldırganların yüksek yetkili hesapları ele geçirerek haklarını kalıcı hale getirmesini önlemeye yardımcı olur. DC’lere yönelik saldırılara karşı, Read-Only Domain Controller (RODC) kullanımı, şube ofisleri gibi güvenliği düşük lokasyonlarda yetkilendirme süreçlerini daha kontrollü hale getirir.

Event Log izleme ve güvenlik denetimleri, sistemde olağandışı aktivitelerin erken tespit edilmesini sağlar. Özellikle Event ID 4625 (başarısız oturum açma), 4740 (hesap kilitlenmesi) ve 4768 (Kerberos Authentication) gibi olaylar düzenli olarak analiz edilerek, saldırı girişimleri tespit edilebilir. DC güvenliğini artırmak için gereksiz servislerin devre dışı bırakılması, Windows Defender Credential Guard gibi ek koruma katmanlarının aktif edilmesi ve saldırı yüzeyini daraltan GPO yapılandırmalarının uygulanması gereklidir.

8- Backup ve Disaster Recovery

Active Directory Directory Services (AD DS) ortamında Backup ve Disaster Recovery stratejileri, veri kaybını önlemek ve kritik sistemlerin kesintisiz çalışmasını sağlamak için olmazsa olmaz bileşenlerdir. Domain Controller (DC) üzerindeki veriler, yalnızca kullanıcı hesapları ve Group Policy'lerden ibaret olmadığı için, eksiksiz bir yedekleme stratejisi oluşturulmadığında Authentication hataları, veri bütünlüğü sorunları ve sistem çökmesi gibi ciddi problemler kaçınılmaz hale gelir.

Backup işlemleri için Windows Server Backup (WSB) en yaygın kullanılan araçlardan biridir ve System State Backup yöntemiyle AD DS veritabanı (NTDS.dit), SYSVOL, Registry ve Boot Configuration Data (BCD) gibi kritik bileşenleri kapsayan bir yedek alınmasını sağlar. Yedekleme sırasında VSS (Volume Shadow Copy Service) kullanılarak, çalışan sistem üzerinde kesintisiz bir anlık görüntü oluşturulur ve veri tutarlılığı korunur.

Disaster Recovery sürecinde, yedekten geri dönüş işlemleri Authoritative ve Non-Authoritative Restore olarak iki farklı senaryoya ayrılır. Non-Authoritative Restore, bir DC’nin çökmesi durumunda sistemin önceki bir yedeğe dönerek mevcut replikasyon sürecine tekrar dahil olmasını sağlar. Ancak, eğer silinen veya değiştirilmiş nesneler tüm DC’lere replikasyon yapıldıysa, sadece Non-Authoritative Restore yeterli olmaz. Bu gibi durumlarda, Authoritative Restore kullanılarak belirli nesneler geri yüklenir ve replikasyon sırasında diğer DC’lere zorla yayılması sağlanır.

Şiddetli bir çökme durumunda, Bare Metal Recovery (BMR) ile tüm sistemin donanım seviyesinde yeniden kurulumu mümkündür. Ancak, yanlış bir yapılandırma ya da eski yedeklerin kullanılması veri tutarsızlıklarına yol açabilir. Bu yüzden, Backup işlemlerinin belirli periyotlarla test edilmesi ve yedeklerin doğrulanması gerekir.

Ek güvenlik önlemleri kapsamında Recycle Bin özelliği aktif edilerek, yanlışlıkla silinen nesnelerin hızlıca geri getirilmesi sağlanabilir. Ayrıca, yedekleme dosyalarının fiziksel olarak güvenli lokasyonlarda saklanması ve Ransomware gibi saldırılara karşı Offline Backup senaryolarının planlanması büyük önem taşır. Active Directory Restore işlemlerinin acil durumlarda hızlıca uygulanabilmesi için, kurtarma sürecinin önceden test edilmesi ve kritik hesapların korunması gereklidir.

9- Monitoring ve Performans İzleme

Active Directory Directory Services (AD DS) ortamında Monitoring ve Performans İzleme, hem sistemin kesintisiz çalışmasını sağlamak hem de olası güvenlik tehditlerini önceden tespit etmek için kritik bir süreçtir. Domain Controller (DC) seviyesinde gerçekleşen Authentication, Authorization, Replication ve Group Policy işlemlerinin düzgün çalışması için belirli metriklerin sürekli olarak izlenmesi gerekir.

Event Viewer, DC üzerinde gerçekleşen olayları analiz etmek için kullanılan temel araçlardan biridir. Özellikle Directory Service, System ve Security Log'ları, kimlik doğrulama hataları, replikasyon problemleri ve yetkisiz erişim girişimleri gibi kritik olayları tespit etmek için düzenli olarak incelenmelidir. Authentication süreçlerine ilişkin Event ID 4625 (başarısız oturum açma), 4740 (hesap kilitlenmesi) ve 4768 (Kerberos Authentication) gibi kayıtlar, saldırı girişimlerini anlamak açısından büyük önem taşır.

Performance Monitor (PerfMon), AD DS bileşenlerinin kaynak tüketimini ve sistem performansını izlemek için kullanılır. CPU, RAM ve Disk kullanımı gibi temel metriklerin yanı sıra, LDAP Query Performansı, NTDS Database Reads/Writes ve Replication Latency gibi AD DS’e özel sayaçlar takip edilerek darboğazlar erken tespit edilebilir. Özellikle yüksek gecikme değerleri, Kerberos Authentication hatalarına ve Client'larda yaşanan oturum açma gecikmelerine neden olabilir.

DC’ler arasındaki replikasyon sağlığı, Repadmin /replsummary ve Repadmin /showrepl komutlarıyla kontrol edilebilir. Replikasyon gecikmeleri, güncel olmayan nesneler ve USN Rollback gibi sorunlar ciddi veri tutarsızlıklarına yol açabilir. DCDiag aracıyla da DC genel sağlık durumu analiz edilerek, servislerin düzgün çalışıp çalışmadığı kontrol edilmelidir.

Özellikle büyük ölçekli ortamlarda Azure Monitor, System Center Operations Manager (SCOM) veya PRTG Network Monitor gibi merkezi izleme araçları kullanılarak proaktif bir denetim mekanizması oluşturulabilir. Bu sayede yalnızca anlık performans takibi değil, uzun vadeli trend analizleri de yapılarak kapasite planlaması gerçekleştirilebilir. AD DS’in kesintisiz çalışmasını sağlamak için, monitoring süreçleri düzenli olarak gözden geçirilmeli ve kritik sistem bileşenleri için otomatik uyarı mekanizmaları devreye alınmalıdır.

10- Client Etkileşimi ve Protokol Desteği

Active Directory Directory Services (AD DS) ortamında Client'lar, Domain Controller (DC) ile sürekli iletişim halinde çalışarak Authentication, Authorization ve kaynak erişimi gibi işlemleri gerçekleştirir. Bu süreçlerin sorunsuz bir şekilde ilerleyebilmesi için, AD DS’in sunduğu protokoller üzerinden güvenilir bir etkileşim sağlanmalıdır.

LDAP (Lightweight Directory Access Protocol), AD DS Client'ların dizin verilerine erişmesini ve sorgulamalar yapmasını sağlayan temel protokoldür. Özellikle Secure LDAP (LDAPS) kullanımı, kimlik doğrulama süreçlerinde verilerin şifrelenmesini sağlayarak güvenliği artırır. Kerberos, NTLM’e kıyasla daha güvenli bir Authentication mekanizması sunarak Ticket Granting Ticket (TGT) ile oturum açan kullanıcıların kimlik doğrulama bilgilerini sürekli olarak yeniden göndermesine gerek kalmadan erişimlerini sürdürmesini sağlar.

Domain ’e katılmış Client'lar, DC ile sürekli iletişim halinde olup, DNS kayıtlarını kullanarak en uygun Authentication sunucusunu belirler. Group Policy Object (GPO) yapılandırmaları sayesinde sistem politikaları, güvenlik ayarları ve yazılım dağıtımları Client'lara merkezi olarak uygulanır. Özellikle Client'ların gpupdate /force komutuyla anında güncellenebilmesi, konfigürasyon değişikliklerinin hızlı bir şekilde yayılmasını sağlar.

Client'lar için zaman senkronizasyonu da kritik bir faktördür. Kerberos Authentication’ın başarılı olabilmesi için Clientt'lar ve DC’ler arasında saat farkının belirlenen tolerans, varsayılan olarak 5 dakika içinde olması gerekir. Bu senkronizasyon, Windows Time Service (W32Time) üzerinden sağlanır ve DC’lerin güvenilir bir zaman kaynağı ile eşleştirilmesi gerekir.

Eski Client ve sistemlerin desteklenmesi için NTLM Authentication hala bazı ortamlarda kullanılabilse de, modern güvenlik standartlarını sağlamak adına Kerberos veya Certificate-Based Authentication (CBA) gibi daha güvenli çözümler tercih edilmelidir. AD DS, aynı zamanda Web Authentication (WebAuthn) ve OAuth gibi modern protokollerle entegrasyon sağlayarak, hibrit ortamlarda bulut servisleriyle daha esnek bir çalışma yapısı sunar.

Client-DC etkileşimi sırasında yaşanabilecek gecikmeler, Authentication hataları ve GPO uygulama sorunları Event Viewer, DCDiag, NLTest ve Repadmin gibi araçlarla analiz edilerek tespit edilebilir. Güvenilir bir Client deneyimi sağlamak için, DNS yapılandırmalarının doğru olması, Kerberos Ticket sürelerinin optimize edilmesi ve GPO’ların çakışmalar yaratmayacak şekilde düzenlenmesi büyük önem taşır.

11- Service Hesapları Yönetimi

Active Directory Directory Services (AD DS) ortamında Service Hesapları, sistem ve uygulamaların belirli işlemleri gerçekleştirebilmesi için kullanılan özel hesap türleridir. Doğru yönetilmediğinde, bu hesaplar ciddi güvenlik açıklarına yol açabileceğinden, en az ayrıcalık prensibiyle yapılandırılmaları ve düzenli olarak denetlenmeleri gerekir.

Geleneksel olarak, servisler için standart kullanıcı hesapları oluşturulup kullanılırdı. Ancak, bu yöntem yüksek ayrıcalıklar gerektirdiğinden ve parola yönetimi zorlukları içerdiğinden güvenlik açısından risklidir. Modern AD DS ortamlarında, bu riskleri azaltmak için Managed Service Account (MSA) ve Group Managed Service Account (gMSA) gibi özel hesap türleri kullanılır.

Managed Service Account (MSA), tek bir sistemde çalışan servisler için geliştirilmiş olup, otomatik parola yönetimi ve Kerberos Authentication desteği sunar. Parola değişiklikleri sistem tarafından yönetildiği için, manuel müdahale gerektirmez ve hesap güvenliği sağlanmış olur.

Group Managed Service Account (gMSA), birden fazla sistemde çalışan uygulamalar ve servisler için kullanılan gelişmiş bir hesap türüdür. Windows Server 2012 ve sonrasında desteklenen gMSA, parolaların otomatik olarak belirli aralıklarla değiştirilmesini sağlar ve birden fazla sunucu tarafından kullanılabilir. Özellikle Load Balancing (yük dengelemesi) yapılan ortamlarda gMSA kullanımı, hem yönetimi kolaylaştırır hem de güvenliği artırır.

Service Hesaplarının güvenliğini sağlamak için Account Delegation, Least Privilege Access ve Kerberos Constrained Delegation (KCD) gibi mekanizmalar devreye alınmalıdır. Hesapların gereksiz yüksek yetkilere sahip olması veya birden fazla sistemde aynı hesap bilgilerinin kullanılması, saldırganlar için büyük bir fırsat yaratır. Ayrıca SID Filtering, AdminSDHolder ve Protected Users Group gibi koruma mekanizmalarıyla kritik hesapların ele geçirilme riskleri azaltılmalıdır.

Daha eski sistemlerle uyumluluk gerektiren ortamlarda, Service Hesaplarının kullanımını izlemek için Event ID 4624 (başarılı oturum açma) ve Event ID 4648 (alternatif kimlik bilgileri kullanılarak giriş yapma) gibi kayıtlar düzenli olarak incelenmelidir. Service Hesaplarının hangi servislerde kullanıldığını belirlemek ve yönetmek için Get-ADServiceAccount, Get-ADComputerServiceAccount ve Get-Service -Name ServisAdi gibi PowerShell komutları kullanılabilir.

Güvenlik açısından, kullanılmayan veya gereğinden fazla yetkilendirilmiş servis hesapları, periyodik olarak gözden geçirilmeli ve gereksiz olanlar kaldırılmalıdır. Managed Service Account (MSA) ve Group Managed Service Account (gMSA) kullanımı teşvik edilerek, manuel parola yönetimi gerektiren standart Service Hesaplarının sayısı en aza indirilmeli ve güvenlik politikaları ile sürekli izleme sağlanmalıdır.

12- LDAP Over SSL/TLS (LDAPS)

Active Directory Directory Services (AD DS) ortamında Lightweight Directory Access Protocol (LDAP), dizin hizmetleriyle Client'lar ve uygulamalar arasındaki iletişimi sağlayan temel protokoldür. Varsayılan LDAP trafiği şifrelenmeden iletildiği için, hassas kimlik doğrulama verilerinin korunması adına LDAP Over SSL/TLS (LDAPS) kullanımı zorunlu hale gelmiştir.

LDAPS, LDAP isteklerini Transport Layer Security (TLS) veya Secure Sockets Layer (SSL) ile şifreleyerek Client-Server arasındaki iletişimi güvenli hale getirir. TCP 389 numaralı port üzerinden çalışan standart LDAP’in aksine, LDAPS 636 numaralı portu kullanır ve kimlik doğrulama bilgileri de dahil olmak üzere tüm trafiği şifreleyerek saldırılara karşı koruma sağlar. Özellikle Man-in-the-Middle (MitM) saldırıları ve kimlik bilgilerinin ele geçirilmesi gibi tehditleri önlemek için LDAPS zorunlu bir güvenlik önlemidir.

LDAPS’in çalışabilmesi için Domain Controller (DC) üzerinde bir Public Key Infrastructure (PKI) veya üçüncü taraf bir Certificate Authority (CA) tarafından imzalanmış bir SSL/TLS sertifikasının yüklenmesi gerekir. Sertifikanın Subject Alternative Name (SAN) içermesi, Client'ların DC’yi doğru şekilde doğrulamasını sağlar. Get-ADRootDSE komutu ile LDAPS desteği doğrulanabilir ve Ldp.exe aracı kullanılarak LDAPS bağlantıları test edilebilir.

LDAP Signing ve LDAP Channel Binding gibi ek güvenlik mekanizmaları, Client'ların yalnızca kimliği doğrulanmış DC’lere bağlanmasını ve LDAPS’in zorunlu hale getirilmesini sağlar. LDAPS’in düzgün çalıştığından emin olmak için, Client ve DC arasındaki sertifika güven zinciri doğrulanmalı ve Event ID 1220 (LDAP over SSL başarıyla başladı) ile Event ID 2886 (LDAP Signing devre dışı) gibi olaylar düzenli olarak izlenmelidir.

Desteklenmeyen sistemler veya hatalı yapılandırılmış Client'lar nedeniyle LDAPS gereklilikleri atlandığında, Network üzerinde ciddi güvenlik açıkları oluşabilir. Bu nedenle, standart LDAP trafiği engellenerek LDAPS zorunlu hale getirilmeli ve kritik sistemler için sertifika süreleri düzenli olarak kontrol edilmelidir.

13- Password Policy ve Account Lockout Politikaları

Active Directory Directory Services (AD DS) ortamında Password Policy ve Account Lockout politikaları, kullanıcı hesaplarının güvenliğini sağlamak ve Brute-Force saldırılarını önlemek için kritik bir rol oynar. Kullanıcı parolalarının güçlü ve karmaşık olması, saldırganların tahmin edebileceği zayıf parolaların kullanımını engellerken, yanlış giriş denemeleri sonrasında hesapların kilitlenmesi yetkisiz erişim girişimlerini sınırlandırır.

Password Policy, Default Domain Policy üzerinden uygulanarak tüm kullanıcı hesaplarının uyması gereken parola gereksinimlerini belirler. Minimum ve maksimum parola uzunluğu, parola geçmişi, parola süresi ve karmaşıklık gereksinimleri gibi ayarlar, Group Policy Object (GPO) aracılığıyla merkezi olarak yönetilir. Güçlü bir parola politikası için şu ayarlar uygulanmalıdır:

✅ Minimum Password Length: En az 14 karakter olmalı.

✅ Password Complexity: Büyük/küçük harf, rakam ve özel karakter içermeli.

✅ Password Expiration: 90 günde bir değiştirilmesi zorunlu olmalı.

✅ Password History: En az 24 eski parola saklanarak tekrar kullanımı engellenmeli.

✅ Minimum Password Age: Kullanıcıların parolayı sürekli değiştirmesini önlemek için en az 1 gün.

Standart Password Policy, tüm Domain ’e uygulanırken, belirli kullanıcı grupları için farklı politikalar tanımlamak gerektiğinde Fine-Grained Password Policies (FGPP) kullanılır. FGPP, Active Directory’de Password Settings Object (PSO) nesneleriyle belirli gruplara veya kullanıcı hesaplarına özel parola gereksinimleri tanımlamaya olanak tanır.

Account Lockout Policy, belirli sayıda başarısız giriş denemesi sonrasında kullanıcı hesaplarını geçici olarak devre dışı bırakarak, brute-force saldırılarına karşı koruma sağlar. Bu politika aşağıdaki temel ayarlarla yapılandırılmalıdır:

✅ Account Lockout Threshold: 5-10 başarısız giriş denemesi sonrası hesap kilitlenmeli.

✅ Account Lockout Duration: 30 dakika boyunca tekrar giriş yapılamamalı.

✅ Reset Account Lockout Counter After: Yanlış giriş sayacı 15 dakika içinde sıfırlanmalı.

Yanlış yapılandırılmış bir Account Lockout Policy, saldırganlar tarafından Denial of Service (DoS) saldırılarıyla kullanıcı hesaplarının kilitlenmesine neden olabilir. Bu nedenle, hesap kilitleme süresi iyi dengelenmeli ve saldırılara karşı ek koruma sağlamak için Smart Lockout, Adaptive Authentication ve Multi-Factor Authentication (MFA) gibi teknolojiler devreye alınmalıdır.

Parola ve hesap kilitleme politikalarının etkinliğini kontrol etmek için Audit Policy yapılandırılarak Event ID 4740 (hesap kilitlendi), Event ID 4625 (başarısız giriş denemesi) gibi Log'lar izlenmeli ve anormal giriş denemeleri anında tespit edilerek saldırı yüzeyi en aza indirilmelidir.

14- Sites and Services Yönetimi

Active Directory Directory Services (AD DS) ortamında Sites and Services Yönetimi, Domain Controller (DC) replikasyonlarını optimize etmek, Client'ların en uygun DC’ye yönlendirilmesini sağlamak ve WAN bağlantılarını verimli kullanmak için kritik bir yapı taşını oluşturur. Büyük ve çok lokasyonlu sistemlerde, her ofis veya veri merkezi ayrı bir Site olarak tanımlanarak replikasyon süreçleri kontrol altına alınır ve gecikmeler en aza indirilir.

Site ve Subnet Yapılandırması, Client'ların kendilerine en yakın DC’ye yönlendirilmesi açısından büyük önem taşır. Active Directory Sites and Services konsolunda tanımlanan Subnet bilgileri, Client'ların hangi Site’a ait olduğunu belirler ve Client'lar, DC Locator mekanizmasını kullanarak oturum açma isteklerini kendilerine en yakın DC’ye yönlendirebilir. Eğer bir Client tanımlı bir Subnet’e ait değilse, rastgele bir DC’ye yönlendirilebilir, bu da gereksiz WAN trafiğine ve gecikmelere yol açabilir.

Replikasyon stratejisi, Intrasite Replication ve Intersite Replication olarak ikiye ayrılır. Intrasite Replication, aynı Site içindeki DC’ler arasında gerçekleştirildiği için, değişiklikler hızlı bir şekilde senkronize edilir ve sık aralıklarla replikasyon yapılır. Intersite Replication ise, WAN bağlantılarının yoğun yük altına girmesini önlemek için belirlenen zaman aralıklarında çalışır ve genellikle IP veya SMTP transport üzerinden gerçekleştirilir.

Bridgehead Server, farklı Site’lar arasındaki replikasyonu yönetmek için kullanılan kritik bir bileşendir. Her Site içinde Knowledge Consistency Checker (KCC), en verimli replikasyon yollarını belirleyerek bağlantıları otomatik olarak optimize eder. Ancak, büyük ölçekli ortamlarda manuel müdahale gerekebilir ve gereksiz bağlantıların kaldırılması veya Site Link Cost ayarlarının optimize edilmesi gerekebilir.

Client'ların doğru Site içinde Authentication yapıp yapmadığını doğrulamak için NLTest /DSGetSite komutu kullanılabilir. Replikasyon problemlerini tespit etmek ve bağlantıların sağlıklı çalıştığını doğrulamak için Repadmin /ReplSummary, Repadmin /Showrepl ve DCDiag gibi araçlar düzenli olarak çalıştırılmalıdır.

Yanlış yapılandırılmış Sites and Services, Client'ların uzak DC’lere yönlendirilmesine, yüksek gecikme sürelerine ve gereksiz bant genişliği tüketimine neden olabilir. Bu yüzden, her yeni Network Subnet’i doğru Site’a eklenmeli, replikasyon bağlantıları düzenli olarak gözden geçirilmeli ve büyük ölçekli yapılarda Site Link Bridging gibi mekanizmalar dikkatlice yapılandırılmalıdır.

15- Schema Uzantıları ve Özelleştirmeler

Active Directory Directory Services (AD DS) içinde Schema, dizindeki tüm nesne türlerini ve bunların sahip olabileceği Attribute'leri tanımlayan temel bir bileşendir. Schema; Object Class'lar, Attribute'ler, Syntax Rule'lar ve Mandatory/Optional Property'ler gibi bileşenlerden oluşarak dizindeki veri yapısını belirler. Standart olarak gelen şema nesneleri çoğu ihtiyacı karşılasa da, özel gereksinimlere uygun olarak Schema uzantıları ve özelleştirmeleri yapılabilir.

Schema değişiklikleri kalıcı ve geri alınamaz olduğu için, her değişiklik öncesinde detaylı bir test yapılmalı ve mevcut yapıdaki etkilere karşı analizler gerçekleştirilmelidir. Schema değişiklikleri, yalnızca Schema Master FSMO rolüne sahip olan Domain Controller (DC) üzerinden yapılabilir. Schema Master, Forest genelinde Schema güncellemelerinden sorumlu olduğu için, yanlış yapılan bir değişiklik tüm ortamı etkileyebilir.

Özelleştirme işlemleri sırasında yeni Object Class veya Attribute eklemek için ldifde veya PowerShell kullanılabilir. Örneğin, ldifde -i -f schema_update.ldf komutu ile yeni bir Schema uzantısı içeren dosya içeri aktarılarak güncelleme yapılabilir. ADSI Edit aracı da doğrudan Schema düzenlemek için kullanılabilir, ancak yanlış yapılandırmalar ciddi tutarsızlıklara neden olabileceğinden dikkatli olunmalıdır.

Schema genişletme işlemlerinde dikkat edilmesi gereken temel noktalar:

✅ Geri dönüşü yoktur, yanlış yapılan bir değişiklik düzeltilemez.

✅ Test ortamında uygulanmalıdır, canlı sistemlerde doğrudan değişiklik yapılmamalıdır.

✅ Replication gecikmeleri göz önünde bulundurulmalıdır, Schema değişiklikleri Forest içindeki tüm DC’lere yayılır.

✅ Mevcut uygulamalarla uyumluluk sağlanmalıdır, Schema değişikliği sonrası bazı eski uygulamalar hata verebilir.

Microsoft Exchange ve bazı özel uygulamalar, Active Directory içinde özel Schema uzantıları gerektirdiğinden, her entegrasyon öncesinde ilgili uygulamanın şemaya yapacağı değişiklikler dikkatlice incelenmelidir. Schema Version güncellemeleri, AD DS’in hangi seviyede olduğunu belirler ve yeni Windows Server sürümlerine yükseltme yapılmadan önce, Schema güncellemesi gerçekleştirilmelidir.

Şemanın mevcut durumunu kontrol etmek için

gibi PowerShell komutları kullanılabilir. Güncellenen nesneleri belirlemek için ise Event ID 1582 (Schema Update Completed) ve Event ID 1109 (Schema Modification Attempted) gibi kayıtlar takip edilmelidir.

Schema özelleştirmeleri, organizasyonun ihtiyaçlarına uygun yeni nesne tanımlamaları ve özel alanlar eklemeyi mümkün kılar. Ancak yanlış veya gereksiz bir genişletme, gereksiz replikasyon yüküne, uyumluluk sorunlarına ve güvenlik açıklarına neden olabilir. Bu yüzden, her değişiklik öncesinde iyi bir planlama yapılmalı ve mümkünse ExtensionAttribute kullanımı gibi alternatif yöntemler değerlendirilmelidir.

16- Kontrol Delegasyonu

Active Directory Directory Services (AD DS) ortamında Kontrol Delegasyonu, belirli kullanıcı veya gruplara Domain Controller (DC) üzerinde yönetimsel görevleri yerine getirebilmeleri için yetki devri yapılmasını sağlar. Varsayılan olarak, Enterprise Admins ve Domain Admins grupları AD DS üzerinde tam yetkiye sahiptir. Ancak, her yöneticiye tam yetki vermek yerine, Least Privilege Principle ilkesine uygun olarak yalnızca ihtiyaç duyulan yetkilerin atanması gerekir.

Delegasyon, Active Directory Users and Computers (ADUC) konsolundaki Delegate Control Wizard aracıyla kolayca yapılandırılabilir. Bu süreçte, belirli bir Organizational Unit (OU) veya nesne seçilir ve belirlenen kullanıcı ya da gruba yetkiler tanımlanır. Örneğin, bir helpdesk ekibine yalnızca password reset, user account unlock ve group membership modification yetkileri verilebilir.

Yetki devri, Access Control List (ACL) ve Access Control Entry (ACE) mekanizmaları ile yönetilir. Her nesne üzerinde belirlenen Permissions ayarları sayesinde, kullanıcılara nesneler üzerinde tam kontrol yerine Read, Write, Modify veya Delete gibi spesifik izinler atanabilir. Delegasyon uygulanırken dikkat edilmesi gereken noktalar şunlardır:

✅ OU bazında yetkilendirme yapılmalı, gereksiz yetkiler verilmemelidir.

✅ Security Group kullanımı teşvik edilmeli, tekil kullanıcı bazlı delegasyondan kaçınılmalıdır.

✅ İzin miras alımı (Inheritance) mekanizması göz önünde bulundurulmalı ve gereksiz yetki devri engellenmelidir.

✅ AdminSDHolder koruması, yüksek yetkili hesaplara uygulanmışsa, delegasyon bu hesaplar için çalışmayabilir.

Delegasyon sırasında belirli komutlar ve araçlar kullanılarak yapılandırma doğrulanabilir. Get-ACL PowerShell komutu ile belirli bir nesnenin erişim izinleri görüntülenebilir:

Ayrıca, dsacls komutu kullanılarak belirli bir nesne üzerindeki yetkilendirme ayarları detaylı olarak incelenebilir:

Gereksiz veya yanlış yapılandırılmış yetkilendirmeleri belirlemek için Event ID 4662 (Directory Service Access Attempted) gibi Log'lar takip edilerek yetki devri yapılan hesapların işlemleri izlenmelidir.

Yanlış yapılandırılmış delegasyon, saldırganların yetkilerini yükseltmelerine veya istemeden fazla yetkilendirilmiş kullanıcıların kritik nesneleri değiştirmelerine neden olabilir. Bu yüzden, yetkilendirme periyodik olarak gözden geçirilmeli, gereksiz veya hatalı izinler kaldırılmalı ve Privileged Access Management (PAM) veya Just Enough Administration (JEA) gibi ek güvenlik önlemleri devreye alınmalıdır.

17- Denetim ve Uyum Raporlaması

Active Directory Directory Services (AD DS) ortamında Denetim ve Uyum Raporlaması, güvenlik ihlallerini önlemek, düzenleyici gereksinimlere uyumluluğu sağlamak ve sistem değişikliklerini izlemek için kritik bir süreçtir. Domain Controller (DC) üzerinde gerçekleşen Authentication işlemlerinden Group Policy değişikliklerine, nesne silme işlemlerinden yetki devri hareketlerine kadar her kritik olayın kaydedilmesi ve raporlanması gerekir.

Denetim Politikalarının Yapılandırılması, Group Policy Object (GPO) kullanılarak merkezi bir şekilde yönetilir. Advanced Audit Policy Configuration ayarları altında Audit Account Logon Events, Audit Account Management, Audit Directory Service Changes ve Audit Object Access gibi politikalar etkinleştirilerek, kullanıcı giriş-çıkışları, hesap değişiklikleri ve dizin üzerindeki nesne değişiklikleri izlenebilir.

Event Log Analizi, DC üzerinde gerçekleşen olayların incelenmesini sağlar. Kritik olayları tespit etmek için Event Viewer altında aşağıdaki Event ID'ler düzenli olarak takip edilmelidir:

👉 Event ID 4624 – Successful logon
👉 Event ID 4625 – Failed logon
👉 Event ID 4740 – User account locked out
👉 Event ID 5136 – Active Directory object modified
👉 Event ID 5145 – File or object accessed
👉 Event ID 4662 – Access attempt on AD DS objects

Uyumluluk ve Güvenlik Standartları, organizasyonların yasal ve endüstri standartlarına uymasını gerektirir. AD DS için ISO 27001, NIST 800-53, GDPR, HIPAA, SOX gibi regülasyonlar, veri bütünlüğü ve erişim kontrollerinin düzenli olarak izlenmesini ve raporlanmasını zorunlu kılar. Bu kapsamda, SIEM (Security Information and Event Management) çözümleri kullanılarak merkezi Log yönetimi sağlanabilir ve güvenlik olayları otomatik olarak analiz edilebilir.

PowerShell ile Raporlama, belirli denetim verilerini hızla toplamak ve analiz etmek için güçlü bir yöntemdir. Örneğin, son 24 saat içinde Active Directory nesnelerinde yapılan değişiklikleri listelemek için aşağıdaki PowerShell komutu kullanılabilir:

Benzer şekilde, belirli bir kullanıcının tüm Authentication işlemlerini görüntülemek için:

Daha gelişmiş raporlama için Microsoft Defender for Identity, Azure AD Identity Protection, Splunk, ManageEngine ADAudit Plus gibi çözümler kullanılabilir.

Yanlış yapılandırılmış denetim mekanizmaları, gereksiz Log yüküne veya kritik olayların gözden kaçmasına neden olabilir. Bu yüzden, gereksiz denetim kurallarından kaçınılmalı, sistem üzerindeki değişiklikler düzenli olarak incelenmeli ve güvenlik ihlallerine karşı proaktif önlemler alınmalıdır.

18- Network Yazıcısı Yapılandırması ve Yönetimi

Active Directory Directory Services (AD DS) ortamında Network Yazıcısı Yapılandırması ve Yönetimi, merkezi yazıcı dağıtımını sağlamak, Client'ların yazıcılara erişimini yönetmek ve baskı işlemlerinin güvenliğini artırmak için kritik bir bileşendir. Group Policy Object (GPO) kullanılarak yazıcılar Client'lara otomatik olarak dağıtılabilir, yetkilendirme ayarları yapılandırılabilir ve baskı yönetimi merkezi hale getirilebilir.

Print Server Yapılandırması, Network üzerindeki yazıcıların yönetimini kolaylaştırmak için kullanılır. Print Management Console (PMC) aracılığıyla bir Print Server oluşturularak, yazıcılar merkezi bir noktadan yönetilebilir ve Client'lara dağıtılabilir. Point and Print Restrictions ayarları ile Client'ların yazıcı sürücülerini güvenli bir şekilde yüklemesi sağlanabilir.

GPO ile Yazıcı Dağıtımı, Client'ların belirli yazıcılara otomatik olarak bağlanmasını sağlamak için kullanılır. User Configuration > Preferences > Control Panel Settings > Printers yoluyla, belirli bir OU'daki kullanıcı veya bilgisayarlara yazıcı ataması yapılabilir. GPP (Group Policy Preferences) ile dağıtılan yazıcılar, kullanıcı oturum açtığında otomatik olarak yüklenir ve yapılandırılır.

Print Spooler Servisi, baskı işlemlerinin düzgün çalışmasını sağlamak için kritik bir bileşendir. Güvenlik açısından Print Spooler servisi, yalnızca gerekli sunucular ve Client'lar üzerinde çalıştırılmalıdır. CVE-2021-34527 (PrintNightmare) gibi güvenlik açıkları nedeniyle, yetkisiz erişimlerin engellenmesi için RestrictDriverInstallationToAdministrators ve PointAndPrint NoWarningNoElevationOnInstall politikalarının doğru yapılandırılması gerekir.

Yetkilendirme ve Erişim Kontrolleri, belirli kullanıcı veya grupların yazıcıları kullanmasını kontrol etmek için Security Tab üzerinden yönetilir. Print, Manage Documents ve Manage Printers gibi izinler belirlenerek yalnızca yetkili kullanıcıların yazıcı ayarlarını değiştirmesi sağlanabilir. Aynı zamanda, baskı kuyruğundaki işlemlerin yönetilmesi için Printer Auditing etkinleştirilerek, Event ID 307 (Print Job Completed) gibi olaylar takip edilebilir.

Monitoring ve Raporlama, baskı hizmetinin kesintisiz çalışmasını sağlamak için düzenli olarak yapılmalıdır. Event Viewer, Print Management Console ve Performance Monitor (PerfMon) gibi araçlarla, baskı işlemlerindeki gecikmeler, hatalar ve güvenlik olayları izlenmelidir.

Yanlış yapılandırılmış bir Network yazıcı yönetimi, Client'ların yazıcılara erişememesine, baskı işlerinin kaybolmasına ve güvenlik açıklarına neden olabilir. Bu yüzden, yazıcı yönetimi politikaları düzenli olarak gözden geçirilmeli, gereksiz sürücüler kaldırılmalı ve Print Spooler servisi yalnızca ihtiyacı olan sistemlerde çalıştırılmalıdır.

19- Yazılım Dağıtımı ve Güncelleme Yönetimi

Active Directory Directory Services (AD DS) ortamında Yazılım Dağıtımı ve Güncelleme Yönetimi, sistemlerin güncel tutulmasını sağlarken güvenlik açıklarını en aza indirmek ve uyumluluğu garanti altına almak için kritik bir süreçtir. Merkezi yönetim mekanizmaları sayesinde, yazılımlar otomatik olarak yüklenebilir, güncellemeler zorunlu hale getirilebilir ve belirli sistemler için özel dağıtım politikaları uygulanabilir.

Group Policy ile Yazılım Dağıtımı, Client'ların belirli uygulamaları otomatik olarak yükleyebilmesini sağlamak için kullanılır. Software Installation (GPSI) politikası aracılığıyla, .msi uzantılı paketler Computer Configuration > Policies > Software Settings > Software Installation altında Client'lara dağıtılabilir. Ancak, GPSI yalnızca temel kurulumlar için uygundur ve gelişmiş dağıtım mekanizmaları gerektiren durumlarda Microsoft Endpoint Configuration Manager (MECM) veya Intune gibi çözümler tercih edilmelidir.

Windows Server Update Services (WSUS), Client'ların ve sunucuların güncelleme süreçlerini merkezi olarak yönetmeye yardımcı olur. WSUS, güncellemelerin Microsoft Update yerine yerel bir WSUS sunucusundan çekilmesini sağlar. Güncellemelerin güvenilir ve doğru bir şekilde dağıtılabilmesi için WSUS Server Targeting kullanılarak farklı Organizational Unit (OU) grupları oluşturulabilir ve her bir grup için özelleştirilmiş güncelleme politikaları uygulanabilir.

Microsoft Endpoint Configuration Manager (MECM) / SCCM, kurumsal ölçekte yazılım dağıtımı ve güncelleme yönetimi için en kapsamlı çözümlerden biridir. MECM ile Application Deployment, Patch Management, Software Inventory ve Compliance Reporting gibi süreçler merkezi olarak yönetilebilir.

Üçüncü Taraf Güncelleme Yönetimi, yalnızca Microsoft güncellemeleriyle sınırlı olmayan sistemler için kritik bir ihtiyaçtır. Adobe, Java, Chrome gibi uygulamaların otomatik olarak güncellenmesi için Patch My PC, Ivanti, ManageEngine Patch Manager gibi ek çözümler entegre edilebilir.

Yanlış yapılandırılmış yazılım dağıtımı ve güncelleme yönetimi, Client'ların kritik yamaları zamanında alamamasına, güvenlik açıklarının artmasına ve sistemlerin kararsız çalışmasına neden olabilir. Bu yüzden, güncelleme politikaları düzenli olarak gözden geçirilmeli, gereksiz yazılımlar temizlenmeli ve kritik güncellemeler için zamanında dağıtım mekanizmaları uygulanmalıdır.

20- Monitoring ve Diagnostics

Active Directory Directory Services (AD DS) ortamında Monitoring ve Diagnostics, sistemin kesintisiz çalışmasını sağlamak ve olası sorunları tespit etmek için temel bir süreçtir. Domain Controller (DC) üzerindeki kimlik doğrulama, yetkilendirme, replikasyon ve Group Policy gibi bileşenlerin sürekli izlenmesi gerekir.

Event Viewer, sistemde gerçekleşen olayları analiz etmek için kullanılır. DC üzerindeki Directory Service, System ve Security Log'ları incelenerek başarısız giriş denemeleri, hesap kilitlenmeleri, nesne değişiklikleri ve replikasyon hataları gibi olaylar takip edilir.

Performance Monitor, DC’nin kaynak kullanımını analiz ederek CPU, RAM, Disk ve Network performansını izler. LDAP oturumları, kimlik doğrulama süreçleri ve replikasyon gecikmeleri gibi metrikler değerlendirilerek olası darboğazlar belirlenir.

Replikasyon sürecinin sağlıklı çalıştığını doğrulamak için DC’ler arasındaki veri senkronizasyonu düzenli olarak kontrol edilir. Replikasyon gecikmeleri veya hatalar, kimlik doğrulama işlemlerini etkileyebileceğinden sistemde tanımlı Site ve bağlantıların yapılandırması gözden geçirilir.

DC’lerin genel sağlık durumu, sistem Log'ları ve hata kayıtları analiz edilerek değerlendirilir. Netlogon servisleri ve DNS yapılandırmaları kontrol edilerek Client'ların doğru DC’ye yönlendirildiğinden emin olunur.

Büyük ölçekli ortamlarda merkezi izleme çözümleri kullanılarak AD DS bileşenleri sürekli gözlemlenir ve belirlenen kritik olaylar için otomatik uyarılar oluşturulur.

21- High Availability ve Disaster Recovery

Active Directory Directory Services (AD DS) ortamında High Availability (yüksek erişilebilirlik), kimlik doğrulama ve yetkilendirme hizmetlerinin kesintisiz çalışmasını sağlamak için kritik bir gerekliliktir. Disaster Recovery (felaket kurtarma) ise olası donanım arızaları, veri kayıpları veya siber saldırılar karşısında AD DS’in hızlı ve güvenli bir şekilde tekrar çalışır hale getirilmesini amaçlar.

Yüksek erişilebilirlik sağlamak için birden fazla Domain Controller (DC) kullanılarak kimlik doğrulama yükü dağıtılmalıdır. AD DS’in Multi-Master Replication mimarisi sayesinde, her DC güncellemeleri replikasyon yoluyla aldığı için tek bir DC’nin devre dışı kalması sistemin tamamını etkilemez. Ancak, Flexible Single Master Operations (FSMO) Roles gibi belirli işlemler yalnızca tek bir DC üzerinden yönetildiğinden, bu rollerin alternatif DC’lere devredilmesi için uygun yapılandırmalar yapılmalıdır.

Global Catalog (GC) sunucularının yük dengesi sağlanarak ve DNS sunucularının yedekli olacak şekilde dağıtılması, Client'ların kesintisiz bir şekilde doğru DC’ye yönlendirilmesini sağlar. Site ve Subnet yapılandırması ile Client'ların en yakın DC’ye bağlanması garantilenmeli ve replikasyon süreleri optimize edilmelidir.

Felaket kurtarma stratejilerinin temelinde Düzenli Backup ve Hızlı Restore süreçleri yer alır. System State Backup, AD DS veritabanı (NTDS.dit), SYSVOL, Boot Configuration Data (BCD) ve Registry gibi kritik bileşenleri içerdiğinden, yedekleme planının düzenli olarak uygulanması gerekir. Felaket senaryolarında Authoritative Restore veya Non-Authoritative Restore yöntemleri kullanılarak sistem en kısa sürede tekrar çalışır hale getirilmelidir.

Active Directory Recycle Bin özelliği, yanlışlıkla silinen nesnelerin geri yüklenmesini kolaylaştırırken, Bare Metal Recovery (BMR) sayesinde donanım seviyesinde kurtarma gerçekleştirilebilir. Replikasyon hataları ve zaman senkronizasyonu sorunları nedeniyle veri tutarsızlıklarının önüne geçmek için, yedekleme sonrası sistemlerin doğrulama süreçleri test edilmelidir.

Yüksek erişilebilirlik ve felaket kurtarma süreçlerinin etkinliğini artırmak için belirli periyotlarla testler yapılmalı, güncellenmiş yedeklerin doğruluğu kontrol edilmeli ve kesinti senaryolarına karşı aksiyon planları hazır bulundurulmalıdır.

22- Active Directory Federation Services (AD FS)

Active Directory Federation Services (AD FS), farklı organizasyonlar veya sistemler arasında kimlik doğrulama süreçlerini güvenli bir şekilde gerçekleştirmek için kullanılan bir federasyon kimlik doğrulama çözümüdür. Geleneksel kullanıcı adı ve parola tabanlı doğrulama yöntemleri yerine, Security Assertion Markup Language (SAML), OAuth ve OpenID Connect gibi protokollerle kimlik doğrulama bilgilerini paylaşarak Single Sign-On (SSO) imkanı sunar.

AD FS, organizasyon içindeki Active Directory Directory Services (AD DS) ile entegre çalışarak, kullanıcıların birden fazla hizmete tek bir oturum açma ile erişmesini sağlar. Bu sayede Microsoft 365, Salesforce, Google Workspace gibi üçüncü taraf servisler veya farklı Domain yapıları arasında güvenli kimlik doğrulama yapılabilir.

Authentication (kimlik doğrulama) sürecinde Client, AD FS sunucusuna yönlendirilir ve kullanıcı kimliği doğrulandıktan sonra yetkilendirme token’ı oluşturularak hedef uygulamaya iletilir. Bu işlem sırasında, Claims-Based Authentication mekanizması kullanılarak, kimlik doğrulama bilgilerinin şifrelenmiş ve güvenli bir şekilde iletilmesi sağlanır.

AD FS mimarisi, Federation Server, Web Application Proxy (WAP) ve Relaying Party Trusts bileşenlerinden oluşur. Federation Server, kimlik doğrulama isteklerini işleyerek token oluştururken WAP, Internet üzerinden gelen talepleri yönlendirerek güvenli bağlantıyı sağlar. Relaying Party Trusts ise, AD FS’in güvenilir olduğu hizmet sağlayıcılarını tanımlar.

Yüksek erişilebilirlik sağlamak için, birden fazla Federation Server kullanılarak yük dengeleme mekanizmaları devreye alınmalıdır. Ayrıca, kimlik doğrulama süreçlerinde Multi-Factor Authentication (MFA) desteği ile güvenlik artırılabilir.

AD FS’in düzgün çalışabilmesi için sertifika yönetimi kritik bir öneme sahiptir. Token imzalama ve şifreleme için kullanılan sertifikalar düzenli olarak güncellenmeli ve Public Key Infrastructure (PKI) ile entegrasyonu sağlanmalıdır.

Güvenlik açısından Brute-Force saldırılarına karşı koruma sağlamak için Extranet Lockout Policy, yetkisiz erişim girişimlerini önlemek için Access Control Policy yapılandırılmalı ve kimlik doğrulama istekleri düzenli olarak izlenmelidir.

23- Bulut Hizmetleri ile Dizin Senkronizasyonu

Active Directory Directory Services (AD DS) ortamında Bulut Hizmetleri ile Dizin Senkronizasyonu, On-Premises kimlik altyapısını bulut tabanlı hizmetlerle entegre ederek tek bir kimlik yönetimi sağlar. Bu süreç, kullanıcı hesapları, grup üyelikleri ve parola senkronizasyonu gibi kimlik bilgilerini eşitleyerek hibrit kimlik yönetimini mümkün kılar.

Bu entegrasyon için en yaygın kullanılan çözüm Microsoft Entra Connect olup, On-Premises Active Directory ile Microsoft Entra ID (eski adıyla Azure Active Directory – Azure AD) arasında senkronizasyon sağlar. Kullanıcılar, hem On-Premises kaynaklara hem de Microsoft 365, Exchange Online, SharePoint Online ve diğer SaaS uygulamalarına aynı kimlik bilgileriyle erişebilir.

Senkronizasyon Yöntemleri, organizasyonun güvenlik ve erişim gereksinimlerine göre farklı seçenekler sunar. Password Hash Synchronization (PHS) yöntemi, On-Premises parolaların hash’lenmiş versiyonlarını buluta eşitleyerek kimlik doğrulamayı Microsoft Entra ID üzerinden yönetmeyi sağlar. Pass-Through Authentication (PTA) ise kimlik doğrulama işlemini doğrudan On-Premises AD DS sunucularında gerçekleştirerek kullanıcı şifrelerini bulutta saklamaz. Federation with AD FS seçeneği, AD FS altyapısı ile entegrasyon sağlayarak Single Sign-On (SSO) desteği sunar.

Seamless Single Sign-On (Seamless SSO) özelliği etkinleştirildiğinde, Domain -Joined cihazlar otomatik olarak oturum açabilir ve kimlik doğrulama süreci kullanıcı müdahalesi olmadan gerçekleşir. Bu, güvenli ve kullanıcı dostu bir deneyim sunarken kimlik bilgisi paylaşımını en aza indirir.

Directory Sync Yönetimi, senkronizasyon sırasında hangi nesnelerin buluta gönderileceğini kontrol etmek için kullanılır. Filtreleme mekanizmaları sayesinde belirli Organizational Unit (OU) nesneleri veya belirli hesaplar senkronizasyon dışında bırakılabilir. Hybrid Identity yapısında, kaynaklar hem On-Premises hem de bulutta yönetildiğinden, Entra ID Connect Health aracı kullanılarak senkronizasyon durumu ve kimlik doğrulama süreçleri sürekli izlenmelidir.

Güvenlik açısından Self-Service Password Reset (SSPR), Conditional Access Policies, Multi-Factor Authentication (MFA) ve Privileged Identity Management (PIM) gibi ek koruma mekanizmaları ile bulut kimlik yönetimi güvence altına alınmalıdır. Ayrıca, Staged Rollout gibi özellikler kullanılarak geçiş süreci kontrollü bir şekilde yönetilmeli ve olası kesintilerin önüne geçilmelidir.

Bu süreçle ilgili ana bileşenler ve önemli adımlar:

1. Entra ID (Azure AD) Connect

Entra ID (Azure AD) Connect, On-Premises Active Directory Directory Services (AD DS) ile Microsoft Entra ID arasında kimlik senkronizasyonu sağlayan bir entegrasyon aracıdır. Kullanıcı hesapları, grup üyelikleri, parolalar ve diğer dizin nesneleri, belirlenen senkronizasyon kurallarına göre buluta aktarılır. Bu süreç, şirket içi kimlik altyapısının bulut hizmetleriyle bütünleşmesini sağlayarak Hybrid Identity modelini oluşturur.

Kimlik doğrulama yöntemi organizasyon ihtiyaçlarına göre belirlenir. Password Hash Synchronization (PHS), kullanıcı şifrelerini hash’lenmiş ve güvenli bir şekilde Microsoft Entra ID’ye aktararak bulut üzerinden doğrulama yapmayı sağlar. Pass-Through Authentication (PTA), kimlik doğrulamayı doğrudan On-Premises AD DS üzerinden gerçekleştirerek parolaların bulutta saklanmasını engeller. Federation with AD FS ise Single Sign-On (SSO) desteğiyle kullanıcı deneyimini iyileştirir.

Seamless Single Sign-On (Seamless SSO), Domain -joined cihazların kimlik doğrulama işlemini arka planda gerçekleştirmesine olanak tanır. Hybrid Join özelliği etkinleştirilerek cihazlar hem On-Premises AD DS hem de Entra ID ile kayıtlı hale getirilebilir. Selective Synchronization mekanizması sayesinde, belirli Organizational Unit (OU) ve nesnelerin buluta aktarımı sınırlandırılabilir.

Entra ID Connect’in sağlıklı çalışabilmesi için Synchronization Service Manager üzerinden senkronizasyon süreçleri takip edilmeli, Entra ID Connect Health kullanılarak hata tespiti yapılmalı ve düzenli olarak Connector Sync Rules gözden geçirilmelidir. Yedeklilik sağlamak için Staging Mode etkinleştirilerek yedek bir sunucu hazırlanabilir.

2. Güvenlik & Uyum (Security & Compliance)

Entra ID entegrasyonu, organizasyonun kimlik güvenliğini artırırken, Security & Compliance politikalarının merkezi olarak yönetilmesini sağlar. Conditional Access Policies, kullanıcı konumu, cihaz durumu ve risk seviyesine bağlı olarak erişim izinlerini kontrol eder. Multi-Factor Authentication (MFA) entegrasyonu, hassas veriler için ek bir güvenlik katmanı ekler.

Identity Protection, riskli giriş denemelerini analiz ederek anormal aktiviteleri tespit eder. Privileged Identity Management (PIM), yüksek ayrıcalıklı hesapların kullanım süresini sınırlandırarak saldırı yüzeyini daraltır. Role-Based Access Control (RBAC) ile kullanıcı ve yönetici izinleri ayrıştırılarak en az ayrıcalık prensibi uygulanır.

Uyumluluk süreçleri, Microsoft Purview Compliance Manager aracılığıyla yönetilebilir. Log Retention Policies sayesinde, kimlik doğrulama ve erişim kayıtları uzun süre saklanabilir. Self-Service Password Reset (SSPR) gibi özellikler, kullanıcıların destek ekiplerine ihtiyaç duymadan şifrelerini yönetmesine olanak tanır.

Microsoft Defender for Identity entegrasyonu ile anormal Active Directory etkinlikleri takip edilebilir. Entra ID Sign-in Logs ve Audit Logs düzenli olarak gözden geçirilerek kimlik erişim ihlalleri tespit edilebilir.

3. Yönetim ve İzleme

Entra ID ve On-Premises AD DS ortamlarının sağlıklı çalışması için düzenli olarak yönetim ve izleme süreçleri uygulanmalıdır. Entra ID Connect Health, senkronizasyon hatalarını ve kimlik doğrulama sorunlarını tespit ederek sistem yöneticilerine detaylı analiz sunar.

Sign-in Logs, kullanıcıların giriş denemelerini analiz ederek başarısız girişleri, riskli oturum açma denemelerini ve şüpheli aktiviteleri takip etmeye yardımcı olur. Audit Logs, sistemde yapılan değişiklikleri kaydederek yönetim faaliyetlerinin izlenmesini sağlar.

Kimlik ve erişim yönetiminin etkin bir şekilde yürütülebilmesi için Access Reviews uygulanarak gereksiz veya kullanılmayan hesaplar belirlenmeli, Conditional Access Insights raporları analiz edilerek erişim politikalarının optimizasyonu sağlanmalıdır. Hybrid Identity Administrator Role kullanılarak yalnızca yetkili kişilerin Entra ID Connect ayarlarını değiştirebilmesi güvence altına alınmalıdır.

On-Premises AD DS ve Entra ID senkronizasyonu için düzenli olarak Synchronization Rules Editor incelenmeli, Synchronization Reports kontrol edilerek beklenmeyen nesne değişiklikleri tespit edilmelidir. Güvenli erişimi sağlamak için Microsoft Sentinel veya SIEM çözümleriyle anormal etkinlikler analiz edilmeli ve tehdit algılama süreçleri iyileştirilmelidir.

24- IP Address Management (IPAM)

IP Address Management (IPAM), Network üzerindeki IP adreslerinin planlanması, tahsisi ve yönetimini merkezi bir şekilde gerçekleştiren bir sistemdir. IPAM, özellikle büyük ölçekli Netrwork'lerde Dynamic Host Configuration Protocol (DHCP) ve Domain Name System (DNS) ile entegre çalışarak adresleme süreçlerini otomatikleştirir ve IP çakışmalarını önler.

Geleneksel manuel IP yönetimi, büyük ölçekli sistemlerde verimsiz ve hataya açık olduğundan, IPAM çözümü kullanılarak tüm IP altyapısının sistematik bir şekilde takip edilmesi sağlanır. IPAM, IPv4 ve IPv6 adres bloklarını yöneterek, hangi cihazların hangi IP adreslerini kullandığını anlık olarak takip edebilir.

DHCP ve DNS Entegrasyonu, IPAM’in en kritik bileşenlerinden biridir. DHCP sunucularından alınan bilgiler doğrultusunda, atanmış IP adresleri ve bunlara bağlı Client'lar takip edilir. DNS kayıtlarıyla entegre çalışarak, hangi IP adresinin hangi cihaz veya kullanıcıya ait olduğu sürekli güncel tutulur. Bu entegrasyon sayesinde, dinamik olarak değişen adresleme yapılarında bile erişim denetimi ve izlenebilirlik artırılmış olur.

IP Adresi Kullanım Takibi, ağda kullanılan IP adreslerinin gerçek zamanlı olarak izlenmesini sağlar. Hangi Subnet'te ne kadar boş adres olduğu, hangi cihazların hangi IP’yi kullandığı, belirli bir IP’nin ne zaman tahsis edildiği gibi bilgiler IPAM üzerinden raporlanabilir. Bu, güvenlik olaylarının araştırılması ve Network kapasite planlaması için kritik bir avantaj sağlar.

IP Adresi Dağıtımı ve Yetkilendirme, yöneticilerin belirli IP aralıklarını rezerve etmesine, IP bloklarını belirli departmanlar veya bölgelere ayırmasına ve yetkisiz IP tahsislerini engellemesine yardımcı olur. Bu sayede, sistemde tanımlı olmayan cihazların ağa erişmesi önlenebilir ve güvenlik politikaları doğrultusunda IP yönetimi sağlanabilir.

Network Segmentasyonu ve Subnet Yönetimi, IPAM ile daha kolay hale gelir. Subnet'ler oluşturularak belirli servisler veya cihazlar için ayrılmış IP blokları belirlenebilir. Örneğin, bir veri merkezinde sunucular için belirlenen bir IP havuzu ile Client'lar için ayrılan IP havuzlarının birbirine karışmasını engellemek için IPAM kullanılabilir.

Uyumluluk ve Log Yönetimi, IPAM'in sunduğu en önemli avantajlardan biridir. Network üzerindeki IP hareketlerini ve değişiklikleri kaydederek, Audit Log'ları oluşturur. Bu sayede, IP bazlı güvenlik ihlalleri veya yetkisiz erişim girişimleri kolayca tespit edilebilir ve geriye dönük incelemeler yapılabilir.

IPAM, otomatik IP tahsisi, kullanım analizi, DHCP-DNS senkronizasyonu ve güvenlik yönetimi gibi özellikleri sayesinde, karmaşık Network yapılarında adresleme süreçlerinin hatasız ve verimli bir şekilde yürütülmesini sağlar. Büyük ölçekli ağlarda IP yönetimini manuel olarak yapmak yerine, IPAM kullanılarak tüm IP altyapısı merkezi bir platform üzerinden yönetilmeli ve sürekli olarak denetlenmelidir.

25- Conditional Access ve Güvenlik Politikaları

Conditional Access, kimlik doğrulama sürecini belirli koşullara bağlayarak güvenliği artıran bir erişim kontrol mekanizmasıdır. Kullanıcıların oturum açma girişimlerini cihaz türü, konum, risk seviyesi, uygulama ve Network durumu gibi faktörlere göre değerlendirerek, belirlenen kurallar çerçevesinde erişim izni verir, ek doğrulama ister veya erişimi tamamen engeller.

Conditional Access Policies, kimlik doğrulama sürecinde dinamik güvenlik kontrolleri uygulanmasını sağlar. Örneğin, belirli bir coğrafi bölgeden veya bilinmeyen bir cihazdan oturum açma girişimi tespit edildiğinde, ek güvenlik doğrulaması talep edilebilir. Bu sayede, saldırganların ele geçirdiği kimlik bilgileriyle oturum açmaları zorlaştırılır.

Multi-Factor Authentication (MFA) Entegrasyonu, Conditional Access ile sıkça birlikte kullanılır. Özellikle yüksek riskli oturum açma denemelerinde, MFA zorunlu hale getirilerek ek bir doğrulama katmanı eklenir. Kullanıcılar, yalnızca parolalarıyla değil, mobil uygulama bildirimi, SMS veya donanımsal güvenlik anahtarlarıyla da kimliklerini doğrulamak zorunda kalır.

Cihaz Tabanlı Politikalar, belirli cihaz türlerinin veya yönetilmeyen cihazların erişimini sınırlandırmak için kullanılır. Örneğin, Intune Compliance Policies ile uyumluluk kontrolleri yapılarak, yalnızca kurumsal güvenlik politikalarına uygun cihazların oturum açmasına izin verilebilir. Jailbreak yapılmış veya güncel güvenlik yamalarına sahip olmayan cihazlar, erişim dışında bırakılabilir.

Risk Tabanlı Erişim Kontrolleri, kullanıcı davranışlarını analiz ederek anormal aktiviteleri tespit eder. Microsoft Entra ID Identity Protection tarafından sağlanan risk değerlendirmesi, kimlik avı saldırıları veya hesap ele geçirme girişimlerini belirleyerek, şüpheli oturum açmaların otomatik olarak engellenmesini veya ek doğrulama adımları uygulanmasını sağlar.

Zorunlu Uygulama Politikaları, belirli kullanıcı gruplarının yalnızca güvenilir uygulamalar üzerinden erişim sağlamasına izin verebilir. Örneğin, Microsoft 365 hizmetlerine yalnızca Outlook ve Teams gibi yetkilendirilmiş uygulamalar üzerinden erişime izin verilirken, bilinmeyen üçüncü taraf uygulamalar kısıtlanabilir.

Session Duration (oturum süresi) ve Conditional Access Sign-out Policies, kullanıcıların belirli bir süre sonunda tekrar kimlik doğrulaması yapmasını gerektirebilir. Bu, özellikle paylaşılan veya halka açık cihazlarda oturum süresinin sınırlandırılması ve yetkisiz erişimlerin önlenmesi için kullanılır.

Conditional Access Audit ve İzleme, politikaların doğru çalıştığını ve güvenlik risklerini tespit etmek için düzenli olarak gözden geçirilmelidir. Sign-in Logs ve Risk Reports gibi araçlar, uygulanan kuralların etkinliğini ölçerek, gereksiz kısıtlamalar veya güvenlik açıkları tespit edilebilir.

Koşullu erişim politikaları, organizasyonun güvenlik seviyesini artırırken kullanıcı deneyimini optimize etmek için dengeli bir şekilde uygulanmalıdır. Gereksiz erişim kısıtlamaları üretkenliği olumsuz etkileyebileceğinden, her politika belirli bir risk değerlendirmesine dayanarak oluşturulmalı ve düzenli olarak güncellenmelidir.

PowerShell Üzerinden Host Name ve Statik IP adresi Yapılandırması

Bu işlemin PowerShell ile yapılması, arka planda tüm yapılandırma adımlarını hem daha hızlı hem de daha tutarlı şekilde uygulama şansı veriyor. Statik IP adresi tanımlanırken InterfaceIndex değerinin doğru alınması, ardından DNS ayarlarının da eksiksiz biçimde konfigüre edilmesi önemli. Çünkü DNS ayarları eksik kalırsa, Domain Controller olarak hizmet veren sunucu kendi ad çözümlemelerini bile tamamlayamayacak duruma gelir ki bu da tüm Domain servislerini aksatır.

Hostname değişikliği yapıldığında sistemin yeniden başlatılması gerektiği unutulmamalı. Aksi takdirde yeni isim Network'te görünmez ve özellikle Active Directory replikasyon süreçlerinde tutarsızlıklara yol açabilir. Özellikle yeni kurulumlarda bu adım tamamlandıktan sonra Primary DNS Suffix değerinin de doğru biçimde yapılandırıldığından emin olmakta fayda var.

PowerShell üzerinden yapılan bu yapılandırmanın bir diğer avantajı da, tüm adımların Log'lanabilir olması. Böylece daha sonra bir sorun çıktığında neyin ne zaman yapıldığını görmek çok daha kolay oluyor. Bu yapı, özellikle Domain Controller gibi merkezi bir rol üstlenen sistemlerde ileride yapılacak otomasyonların da temelini oluşturuyor.

En nihayetinde elle tıklayarak yapılan ayarlara göre çok daha sağlam, çok daha sürdürülebilir bir kurulum ortaya çıkıyor. Baştan düzgün planlanmış bir PowerShell konfigürasyonu, ileride yaşanabilecek Network tabanlı problemlerin de önüne geçmiş oluyor. Bu da işi baştan sıkı tutmanın ne kadar önemli olduğunu bir kez daha gösteriyor.

1- Get-WmiObject Win32_ComputerSystem komutu ile öncelikle, Server makinamın Host Name'ini kontrol ediyorum.



2- Aşağıdaki komut ile mevcut Host Name'i SRV001 olarak değiştiriyorum.

Host Name değişikliği, zorunlu bir işlem olmamakla birlikte, akılda kalıcı daha basit bir Host Name ile değiştirmek, yönetimsel açıdan daha kolay olacaktır. Değişim işlemini gerçekleştirdikten sonra, sunucumuzu bir kez Restart ederek, değişikliklerin uygulanmasını sağlıyoruz.

3- Restart işleminden sonra sunucu Host Name'inin SRV001 olarak değiştiğini görebiliyoruz.



4- Bir sonraki adım, sunucumuza sabit bir IP adresi tanımlaması yapmak olacak. Ama öncelikle, sunucumda yüklü olan Network Interface Card'ları, netsh interface ipv4 show address komutu yardımıyla görüntülüyorum. Sunucumda yüklü olan NIC, Ethernet0 isminde görünüyor.



5- Dilğerseniz, yüklü olan Network Interface Card (NIC) ismini de aşağıdaki komutla değiştirebilirsiniz.

6- Sunucumuza sabit IP adresi tanımlaması için aşağıdaki komutu kullanmamız yeterlidir. Bu komut yardımıyla Sabit IP Adresi, Subnet Mask ve Defeault Gateway tanımları yapmış oldum.

6.1- Tanımlamaları, ipconfig komutu yardımıyla da görüntüleyebilirsiniz.



7- Sabit IP adresi tanımlaması yaptıktan sonra sıra, yine sabit DNS IP adresi tanımlama işlemine geldi. Bu işlem için aşağıdaki komutu kullanmamız yeterlidir.

7.1- Tanımlamaları, ipconfig /all komutu yardımıyla da görüntüleyebilirsiniz.



8- Host Name değişikliği, statik IP adresi tanımla gibi tüm ön yapılandırma ayarlarımızı tamamladıktan sonra sıra, Active Directory Domain Services rolünü kurmaya geldi.

8.1- Active Directory Domain Services rolünü kurmadan önce, sunucumdaki yüklü olan tüm rol ve servislerin listesini aşağıdaki komut yardımıyla alıyorum.

Görüldüğü gibi, Active Directory Domain Services rolü kurulu değil.



Tüm bu ön yapılandırma hazırlıklarının tamamlanmasının ardından sıra, Windows Server 2016'da Active Directory Domain kurulum işlemine geldi. Domain Controller Kurulum işlemi iki aşamadan oluşmaktadır.

1. Active Directory Domain Services Kurulumu

1.1- Server Manager'a giriyoruz. Manage menüsünden Add roles and features seçeneğini seçerek Add Roles and Features Wizard seçeneğine basıyorum.




1.2- Installation Type alanında Role-based or fature-based installation seçeneğini seçiyor, Windows Server 2016'da Active Directory Domain Controller Kurulumu işlemine devam etmek için Next butonuna basarak ilerliyorum.



1.3- Server Selection alanında Active Directory'nin hangi Server'a kurulacağını seçtikten sonra, Server Roles alanında Active Directory Domain Services'i işaretliyorum.




1.3.1- Active Directory Domain Services'i işaretledikten sonra, servis ile ilişkili zorunlu Feature'ların yükleneceği bilgisi veriliyor. Add Features seçeneğini seçiyor, Windows Server 2016'da Active Directory Domain Controller Kurulumu işlemine devam etmek için Next butonuna basarak ilerliyorum.





NOT 2: Active Directory Primary Domain Controller kurulumu ile birlikte DNS Server kurulumu da yapılmaktadır. Server Roles alanında bu servisi seçmesek bile, Promote etme işlemi sırasında da DNS Server'ı kurup kurmayacağımızı seçebiliyoruz.

1.4- Active Directory Domain Services ve DNS Server rollerinin seçiminden sonra, Features alanında herhangi ek Feature (özellik) yüklemeyeceğim için, Windows Server 2016'da Active Directory Domain Controller Kurulumu işlemine devam etmek için Next butonuna basarak ilerliyorum.



1.5- Confirmation alanında Kurulum yapacağım rol (servis) ve Feature (özellik) bilgileri yer alıyor. Bu alanda Install botonuna basarak Active Directory Domain Services ve DNS Server rol (servis) ve Feature (özellik) yükleme işlemine başlıyorum.



1.6- Windows Server 2016'da Primary Domain Controller (PDC) kurulumu ilk aşamasında Active Directory Domain Services Kurulumu işlemi başladı.





1.7- Windows Server 2016'da Primary Domain Controller (PDC) kurulumu ilk aşamasında Active Directory Domain Services Kurulumu işlemi tamamlandı. Close butonuna basarak Wizard'ı sonlandırıyorum.

2. Active Directory Domain Controller'a Promote Etme

1.8- Active Directory Domain Services Kurulumu işlemi tamamlandıktan sonra Server Manager sağ üst köşedeki bayrak simgesi altında sarı renkte ünlem işareti çıkmaktadır. Bunun anlamı, genelde, yüklediğiniz bir servis sonrası sizden yapılandırma ayarlarını tamlamanızı bekliyor olmasıdır. Üzerine tıkladığınızda, Configuration required for Active Directory Domain Services yazılı uyarı mesajının altında Promote this server to a Domain controller seçeneğine tıklıyor, Active Directory Domain Controller kurulum işlemini başlatıyorum.



3. Promote this server to a Domain controller seçeneğine tıkladıktan sonra karşımıza Active Directory Domain Services Configuration Wizard penceresi çıkıyor. Bu Wizard üzerindeki Deployment Configuration adımında, Select the deployment operation altında Add a Domain controller to an existing Domain  

✔ Add a Domain controller to an existing Domain : Bu seçenek ile, mevcut Domain yapısı üzerine bir Additional DC kurulumu gerçekleştirilir.



✔ Add a new Domain to an existing forest: Bu seçenek ile, mevcut Domain yapısı üzerine bir Child Domain kurulumu gerçekleştirilir.



✔ Add a new forest: Bu seçenek ile, yeni bir Domain yapısı kurulumu gerçekleştirilir.



Bilgi!: Burada Domain adı belirlerken, Domain adından sonra . (Nokta) koyularak bir Suffix (son ek) belirleniz ki bu Suffix, LAN ortamında genellikle .local şekilde olabiliyor. Bu bir tercih meselesidir. . (Nokta) koyulmadan devam edilmesi halinde ise hata verecektir.



3.1.2- Yeni bir Domain ortamı kuruyor olduğum için ben, Add a new forest seçeneğini seçerek, Root Domain name alanına .com Suffix'i ile firatboyan.com Domain adını giriyor, Next butonuna basarak ilerliyorum.



4. Domain Controller Options adımında;

✅ Forest Functional Level

Active Directory ortamında Forest Functional Level, Forest içindeki tüm Domain'lerin destekleyeceği en düşük Domain Controller sürümünü belirler. Bu seviye, organizasyon genelinde kullanılabilecek Active Directory özelliklerini, güvenlik mekanizmalarını ve replikasyon yöntemlerini doğrudan etkiler. Forest içinde birden fazla Domain olabilir ve her biri kendi içerisinde farklı Domain Functional Level değerine sahip olabilir. Ancak Forest Functional Level yükseltildiğinde, o Forest içerisindeki tüm Domain'lerin en az bu seviyeye uygun olması gerekir.

Bir Forest Functional Level yükseltildiğinde, eski nesil Domain Controller'ların bu seviyeye uygun olup olmadığı kontrol edilmelidir. Örneğin, Forest Functional Level Windows Server 2016 olarak belirlenmişse, ortamda Windows Server 2012 veya daha eski bir sürümde çalışan bir Domain Controller bulunamaz. Eğer eski sürüm bir Domain Controller varsa, bu makine yükseltilmeli veya ortamdan kaldırılmalıdır. Aksi takdirde, replikasyon hataları, kimlik doğrulama problemleri ve Group Policy nesnelerinin düzgün çalışmaması gibi ciddi sorunlar ortaya çıkabilir.

Forest Functional Level yükseltme işlemi geri alınamaz. Bu yüzden değişiklik yapılmadan önce detaylı bir analiz gereklidir. Hangi Active Directory bileşenlerinin etkileneceği, mevcut Domain Controller'ların destekleyip desteklemediği ve sistemin yeni seviyeye geçişe uygun olup olmadığı önceden belirlenmelidir. Yanlış bir yükseltme, Active Directory servislerinin düzgün çalışmamasına yol açabilir.

Bu seviyenin yükseltilmesiyle birlikte, Active Directory ortamında daha gelişmiş güvenlik protokolleri, Kerberos iyileştirmeleri, gelişmiş Group Policy yönetimi ve daha verimli replikasyon mekanizmaları gibi avantajlar elde edilir. Ancak bu özelliklerin tam anlamıyla kullanılabilmesi için Forest içindeki tüm Domain'lerin de uygun şekilde yükseltilmiş olması gerekir. Eğer ortam hala eski sürümde kalıyorsa, bazı gelişmiş güvenlik politikalarından ve replikasyon verimliliğinden faydalanılamaz.

✅ Domain Functional Level

Forest içindeki her Domain , kendi Domain Functional Level değerine sahiptir ve bu seviye, belirli bir Domain içerisindeki en düşük desteklenen Domain Controller sürümünü belirler. Forest Functional Level tüm Domain'leri kapsarken, Domain Functional Level yalnızca belirli bir Domain için geçerlidir. Ancak Domain Functional Level hiçbir zaman Forest Functional Level’dan daha düşük olamaz.

Bir Domain Functional Level yükseltildiğinde, o Domain içerisindeki tüm Domain Controller'ların en az bu seviyeye yükseltilmiş olması gerekir. Örneğin, Domain Functional Level Windows Server 2016 olarak belirlenmişse, bu Domain içindeki tüm Domain Controller'ların en az Windows Server 2016 olması zorunludur. Eğer daha eski sürüm bir Domain Controller varsa, bu makinenin güncellenmesi veya ortamdan çıkarılması gerekir.

Domain Functional Level’ın belirlenmesi, Active Directory ortamında hangi özelliklerin kullanılacağını doğrudan etkiler. Windows Server 2016 seviyesine yükseltilmiş bir Domain , gelişmiş güvenlik özelliklerinden, daha hızlı replikasyon süreçlerinden ve yeni nesil Group Policy nesnelerinden faydalanabilir. Ancak bu seviyenin yükseltilmesi de geri alınamaz. Bu yüzden değişiklik yapılmadan önce, mevcut Domain Controller'ların yeni seviyeyi destekleyip desteklemediği detaylı şekilde analiz edilmelidir.

Bir Forest içinde farklı Domain'ler, birbirlerinden bağımsız olarak farklı Domain Functional Level değerlerine sahip olabilir. Ancak bu seviyelerin Forest Functional Level ile uyumlu olması zorunludur. Eğer Forest Functional Level Windows Server 2016 olarak ayarlanmışsa, o Forest içinde Windows Server 2012 veya daha düşük seviyede bir Domain Functional Level kullanılamaz.

Bu yapılandırmaların doğru şekilde planlanması, Active Directory ortamının stabilitesini ve yönetilebilirliğini doğrudan etkiler. Yanlış bir yükseltme, eski sistemlerle uyumluluk sorunlarına ve kimlik doğrulama hatalarına neden olabilir. Bu yüzden, her yükseltme öncesinde, organizasyonun tüm bileşenlerinin yeni seviyeye uygun olup olmadığı dikkatlice kontrol edilmelidir.

Bu noktaya kadar Forest Functional Level (FFL) ve Domain Functional Level (DFL) kavramlarını detaylı bir şekilde ele aldık. Şimdi, bu yapılandırmaların gerçek bir senaryoda nasıl çalıştığını görmek için aşağıdaki görsele bakalım.

Bu görsel, Parent Domain ve Child Domain ’ler arasındaki FFL ve DFL seviyelerinin nasıl belirlendiğini, hangi sürümlerin desteklendiğini ve hangi Domain Controller’ların uyumsuz olduğu durumları gösteriyor. Ortamın nasıl şekillendiğini anlamak için detayları inceleyelim.



Burada Active Directory’nin Forest Functional Level (FFL) ve Domain Functional Level (DFL) yapılandırmasının nasıl çalıştığını gösteren bir senaryo var. firatboyan.com ana Domain, yani Parent Domain olarak kurulu. Ona bağlı istanbul.firatboyan.com ve ankara.firatboyan.com olmak üzere iki alt Domain, yani Child Domain bulunuyor.

Parent Domain olan firatboyan.com için Forest Functional Level Windows Server 2016 olarak belirlenmiş. Bu seviyede, Windows Server 2016 ve Windows Server 2019 Domain Controller’lar desteklenirken, Windows Server 2012R2 desteklenmiyor. Çünkü FFL, en düşük desteklenen Domain Controller sürümünü belirlediği için bu seviyenin altında bir Domain Controller ortamda çalıştırılamaz.

Domain Functional Level da Windows Server 2016 olarak belirlenmiş. Bu durumda, Windows Server 2016 ve Windows Server 2019 Additional Domain Controller olarak eklenebilir, ancak Windows Server 2012R2 eklenemez.

Alt Domain lere bakıldığında, istanbul.firatboyan.com ve ankara.firatboyan.com için de aynı durum geçerli. Her iki alt Domain in de FFL seviyesi Windows Server 2016 ve bu seviyede sadece Windows Server 2016 ve Windows Server 2019 destekleniyor. Windows Server 2012R2 ise bu ortama dahil edilemiyor çünkü Forest seviyesi Windows Server 2016 olduğu için daha düşük bir sürüm kullanılamaz.

Burada önemli olan, DFL hiçbir zaman FFL’den daha yüksek olamaz, ancak daha düşük olabilir. Örneğin, FFL Windows Server 2016 iken, DFL Windows Server 2012R2 olarak belirlenebilirdi. Ancak bu senaryoda hem FFL hem de DFL Windows Server 2016 olarak ayarlanmış, bu yüzden daha eski sürümler sistemde çalıştırılamıyor.

Kısaca, bu yapıdaki her Domain en az Windows Server 2016 seviyesinde olmak zorunda ve eski nesil bir Domain Controller bu ortama entegre edilemiyor. Bu, ortamın daha güvenli ve modern özellikleri destekleyecek şekilde yapılandırıldığı anlamına geliyor. 

✅ Domain Name System (DNS) Server

Active Directory ortamında DNS Server, dizin hizmetlerinin doğru şekilde çalışabilmesi için kritik bir bileşendir. DNS olmadan, istemcilerin ve Domain Controller'ların birbirlerini bulmaları ve iletişim kurmaları mümkün olmaz. Active Directory ortamında DNS, sadece ad çözümleme işlevini yerine getirmekle kalmaz, aynı zamanda SRV (Service) kayıtları aracılığıyla istemcilerin en yakın Domain Controller’ı bulmasını sağlar.

Active Directory Promote işlemi sırasında DNS Server’ın kurulumu varsayılan olarak açık gelir ve bu seçeneğin kapatılması tavsiye edilmez. Eğer ortamda önceden yapılandırılmış bir DNS sunucu bulunmuyorsa, yeni bir Domain kurulurken DNS Server da yüklenmelidir. Active Directory tarafından kullanılan tüm SRV kayıtları, Domain Controller'ların DNS veritabanında tutulur ve istemciler, oturum açma gibi işlemler için bu kayıtlara başvurur.

Kurulum sırasında DNS Server seçeneği işaretli bırakılırsa, sistem otomatik olarak DNS bileşenlerini yükler ve Active Directory için gerekli olan Zone yapılandırmalarını oluşturur. Ancak, DNS Server’ın düzgün çalışabilmesi için TCP/IP ayarlarının doğru yapılandırılmış olması gerekir. Ek olarak, ortamdaki DNS Server'lar için Forwarders ayarlanarak dış dünyaya yapılan sorguların yönetimi optimize edilebilir.

✅ Global Catalog (GC)

Global Catalog, Active Directory içerisindeki nesnelerin indeks bilgilerini tutan ve organizasyon genelinde hızlı sorgulama yapılmasını sağlayan kritik bir hizmettir. Bir Domain Controller üzerinde çalışan bu bileşen, tüm Forest içerisindeki nesnelerin belirli Attribute'lerini içeren bir veri tabanı sunar. Global Catalog Server olarak yapılandırılan Domain Controller’lar, istemcilerin en kısa sürede doğru nesneye erişmesini sağlamak için Active Directory sorgularını optimize eder.

Bu indeksleme mekanizması sayesinde, istemciler herhangi bir Domain ’deki nesneleri (kullanıcılar, gruplar, bilgisayarlar) hızlı bir şekilde bulabilir. Global Catalog, Universal Group üyeliklerini de sakladığı için, bir kullanıcının oturum açma işlemi sırasında kimlik doğrulama sürecine doğrudan etki eder. Eğer bir kullanıcı bir Universal Group üyesiyse ve ortamdaki tüm Global Catalog Server'lar devre dışı kalırsa, kullanıcı oturum açamaz. Bu durumun tek istisnası Domain Admins grubuna üye olan hesaplar içindir; bu hesaplar, ortamda aktif bir Global Catalog olmasa bile oturum açabilirler.

İlk Domain Controller kurulumunda Global Catalog seçeneği zorunlu olarak etkinleştirilir ve kapatılamaz. Ancak, Additional Domain Controller kurulumlarında bu seçeneğin etkin olup olmaması yöneticiye bırakılmıştır. Yüksek erişilebilirlik sağlamak amacıyla, her Domain Controller’ın Global Catalog olarak yapılandırılması önerilir. Eğer yalnızca belirli bir Domain Controller, Global Catalog olarak atanmışsa ve bu sunucu devre dışı kalırsa, istemciler Universal Group üyeliklerini doğrulayamaz ve bazı dizin hizmetleri çalışamaz hale gelir.

✅ Read-Only Domain Controller (RODC)

RODC, yani Read-Only Domain Controller, Active Directory ortamında salt okunur veri tabanına sahip olan özel bir Domain Controller türüdür. Bu yapılandırma, genellikle güvenliğin tam olarak sağlanamadığı uzak ofisler veya fiziksel erişimin riskli olduğu lokasyonlarda kullanılır. Standart bir Domain Controller tüm dizin veritabanını yazma yetkisiyle saklarken, RODC yalnızca okuma yetkisine sahiptir ve istemciler tarafından yapılan değişiklikleri doğrudan yazamaz.

RODC’nin en büyük avantajlarından biri, parola replikasyonunu sınırlayabilmesidir. Yani, istemcilerin kimlik bilgileri bir RODC üzerinde tutulmayabilir ve sadece belirli hesapların parolaları cache olarak saklanabilir. Böylece, bir saldırgan fiziksel erişim sağlayarak RODC’yi ele geçirse bile, Domain içerisindeki tüm kullanıcıların parolalarına erişemez.

Bir RODC, istemciler için kimlik doğrulama yapabilir ancak nesnelerde değişiklik yapamaz. Eğer bir istemci bir RODC’ye yazma işlemi yapmak isterse, değişiklikler en yakın tam yetkili Domain Controller’a iletilir ve merkezi olarak işlenir. Bu sayede, güvenilmeyen bölgelerde bulunan Domain Controller'ların saldırıya uğraması durumunda, Active Directory verisinin bütünlüğü korunmuş olur.

Primary Domain Controller kurulumu sırasında RODC seçeneği devre dışıdır ve yapılandırılamaz. Ancak Additional Domain Controller kurulumu yapıldığında, yönetici tercihe bağlı olarak bir sunucuyu RODC olarak yapılandırabilir. Bu yapılandırmanın yapılması, özellikle uzak lokasyonlarda güvenlik riskini minimize etmek için önemlidir.

✅ Directory Services Restore Mode (DSRM) Password

DSRM, Active Directory’nin kurtarma işlemleri için kullanılan özel bir moddur ve DSRM Password, bu moda erişim sağlamak için kullanılan paroladır. Active Directory ortamında yaşanabilecek veri tabanı bozulmaları, replikasyon hataları veya Domain Controller’ın düzgün çalışmaması gibi durumlarda, DSRM kullanılarak sistem geri yüklenebilir.

Kurulum sırasında belirlenen bu parola, Local Administrator hesabına atanır ve sadece Active Directory servisleri durdurularak erişilebilir. Normal şartlarda bir Domain Controller’a Domain Administrator hesabı ile giriş yapılabilirken, DSRM modunda yalnızca belirlenen parola ile oturum açılabilir. Bu mod, özellikle NTDS.DIT veri tabanı üzerinde işlem yapmak gerektiğinde kullanılır.

Bu parola unutulmamalıdır çünkü Domain Controller çalışamaz hale geldiğinde ve dizin hizmetleri çöktüğünde, DSRM modu ile sistem kurtarılabilir. Yanlış veya unutulmuş bir parola, sistemin yeniden yapılandırılmasını gerektirebilir ve Active Directory veri tabanına erişimi engelleyebilir.

Tüm gerekli ayarlar yapılandırıldıktan sonra, Next butonuna basılarak işlemlere devam edilir. 



5- DNS Options adımında karşımıza, A delegation for this DNS server cannot be created because the authoritative parent zone cannot be found.. uyarısı çıkıyor.  Bu uyarı, henüz ortamda bir DNS Server olmadığı ve bu DNS Server üzerinde firatboyan.com Zone'una dış ortamdan (Internet) erişim için bir yetkilendirme yapılmadığı için çıkmaktadır ve Domain Controller kurulumu için herhangi bir problem teşkil etmemektedir. Next butonuna basarak ilerliyorum.

6- Additional Options adımındaki The NetBIOS Domain name alanında, Deployment Configuration adımında belirledimiz Domain adı ile aynı olacak şekilde Domain NetBIOS (Network Basic Input/Output System) isim bilgisi oluşmaktadır.
Domain NetBIOS Name'in kullanıldığı alanları açıklamak gerekirse,

6.1- Firewall, Mail Gateway vb kutu çözümler ve 3rd Party yazılımlar, Active Directory entegrasyonu sırasında Domain'lerin NetBios isimleri ile kimlik doğrulama yaparlar.

6.2- Domain ortamınızı kurduğumuzda, diğer Member Server'ları ya da Client PC'leri Domain'e Join etmek istediğimizde alan adı için firatboyan.com yazarsanız bu istek, DNS Server üzerinde yorumlanır ve size cevap döner. Eğer FIRATBOYAN yazarsanız, bu durumda WINS varsa, WINS üzerinde yorumlanır ve size cevap döner. WINS yoksa, Broadcast mesaj ile Domain bulunur.

6.3- Windows 7 ya da Windows 10 bir işletim sisteminde firat@firatboyan.com veya FIRATBOYAN\firat şeklinde Logon olabilirsiniz. Ancak Microsoft'a ait olmayan ürünler için UPN (Universal Principle Name) dediğimiz firat@firatboyan.com şeklindeki yazım desteklenmez ve SamAccountName dediğimiz FIRATBOYAN\firat şeklinde NetBios name kullanmanız gerekir.
 

7- Paths alanında;

✅ Database Folder

Active Directory ortamında NTDS.DIT, dizin hizmetinin merkezi veritabanı olup, Domain Controller üzerindeki tüm nesnelerin kayıtlarını saklar. Bu veritabanı; Users, Groups, Computers, Organizational Units (OU), Group Policy Objects (GPO) ve diğer Active Directory nesneleri için bir depolama alanıdır. Varsayılan olarak C:\Windows\NTDS dizini altında bulunur, ancak kurulum sırasında farklı bir disk veya dizin belirlenerek veri bütünlüğü ve performans artırılabilir.

Active Directory veritabanı Extensible Storage Engine (ESE) tabanlı bir yapıya sahiptir. Bu yapı, veritabanının transaction Log mekanizmasıyla çalışmasını ve çökme durumlarında veri kaybını en aza indirmesini sağlar. NTDS.DIT, Multi-Master Replication prensibine göre çalışır, yani her Domain Controller, Active Directory üzerindeki değişiklikleri birbirine replikasyon yoluyla iletir. Bu sayede merkezi bir yapı yerine dağıtık bir model ile tüm Domain Controller’lar güncel kalır.

Veritabanının disk üzerindeki boyutu zamanla büyüyebilir. Kullanılmayan nesneler, Tombstone süresi boyunca (varsayılan olarak 180 gün) saklanır ve belirlenen süre sonunda Garbage Collection işlemi ile temizlenir. Bu nedenle, zamanla büyüyen NTDS.DIT dosyasının optimize edilmesi için düzenli bakım gereklidir. Eseutil aracı ile veritabanı bakım işlemleri yapılabilir ve gereksiz yer kaplayan alanlar optimize edilebilir.

Veritabanı dizininin ayrı bir fiziksel diske taşınması, performansı artırmak açısından kritik bir adımdır. Özellikle büyük ölçekli ortamlarda, RAID 1 veya RAID 10 yapılandırılmış disklerde saklanması, veri güvenliği açısından büyük avantaj sağlar.

✅ Log Files Folder

Active Directory veri tabanının tutarlılığını sağlamak için kullanılan Log dosyaları, NTDS.DIT içerisindeki değişiklikleri kaydederek sistem çökmesi veya güç kaybı gibi durumlarda veri bütünlüğünü korur. Transaction Log mekanizması sayesinde, yapılan değişiklikler önce Log dosyalarına yazılır ve daha sonra NTDS.DIT içerisine işlenir. Böylece, sistem beklenmedik bir şekilde kapanırsa veya hata alırsa, Log dosyaları kullanılarak veri kaybı en aza indirilir.

Varsayılan olarak Log dosyaları C:\Windows\NTDS dizininde saklanır. Ancak, büyük ölçekli Active Directory ortamlarında bu Log dosyalarının ayrı bir fiziksel diskte saklanması, disk erişim hızını artırarak performansın iyileştirilmesini sağlar. Log dosyaları sürekli olarak büyüdüğünden, disk alanı düzenli olarak izlenmeli ve gerekirse eski log’lar temizlenmelidir.

Log dosyaları, edb.log ve res1.log, res2.log gibi farklı dosyalardan oluşur:

👉 Edb.log: Mevcut işlemlerin kaydedildiği ana Log dosyasıdır.

👉 Edb.chk: Log dosyaları ile NTDS.DIT veritabanı arasındaki senkronizasyonu takip eden Checkpoint dosyasıdır.

👉 Res1.log, Res2.log: Sistem çökmesi veya Disk dolması gibi durumlarda kullanılmak üzere ayrılan Backup Log dosyalarıdır.

👉 Edbxxxx.log: Döngüsel olarak kullanılan eski Transaction Log dosyalarıdır.

Log dosyalarının bozulması veya Log’ların disk üzerinde dolması durumunda, Active Directory servisleri çalışmayı durdurabilir. Bu nedenle, Log dosyalarının disk alanı tüketimini izlemek ve belirli aralıklarla kontrol etmek önemlidir. Ayrıca, Circular Logging (döngüsel loglama) özelliği devreye alınarak Log dosyalarının aşırı büyümesi engellenebilir. Ancak, döngüsel loglama etkinleştirildiğinde veri kaybı riski artacağından, kritik sistemlerde önerilmez.

Active Directory veritabanının ve Log dosyalarının ayrı fiziksel disklerde tutulması, yüksek performans ve veri güvenliği sağlamak açısından en iyi uygulamalardan biridir. Eğer her ikisi aynı diskte tutulursa, özellikle yüksek kullanıcı trafiğine sahip ortamlar için I/O (Input/Output) yükü artar ve gecikmelere neden olabilir. Bu yüzden, Log dosyalarının RAID 1 veya RAID 10 konfigürasyonlu yüksek performanslı bir diskte tutulması, sistemin daha hızlı ve güvenilir çalışmasını sağlar.

✅ NETLOGON

Domain Controller'lar, kimlik doğrulama ve oturum açma işlemlerini güvenilir bir şekilde gerçekleştirmek için NETLOGON klasörünü kullanır. Bu paylaşımlı alan, kullanıcıların Logon ve Logout süreçlerinde çalıştırılması gereken Script dosyalarını saklar. Oturum açma sırasında belirli ayarların uygulanması, sürücü haritalamalarının gerçekleştirilmesi, Network yazıcılarının atanması veya belirli güvenlik politikalarının devreye alınması gibi işlemler, buradaki Script'ler aracılığıyla yönetilir.

Windows NT ile birlikte kullanılmaya başlanan NETLOGON klasörü, modern Windows Server sürümlerinde de aynı işlevi sürdürür. Ancak, içerik erişimi tamamen SYSVOL içindeki Scripts klasörüne yönlendirilmiş durumdadır. NETLOGON’a eklenen herhangi bir Script dosyası, otomatik olarak SYSVOL altında ilgili dizine yönlendirilir ve burada saklanır. Bunun sebebi, birden fazla Domain Controller bulunan ortamlarda merkezi yönetimi sağlamak ve tüm replikasyon sürecini Active Directory ile uyumlu hale getirmektir.

Replikasyon mekanizması, NETLOGON içeriğinin Active Directory ortamındaki diğer Domain Controller'lara senkronize edilmesini sağlar. Bu süreç, Distributed File System Replication (DFSR) veya daha eski ortamlarda File Replication Service (FRS) üzerinden gerçekleştirilir. DFSR kullanılıyorsa, SYSVOL replikasyonu daha etkin bir şekilde yönetilir ve veri bütünlüğü sağlanır. Eğer ortam hala FRS kullanıyorsa, eski ve verimsiz bir mekanizma ile replikasyon yapıldığı için sistemin DFSR’a geçirilmesi gereklidir.

NETLOGON'un çalışma mantığı sadece Script dosyalarını saklamaktan ibaret değildir. Kerberos ve NTLM kimlik doğrulama süreçlerinde önemli bir rol oynar ve istemcilerin doğru Domain Controller ile iletişim kurmasını sağlayan Locator servisini destekler. Özellikle büyük Active Directory ortamlarında, istemcilerin hangi Domain Controller'a yönlendirileceğini belirleyen mekanizmaların sağlıklı çalışması, NETLOGON’un doğru yapılandırılmasıyla doğrudan ilişkilidir.

Güvenlik açısından NETLOGON'un korunması ve izlenmesi büyük önem taşır. Yetkisiz değişikliklerin önlenmesi için NTFS izinleri doğru şekilde atanmalı ve SYSVOL replikasyon süreçleri düzenli olarak denetlenmelidir. Event Log’larda özellikle NETLOGON ile ilgili hatalar veya kimlik doğrulama sorunları tespit edilirse, replikasyon gecikmeleri, DNS sorunları veya Kerberos bileşenlerinde bir problem olup olmadığı detaylıca incelenmelidir.

Bu nedenle NETLOGON'un sadece bir Script dizini olmadığını, aslında Active Directory kimlik doğrulama süreçlerinin merkezinde yer aldığını unutmamak gerekir. Kurulum tamamlandıktan sonra herhangi bir kesinti yaşanmaması için replikasyon, izin yönetimi ve Log analizlerinin düzenli olarak yapılması gerekir.

✅ SYSVOL (System Volume)

Active Directory ortamında SYSVOL, tüm Domain Controller'lar tarafından paylaşılan ve Group Policy nesnelerinin (GPO) yanı sıra oturum açma ve kapatma sırasında çalıştırılacak Script dosyalarını barındıran merkezi bir klasördür. Bu klasör, dizin hizmetinin sorunsuz bir şekilde çalışmasını sağlamak için replikasyon mekanizması ile tüm Domain Controller'lara eşit olarak dağıtılır.

Her Domain Controller, SYSVOL içeriğini replikasyon yoluyla senkronize eder. Modern Windows Server sürümlerinde bu işlem Distributed File System Replication (DFSR) tarafından gerçekleştirilirken, eski sistemlerde File Replication Service (FRS) kullanılmaktadır. DFSR, FRS'e kıyasla daha güvenilir bir replikasyon yöntemi sunar, verinin sıkıştırılarak taşınmasını sağlar ve değişen veri bloklarını takip ederek gereksiz trafik oluşumunu önler. FRS kullanılan ortamlarda, replikasyon gecikmeleri, tutarsızlıklar ve performans sorunları yaşanabilir, bu nedenle ortamın DFSR’a yükseltilmesi önerilir.

SYSVOL içindeki en önemli alt klasörlerden biri Policies dizinidir. Group Policy ayarlarının XML tabanlı yapılandırma dosyaları ve ilgili script’leri burada saklanır. Bir GPO oluşturulduğunda, Active Directory içindeki Group Policy Container (GPC) nesnesi ile SYSVOL içerisindeki Policy dosyası eşleşir. Eğer replikasyon düzgün çalışmazsa, istemciler eski veya eksik Group Policy ayarlarını alabilir, bu da yönetimsel sorunlara yol açabilir.

Bir diğer kritik dizin Scripts klasörüdür. NETLOGON içinde yer alan Script dosyaları aslında doğrudan SYSVOL içindeki Scripts dizinine yönlendirilmiş durumdadır. Bu yapı sayesinde birden fazla Domain Controller’ın bulunduğu ortamlarda oturum açma işlemlerinde çalıştırılan Script’ler tutarlı kalır. Kullanıcı giriş yaptığında, Group Policy tarafından belirlenen Logon Script’leri çalıştırılarak, paylaşılan sürücülerin atanması, Network yazıcılarının belirlenmesi, güvenlik politikalarının uygulanması gibi işlemler gerçekleştirilir. SYSVOL üzerinde yapılan değişiklikler, replikasyon ile otomatik olarak tüm Domain Controller'lara yayılır ve böylece ortamın bütünlüğü korunur.

Bu klasörün korunması ve yönetilmesi büyük önem taşır. SYSVOL replikasyon hataları veya bozulmalar, Group Policy uygulamalarının başarısız olmasına ve istemcilerin yanlış yapılandırmalar almasına neden olabilir. SYSVOL replikasyon durumunu kontrol etmek için dcdiag /test:sysvolcheck ve dcdiag /test:advertising gibi komutlar kullanılarak, replikasyonun doğru çalışıp çalışmadığı düzenli olarak incelenmelidir.

SYSVOL içeriği zaman içinde büyüyebilir ve replikasyon sürelerini uzatabilir. Gereksiz veya eski GPO nesneleri temizlenmeli, hatalı replikasyon işlemleri düzeltilmeli ve yetkisiz değişiklikleri önlemek için NTFS izinleri dikkatlice yapılandırılmalıdır. Eğer replikasyon sorunu yaşanıyorsa, dfsrmig komutu ile SYSVOL replikasyonunun DFSR’a yükseltilmesi sağlanarak daha güvenli ve kararlı bir yapı elde edilebilir.

Bu nedenle SYSVOL, yalnızca bir dosya paylaşım alanı değil, aynı zamanda Active Directory ortamının yönetimini sağlayan kritik bir bileşendir. Replikasyon süreçleri doğru çalıştığında, kullanıcılar her oturum açtığında tutarlı ve güncel politikalar alır, böylece sistem yönetimi daha güvenilir hale gelir.

Bilgi: Bu Path alanları, kurulum esnasında belirlenen yollar üzerinden atanabilir ve sonrasında komut satırından değiştirilmesi mümkündür. Doğru yapılandırma ve düzenli bakım ile Active Directory yapısının kararlılığı sağlanmalıdır.

Path alanını dilediğimiz gibi yapılandırdıktan sonra, Next butonuna basarak ilerliyorum.



8- Review Options adımında yaptığım ayarların bir özeti yer alıyor. Ek olarak View script butonuna tıkladığımzda, Active Directory kurulumu için bir de PowerShell Script'i oluşmaktadır. Bu Script ile de PowerShell üzerinden Domain Controller kurulumu yapılabilmektedir. Next butonuna basarak ilerliyorum.





9- Prerequisites Check adımında, Active Directory kurulumu için gerekli olan ön gereksinimler kontrol edilmektedir. Eğer tüm ön gereksinimler sağlanırsa, Install butonuna basarak Active Directory kurulum işlemi başlatılabilir.



10- Windows Server 2016'da Active Directory Domain kurulum işlemi başladı.




11- Active Directory kurulumu tamamlandıktan sonra Server, Restart edilecektir.



12- Active Directory kurulumu tamamlandıktan sonra aşağıdaki PowerShell komutu ile Domain Controller bilgisini alıyorum.

13- Aşağıdaki PowerShell komutu ile de Primary Domain Controller bilgisi alınabilir.

Windows Server 2019 üzerinde Active Directory Domain kurulumu tamamlandığında, organizasyonun kimlik ve erişim yönetimi için merkezi bir yapı oluşturulmuş olur. Domain Controller'lar, kullanıcılardan cihazlara, uygulamalardan servis hesaplarına kadar tüm kimlik verilerini güvenli bir şekilde barındırarak, erişim politikalarının uygulanmasını sağlar.

Yapılandırma tamamlandıktan sonra, Group Policy yönetimi ile kullanıcı ve bilgisayar nesnelerine belirli kurallar atanabilir, Kerberos ile kimlik doğrulama süreçleri yürütülebilir ve DNS entegrasyonu sayesinde isim çözümleme işlemleri sorunsuz bir şekilde gerçekleştirilebilir. Active Directory Recycle Bin etkinleştirilme, yanlışlıkla silinen nesnelerin kurtarılmasını sağlarken, Global Catalog rolü organizasyon genelinde daha hızlı sorgulamalar yapılmasına olanak tanır.

Domain ortamının sağlıklı çalışması için replikasyon mekanizmasının düzenli olarak kontrol edilmesi, zaman senkronizasyonunun doğru yapılandırılması ve FSMO rollerinin ihtiyaçlara göre dağıtılması gerekir. Yüksek erişilebilirlik sağlamak adına birden fazla Domain Controller kullanılması, felaket senaryolarına karşı daha dayanıklı bir yapı oluşturulmasını sağlar.

Bu noktada, Active Directory’nin sadece kurulup bırakılacak bir bileşen olmadığı unutulmamalı. Düzenli bakım, güvenlik güncellemeleri ve Log analizleri ile sistemin stabil ve güvenli çalışması sağlanmalıdır. Kurulum tamamlandıktan sonra, yönetim süreçlerini otomatize etmek ve organizasyonun ihtiyaçlarına uygun politikalar oluşturmak en önemli adımlardan biridir.

Faydalı olması dileğiyle...