Microsoft Entra Domain Services Kurulumu (2026)

Microsoft Entra Domain Services (eski adıyla Azure Active Directory Domain Services), Azure üzerindeki sanal makineler ve geleneksel uygulamalar için Microsoft tarafından yönetilen bir Active Directory etki alanı sunar. Domain join, Group Policy, LDAP/LDAPS, Kerberos ve NTLM gibi ihtiyaçları karşılamak için Domain Controller işletim sistemi kurmanız, yama yönetmeniz veya DC altyapısının sürekliliğini kendiniz sağlamanız gerekmez. Bu makalede, hizmeti Azure üzerinde sıfırdan oluşturma ve güvenli biçimde devreye alma sürecini adım adım ele alacağım.

Güncelleme: Ekim 2026. Bu içerik gerçek bir müşteride çalıştırılmış laboratuvar kaydı değil; Microsoft Learn üzerinde belgelenmiş güncel ürün davranışları ve üretim ortamı tasarım prensipleri kullanılarak hazırlanmış teknik uygulama rehberidir. Portal ekranlarının adları ve lisans seçenekleri zamanla değişebilir.

Microsoft Entra Domain Services nedir, ne değildir?

Microsoft Entra ID, modern uygulamaların bulut kimliği, OAuth/OIDC ve koşullu erişim gibi ihtiyaçlarını karşılar. Microsoft Entra Domain Services ise özellikle eski uygulamaların ihtiyaç duyduğu klasik AD protokollerini yönetilen bir etki alanında sunar. Bu iki hizmet birbirinin alternatifi değil, farklı ihtiyaçlar için tamamlayıcı bileşenlerdir.

Yönetilen etki alanı: Microsoft DC sunucularını, yüksek erişilebilirlik altyapısını ve işletim sistemi bakımını yönetir.
Bağımsız etki alanı: Şirket içindeki AD forest yapınıza otomatik olarak ek bir Domain Controller kurulmuş olmaz.
Tek yönlü kimlik eşitlemesi: Kullanıcı ve grup verisi Microsoft Entra ID’den yönetilen etki alanına eşitlenir; yönetilen etki alanında yapılan değişiklikler Entra ID’ye geri yazılmaz.
Yönetim sınırları: Domain Admin/Enterprise Admin yetkisi verilmez; schema extension ve Domain Controller’a RDP erişimi desteklenmez.
Uygun senaryo: Azure VM üzerinde çalışan LDAP/Kerberos bağımlı eski kurumsal uygulamalar, domain join ve belirli GPO ihtiyaçları.

1. Mimariyi kurmadan önce planlayalım

Bir örnek üzerinden ilerleyelim: Azure aboneliğimizde yönetilen etki alanımız corp.contoso.com, hizmet için ayrılmış subnetimiz 10.20.1.0/24 ve uygulama sunucularımızın subneti 10.20.2.0/24 olsun. Bunlar yalnızca örnek değerlerdir; kendi DNS adınızı ve çakışmayan IP bloklarınızı planlamalısınız.

Aktif bir Azure aboneliği ve bu abonelikle ilişkilendirilmiş Microsoft Entra tenant.
Hizmet kurulumunda gereken Microsoft Entra yönetim rolleri (Application Administrator ve Groups Administrator) ile Azure tarafında Domain Services Contributor yetkisi.
Yönetilen etki alanı için ayrılmış, başka iş yüklerinin kullanılmadığı subnet ve çalışan DNS tasarımı.
Hizmetin oluşturulacağı abonelik, kaynak grubu ve bölge kararı: Bunlar sonradan taşınamayacağından başlangıçta doğru seçilmeli.
SKU, yedekleme sıklığı, kapasite ve Azure tüketim maliyeti değerlendirmesi.
Kullanıcı kimliklerinin cloud-only mi yoksa şirket içi AD’den Connect Sync ile mi geldiğinin belirlenmesi.

Önemli: Örnek alan adını kendi şirket alan adınızla değiştirmeden kullanmayın. Mevcut şirket içi etki alanınızla aynı DNS adını yanlış yerde kullanmak, VPN/peering üzerinden ad çözümlemesinde çakışma yaratabilir.

2. Yönetilen etki alanını Azure üzerinde oluşturma

Microsoft Entra yönetim merkezini açın; Microsoft Entra Domain Services hizmetini arayıp Create sihirbazını başlatın.
Basics: Subscription, Resource Group, DNS domain name, Region ve SKU değerlerini belirleyin. Kurumsal bir adlandırma standardı kullanın.
Networking: Hizmete ayrılmış VNet/subnet seçin veya oluşturun. Yönetilen etki alanı subnetine uygulama sunucularını yerleştirmeyin.
Administration: Yetkili yöneticileri AAD DC Administrators grubuyla ilişkilendirin. Bu grup Domain Admin grubuyla eşdeğer değildir.
Synchronization: Gerekiyorsa tüm kullanıcılar yerine belirli grupları kapsayan scoped synchronization seçeneğini değerlendirin.
Review + create: Ayarları ve özellikle DNS adı, subnet ve bölgeyi son kez kontrol ettikten sonra dağıtımı başlatın.

Dağıtım tamamlandığında hizmetin durumunun Running olduğunu doğrulayın. Microsoft belgelerine göre ilk kurulum yaklaşık bir saate kadar sürebilir; kullanıcı ve parola verilerinin ilk eşitlemesi ise dizinin büyüklüğüne göre çok daha uzun sürebilir. Oluşturma adımından hemen sonra kullanıcı girişi denemesinin başarısız olması tek başına hizmetin bozuk olduğunu göstermez.

3. DNS ve sanal ağ yapılandırması

Kurulumdan sonra hizmetin Overview sayfasında Microsoft tarafından sağlanan iki yönetilen Domain Controller IP adresi görüntülenir. Yönetilen etki alanında çözümleme yapması gereken sanal ağın DNS sunucuları olarak portalda görüntülenen bu adresleri yapılandırın. Sabit örnek IP adreslerini kopyalamayın.

Azure portal üzerinde VNet → DNS servers alanında Custom seçeneğiyle iki DC IP adresini girin ve kaydedin.
Bu ayarın mevcut VM’lere yansıması için ilgili VM’nin DHCP/DNS ayarlarını yenileyin veya bakım planına göre yeniden başlatın.
Peered VNet ve hibrit ağlarda yönlendirme ile DNS forwarding/conditional forwarding tasarımını ayrıca kontrol edin.
NSG ve özel UDR kuralları üzerinden Domain Services’in ihtiyaç duyduğu trafiğin engellenmediğini doğrulayın; Microsoft’un hizmet için oluşturduğu kuralları rastgele silmeyin.

Yönetim VM’sinden önce DNS, ardından protokol erişimini kontrol edin:

ipconfig /all
nslookup corp.contoso.com
Resolve-DnsName corp.contoso.com
Test-NetConnection corp.contoso.com -Port 389
Test-NetConnection corp.contoso.com -Port 636

Bu komutlarda corp.contoso.com örnek etki alanıdır. TCP 636 testi yalnızca Secure LDAP etkinleştirilmiş ve ağ erişimi izinli ise başarılı olabilir. TCP portunun erişilebilir olması sertifika güveninin veya uygulama doğrulamasının başarılı olduğu anlamına gelmez.

4. Kimlik eşitlemesi ve parola karmaları: en çok karıştırılan konu

Microsoft Entra Domain Services kullanıcıları kendiliğinden yeni parolalarla oluşturmaz. Kerberos/NTLM kimlik doğrulaması için ilgili parola karmalarının sağlanması gerekir. Bunun için cloud-only ile hibrit hesapları ayrı ele almalıyız.

Cloud-only kullanıcılar

Microsoft Entra ID içinde doğrudan oluşturulmuş mevcut kullanıcıların, yönetilen etki alanı etkinleştirildikten sonra parolalarını değiştirmeleri gerekebilir. Bu işlem, gerekli Kerberos/NTLM uyumlu parola karmalarının oluşturulmasını tetikler. Ardından eşitleme tamamlanana kadar beklenmelidir. Kurumun kimlik politikalarına uygun biçimde Self-Service Password Reset (SSPR) sürecini planlayın.

Şirket içi AD’den eşitlenen kullanıcılar

Hibrit kullanıcılar için Microsoft Entra Connect Sync tarafında Domain Services’in gerektirdiği legacy NTLM/Kerberos password hash synchronization ayarlarının yapılandırılması gerekir. Standart kullanıcı/nesne eşitlemesini görmek, gerekli parola karmalarının yönetilen etki alanına ulaştığı anlamına gelmez.

Kritik sınır: Microsoft Entra Cloud Sync, bu senaryoda Domain Services’in ihtiyaç duyduğu şirket içi parola karması eşitlemesi için Microsoft Entra Connect Sync’in yerine kullanılamaz. Mimariyi buna göre tasarlayın.

Eşitleme Entra ID → Managed Domain yönündedir. Yönetilen etki alanında senkronize kullanıcıların parolasını değiştirerek Entra ID’ye geri yazma beklentisi doğru değildir. Kurulum sonrası otomatik eşitlemenin tamamlandığını ve test kullanıcılarının gerçekten kimlik doğrulayabildiğini doğrulayın.

5. Windows Server 2022/2025 sanal makinesini domain’e alma

Yönetilen etki alanı çalışan, DNS ayarları doğru ve test kullanıcısının parolası senkronize edilmiş durumdayken uygulama VM’sini domain’e dahil edebiliriz. İnternete açık RDP yerine mümkünse Azure Bastion kullanın.

Windows Server sanal makinesini yönetilen etki alanına yönlendirilmiş DNS’i kullanan subnet içine kurun.
Azure Bastion ile VM’ye bağlanın.
Server Manager → Local Server → Workgroup alanından Change seçeneğine girin.
Domain alanına örneğin corp.contoso.com yazın.
Yönetilen etki alanında geçerli bir kullanıcı hesabının UPN ve parola bilgilerini girin.
Etki alanı üyeliği başarılıysa VM’yi yeniden başlatın ve domain ile oturum açmayı test edin.

Aynı işlem PowerShell ile de gerçekleştirilebilir; aşağıdaki komut makinenin domain üyeliğini değiştirdiği ve yeniden başlattığı için yalnızca doğru VM üzerinde, uygun bakım penceresinde çalıştırılmalıdır:

Add-Computer -DomainName "corp.contoso.com" -Credential (Get-Credential) -Restart

Kontrol için:

(Get-CimInstance Win32_ComputerSystem) | Select-Object Name, Domain, PartOfDomain
nltest /dsgetdc:corp.contoso.com
gpresult /r

6. Yönetim yetkileri ve RSAT kurulumu

Klasik AD DS ile yönetilen etki alanı arasındaki önemli farklardan biri yetkidir. AAD DC Administrators grubundaki yöneticiler bazı Group Policy, DNS ve OU görevlerini yapabilir; ancak Microsoft’un yönettiği Domain Controller’lara RDP bağlanamaz, schema genişletemez ve Domain Admin/Enterprise Admin yetkileri alamaz.

Domain’e katılmış yönetim sunucusunda RSAT bileşenlerini kurabilirsiniz:

Get-WindowsFeature RSAT-AD-Tools,RSAT-DNS-Server
Install-WindowsFeature RSAT-AD-Tools,RSAT-DNS-Server

Bu komutlar yalnızca uygun Windows Server yönetim VM’sinde ve yönetici yetkisiyle uygulanmalıdır. ADAC, ADUC, DNS ve GPMC araçlarının çalışabilirliği hizmetin sağladığı yetki sınırları içindedir.

7. LDAPS yapılandırması ve sertifika güvenliği

LDAP sorgularında hassas verilerin korunması için mümkün olduğunda Secure LDAP (LDAPS) tercih edin. Azure portalındaki yönetilen etki alanı → Secure LDAP ekranından etkinleştirilir. Bunun için DNS adıyla eşleşen, istemciler tarafından güvenilen ve özel anahtarı içeren uygun sertifika gerekir. Sertifikanın biçimi ve parola korumasını Microsoft’un güncel gereksinimlerine göre kontrol edin.

Sertifika konu adı/SAN alanını, uygulamaların gerçekten bağlanacağı LDAPS DNS adıyla eşleştirin.
Sertifika zincirinin istemci tarafından güvenildiğini ve süre sonunu kontrol edin.
Özel anahtar içeren PFX dosyasını güvenli biçimde yönetin; parolasını metne veya otomasyon kayıtlarına gömmeyin.
Mümkünse LDAPS erişimini özel ağ/VPN üzerinden sağlayın.
Public internet üzerinden Secure LDAP seçeneğini yalnızca zorunluysa açın; TCP 636 erişimini NSG üzerinden belirli, güvenilir kaynak IP adresleriyle sınırlandırın.
Sertifika yenilemesini kesinti oluşmadan planlayın; yeni sertifika gerekiyorsa istemci güven zincirini de güncelleyin.

Bağlantıyı önce isim çözümlemesi ve TCP erişimi, sonra sertifika ve LDAP bind düzeyinde sınayın. Domain’e bağlanan test VM’sinde uygun RSAT aracı varsa ldp.exe ile SSL seçerek bağlantıyı doğrulayabilirsiniz. Sadece Test-NetConnection başarısına bakıp LDAPS yapılandırmasını tamamlandı kabul etmeyin.

8. NSG, ağ erişimi ve üretim güvenliği

Domain Services subnetinde Microsoft tarafından oluşturulan hizmet kurallarını değiştirmeden önce belgeleri kontrol edin.
Uygulama subnetleri ve peered VNet erişimini açık, test edilebilir ağ akışlarıyla tanımlayın.
İnternetten RDP/LDAP/SMB erişimini genel kural olarak açmayın; Bastion ve VPN/özel bağlantı seçeneklerini değerlendirin.
Yönetici hesaplarını asgari yetki ilkesiyle seçin; AAD DC Administrators üyeliklerini periyodik gözden geçirin.
Gereken kullanıcı/grup kapsamıyla sınırlı senkronizasyonu değerlendirin.
LDAPS sertifika süresi, yönetilen etki alanı Health uyarıları, DNS, parola eşitlemesi ve Azure maliyetini düzenli izleyin.
Geleneksel LDAP/NTLM protokollerine bağımlı uygulamalar için modern kimlik doğrulamaya geçiş planını ayrıca oluşturun.

9. En sık karşılaşılan hatalar

Domain join sırasında kullanıcı adı/parola sorulmuyor: DNS, subnet, peering, NSG ve DC bağlantısını inceleyin.
Kullanıcı doğrulanmıyor: Cloud-only hesapta parola değişikliği, hibrit hesapta Connect Sync legacy hash eşitlemesi ve eşitleme süresini kontrol edin.
LDAPS bağlantı hatası: Sertifika Subject/SAN, CA güven zinciri, DNS adı, PFX ve 636 erişimini doğrulayın.
Grup ilkesi beklenen sonucu vermiyor: Yönetilen etki alanının GPO/OU yetki modelini, bilgisayar üyeliğini ve gpresult çıktısını kontrol edin.
Uygulama erişim sorunu: Yönetilen domain’i mevcut on-prem AD forest’ınızın doğrudan bir DC’si gibi varsaymayın; uygulamanın bağımlılıklarını ve gerekirse trust tasarımını ayrıca inceleyin.

10. Üretime geçiş kontrol listesi

Abonelik, kaynak grubu, bölge ve SKU seçimleri onaylandı.
DNS adı şirket içi etki alanları ve VNet ile çakışmıyor.
Domain Services durumu Running, uyarılar kontrol edildi.
VNet DNS ayarlarında portalın verdiği iki DC IP adresi kullanılıyor.
Cloud-only veya hibrit kullanıcıların gerekli parola karmaları hazır.
Test VM domain’e alındı; kullanıcı oturumu ve Group Policy doğrulandı.
LDAPS etkinse sertifika zinciri ve uygulama bazlı bind testi başarılı.
Public LDAPS yalnızca gerekliyse açık; NSG kaynak adresleri sınırlandırılmış.
Yönetici yetkileri, izleme, maliyet ve geri dönüş/kesinti planı belgelendi.

Sonuç

Microsoft Entra Domain Services özellikle eski uygulamaları Azure’a taşırken klasik Active Directory protokollerine bağımlılığı yönetilen bir hizmetle karşılamak için güçlü bir seçenektir. Ancak şirket içi AD’nin birebir kopyası değildir. Başarılı bir dağıtımın kritik unsurları, doğru DNS ve sanal ağ tasarımı, parola karmalarının gerçekten senkronize edilmesi, LDAPS sertifika güvenliği ve yönetilen etki alanının yetki sınırlarının baştan kabul edilmesidir.

ÇözümPark’ta yayımladığım eski Azure Active Directory Domain Services nedir? makalesi kavramsal mimari ve tarihsel ürün gelişimini ele alıyor. Burada ise ayrı bir uygulama ihtiyacına odaklanarak kurulum, doğrulama ve güvenliği ön plana çıkardım.

Microsoft Learn kaynakları

Published On: 17 Ekim 2026 / Categories: Microsoft Azure / 12,1 min read /

Microsoft Entra Domain Services Kurulumu ve Güvenli Yapılandırması