Active Directory Rehberi: Mimari, Kurulum ve Yönetim

Active Directory, Windows tabanlı kurumsal altyapının kimlik omurgasıdır. Kullanıcı hesaplarını, bilgisayarları, grupları, password policy’leri ve yetkilendirmeleri tek merkezden yöneten bir dizin servisidir. Doğru kurulmuş bir AD sayesinde çalışan tek hesapla tüm kurumsal kaynaklara güvenle erişir, yönetici tek noktadan yüzlerce makineyi şekillendirir, güvenlik ekibi saldırı yüzeyini tek katmanda izler.

Bu rehber, AD’yi ilk defa kuracak sistem yöneticisinden mevcut domain’i yeni sürüme taşımak isteyen deneyimli mühendise kadar her seviyedeki okuyucu için hazırlandı. Her bölüm önce gündelik bir analoji ile kavramı yerleştirir, ardından teknik derinliğe iner.

Bu rehberdeki başlıkların gerçek bir projede nasıl bir araya geldiğini, uç noktaların WORKGROUP’tan tek bir sıkılaştırılmış domain’e taşındığı Active Directory modernizasyon vaka çalışmasında görebilirsiniz.

Bu makale BT sistem yönetimi ana hizmet sayfasının Active Directory koluna odaklanan kapsamlı bir rehberdir. Tamamlayıcı Windows Server rollerinden DNS yapılandırması ve DHCP kurulumu için ayrı rehberler yayında; File Server ve Print Server rolleri ilerleyen dönemde aynı derinlikte ele alınacaktır. Bu makalenin kapsamı yalnızca Active Directory Domain Services (AD DS) üzerindedir.

Active Directory Nedir?

Bir holding düşünün: onlarca şirketi, yüzlerce çalışanı, binlerce müşterisi, farklı lokasyonları, ortak kurumsal kimliği olan bir yapı. Bu holdingin iki vazgeçilmez birimi vardır. Birincisi insan kaynakları; kimin hangi şirkette, hangi pozisyonda, hangi yetkiyle çalıştığını tek merkezde tutar. İkincisi güvenlik kartı ve yetkilendirme sistemi; bir müdürün kendi katına girebilmesi, bir BT personelinin sunucu odasına erişebilmesi, bir stajyerin üretim alanına adım atamaması bu kartların tanımlı yetkileriyle yönetilir.

Üçüncü bir katman daha vardır; iç yönetmelik. Kimin hangi yazılımı kullanabileceği, hangi belge türünün hangi kata gideceği, hangi saatte binaya girilip çıkılacağı yazılı politikalarla belirlidir.

Active Directory, kurumsal Windows ağında tam olarak bu üç birimin dijital karşılığıdır. Kullanıcı hesapları holding insan kaynakları kayıtlarına, güvenlik grupları personel kartlarının yetki seviyelerine, Group Policy nesneleri iç yönetmeliğe denk düşer. Bir çalışan bilgisayarına oturum açarken arka planda AD’deki kaydı sorgulanır, parolası kontrol edilir, üyesi olduğu gruplar derlenir, hangi makinede hangi kısıtlamaya tabi olduğu belirlenir. Bütün bu süreç saniyeler içinde, merkezi Domain Controller sunucular tarafından yürütülür.

AD vs Workgroup: Merkezi Yönetimin Farkı

Küçük bir ofiste her bilgisayarın kendi kullanıcı hesaplarını, kendi password policy’sini, kendi paylaşım izinlerini yönettiği modele Workgroup denir. Üç kişilik bir ofis için bu gerçekten yeterlidir ve AD kurmak gereksiz bir yüktür. Peki neden belli bir noktadan sonra bütün kurumlar bundan vazgeçiyor?

Cevap bir çarpma işleminde. Workgroup’ta hesap sayısı, kullanıcı sayısı değil, kullanıcı × makine sayısıdır. Çünkü her makine kendi hesaplarını kendi tutar:

Bu tablo “merkezi yönetim daha iyidir” demiyor; belli bir büyüklükten sonra Workgroup’un fiilen yönetilemez hale geldiğini söylüyor. Aradaki fark budur.

Kırılmayı en net gösteren an ise bir çalışanın işten ayrıldığı gündür. Workgroup’ta o kişinin hesabını 20 makinede tek tek silmeniz gerekir ve asıl sorun şudur: birini atlarsanız o makine kalıcı bir açık kapı olarak kalır, üstelik hangisini atladığınızı öğrenmenin bir yolu yoktur. Active Directory’de aynı iş tek hesabın devre dışı bırakılmasıyla, saniyeler içinde ve doğrulanabilir biçimde biter. Aynı mantık binanın kapısına da uzanır: kartlı geçiş sistemi dizine bağlandığında işten ayrılanın kartı da aynı adımla kapanır.

Üçüncü kırılma denetimde yaşanır. “Bu dosyaya kim, ne zaman erişti”, “bu parolayı kim değiştirdi?” sorularının Workgroup’ta merkezi bir cevabı yoktur; kayıtlar her makinenin kendi içinde dağınık durur. KVKK uyumu, ISO denetimleri ve müşteri güvenlik soru formlarında sorulan da tam olarak bu sorulardır.

Holding analojisiyle: her binanın kendi kapıcısı olsa, kapıcılar birbirini tanımasa ve bir çalışan işten ayrıldığında haberin her binaya ayrı ayrı ulaştırılması gerekse ne olurdu? Küçük bir işletmede sorun çıkmaz. Ama bina sayısı arttıkça bir gün mutlaka birine haber ulaşmaz, ve o kapı yıllarca açık kalır.

Workgroup’ta bir çalışanın parolasını değiştirmek için her makineye ayrı ayrı girmek gerekir. AD’de tek tıkla kullanıcı kilitlenir, parola sıfırlanır veya yetki düşürülür.

Active Directory Mimarisi

AD’yi iç içe geçmiş sınırlarla tasarlanmış bir holding yapısı olarak düşünmek en hızlı yoldur. En dışta forest vardır; tüm yapının hukuki ve teknik sınırıdır. Forest’ın içinde bir veya daha fazla tree, tree’lerin içinde domain’ler, domain’lerin içinde Organizational Unit (OU) hiyerarşisi, OU’ların içinde de kullanıcı, grup ve bilgisayar nesneleri bulunur.

Domain, Tree, Forest

Domain AD’nin temel güvenlik sınırıdır; bir şirkete denk düşer. Örneğin ad.sercebilisim.com tek başına bir domain olabilir; içindeki kullanıcı, grup ve bilgisayarlar bu sınırın içinde yaşar, aynı password policy, aynı güvenlik modeline tabidir.

Tree aynı DNS ad alanını paylaşan domain’ler topluluğudur. Örneğin ad.sercebilisim.com, tr.ad.sercebilisim.com ve eu.ad.sercebilisim.com aynı tree içinde yer alan üç ayrı domain’dir. Parent ve child domain arasında otomatik güven ilişkisi (transitive trust) kurulur.

Forest mimarinin en dış sınırıdır; bir veya birden çok tree’yi kapsar. Forest tek bir schema (nesne tanım şablonu) ve tek bir global catalog paylaşır. Holding analoji ile; forest holding bütünü, tree her bir şirket grubu, domain tek tek şirketler, OU şirket içi departmanlardır.

Küçük ve orta ölçekli kurumların büyük çoğunluğu için tek forest, tek domain modeli en doğru seçimdir. Birden fazla domain açmak çoğu zaman gereksiz karmaşıklık getirir; OU hiyerarşisi ve GPO tek domain içinde bütün izolasyon ihtiyacını karşılar.

Global Catalog: Forest’in Ortak Arama Dizini

Yukarıda “forest tek bir global catalog paylaşır” dedik; bu cümle sık geçer ama ne anlama geldiği nadiren açıklanır. Global Catalog (GC), forest içindeki bütün domain’lerin nesnelerinin kısmi bir kopyasını tutan özel bir dizindir. Kurulum sihirbazında işaretlenen o kutunun arkasında duran şey budur.

Buradaki kilit kelime kısmi. GC her nesnenin her özniteliğini taşımaz; yalnızca aramada sık kullanılan alanları taşır (kullanıcı adı, e-posta, grup üyeliği gibi). Bir nesnenin tüm ayrıntısı hâlâ kendi domain’inin Domain Controller’ında durur.

Holding analojisiyle devam edelim: her şirketin kendi personel arşivi kendi binasındadır ve orada her çalışanın tam dosyası bulunur. Holding merkezinde ise bütün şirketlerin çalışanlarını kapsayan özet bir kütük vardır: kim, hangi şirkette, hangi ekipte. Birini ararken önce o kütüğe bakarsınız; ayrıntı gerekiyorsa ilgili şirketin arşivine gidersiniz.

Neden gerektiği de buradan çıkıyor:

• Çok domain’li forest’lerde arama. Sıradan bir dizin sorgusu yalnızca kendi domain’ini görür. Başka bir domain’deki kullanıcıyı bulmak GC’ye sorulmasını gerektirir; aksi halde o kullanıcı “yok” gibi görünür.
• Universal grup üyeliği. Oturum açarken kullanıcının universal grup üyelikleri kontrol edilir ve bu bilgi yalnızca GC’de tutulur. GC’ye erişilemeyen bir ortamda oturum açma gecikebilir ya da yetkiler eksik uygulanabilir.
• Exchange ve dizin tüketen uygulamalar. Adres listelerini GC üzerinden çözerler; bu yüzden Exchange bulunan ortamlarda GC yerleşimi bir performans kararıdır.

Tek domain’li ortamlarda pratikte fark hissetmezsiniz, çünkü zaten tek domain vardır ve normal dizin sorgusu her şeyi görür. Yine de ilk Domain Controller kurulurken GC işaretli gelir ve öyle bırakılmalıdır: oturum açma sırasındaki universal grup kontrolü ona bağlıdır. Birden fazla lokasyonu olan ortamlarda ise her siteye en az bir GC koymak, kullanıcıların kimlik sorgularını WAN hattına taşımamak için standart pratiktir.

Organizational Unit (OU): Kurumun İç Departman Klasörleri

OU’lar domain içinde nesneleri gruplayan klasör benzeri yapılardır; ancak klasörden çok daha güçlüdürler. Çünkü OU’ya hem Group Policy hem de yönetim yetkisi delegasyonu uygulanabilir.

İyi bir OU tasarımı iki soruya cevap verir: “Bu nesneleri birlikte nasıl yönetmek istiyorum?” ve “Bu nesnelerin üzerinde hangi policy’leri uygulayacağım?” Departman bazlı (Muhasebe, Satış, BT), lokasyon bazlı (İstanbul, Ankara, İzmir) veya karma modeller kullanılabilir. Tecrübe şunu söylüyor: her katman bir yönetim gerekçesi taşımalı. Gerekçesi olmayan bir seviye eklemek ağacı derinleştirir, GPO kalıtımını takip edilemez hale getirir ve ileride yönetim kabusuna dönüşür.

Sahada işe yarayan kalıp şudur: lokasyon ağacı tek bir Lokasyonlar OU’su altında toplanır, her lokasyonun altında nesne tipine göre Bilgisayarlar, Gruplar ve Kullanicilar ayrılır, departman kırılımı gerekiyorsa Kullanicilar altına açılır.

ad.sercebilisim.com/
  OU=Lokasyonlar/
    OU=Genel_Mudurluk/
      OU=Bilgisayarlar/
      OU=Gruplar/
      OU=Kullanicilar/
        OU=BT/
        OU=Muhasebe/
    OU=Halkali/
      OU=Bilgisayarlar/
      OU=Gruplar/
      OU=Kullanicilar/
  OU=Sunucular/
  OU=Evrensel_Gruplar/
  OU=Servis_Kullanicilari/

Departman OU’larını yalnızca ihtiyaç duyulan lokasyonda açın. Yukarıdaki örnekte Genel Müdürlük’te BT ve Muhasebe kırılımı varken Halkalı şubesinde yok; oradaki kullanıcı sayısı ayrı policy gerektirmiyorsa o katmanı açmak boş klasör üretmekten başka işe yaramaz.

Lokasyon ağacının dışında kalan üç top-level OU’ya dikkat edin. Sunucular sunucu nesnelerini istemcilerden ayırır, çünkü sunucuya uygulanan GPO seti (sıkılaştırma, audit, servis ayarları) client policy’lerden köklü biçimde farklıdır. Servis_Kullanicilari insan olmayan hesapları ayırır; bir hesabın OU’suna bakarak “bu bir insan mı, servis mi?” sorusuna anında cevap verirsiniz ve servis hesabına özel password policy hedeflemek kolaylaşır. Evrensel_Gruplar ise belirli bir lokasyona bağlı olmayan grupları toplar.

Site ve Subnet: Coğrafi Topoloji

OU mantıksal yönetim sınırıdır; Site ise fiziksel (coğrafi veya ağ) sınırdır. Farklı lokasyonlarda DC’leriniz varsa ve aralarında WAN hattı varsa AD’ye “işte İstanbul subnet’i, işte Ankara subnet’i, aralarındaki hat 20 Mbps” bilgisini vermek gerekir. Bu sayede İstanbul’daki bir kullanıcı oturum açarken İstanbul’daki DC’ye yönelir, Ankara’daki DC’ye değil. Replication trafiği de WAN’da programlı ve sıkıştırılmış bir şekilde akar.

FSMO Rolleri: Domain’deki 5 Özel Yetki

Active Directory’nin en çok yanlış anlaşılan kavramlarından biri FSMO rolleridir. “Flexible Single Master Operations” kısaltmasıyla, AD’de aynı anda yalnızca tek bir DC’de çalışabilen beş kritik rolü ifade eder. Diğer işlemler multi-master çalışır; yani herhangi bir DC üzerinde yapılan değişiklik diğerlerine replike olur. Ancak şu beş operasyon özel izolasyon gerektirir.

Holding analoji ile FSMO’ları şöyle düşünebilirsiniz: genel müdürlük vardır, bölge müdürlükleri vardır; günlük kararların çoğu yerel verilir ve sonra merkezle senkronlanır. Ancak şirket kuruluşu (schema değişikliği), personel sicil numarası üretimi (RID tahsisi), resmi zaman damgası (time source) gibi bazı işler sadece belirli merkezlerde yürütülür.

Forest Seviyesindeki Roller

Schema Master: AD nesne tanımlarının (attribute ve class tanımları) değiştirilebildiği tek DC’dir. Exchange kurulumu veya Windows Server sürüm yükseltmesi gibi işlemler schema uzantısı gerektirir.

Domain Naming Master: Forest’a yeni domain eklenmesi veya mevcut domain’in kaldırılması operasyonlarını koordine eder.

Her iki rol forest başına bir DC’dedir; normal şartlarda forest root domain’deki ilk DC’de çalışır.

Domain Seviyesindeki Roller

RID Master: Her yeni güvenlik nesnesi (kullanıcı, grup, bilgisayar) için benzersiz SID üretiminde kullanılan RID havuzunu dağıtır. Her DC bu master’dan belirli aralıklarla RID bloku alır.

PDC Emulator: En kritik FSMO rolüdür. Domain içindeki zaman senkronizasyonunun referans noktası, parola değişikliklerinin önce bildirildiği nokta ve bazı legacy client’lar için primary DC görevini üstlenir. PDC Emulator çalışmadığında Kerberos biletleri bozulabilir, hesap kilitleme olayları geç işlenebilir.

Infrastructure Master: Cross-domain referans güncellemelerini yöneten roldür. Tek domain’li forest’ta kritikliği düşüktür.

Rol Taşıma (Transfer) ve Zorla Alma (Seize)

Sağlıklı bir DC başka bir DC’ye rolü transfer edebilir. Ancak rol sahibi DC donanımsal olarak ölürse ve geri dönmeyecekse rolü başka DC’ye seize etmek gerekir. Seize operasyonu tek yönlüdür; orijinal DC bir daha ağa alınmamalıdır, yoksa USN yarışı ve replication bozulmaları yaşanır.

Hangi DC’nin hangi rolü taşıdığını bir PowerShell komutuyla listelemek mümkündür:

netdom query fsmo

Bu çıktıyı bir pano gibi yönetim dokümantasyonunda bulundurmak, kritik anlarda zaman kazandırır.

DNS ve Active Directory: Ayrılmaz İkili

Active Directory, DNS olmadan ayağa kalkmaz. Kullanıcı bilgisayarı domain’e oturum açarken DC’yi bulmak için DNS’e sorar; client’lar Kerberos için KDC’yi DNS üzerinden bulur; replication topolojisi DNS kayıtları üzerinden şekillenir. AD ile birlikte kurulan DNS rolü, bu entegrasyon için özel olarak tasarlanmıştır. Protokolün kendisiyle ilk kez tanışıyorsanız, isim çözümlemenin nasıl işlediğini ve kayıt türlerini DNS nedir rehberimizde bulabilirsiniz.

AD-Integrated DNS Zone’ları

Geleneksel DNS sunucularında zone dosyası düz metin olarak tutulur; primary ve secondary sunucular arasında zone transfer ile aktarılır. AD-integrated DNS zone’ları ise zone verisini doğrudan AD veri tabanına (ntds.dit) yazar. Bu sayede:

• Zone her DC’de otomatik replike olur, zone transfer trafiği kalkar.
• Multi-master yazım sağlanır; herhangi bir DNS sunucuda yapılan değişiklik diğerlerine akar.
• Güvenli dinamik güncelleme (secure dynamic update) devreye girer; sadece kimliği doğrulanmış makineler kendi kayıtlarını güncelleyebilir.

SRV Kayıtları ve DC Yerleştirme Mantığı

AD ayağa kaldırıldığında DNS’e otomatik olarak yüzlerce SRV kaydı yazılır. Bunlar client’ların “en yakın Domain Controller kim?”, “LDAP sunucusu nerede”, “Kerberos nereden biletleniyor?” sorularına cevap verir. Bu kayıt bulunduktan sonra biletin nasıl üretildiğini, KDC’nin akıştaki rolünü ve bilet alınamadığında hangi hata kodunun neyi gösterdiğini Kerberos nedir rehberimizde ele alıyoruz.

_ldap._tcp.dc._msdcs.ad.sercebilisim.com    SRV 0 100 389 dc01.ad.sercebilisim.com.
_kerberos._tcp.dc._msdcs.ad.sercebilisim.com SRV 0 100 88  dc01.ad.sercebilisim.com.

nslookup ile SRV kayıtlarını hızla doğrulayabilirsiniz:

nslookup -type=srv _ldap._tcp.dc._msdcs.ad.sercebilisim.com

En Sık DNS Sorunları

Sahada en çok karşılaşılan AD sorunlarının büyük kısmı aslında DNS sorunudur. Bir bilgisayarın domain’e oturum açamaması, replication’ın çalışmaması, GPO’nun uygulanmaması çoğu zaman “DC yerine ISS DNS’i (8.8.8.8) primary olarak yazılmış” hatasına dayanır.

Active Directory Kurulumu

AD kurulumu üç aşamada ilerler: Windows Server hazırlığı, AD DS rolünün yüklenmesi ve Domain Controller promotion. Kuruluma başlamadan statik IP tanımlanmalı, hostname kalıcı olarak ayarlanmalı, primary DNS 127.0.0.1 yapılmalı ve NTP senkronizasyonu doğrulanmalıdır. Kerberos 5 dakikadan fazla saat farkını tolere etmez; promotion öncesi zaman kaynağı ihmal edilmez.

Promotion tamamlandıktan sonra dcdiag /v ve repadmin /showrepl çalıştırılmadan ortam üretime verilmez. “0 fail” çıktısı görmek, DC’nin sağlıklı olduğunun temel kanıtıdır.

Ön koşul listesi, adım adım PowerShell kurulumu ve sağlık kontrol prosedürü Active Directory kurulum rehberinde ele alınmaktadır.

Kullanıcı, Grup ve Bilgisayar Yönetimi

AD kurulduktan sonra asıl iş başlar: gerçek kullanıcı, grup ve bilgisayarların içeri alınması, doğru OU’lara yerleştirilmesi, doğru gruplara üye yapılması.

OU Tasarım Prensipleri

İyi bir OU tasarımında üç ilke vardır:

1. Yönetim delegasyonu OU bazlıdır: BT ekibindeki junior mühendise “sadece Satış OU’sundaki kullanıcıların parolasını sıfırla” yetkisini vermek isterseniz, satış kullanıcıları ayrı bir OU’da toplanmalıdır.
2. GPO OU bazlı uygulanır: “Muhasebe kullanıcılarının masaüstünden USB disk engellensin” kuralı için muhasebe OU’su şarttır.
3. Default Users ve Computers konteyneri kullanılmaz: Yeni eklenen nesneler otomatik buraya düşer; ancak bu konteynerlere GPO uygulanamaz. redirusr ve redircmp komutlarıyla default konumlar taşınır.

Kullanıcı Hesapları

Her kullanıcının iki ana kimlik bilgisi vardır. UPN (User Principal Name) modern ve tercih edilen biçimdir: ilker.pehlivan@ad.sercebilisim.com. sAMAccountName eski NetBIOS tabanlı yapıdır; 20 karakter sınırı ile ipehlivan gibi kısaltmalar kullanılır. Modern uygulamalar UPN kullanır, legacy servisler sAMAccountName ile çalışabilir.

PowerShell ile toplu kullanıcı oluşturmak tek tek arayüzden girmekten çok daha hızlıdır:

$SecurePass = ConvertTo-SecureString "Serce2026!" -AsPlainText -Force
New-ADUser -Name "Ayse Demir" `
  -SamAccountName "ademir" `
  -UserPrincipalName "ayse.demir@sercebilisim.com" `
  -Path "OU=Muhasebe,OU=Kullanicilar,OU=Genel_Mudurluk,OU=Lokasyonlar,DC=ad,DC=sercebilisim,DC=com" `
  -AccountPassword $SecurePass `
  -Enabled $true

Güvenlik Grupları vs Distribution Grupları

AD gruplarının iki türü vardır: Security ve Distribution. Security grupları hem kimlik doğrulama sırasında yetki taşır hem de e-posta listesi gibi kullanılabilir. Distribution grupları ise sadece e-posta dağıtımı içindir; ACL’de yetki taşımaz. Modern ortamda neredeyse her zaman Security grubu kullanılır; Distribution grubu ihtiyacı genellikle Exchange veya Microsoft 365 tarafındaki dağıtım listeleriyle karşılanır.

Security grupları üç kapsamda (scope) açılır:

• Domain Local: Aynı domain içinde tanımlı kaynaklara yetki vermek için.
• Global: Kullanıcı ve bilgisayar gibi hesapları tek kategoride toplamak için.
• Universal: Forest genelinde erişim gerektiğinde.

Bilgisayarları Domain’e Ekleme

Windows 10 veya 11 bir bilgisayarı domain’e eklemek için sistem ayarlarından Access work or school bölümüne girilir ve “Join this device to a local Active Directory domain” seçilir. Tercih edilen yöntem ise PowerShell veya otomasyondur:

Add-Computer -DomainName "ad.sercebilisim.com" `
  -OUPath "OU=Bilgisayarlar,OU=Genel_Mudurluk,OU=Lokasyonlar,DC=ad,DC=sercebilisim,DC=com" `
  -Credential (Get-Credential) `
  -Restart

Kurumsal imaj dağıtımında MDT, WDS veya Intune kullanılıyorsa bu adım otomatikleştirilir.

Katılımın kırıldığı yerler komutta değil, komuttan önceki ön koşullardadır: DNS’in Domain Controller’ı göstermesi, saat sapmasının 5 dakikayı geçmemesi ve hostname’in katılımdan önce belirlenmiş olması. Ön koşullar, -OUPath verilmediğinde nesnenin düştüğü Computers konteynerinin neden GPO almadığı ve sık görülen katılım hataları Bilgisayarı ve sunucuyu domain’e ekleme rehberinde adım adım ele alınıyor.

Yetkilendirme: AGDLP Modeli

Microsoft’un resmi önerdiği yetkilendirme modeli AGDLP’dir: Account → Global → Domain Local → Permission.

1. A (Account): Kullanıcı hesabı.
2. G (Global Group): Aynı rolde çalışanları toplar, örneğin “Muhasebe Kullanıcıları”.
3. DL (Domain Local Group): Bir kaynak üzerindeki yetki düzeyini temsil eder, örneğin “Muhasebe Paylaşımı Okuma”.
4. P (Permission): Bu Domain Local grup üzerinden ACL’de tanımlanan gerçek izin.

Bu modele bağlı kalmak; yeni kullanıcı geldiğinde tek tek klasörlere yetki vermek yerine, kullanıcıyı doğru Global gruba eklemek demektir. Bakım maliyeti dramatik biçimde düşer.

OU tasarımından PowerShell ile toplu kullanıcı oluşturmaya, grup kapsamlarından yetki devrine kadar bu konuların adım adım işlendiği detaylı rehber Active Directory Kullanıcı, Grup ve OU Yönetimi makalesinde bulunur.

Group Policy (GPO) Temelleri

GPO, Windows ortamında kullanıcı ve bilgisayar davranışlarını merkezi olarak dayatmanın birincil yoludur. Masaüstü duvar kağıdından parola uzunluğuna, yazılım dağıtımından USB kısıtlamasına kadar yüzlerce ayar GPO ile yönetilir.

GPO Nedir, Nasıl Uygulanır?

Bir GPO, Group Policy Management Console (GPMC) üzerinden oluşturulur, ardından Site, Domain veya OU seviyesine linklenir. Uygulanma sırası LSDOU olarak kısaltılır:

1. Local Policy
2. Site
3. Domain
4. OU (parent → child)

Aynı ayar birden fazla seviyede tanımlıysa, zincirin sonundaki kazanır; yani child OU’daki GPO, domain GPO’sunu override eder. Bu sıralamayı “Enforced” ve “Block Inheritance” ayarları özelleştirir.

Sık Kullanılan GPO Ayarları

• Password Policy: Default Domain Policy içinde; minimum uzunluk, complexity, history, lockout threshold.
• Drive Mapping: Kullanıcının oturum açtığında belirli paylaşımı H: sürücüsü olarak görmesi.
• Software Restriction / AppLocker: Belirli uygulamaların çalışmasını engelleme.
• Screen Lock Timeout: 10 dakika inaktivite sonrası ekran kilitlensin.
• Printer Deployment: Belirli yazıcıları otomatik ekleme.
• Firewall Ayarları: Windows Defender Firewall kuralları merkezi yönetim.

GPO Sorunlarını Çözme

Bir kullanıcıda beklenen GPO uygulanmıyorsa önce istemci tarafında kontrol edilir:

gpresult /h C:\Temp\GPResult.html
gpresult /r
gpupdate /force

gpresult /h çok okunaklı bir HTML rapor üretir; hangi GPO’ların uygulandığını, hangilerinin filtrelendiğini gösterir. Sorun devam ederse DC üzerinde Event Viewer altındaki Group Policy loglarına bakılır.

GPO oluşturma, linkleme, security/WMI filtering ve sorun giderme adımlarının uçtan uca anlatıldığı ayrıntılı rehber için Active Directory GPO Yönetimi makalesine bakabilirsiniz.

Replication, Sites & Services

Tek DC’li ortamda replication ihtiyacı yoktur; çünkü değişiklikler tek yerde tutulur. İki veya daha fazla DC olduğu anda, aralarındaki veri senkronizasyonu kritik hale gelir.

Holding analojisiyle düşünün: her şehirdeki şube kendi sicil defterini tutar, ama hepsi genel müdürlük kaydını yansıtmak zorundadır. İstanbul şubesinde işten çıkarılan bir çalışan, Ankara şubesinin defterine de işlenmelidir; aksi halde Ankara hâlâ o çalışanı aktif görür. Replication, tam olarak bu defterler arası senkronizasyondur.

Intra-site ve Inter-site Replication

Aynı site içindeki DC’ler arasında replication intra-site olarak adlandırılır; değişiklikler genellikle 15 saniye içinde akar, sıkıştırma yapılmaz. Farklı site’lar arasındaki replication inter-site’tır; trafik sıkıştırılır, programlanmış aralıklarla akar. Bu sayede WAN hattı gereksiz yere dolmaz.

Replication topolojisi otomatik olarak KCC (Knowledge Consistency Checker) tarafından hesaplanır; her site’ın replication sorumlusu ISTG (Inter-Site Topology Generator) olan DC’dir.

Replication Sorunları Tespiti

En hızlı teşhis aracı:

repadmin /showrepl
repadmin /replsummary
dcdiag /test:replications

repadmin /replsummary çıktısında “largest delta” değeri endişe verici boyuttaysa (örneğin 2 gün), o partner ile replication takılmış demektir. Sebepler DNS, firewall, RPC port bloklanması veya tombstone süresini aşan bir DC’nin geri dönmeye çalışması olabilir.

Active Directory Güvenliği

AD saldırganların bir numaralı hedefidir; çünkü bir kere Domain Admin olan saldırgan tüm kurumu yönetir. Son yıllarda yaşanan büyük fidye saldırılarının neredeyse tamamı AD üzerinden ilerler. Kurumsal siber güvenlik disiplini ile birlikte ele alınmayan bir AD zayıftır.

Tier Modeli (Tier 0/1/2)

Microsoft’un önerdiği modelde yetkiler üç katmana ayrılır:

• Tier 0: Forest/Domain omurga sistemleri. Domain Controller, ADFS, PKI sunucuları. Sadece Tier 0 yöneticileri erişebilir.
• Tier 1: Sunucular ve servis altyapısı (uygulama sunucuları, veri tabanları).
• Tier 2: Son kullanıcı makineleri ve helpdesk.

Altın kural şudur: yüksek tier’daki hesap asla düşük tier’daki makineye oturum açmaz. Domain Admin yetkili bir hesap kullanıcı bilgisayarında oturum açarsa, o bilgisayar kompromize olduğunda Kerberos bileti çalınıp domain’e yayılır.

LAPS (Local Administrator Password Solution)

Her Windows bilgisayarında bir yerel Administrator hesabı vardır. Klasik hata tüm makinelerde aynı parolayı kullanmaktır; bir makine kompromize olduğunda saldırgan aynı parola ile tüm diğer makinelere atlayabilir (pass-the-hash). LAPS her makine için ayrı, rastgele bir parola üretir ve AD’de makine nesnesinin attribute’unda güvenli biçimde tutar. Windows LAPS, Windows Server 2025 ve Windows 11 23H2’de işletim sisteminin parçasıdır, Windows Server 2019 ve 2022’ye Nisan 2023 güncellemesiyle geldi. Kurulumunu ve izin katmanlarını LAPS kurulumu rehberinde anlattık.

Kullanıcı Kilitlenme Sorunları ve Audit Policy

“Hesabım sürekli kilitleniyor” şikayeti sahada en çok duyulan sorunlardandır. Sebep çoğu zaman eski bir cihazda (eski telefon, eski RDP oturumu, zamanlanmış görev) saklanan eski parola ile sürekli başarısız deneme olur.

Teşhis için:

1. Audit Policy’de “Logon/Logoff” ve “Account Lockout” audit’i aktif edilir.
2. Event ID 4740 (hesap kilitlendi) PDC Emulator üzerinde aranır.
3. lockoutstatus.exe aracı veya Microsoft Account Lockout Status ile hangi makineden kaynaklandığı bulunur.

Password Policy’ler ve Fine-Grained Password Policies

Default Domain Policy tek bir password policy dayatır; ancak bazı hesap grupları (örneğin servis hesapları veya yöneticiler) için farklı kurallar gerekir. Fine-Grained Password Policies (FGPP), belirli güvenlik gruplarına özel password policy uygulanmasına izin verir; Password Settings Object (PSO) nesnesi ile oluşturulur ve hedef gruba bağlanır.

Yukarıdaki Tier modeli, LAPS ve Fine-Grained Password Policy kavramlarının GPO ve PowerShell üzerinden sahada nasıl kurulduğu, break-glass hesapları ve AdminSDHolder gibi ileri konularla birlikte Active Directory Güvenlik Sıkılaştırması Rehberi makalesinde adım adım ele alınıyor.

Yedekleme ve Felaket Kurtarma

AD, kurumsal operasyonun en kritik tek bileşenidir. AD’yi kaybetmek kullanıcıların hiçbir kurumsal kaynağa erişememesi anlamına gelir.

System State Backup

Windows Server Backup ile System State yedeği, AD veri tabanını, SYSVOL’ü ve registry’yi içerir. Günlük otomatik olarak farklı bir diske alınmalı, en az haftalık bir kopyası farklı lokasyona yedeklenmelidir. Bu yedeğin kaç nüsha tutulacağı, bir kopyasının fidye yazılımına karşı değiştirilemez olup olmayacağı ve geri dönüşün nasıl test edileceği ayrı bir disiplindir; kurumsal veri yedekleme ve felaket kurtarma rehberimizde 3-2-1-1-0 kuralı ve RTO/RPO hedefleriyle birlikte ele alıyoruz.

Authoritative ve Non-authoritative Restore

Bir nesne yanlışlıkla silinmişse iki geri yükleme türü vardır:

• Non-authoritative Restore: DC’nin kendi verisini eski yedekten döndürür; replication sonrası diğer DC’ler tarafından üzerine yazılır. Yani silinen nesne geri gelmez.
• Authoritative Restore: Geri yüklenen nesne için USN artırılır; replication sırasında bu DC’nin verisi diğer DC’lere zorla dayatılır.

Kazara silinen nesnenin geri alınması için authoritative restore kullanılır; ntdsutil ile yapılır.

AD Recycle Bin

Windows Server 2008 R2 ile gelen bu özellik, silinen AD nesnelerinin tüm attribute’ları ile birlikte tombstone süresi boyunca (varsayılan 180 gün) kurtarılabilmesini sağlar. Aktif edilmesi forest-wide tek yönlü bir işlemdir:

Enable-ADOptionalFeature -Identity "Recycle Bin Feature" `
  -Scope ForestOrConfigurationSet `
  -Target "ad.sercebilisim.com"

Yeni kurulan her forest’ta ilk iş olarak aktif edilmelidir.

Hybrid Identity: Entra ID (Azure AD) Entegrasyonu

Microsoft 365, Teams, SharePoint Online gibi bulut hizmetleri Entra ID üzerinde kimlik doğrular. Birçok kurumun hedefi iç AD ile Entra ID’yi birbirine bağlamaktır; böylece çalışan tek parola ile hem iç ağ kaynaklarına hem bulut servislerine erişir.

UPN Suffix: Tek Kimlik Stratejisi

Hybrid identity’nin temel sorusu şudur: kullanıcı Windows’a hangi adresle girecek? AD domain’i ad.sercebilisim.com olduğunda varsayılan UPN ilker.pehlivan@ad.sercebilisim.com olur; bu adres mail adresiyle uyuşmaz ve iki ayrı kimlik yönetimi doğurur.

Çözüm alternatif UPN suffix yapılandırmasıdır. AD kurulumu tamamlandıktan sonra Active Directory Domains and Trusts konsolunda domain root’una sağ tıklanır, Properties açılır ve sercebilisim.com UPN suffix listesine eklenir. Ardından kullanıcıların UPN’i ilker.pehlivan@sercebilisim.com olarak ayarlanır. Bu sayede kullanıcı aynı adresle hem domain’e hem maile hem de Microsoft 365’e giriş yapar. Entra ID Connect kurulumunda bu UPN buluta aynen senkronize olur.

UPN suffix uyuşmazlığının en somut etkisi Microsoft 365 lisanslama sürecinde görülür. Entra ID Connect, on-premises’te oluşturulan kullanıcıyı buluta senkronize ederken UPN’i @sercebilisim.onmicrosoft.com formatına dönüştürür; bu durumda kullanıcı ilker.pehlivan@sercebilisim.com adresiyle değil, otomatik oluşturulan onmicrosoft adresiyle tanımlanır. Otomatik lisans atama kuralları, Exchange Online posta kutusu oluşturma ve Teams kimliği bu UPN üzerinden işlediğinden uyuşmazlık; yanlış adrese atanan lisanslar, açılmayan posta kutuları ve birbirinden kopuk giriş deneyimleri olarak geri döner.

Doğru yapılandırıldığında ise süreç tersine işler: AD’de yeni kullanıcı oluşturulduğu anda Entra ID senkronize eder, Microsoft 365 lisansı otomatik atanır, Exchange Online posta kutusu açılır ve kullanıcı ilk günden tek kimlikle her servise erişir.

Entra ID Connect ve Cloud Sync

Entra ID Connect (eski adıyla Azure AD Connect) klasik ve en yaygın araçtır; iç AD ile Entra ID arasında senkronizasyonu yürütür. Cloud Sync ise bulut tabanlı, daha hafif alternatifidir. Üç kimlik doğrulama yöntemi seçilir:

• Password Hash Sync (PHS): Parolaların hash’inin hash’i Entra ID’ye senkronlanır; en basit ve yaygın yöntem.
• Pass-through Authentication (PTA): Kimlik doğrulama iç AD’de yapılır; parolalar buluta hiç gönderilmez.
• Federation (ADFS): Geleneksel federation modeli; modern yeni kurulumlarda nadiren tercih edilir.

Active Directory Migration

Her AD bir gün migration gerektirir: eski Windows Server sürümünden yenisine taşınır, iki kurum birleşir veya şirket bölünür.

Bunu bir şirketin eski binadan yeni binaya taşınması gibi düşünebilirsiniz: önce yeni bina hazırlanır, eşyalar kademeli taşınır, eski bina en son boşaltılır. Şirketi bir gecede toptan eski binadan yeni binaya taşımak (in-place upgrade) riskli olduğu gibi, AD’de de kademeli geçiş tercih edilir.

Sürüm Yükseltme (2012 R2 → 2022)

Modern AD’de in-place upgrade önerilmez; tercih edilen yöntem yan yana yükseltmedir:

1. Yeni Windows Server 2022 makineleri kurulur ve mevcut domain’e ek DC olarak eklenir.
2. adprep /forestprep ve adprep /domainprep yeni DC ile birlikte çalıştırılır.
3. FSMO rolleri yeni DC’ye transfer edilir.
4. Eski DC’ler demote edilip kaldırılır.
5. Domain ve forest functional level’ı yeni sürüme yükseltilir.

Bu yaklaşım downtime’ı sıfıra indirir ve geri dönüş noktası bırakır.

Cross-Forest Migration

Şirket birleşmesi gibi durumlarda iki ayrı forest’ı birleştirmek gerekebilir. ADMT (Active Directory Migration Tool) kullanıcıları, grupları, bilgisayarları ve SID history’yi kaynak forest’tan hedef forest’a taşır. Büyük migration’lar çoğunlukla bir veri merkezi migration projesi ile birlikte ilerler.

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

Kullanıcı Şifre Değiştirme ve Sıfırlama

Bir kullanıcının parolasını sıfırlamanın en hızlı yolu PowerShell:

Set-ADAccountPassword -Identity "ademir" `
  -Reset `
  -NewPassword (ConvertTo-SecureString "Gecici2026!" -AsPlainText -Force)
Set-ADUser -Identity "ademir" -ChangePasswordAtLogon $true

Password policy gereği kullanıcı ilk oturumda yeni parola belirlemeye zorlanır. Kullanıcı kendi parolasını değiştirmek isterse Ctrl+Alt+Del > Change Password yolu ile yapar.

“İstenen İşlem İçin Yükseltme Gerekiyor” Hatası

GPMC veya AD Users and Computers aracında bir ayarı değiştirirken bu hatayı alıyorsanız, muhtemelen standart kullanıcı hesabıyla oturum açmışsınızdır. RSAT araçlarını “Run as administrator” ile başlatmak veya yönetici hesabına geçmek gerekir. Daha doğru çözüm, yönetim işleri için ayrı bir adm. önekli hesap ve PAW (Privileged Access Workstation) kullanmaktır.

Replication Hataları

“The target principal name is incorrect” hatası genellikle makine hesabının parolasının out-of-sync olmasından kaynaklanır. Hızlı çözüm:

Reset-ComputerMachinePassword -Server "dc01.ad.sercebilisim.com" -Credential (Get-Credential)

Replication tamamen takılmışsa ve tombstone süresi yakınsa, sorunlu DC demote edilip metadata cleanup yapılmalıdır.

Kullanıcı Hesabı Kilitlenmesi Debug

Event ID 4740 PDC Emulator üzerinde aranır. Eventin “Caller Computer Name” alanı kilitlenmeye sebep olan cihazı gösterir. Sık rastlanan kaynaklar:

1. Eski parola ile kayıtlı mobil cihaz (Exchange ActiveSync).
2. Zamanlanmış görevde kayıtlı eski hesap bilgisi.
3. Unutulmuş bir RDP oturumu.
4. Mapping’de kayıtlı eski paylaşım kimliği.

Sonuç: AD Sadece Bir Dizin Değil, Kurumun Omurga Yönetimidir

Active Directory bir teknoloji seçiminden fazlasıdır; bir kurumun kimlik, yetki ve policy disiplinidir. İyi tasarlanmış bir AD ortamı yıllar boyunca sessizce çalışır, her sabah yüzlerce çalışanın ilk işinin kimlik doğrulama olduğu görünmez bir omurga haline gelir. Kötü tasarlanmış bir AD ise her gün yeni bir yangın üretir, güvenlik ekibini uykusuz bırakır, ilk büyük saldırıda tüm kurumu birlikte devirir.

Bu rehberdeki başlıklar uzun vadeli bir yol haritasıdır. Yeni kurulan bir ortamda tek seferde hepsinin tam olgunluğa ermesi beklenmez; fakat hangi başlığı nasıl geliştireceğinizi bilmek doğru yöne hareket etmeyi kolaylaştırır. BT sistem yönetimi ana sayfasında AD’yi çevreleyen DNS, DHCP, File Server, yedekleme ve sanallaştırma katmanlarına tek bütün halinde göz atmanızı öneririz. AD’nin güvenlik tarafındaki derinliği için kurumsal siber güvenlik rehberi tamamlayıcı kaynaktır.

Bu rehberin üzerine kurulan konuları ayrı makalelerde ele aldık: dizinin hangi protokolle sorgulandığını ve 389 ile 636 arasındaki farkı LDAP nedir rehberimizde, envanter ve destek tarafındaki entegrasyonu GLPI yönetimi rehberimizde, şirket içi kimliğin bulutla birleştirilmesini ise Entra ID Connect rehberimizde anlatıyoruz. AD kuruldu; asıl iş şimdi başlıyor.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn