- 01Microsoft Entra ID ile Windows Server Active Directory aynı ürün değildir; hybrid identity iki sistemi kontrollü kimlik yaşam döngüsüyle birlikte çalıştırır.
- 02Yeni deployment'larda Cloud Sync güçlü bir adaydır; ancak device sync ve bazı gelişmiş hybrid senaryolarda Connect Sync hâlâ gerekli olabilir.
- 03Password Hash Synchronization çoğu organizasyon için daha sade ve dayanıklı cloud authentication modeli sağlar; PTA on-prem authentication bağımlılığı gerektirir.
- 04UPN, source anchor, duplicate attributes ve mevcut cloud-only hesaplar synchronization açılmadan önce pilotta doğrulanmalıdır.
- 05Active Directory decommission kararı Group Policy, LDAP, Kerberos, service account ve domain-joined cihaz bağımlılıkları çıkarıldıktan sonra verilmelidir.
Kısaca
Microsoft Entra ID ile şirket içi Active Directory birlikte kullanılabilir; ancak bu iki sistem aynı şey değildir. On-premises Active Directory klasik domain, Group Policy, Kerberos/NTLM ve bilgisayar hesabı modelini taşırken, Microsoft Entra ID cloud identity ve access management katmanıdır. Hibrit kimlik mimarisinin amacı kullanıcıları iki kez yönetmek değil, doğru kullanıcı ve grup nesnelerini kontrollü biçimde senkronize edip cloud ve on-prem erişimi tek kimlik yaşam döngüsüne bağlamaktır.
Dynamis Teknoloji'de hibrit kimlik tasarımını araç seçiminden önce şu sırayla ele alıyoruz:
- hangi kullanıcılar senkronize olacak?
- kaç forest/domain var?
- cihazlar on-prem AD'ye mi bağlı, Entra'ya mı katılacak?
- hangi uygulamalar LDAP/Kerberos bağımlı?
- parola doğrulama nerede yapılacak?
- MFA ve Conditional Access nasıl uygulanacak?
- servis hesapları ve privileged kullanıcılar nasıl ayrılacak?
Entra ID ile Active Directory arasındaki fark
Windows Server Active Directory tipik olarak şunları sağlar:
- domain join
- Group Policy
- Kerberos
- NTLM
- LDAP
- computer account
- OU
- domain/forest trust
Microsoft Entra ID ise:
- cloud authentication
- Microsoft 365
- SaaS SSO
- OAuth/OpenID Connect/SAML
- MFA
- Conditional Access
- device identity
- cloud application access
alanlarında kullanılır.
Bu nedenle Entra ID, klasik Active Directory'nin yalnızca yeni adı değildir.
Hibrit kimlik nedir?
Hibrit kimlik, aynı kullanıcı kimliğinin on-premises Active Directory ve Microsoft Entra ID tarafında kontrollü biçimde temsil edilmesidir.
Örnek:
- kullanıcı on-prem AD'de oluşturulur
- belirli attribute'lar Entra ID'ye senkronize edilir
- kullanıcı Microsoft 365'e aynı kimlikle erişir
- şirket içi dosya sunucusuna AD üzerinden erişir
- cloud uygulamalarında MFA/Conditional Access uygulanır
Bu modelde source of authority tasarımı önemlidir.
Source of authority neden önemlidir?
Bir kullanıcı veya grup nesnesinin hangi sistemden yönetileceği net olmalıdır.
Örneğin on-prem AD source of authority ise:
- isim
- UPN
- group membership
- belirli attribute'lar
on-prem'den değişir ve cloud'a senkronize edilir.
Aynı attribute'ı iki taraftan manuel yönetmeye çalışmak drift ve destek problemi yaratabilir.
Senkronizasyon için hangi seçenekler var?
Microsoft tarafında iki ana senkronizasyon yaklaşımı vardır:
- Microsoft Entra Cloud Sync
- Microsoft Entra Connect Sync
Yeni tasarımda seçim alışkanlığa göre değil, gereksinime göre yapılmalıdır.
Microsoft Entra Cloud Sync nedir?
Cloud Sync, hafif agent tabanlı ve büyük ölçüde cloud-managed bir provisioning/synchronization modelidir.
Öne çıkan yönleri:
- hafif provisioning agent
- birden fazla agent ile yüksek erişilebilirlik
- multi-forest senaryolar
- cloud üzerinden configuration
- daha düşük on-prem management footprint
Microsoft güncel hybrid identity guidance içinde Cloud Sync'i stratejik yön olarak konumlandırır.
Ancak her senaryoda Connect Sync'in yerini tamamen almış değildir.
Microsoft Entra Connect Sync ne zaman hâlâ gerekir?
Connect Sync bazı gelişmiş senaryolarda hâlâ anlamlıdır.
Özellikle:
- device synchronization
- Hybrid Entra Join senaryoları
- gelişmiş/custom synchronization rule
- bazı Exchange hybrid gereksinimleri
- belirli legacy hybrid ihtiyaçları
varsa Connect Sync gereksinimi çıkabilir.
Bu nedenle migration kararı feature matrix ile verilmelidir.
Cloud Sync vs Connect Sync kısa karşılaştırma
| Kriter | Cloud Sync | Connect Sync |
|---|---|---|
| Yönetim modeli | Cloud-managed | On-prem server ağırlıklı |
| Agent footprint | Hafif agent | Sync engine/server |
| Multi-forest | Güçlü | Destekler |
| HA | Çoklu agent | Staging server modeli |
| Device sync | Sınırlı/uygun değil | Daha geniş destek |
| Custom sync rule | Daha sınırlı | Daha gelişmiş |
| Yeni sade deployment | Güçlü aday | Gereksinime bağlı |
Feature desteği zamanla değişebileceği için üretim kararı öncesi Microsoft'un güncel comparison dokümanı kontrol edilmelidir.
Authentication yöntemi ayrıca seçilmelidir
Directory synchronization ile authentication aynı karar değildir.
Başlıca seçenekler:
- Password Hash Synchronization
- Pass-through Authentication
- Federation
Password Hash Synchronization nedir?
PHS'de on-premises parola hash'inin doğrudan kendisi Entra ID'ye kopyalanmaz.
Microsoft Entra Connect/Cloud Sync tarafında parola hash'i ek işlemden geçirilmiş bir türeve dönüştürülür ve bu türev cloud'a senkronize edilir.
Cloud sign-in sırasında authentication Entra ID tarafında yapılır.
Avantajlar:
- on-prem authentication altyapısına daha az bağımlılık
- daha basit mimari
- daha yüksek dayanıklılık
- kullanıcı cloud'a giriş yaparken domain controller'a ulaşma gereksinimi olmaması
Microsoft hybrid authentication guidance, PHS'yi çoğu organizasyon için önerilen temel yaklaşım olarak konumlandırır.
Pass-through Authentication nedir?
PTA'da kullanıcı cloud uygulamasına giriş yaparken parola doğrulaması on-premises Active Directory üzerinden yapılır.
Akış:
- kullanıcı Entra ID login ekranına parola girer
- request güvenli biçimde PTA agent'a iletilir
- agent on-prem AD üzerinde doğrulama yapar
- sonuç cloud'a döner
PTA şu durumda değerlendirilebilir:
- sign-in anında on-prem account state'e bağımlılık gerekiyorsa
- belirli security requirement varsa
Ancak PTA:
- agent
- network
- domain controller
erişimine bağımlıdır.
Bu nedenle high availability için birden fazla agent kullanılmalıdır.
PHS neden PTA için backup olabilir?
PTA kullanan organizasyonlarda PHS'nin backup authentication yöntemi olarak ayrıca açık tutulması değerlendirilebilir.
Böylece on-prem authentication altyapısı erişilemez olduğunda emergency cloud authentication seçeneği bulunabilir.
Bu karar security ve operasyon gereksinimleriyle birlikte verilmelidir.
Federation ne zaman gerekir?
Federation daha karmaşık bir modeldir.
AD FS veya başka federasyon altyapısı kullanılıyorsa:
- certificate lifecycle
- proxy
- farm availability
- patch
- monitoring
gibi ek operasyon yükleri vardır.
Modern Entra ID yetenekleri nedeniyle federation artık yalnız gerçekten gerekli senaryolarda tercih edilmelidir.
Legacy gereksinim yoksa PHS veya PTA genellikle daha sade mimari sağlar.
Kullanıcı senkronizasyon scope'u nasıl belirlenmeli?
Tüm AD'yi otomatik olarak cloud'a taşımak doğru yaklaşım değildir.
Önce:
- aktif çalışanlar
- servis hesapları
- privileged hesaplar
- test kullanıcıları
- legacy kullanıcılar
- shared account
ayrılmalıdır.
Senkronizasyon scope'u:
- OU
- group
- attribute
mantığıyla kontrollü tutulabilir.
UPN problemi neden sık yaşanır?
On-prem AD'de kullanıcılar:
user@company.local
gibi non-routable UPN kullanıyor olabilir.
Cloud tarafında doğrulanmış domain gereksinimi nedeniyle:
user@company.com
gibi routable UPN tasarımı gerekebilir.
Migration öncesi:
- UPN
- proxyAddresses
- immutable/source anchor
alanları kontrol edilmelidir.
Source Anchor nedir?
Hybrid identity'de on-prem kullanıcı ile Entra ID nesnesinin aynı kişi olduğunu belirlemek için kalıcı bir eşleştirme gerekir.
Bu amaçla source anchor/immutable identifier kullanılır.
Bu değer yanlış planlanırsa:
- duplicate user
- hard-match problemi
- soft-match problemi
oluşabilir.
Bu nedenle mevcut tenant'a sonradan sync açılırken özellikle dikkatli olunmalıdır.
Mevcut cloud kullanıcıları varsa ne olur?
Microsoft 365 daha önce cloud-only kullanıcılarla kullanıldıysa sonradan on-prem AD ile senkronizasyon açarken identity matching yapılmalıdır.
Kontrol edilmesi gerekenler:
- UPN
- primary SMTP
- object matching
- duplicate proxyAddress
- conflicting account
Pilot kullanıcı grubu ile başlanması güvenlidir.
Group sync nasıl ele alınmalı?
Security group ve distribution group yapısı envantere alınmalıdır.
Her group'u cloud'a taşımak gerekli olmayabilir.
Özellikle:
- nested group
- dynamic membership
- mail-enabled group
- privileged group
ayrı incelenmelidir.
Privileged hesaplar senkronize edilmeli mi?
Domain Admin gibi yüksek ayrıcalıklı hesapların günlük cloud hesabı olarak kullanılması doğru değildir.
Sağlıklı model:
- normal user account
- ayrı admin account
- ayrı privileged role
olabilir.
Cloud privileged erişim için:
- MFA
- Conditional Access
- PIM
- phishing-resistant authentication
değerlendirilmelidir.
Conditional Access hibrit kimlikte neden önemlidir?
Directory synchronization tek başına güvenlik sağlamaz.
Conditional Access ile:
- MFA zorunluluğu
- location
- device compliance
- risk
- application sensitivity
bazlı erişim policy uygulanabilir.
Ancak yanlış policy admin lockout yaratabilir.
Break-glass hesapları ve exclude stratejisi test edilmelidir.
Hybrid Entra Join nedir?
Bir Windows cihaz aynı anda:
- on-prem Active Directory domain'e joined
- Microsoft Entra ID'de registered/joined state
ile çalışabilir.
Bu model özellikle:
- mevcut Group Policy bağımlılığı
- on-prem application
- kademeli Intune geçişi
olan organizasyonlarda kullanılır.
Ancak cloud-native cihaz yönetimine geçiş hedefleniyorsa uzun vadeli device strategy ayrıca tasarlanmalıdır.
Entra Join ne zaman daha iyi olabilir?
Yeni cihazlarda:
- on-prem LDAP/Kerberos bağımlılığı düşükse
- Intune kullanılacaksa
- SaaS/cloud-first uygulama modeli varsa
Entra Join daha sade olabilir.
Her cihazı sırf geçmiş alışkanlık nedeniyle hybrid join yapmak gerekmeyebilir.
Service account'lar neden ayrı değerlendirilmelidir?
Legacy application'lar:
- domain service account
- scheduled task
- IIS app pool account
- Windows service
kullanıyor olabilir.
Bunları normal kullanıcı gibi sync etmek doğru olmayabilir.
Alternatif:
- Managed Identity
- gMSA
- workload identity
- service principal
olabilir.
Ancak application desteği doğrulanmalıdır.
LDAP bağımlılıkları nasıl bulunur?
On-prem AD'nin kapatılmasını zorlaştıran en önemli alanlardan biri LDAP/Kerberos kullanan legacy application'lardır.
Envantere ekleyin:
- LDAP bind
- LDAPS
- Kerberos SPN
- NTLM
- domain group authorization
- Windows Integrated Authentication
Bu bağımlılıklar cloud migration planında ayrı iş paketi olmalıdır.
DNS ve domain controller bağımlılığı
Hybrid identity ortamında network tarafında:
- DNS resolution
- domain controller connectivity
- site/subnet
- latency
önemlidir.
On-prem AD ile cloud workload aynı anda kullanılacaksa VPN/ExpressRoute veya uygun network bağlantısı gerekebilir.
Password writeback nedir?
Belirli lisans ve configuration koşullarında kullanıcı cloud self-service password reset üzerinden parolasını değiştirdiğinde değişiklik on-prem AD'ye geri yazılabilir.
Bu özellik deployment öncesi:
- licensing
- permissions
- agent/connectivity
- security policy
açısından doğrulanmalıdır.
Group writeback ve device writeback
Writeback özelliklerinin desteği kullanılan senkronizasyon yöntemine ve güncel Microsoft feature setine bağlıdır.
Bu nedenle legacy blog'lardaki feature tablolarına güvenmek yerine production tasarımında güncel Microsoft dokümantasyonu kontrol edilmelidir.
Monitoring nasıl yapılmalı?
Hybrid identity kritik production servisidir.
İzlenmesi gerekenler:
- synchronization health
- agent health
- export/import error
- duplicate attribute
- password sync error
- PTA agent health
- sign-in failure
- risky sign-in
olmalıdır.
Senkronizasyonun haftalarca sessizce bozuk kalması onboarding/offboarding riskidir.
Kullanıcı offboarding nasıl çalışmalı?
Bir çalışan ayrıldığında process yalnız AD hesabını disable etmekten ibaret olmamalıdır.
Kontrol edin:
- on-prem AD disable
- Entra session revoke
- group membership
- privileged role
- MFA method
- device ownership
- SaaS access
Identity lifecycle HR/IT süreciyle bağlanmalıdır.
Active Directory tamamen kapatılabilir mi?
Evet, bazı organizasyonlarda uzun vadede mümkün olabilir.
Ancak önce bağımlılıklar kaldırılmalıdır.
Kontrol edin:
- domain-joined computer
- Group Policy
- LDAP
- Kerberos
- NTLM
- file server ACL
- legacy application
- service account
- SQL Integrated Authentication
Bu bağımlılıklar varsa doğrudan Entra ID'ye geçmek application sorunları yaratabilir.
Active Directory nedir? klasik AD bileşenlerini ayrıca açıklar.
Örnek küçük şirket mimarisi
Senaryo:
- 50 kullanıcı
- tek AD forest
- Microsoft 365
- birkaç on-prem Windows uygulaması
- domain-joined PC'ler
Basit model:
- on-prem AD source of authority
- Entra Cloud Sync veya gereksinime göre Connect Sync
- Password Hash Synchronization
- MFA
- Conditional Access
- group-based RBAC
- pilot Hybrid Join veya cihaz stratejisine göre Entra Join
olabilir.
Burada federation çoğu zaman gereksiz karmaşıklık yaratabilir.
Örnek orta ölçekli mimari
Senaryo:
- birden fazla forest
- 500+ kullanıcı
- on-prem ve Azure workload
- legacy LDAP application
- Intune geçişi
Plan:
- forest/source analysis
- Cloud Sync suitability assessment
- Connect Sync gereken device/legacy workload ayrımı
- centralized monitoring
- PHS/PTA strategy
- staged device migration
- privileged identity controls
olarak tasarlanabilir.
Pilot rollout nasıl yapılmalı?
Production'da tüm kullanıcılarla başlamayın.
Pilot grup:
- IT ekibi
- farklı departmanlardan birkaç kullanıcı
- farklı device tipi
- farklı application pattern
içermelidir.
Pilot sırasında:
- sign-in
- Microsoft 365
- password change
- MFA
- device login
- file/application access
- offboarding
test edilmelidir.
Hibrit kimlik migration kontrol listesi
- Forest/domain envanteri
- UPN ve SMTP kontrolü
- Duplicate attribute taraması
- Source of authority kararı
- Sync scope
- Cloud Sync vs Connect Sync
- Authentication method
- MFA/Conditional Access
- Device identity
- Service account
- LDAP/Kerberos dependency
- Monitoring
- Pilot
- Rollback/support plan
Azure Landing Zone ile ilişki
Azure Landing Zone identity ve access management'i temel design area'lardan biri olarak ele alır.
Landing Zone içinde:
- tenant ownership
- RBAC
- privileged access
- managed identity
- subscription access
kararları hybrid identity modelinden etkilenir.
Bu nedenle Azure platform governance ile identity architecture ayrı projeler gibi yönetilmemelidir.
Dynamis'te hibrit kimlik yaklaşımı
Dynamis'in Azure yönetimi hizmetinde önce mevcut identity dependency'lerini çıkarıyoruz.
Assessment kapsamında:
- AD forest/domain
- user/group
- UPN/domain
- device
- application dependency
- service account
- sync method
- authentication
- MFA/Conditional Access
- monitoring
incelenir.
Ardından küçük pilot grup ile synchronization ve authentication akışı doğrulanır.
Amacımız on-prem AD'yi sırf modern görünmek için kaldırmak değil; kalan bağımlılıkları görünür hale getirip identity operasyonunu güvenli biçimde sadeleştirmektir.
Sık yapılan hatalar
Entra ID'yi Active Directory'nin birebir cloud versiyonu sanmak: İki sistemin işlevleri farklıdır.
Tüm OU'ları filtrelemeden sync etmek: Gereksiz ve legacy nesneler cloud'a taşınabilir.
UPN ve SMTP conflict'lerini pilot öncesi kontrol etmemek: Duplicate account sorunları yaratır.
Araç seçimini alışkanlığa göre yapmak: Cloud Sync ve Connect Sync feature ihtiyaçlarına göre seçilmelidir.
Directory sync ile authentication yöntemini aynı şey sanmak: Ayrı tasarım kararlarıdır.
MFA/Conditional Access'i migration sonrasına bırakmak: Cloud erişimi ilk günden korunmalıdır.
Service account ve LDAP bağımlılıklarını unutmak: AD decommission planını bloke eder.
Sırada ne var
Kaynaklar
Kaynaklar
- 1.Microsoft Entra hybrid identity documentationMicrosoft Learn · 2026-09-25
- 2.What is Microsoft Entra Cloud Sync?Microsoft Learn · 2026-09-25
- 3.Cloud Sync and Connect Sync comparisonMicrosoft Learn · 2026-09-25
- 4.Choose the right authentication methodMicrosoft Learn · 2026-09-25
- 5.Password hash synchronizationMicrosoft Learn · 2026-09-25
- 6.Pass-through authenticationMicrosoft Learn · 2026-09-25
- 7.Microsoft Entra Connect HealthMicrosoft Learn · 2026-09-25
Sık sorulan sorular
Microsoft Entra ID ile şirket içi Active Directory aynı şey mi?
Hayır. Windows Server Active Directory on-premises domain, computer account, Group Policy ve Kerberos/NTLM gibi klasik AD işlevlerini sağlar. Microsoft Entra ID ise cloud identity ve access management hizmetidir. Hibrit kimlik mimarisinde kullanıcı ve grup kimlikleri uygun bir senkronizasyon aracıyla iki ortam arasında eşleştirilir; iki dizin birbirinin birebir kopyası değildir.
Entra Cloud Sync mi, Entra Connect Sync mi kullanılmalı?
Yeni tasarımda önce gereksinimler karşılaştırılmalıdır. Microsoft, Cloud Sync'i hybrid identity synchronization için stratejik yön olarak konumlandırır ve cloud-managed, hafif agent tabanlı bir model sunar. Ancak Connect Sync hâlâ Hybrid Entra join/device sync gibi Cloud Sync'te bulunmayan bazı senaryoları destekler. Bu nedenle seçim; forest sayısı, device sync, Exchange hybrid, object sayısı ve custom sync kurallarına göre yapılmalıdır.
Password Hash Synchronization güvenli midir?
Microsoft Entra Password Hash Synchronization, on-premises parola hash'inin kendisini doğrudan kopyalamaz; hash'in ek olarak işlenmiş bir türevi Entra ID'ye senkronize edilir. Microsoft, PHS'yi hybrid authentication için en basit ve en dayanıklı seçenek olarak önerir çünkü cloud sign-in sırasında on-premises authentication altyapısına bağımlılık yoktur. Yine de MFA, Conditional Access ve privileged account kontrolleri ayrıca uygulanmalıdır.
Pass-through Authentication ne zaman tercih edilir?
PTA, cloud sign-in sırasında kullanıcının parolasını on-premises Active Directory'de doğrulatır. On-prem account state veya parola politikalarının sign-in anında uygulanmasının özel bir gereksinim olduğu durumlarda tercih edilebilir. Ancak PTA on-premises agent, network ve domain controller erişimine bağımlıdır; yüksek erişilebilirlik için birden fazla agent ve PHS backup stratejisi değerlendirilmelidir.
Hibrit kimlikte Active Directory kapatılabilir mi?
Bu, workload ve cihaz bağımlılıklarına bağlıdır. On-prem uygulamalar Kerberos/LDAP, domain join, Group Policy veya AD tabanlı service account kullanıyorsa Active Directory'yi doğrudan kapatmak mümkün olmayabilir. Önce kullanıcı, cihaz, uygulama, protocol ve service account bağımlılıkları çıkarılmalı; cloud-native karşılıkları doğrulanmalı ve sonra kademeli dönüşüm planlanmalıdır.