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ı, parola politikalarını 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 makale BT sistem yönetimi ana hizmet sayfasının Active Directory koluna odaklanan kapsamlı bir rehberdir. DNS, DHCP, File Server ve Print Server gibi tamamlayıcı Windows Server rolleri için ilerleyen dönemde aynı derinlikte ayrı rehberler yayınlanacaktı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 IT 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 parola politikasını, kendi paylaşım izinlerini yönettiği modele Workgroup denir. 3 kişilik bir ofis için bu yeterli olabilir; ancak 10 bilgisayarın üzerine çıktığınızda merkezi yönetim kaçınılmaz olur.

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 sercebilisim.local tek başına bir domain olabilir; içindeki kullanıcı, grup ve bilgisayarlar bu sınırın içinde yaşar, aynı parola politikası, aynı güvenlik modeline tabidir.

Tree aynı DNS ad alanını paylaşan domain’ler topluluğudur. Örneğin sercebilisim.local, tr.sercebilisim.local ve eu.sercebilisim.local 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.

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 politikaları uygulayacağım?” Departman bazlı (Muhasebe, Satış, IT), lokasyon bazlı (İstanbul, Ankara, İzmir) veya karma modeller kullanılabilir. Tecrübe şunu söylüyor: çok katmanlı OU ağacı ileride yönetim kabusuna dönüşür. İki veya üç seviye yeterlidir.

sercebilisim.local/
  OU=Istanbul/
    OU=Muhasebe/
    OU=Satis/
    OU=IT/
  OU=Ankara/
    OU=Muhasebe/
    OU=Satis/
  OU=ServiceAccounts/
  OU=AdminAccounts/

Servis hesapları ve yönetici hesapları için mutlaka ayrı OU açılmalıdır. Çünkü bu hesaplara uygulanacak GPO, sıradan kullanıcılardan farklıdır; örneğin yönetici hesapları için daha sıkı audit, servis hesapları için parola süresiz ayarı.

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.

AD-Integrated DNS Bölgeleri

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 bölgeleri 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.

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

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

nslookup -type=srv _ldap._tcp.dc._msdcs.sercebilisim.local

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: IT 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=Istanbul,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 "sercebilisim.local" `
  -OUPath "OU=IT,OU=Istanbul,DC=sercebilisim,DC=local" `
  -Credential (Get-Credential) `
  -Restart

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

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.

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ı

• Parola Politikası: 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.

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.

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 Server 2022 ve Windows 11 ile “Windows LAPS” yerleşik olarak gelir.

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.

Parola Politikaları ve Fine-Grained Password Policies

Default Domain Policy tek bir parola politikası 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 parola politikası uygulanmasına izin verir; Password Settings Object (PSO) nesnesi ile oluşturulur ve hedef gruba bağlanır.

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. BT sistem yönetimi ana sayfasındaki yedekleme ve olağanüstü durum kurtarma yaklaşımı ile uyumlu çalışır.

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 "sercebilisim.local"

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.

Azure AD Connect ve Cloud Sync

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.

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

Parola politikası 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.sercebilisim.local" -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 politika 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.

İleriki makalelerde bu rehberin üzerine GLPI entegrasyonu, LDAP yapılandırması, Entra ID Connect adımları ve AD-odaklı saldırı senaryolarına karşı korunma pratikleri eklenecektir. AD kuruldu; asıl iş şimdi başlıyor.

Yazan

İlker Pehlivan

Kurucu | Ağ ve Sistem Yöneticisi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.