AD DS, Entra ID, Entra Domain Services ve AD FS: Ürünleri ve sınırlarını ayırmak.

1. Core Mechanism / Temel mekanizma

Hibrit bir ortamı okurken ilk soru “kullanıcı nerede?” değil, “hangi authority hangi protokolle hangi kararı veriyor?” sorusudur. AD DS forest/domain sınırında LDAP, Kerberos, NTLM ve Group Policy sunar. Entra ID bir tenant sınırında OAuth 2.0, OpenID Connect ve SAML gibi modern protokollerle token verir. Entra Domain Services, Azure bölgesine yerleştirilen ve Microsoft tarafından yönetilen domain controller'larla legacy uygulamalara domain join, LDAP, Group Policy ve Kerberos/NTLM sağlar; Entra ID, senkronize edilen kimliklerin kaynağıdır. AD FS ise Entra ID'nin sign-in işini devrettiği ayrı bir on-premises authentication system'dir.

Arabirimler ve belirtimler

• AD DS: kuruluşun işlettiği directory service. Nesneler forest ve domain naming context'lerinde tutulur; istemciler LDAP, Kerberos ve NTLM ile konuşur, Group Policy ile yapılandırılır. Şema, replication ve DC'lerin işletimi kuruluşa aittir.
• Microsoft Entra ID: tenant sınırında çalışan cloud identity provider. Uygulamalara token verir, Conditional Access gibi cloud kontrolleri burada değerlendirilir. AD DS'nin LDAP/Kerberos/Group Policy yüzeyinin cloud kopyası değildir.
• Microsoft Entra Domain Services: benzersiz bir namespace ile oluşturulan managed domain. Microsoft, seçilen Azure region'ında bir replica set olarak iki Windows Server domain controller dağıtır ve bunları yönetir; müşterinin DC kurması, yapılandırması, patch'lemesi veya izlemesi gerekmez. Entra ID, bu managed domain'e senkronize edilen kimliklerin kaynağıdır.
• Managed domain Entra ID'den tek yönlü (one-way) senkronizasyonla beslenir. LDAP write desteği yalnız managed domain içindeki custom OU'larda oluşturulan nesneler içindir; Entra ID'den senkronize edilen kaynaklar için write desteklenmez.
• AD FS: Entra Connect ile yapılandırılabilen on-premises federation service. Federated sign-in'de Entra ID parola doğrulamasını AD FS gibi güvenilen authentication system'e devreder; AD FS farm, WAP sunucuları ve sertifikalar kuruluşun sorumluluğundadır.

Dört ürün, dört farklı authority

Bir ortam diyagramında “AD” kutusu çizmek kolaydır, ama o kutu hangi kararı veriyor sorusu cevapsız kalırsa bütün risk analizi kayar. AD DS bir dizin ve kimlik doğrulama altyapısıdır: hesap nesnesi orada yaşar, Kerberos bileti oradan çıkar, makine yapılandırması Group Policy ile oradan dağıtılır. Entra ID bir dizin gibi görünse de uygulama erişimini token ile yöneten bir identity provider'dır; AD DS'in protokol yüzeyini taklit etmez.

Entra Domain Services, bu iki ürünle aynı şey olmayan, Microsoft'un yönettiği bir managed domain'dir. Müşterinin DC dağıtmadan domain join, Group Policy, LDAP ve Kerberos/NTLM kullanabilmesini sağlar. Senkronize edilen kullanıcı ve gruplar için Entra ID kaynak authority'dir; eşitleme tek yönlüdür ve managed domain'deki değişiklikler Entra ID'ye ya da on-premises AD DS'e geri yazılmaz.

AD FS dördüncü ve en çok karıştırılan bileşendir. Federation, bir dizin değil bir güven ve doğrulamayı devretme ilişkisidir. Entra ID bir domain'i federated olarak işaretlediğinde, o domain'in kullanıcıları için sign-in doğrulamasını güvendiği authentication system'e, tipik olarak on-premises AD FS'e devreder. AD FS, federation assertion üretir; Entra ID assertion'ı doğruladıktan sonra kendi token'ını verir.

Senkronizasyon yollarını ayrı çiz: Entra ID → Domain Services yolunun dönüşü yoktur. Desteklenen SSPR parola değişiklikleri, ayrı writeback özelliği yapılandırılmışsa Entra ID’den on-premises AD DS’e gidebilir. Bu özellik managed-domain nesnelerini veya cloud’daki her değişikliği geri taşımaz.

Protokol yüzeyi ürünü belirler

Bir uygulamanın hangi ürüne ihtiyaç duyduğunu anlamak için ürün adına değil, uygulamanın konuştuğu protokole bakılır. LDAP bind, Kerberos SPN veya domain join gerektiren bir legacy uygulama, Entra ID'nin OIDC/OAuth token yüzeyini tek başına kullanarak bu gereksinimleri karşılayamaz. Microsoft Learn, modernize edilemeyen LDAP, Kerberos, NTLM, Group Policy veya domain join bağımlı uygulamaları Azure'a taşımak için Domain Services'ı lift-and-shift seçeneği olarak tarifler.

Tersi de doğrudur: modern bir SaaS uygulaması için Entra ID yeterliyken ortama Domain Services eklemek gereksiz bir AD DS protokol yüzeyi açar. Microsoft bu hizmeti genel bir on-premises AD yerine geçme çözümü değil, legacy authentication gerektiren Azure iş yükleri için geçiş kabiliyeti olarak konumlandırır.

Bu nedenle bir tasarım incelemesinde “hangi ürünü kullanıyoruz?” sorusu tek başına yetersizdir. Her iş yükü için konuşulan protokol, kararı veren authority ve nesnenin asıl kaynağı ayrı ayrı yazılmalıdır.

Yönetim sınırı güvenlik sınırıdır

Managed domain'de domain controller'lar Microsoft tarafından yönetilir; müşteri bu DC'leri yapılandırmaz, patch'lemez, izlemez. Bu, operasyonel yükü azaltırken müşterinin kendi işlettiği AD DS'tekiyle aynı yönetim ayrıcalıklarına sahip olmadığı anlamına gelir. LDAP write, managed domain içindeki custom OU'larda oluşturulan nesnelerle sınırlıdır; Entra ID'den gelen senkronize nesnelere yazılamaz.

AD FS'te ise yönetim sınırı tamamen kuruluştadır: farm sunucuları, token imzalama sertifikaları, claim rule'ları ve WAP katmanı işletilir. Federation sertifikalarının yenilenmesi ve trust'ın onarılması Microsoft Learn'de ayrı operasyonel yordamlar olarak listelenir. Bu yüzden AD FS, kullanıcı doğrulaması için kritik bir on-premises bağımlılık ve ayrı bir saldırı yüzeyidir.

Özetle her ürün için üç satır gerekir: nesneyi kim barındırıyor, kararı kim veriyor, altyapıyı kim yönetiyor. Bu üç satır farklı taraflara işaret ediyorsa, güvenlik sınırı da orada çizilir.

Durum ve veri akışı

1. Legacy bir uygulama LDAP bind veya domain join ister. Bu istek AD DS'e ya da Entra Domain Services managed domain'ine gider; Entra ID'nin OIDC/OAuth yüzeyi bu isteği karşılamaz.
2. Modern uygulama Entra token’ı ister. Buradaki federated örnekte AD FS kullanıcıyı doğrulayıp SAML assertion imzalar; Entra ID assertion’ı doğruladıktan sonra kendi token’ını verir.
3. Managed domain'deki kullanıcı, grup ve kimlik bilgileri Entra ID'den tek yönlü senkronizasyonla gelir. Hibrit ortamda on-premises AD DS verisi önce Entra ID'ye senkronize edilir, oradan managed domain'e ulaşır.
4. Managed domain içindeki custom OU'da oluşturulan bir nesne LDAP ile yazılabilir; Entra ID'den senkronize edilen bir nesne için aynı write yolu yoktur. Bu fark, nesnenin kaynağı ve bulunduğu OU birlikte kontrol edilerek okunur.

2. Exploitation / İstismar

Broken trust assumption

AD DS, Entra ID, Entra Domain Services ve AD FS’i aynı protokolleri, yönetim yetkilerini ve senkronizasyon yollarını kullanan tek bir ürün gibi görmek.

Technical prerequisites

• Envanter ve mimari diyagramları tüm kimlik bileşenlerini tek bir “AD” kutusunda toplar; authority, protokol ve yönetim sahipliği ayrı alanlar olarak yazılmaz.
• Legacy uygulamaların hangi protokolü konuştuğu belgelenmemiştir; LDAP/Kerberos bağımlılığı ile modern token akışı aynı başlıkta ele alınır.
• Federated bir domain'in kullanıcı doğrulamasının on-premises AD FS'e bağlı olduğu ve managed domain senkronizasyonunun tek yönlü olduğu risk kayıtlarında görünmez.

Exploitation mechanism / İstismar mekanizması

Entra Domain Services içindeki bir değişiklik Entra ID’ye veya on-premises AD DS’e geri akmaz. Custom OU’da yerel oluşturulmuş nesneye yapılan LDAP write, senkronize bir nesneye aynı biçimde uygulanamaz; managed domain’i düzenlemek kaynak dizini onarmaz. Ayrı yapılandırılmış password writeback ise desteklenen SSPR parola değişikliklerini Connect Sync veya Cloud Sync üzerinden on-premises AD DS’e gönderebilir. Bu, genel bir çift yönlü senkronizasyon değildir ve Domain Services bu yolda yer almaz. Yönetim sınırı da farklıdır: managed-domain DC’lerini Microsoft, AD FS farm’ını kuruluş işletir. Buradaki federated örnekte AD FS kullanıcıyı doğrulayıp SAML assertion imzalar; Entra ID assertion’ı doğrulayarak kendi token’ını verir. Farm’ın erişilebilirliği ve imzalama yapılandırması bu nedenle önemlidir; AD FS bir dizin değildir.

Devredilen doğrulama, devredilen risk

AD FS örneğinde farm kullanıcıyı doğrular ve imzalı SAML assertion üretir. Entra ID assertion’ı doğrulayıp kendi token’ını verir; bunlar ayrı kararlardır. Farm sunucuları, token-signing certificate’lar ve claim rule’lar, federation service’in neyi beyan ettiğini belirlediği için incelenir. AD FS, Entra uygulama token’ını üreten bileşen değildir.

Bu ders saldırı yürütme yöntemi öğretmez. Savunma tarafında doğru çerçeve şudur: federated bir tenant'ta AD FS farm'ı tier 0 kabul edilmeli, sertifika ve trust onarım yordamları yetkili ve izlenen süreçler olarak tanımlanmalıdır. Aynı inceleme, cloud authentication seçeneklerine geçiş planı için de yapılır.

Yanlış ürün seçimi yeni protokol yüzeyi açar

Modern bir uygulama için Entra ID yeterliyken ortama managed domain eklemek, yalnız maliyet değil saldırı yüzeyi kararıdır: LDAP, Kerberos/NTLM ve Group Policy yüzeyi Azure'da da açılmış olur. Microsoft bu hizmeti legacy bağımlılığı olan iş yükleri için geçiş kabiliyeti olarak tarif eder; cloud-native uygulamaların Entra ID'yi doğrudan kullanması önerilir.

Tersine, LDAP bind bekleyen bir uygulamayı yalnız Entra ID ile çalıştırmaya zorlamak da çoğu zaman uygulamanın zayıf bir ara katmanla sarılmasına yol açar. Her iki hatanın ortak kökü aynıdır: ürünler arasındaki protokol ve authority farkının belgelenmemiş olması.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Her kimlik bileşeni için ayrı satır tut: AD DS forest/domain, Entra tenant, varsa Entra Domain Services managed domain namespace'i ve varsa AD FS farm. Her satırda authority, protokol yüzeyi ve yönetim sahibi ayrı alan olmalıdır.
• Her domain için sign-in yönteminin managed mı federated mı olduğunu kaydet; federated ise doğrulamanın hangi on-premises sisteme devredildiği ve o sistemin sertifika yenileme takvimi ayrıca izlenmelidir.
• Managed domain kullanılıyorsa nesnelerin kaynağını ve OU'sunu ayrı kaydet: custom OU'da oluşturulan nesneler ile Entra ID'den senkronize gelen nesnelerin yazılabilirlik davranışı aynı değildir.
• Legacy uygulama envanterinde her uygulamanın konuştuğu protokolü (LDAP, Kerberos, NTLM, domain join, OIDC/OAuth/SAML) yaz; ürün seçimini bu alandan türet.
• Yapılandırılmış password writeback’i managed-domain senkronizasyonundan ayrı kaydet; kaynağı, hedefi ve desteklenen değişiklik kapsamını belirt.

Events and relevant fields

• Bir hesabın Entra ID'de görünmesi, o hesabın on-premises AD DS'te aynı ayrıcalıklara sahip olduğunu göstermez; iki tarafın yetki modeli ayrı değerlendirilir.
• Managed domain'de gözlenen bir Group Policy veya LDAP davranışı, on-premises AD DS yapılandırmasının kanıtı değildir. Managed domain ayrı bir namespace ve ayrı bir replica set'tir.
• Federated bir domain'de cloud sign-in hatası, cloud tarafındaki bir arızadan çok devredilen on-premises bileşenin erişilebilirliği veya sertifika durumuyla ilgili olabilir.
• Entra ID'den managed domain'e akışın tek yönlü olması nedeniyle, managed domain'de bir nesnenin eksik olması “silinmiş” değil “kaynakta kapsam dışı” anlamına gelebilir.

Envanteri ürün adıyla değil yetenekle yaz

Operasyon ekiplerinin en sık karşılaştığı sorun, bir olayın hangi tarafta çözüleceğinin belirsiz olmasıdır. Envanterde yalnız ürün adı varsa, bir LDAP hatası ile bir token hatası aynı ekibe aynı önceliğe düşer. Yetenek tabanlı envanter bunu çözer: her bileşen için desteklenen protokoller, nesnelerin kaynağı ve yazılabilirlik davranışı yazılır.

Bu yaklaşım bir ayrıcalık incelemesinde de işe yarar. On-premises AD DS'te geçerli olan yönetim grubu modeli managed domain'de aynı değildir; DC'ler Microsoft tarafından yönetilir. Dolayısıyla “Domain Admin denetimi yaptık” cümlesi, hangi domain'den söz edildiği belirtilmeden anlam taşımaz.

Sınırı aşan olaylarda kanıt zincirini ayır

Bir kullanıcı cloud uygulamasına giremediğinde sorun dört farklı yerde olabilir: on-premises hesap durumu, senkronizasyon kapsamı, devredilen doğrulama bileşeni veya cloud politika değerlendirmesi. Bu katmanlar ayrı kanıt kaynaklarına sahiptir ve biri diğerinin yerine geçmez.

Bu nedenle olay incelemesinde önce domain'in sign-in yöntemi, sonra nesnenin kaynağı, sonra ilgili bileşenin sağlık durumu okunur. Kanıt zinciri bu sırayla kurulduğunda, “cloud arızası” etiketiyle kapatılan olayların önemli bir kısmının aslında devredilmiş bir on-premises bağımlılık olduğu görülür.

Detection logic · KQL

SigninLogs
| where TimeGenerated > ago(7d)
| summarize attempts = count() by UserPrincipalName, ResultType, AppDisplayName
| order by attempts desc

Query assumptions

• Sorgu bir tenant’ta çalıştırılmadı. Bağlantısı verilen Microsoft SigninLogs şeması bu alanları tanımlar; kullanım öncesinde toplanan tablonun şemasını kontrol et. ResultType string’dir; bu toplama işlemi sign-in yöntemini tek başına göstermez.
• Sorgu, bir domain'in managed mı federated mı olduğunu kanıtlamaz; sign-in yöntemi authoritative Entra yapılandırma yüzeyinden okunmalıdır.
• On-premises AD DS, managed domain ve AD FS tarafındaki olaylar bu tabloda bulunmayabilir; ürün sınırını aşan korelasyon ayrı kaynak gerektirir.

False positives

• Yüksek sayıda başarısız sonuç, saldırı yerine yanlış yapılandırılmış bir istemci veya süresi dolmuş bir sertifika kaynaklı olabilir.
• Aynı UPN'in farklı uygulamalarda görünmesi ayrı kimlikler anlamına gelmez; tek kullanıcı birden çok uygulama akışında görünür.
• Negatif örnek: federated bir domain'de parola doğrulaması devredilen sistemde yapıldığından, cloud tarafındaki kayıt tek başına on-premises doğrulama davranışını açıklamaz.

Hardening

• Mimari dokümanında dört ürünü tek “AD” kutusunda birleştirme; authority, protokol ve yönetim sahipliği ayrı alanlar olarak tutulsun.
• Managed domain'i on-premises AD DS'in yedeği veya kopyası olarak konumlandırma; tek yönlü senkronizasyon nedeniyle kurtarma senaryosu ayrı tasarlanmalıdır.
• Federation kullanılıyorsa token imzalama sertifikalarının ve trust onarım yordamlarının sahibi, takvimi ve onay akışı yazılı olsun.
• Legacy uygulamalar için managed domain'i geçici bir köprü olarak planla; modernize edilen uygulamaları doğrudan Entra ID'ye taşıyarak AD DS protokol yüzeyini daralt.
• Her yeni iş yükünde “hangi protokol gerekli?” sorusunu ürün seçiminden önce yanıtla; gereksiz LDAP/Kerberos yüzeyi açma.

Örnekler üzerinde oku / Read the examples

O:SYG:SYD:(A;;RPLCLORC;;;AU)(D;;WPSDDTWDWO;;;DA)

İki yanlış kanı / Two reality checks

Sanılan: Microsoft Entra ID, Active Directory'nin bulut sürümüdür; Entra Domain Services de on-premises AD'nin bulut kopyasıdır.

Gerçekte: Hayır. Entra ID, uygulamalara token veren bir cloud identity provider'dır ve AD DS'in LDAP/Kerberos/Group Policy yüzeyini sunmaz. Entra Domain Services ise Microsoft'un yönettiği domain controller'lardan oluşan ayrı namespace'li bir managed domain'dir ve Entra ID'den tek yönlü senkronizasyonla beslenir; on-premises AD DS'in replikası ya da yedeği değildir.

Sanılan: AD FS de bir dizindir; federated ortamda kullanıcılar aslında AD FS'te tutulur.

Gerçekte: Hayır. AD FS bir federation service'tir, kimlik deposu değildir. Federated sign-in'de Entra ID parola doğrulamasını güvendiği bu ayrı authentication system'e devreder; kullanıcı nesnesi yine on-premises AD DS'te bulunur ve dizin verisi Entra ID'ye senkronizasyon yoluyla taşınır.

Kaynaklar / Sources

• Microsoft · Overview of Microsoft Entra Domain Services
  Managed domain services tanımı; replica set içinde iki yönetilen domain controller; Entra ID'nin source of authority olması; one-way synchronization; LDAP write yalnız managed domain'de oluşturulan nesneler için.
• Microsoft · Authentication for Microsoft Entra hybrid identity solutions
  Cloud authentication ve federated authentication tanımları; federated sign-in'de doğrulamanın ayrı bir güvenilen authentication system'e devredilmesi.
• Microsoft · Microsoft Entra Connect and federation
  AD FS farm kurulumu, trust onarımı, federation sertifikalarının yenilenmesi ve WAP sunucusu ekleme yordamları.
• Microsoft · Domain Services synchronization
  One-way managed-domain sync and custom OU boundary
• Microsoft · SSPR password writeback
  Separately configured Entra-to-AD DS password writeback
• Microsoft · Hybrid authentication resilience
  AD FS SAML assertion; Entra validation and token issuance
• Microsoft · SigninLogs schema
  TimeGenerated datetime; UserPrincipalName,ResultType,AppDisplayName string