Entra Connect Sync mi Cloud Sync mi? Hibrit Kimlik Senkronizasyonu

Hibrit kimlikte sorunların çoğu senkronizasyon aracından değil, araca yüklenen kirli AD verisinden ve yanlış verilmiş kimlik doğrulama kararından çıkar. Şirket içi Active Directory’yi Microsoft Entra ID’ye bağlamanın iki resmi yolu var: Entra Connect Sync ve Entra Cloud Sync. İkisi de kullanıcıları, grupları ve parola hash’lerini buluta taşır; mimarileri, destekledikleri senaryolar ve işletim yükleri farklıdır. Aşağıda araç seçimini, PHS/PTA/federasyon kararını, AD hazırlığını ve senkronizasyon hatalarının nasıl okunacağını sırayla anlatıyoruz.

Hibrit kimlikte iki senkronizasyon aracı

Entra Connect Sync, eski adıyla Azure AD Connect, bir Windows Server üzerine kurulan tam bir senkronizasyon motorudur. Bağlayıcı alanları (connector space), metaverse ve senkronizasyon kuralları sunucuda yerel bir SQL veritabanında durur. Yapılandırma sunucudaki sihirbaz ve Synchronization Rules Editor ile yapılır.

Entra Cloud Sync yapılandırmayı buluta taşır. Şirket içinde yalnız hafif bir provizyon ajanı (Microsoft Entra provisioning agent) çalışır; ajan Entra ID’ye giden 443 bağlantısıyla bağlanır, senkronizasyon mantığı Microsoft’un bulut hizmetinde yürür. Birden fazla ajan kurularak yüksek erişilebilirlik sağlanır; ajanlar aktif–aktif çalışır.

Microsoft, yeni kurulumlarda ihtiyaçları karşılıyorsa Cloud Sync’in değerlendirilmesini öneriyor. Ama Connect Sync’in sağladığı bazı senaryolar Cloud Sync’te hâlâ yok. Karar bu farklara göre verilir, alışkanlığa göre değil.

Özellik karşılaştırma tablosu

Bu özellik kümesini Microsoft düzenli olarak genişletiyor; karar öncesinde Microsoft Learn’deki güncel karşılaştırma sayfasına bakın. Sahada belirleyici olan üç soru var: Windows cihazlar hibrit Entra join olacak mı? PTA kullanılacak mı? Özel senkronizasyon kuralı gerektiren öznitelik dönüşümleri var mı? Birine “evet” diyorsanız Connect Sync gerekir. Birleşme sonrası bağlantısız ormanlar veya sunucu bakım yükünü azaltma hedefi öndeyse Cloud Sync öne çıkar.

Kimlik doğrulama yöntemi: PHS, PTA ve federasyon

Senkronizasyon aracı ile kullanıcıların nasıl oturum açacağı ayrı kararlardır. Karıştırılırsa ilk büyük kesintide fark edilir.

• Password Hash Synchronization (PHS): Kimlik doğrulama tamamen bulutta yapılır. Şirket içi sunucu ve sistem altyapısı çökse bile kullanıcılar Microsoft 365’e erişmeye devam eder. Sızdırılmış kimlik bilgisi tespiti gibi Entra ID Protection özellikleri PHS’ye dayanır. Çoğu kurum için varsayılan ve en az bağımlılıklı seçenek budur.
• Pass-through Authentication (PTA): Parola, şirket içindeki PTA ajanları tarafından doğrudan DC’ye karşı doğrulanır. Parolanın hiçbir türevinin buluta gitmemesi şartı olan kurumlarda tercih edilir. Bedeli şudur: ajanlar ve DC erişimi oturum açmanın tek yolu haline gelir. Microsoft yüksek erişilebilirlik için birden fazla ajan önerir; PTA kullanılsa bile PHS’yi yedek olarak açık tutmayı değerlendirin.
• Federasyon (AD FS): Kimlik doğrulama şirket içi AD FS çiftliğine devredilir. Ek sunucu, sertifika ve WAP katmanı ister. Microsoft federasyondan yönetilen kimlik doğrulamaya (PHS veya PTA) geçişi önerir; yeni kurulumda yalnız akıllı kart veya üçüncü taraf MFA gibi gerçek bir zorunluluk varsa düşünülür. Süresi dolan bir token imzalama sertifikası, bütün oturum açmaları aynı anda durdurur.

Oturum açma sonrası koşullu erişim ve MFA politikaları ayrı bir tasarım konusu; bu tarafı Conditional Access planlama rehberi anlatıyor.

Senkronizasyon öncesi AD hazırlığı: UPN soneki, IdFix, OU filtreleme

Senkronizasyon hatalarının büyük bölümü, kurulumdan önce temizlenebilecek AD verisinden gelir. Bu iş atlanırsa hata listesiyle aylarca uğraşılır.

1. Yönlendirilebilir UPN soneki: Ormanın adı ornek.local ise kullanıcılar kullanici@ornek.local ile senkronize edilir ve bulutta onmicrosoft.com adresine düşer. Active Directory Domains and Trusts’ta doğrulanmış alan adı (ornek.com.tr) UPN soneki olarak eklenir; kullanıcıların UPN’i birincil e-posta adresiyle eşlenecek şekilde güncellenir.
2. IdFix taraması: Microsoft’un açık kaynak IdFix aracı yinelenen proxyAddresses ve UPN değerlerini, geçersiz karakterleri ve biçim hatalarını listeler. Önerilen düzeltmeler toplu uygulanabilir; ama her değişikliği önce dışa aktarıp gözden geçirin.
3. OU filtreleme: Servis hesapları, devre dışı kullanıcılar, test nesneleri ve yerleşik gruplar senkronizasyon kapsamına alınmaz. Kapsam OU yapısıyla belirlenecekse kullanıcı ve bilgisayar nesneleri önce düzenli OU’lara taşınır.
4. AD sağlığı: Replikasyon hataları, eski DC kayıtları ve DNS sorunları senkronizasyonu doğrudan bozar. Kurulumdan önce Active Directory sağlık kontrolü adımlarını tamamlayın.

UPN güncellemesi için kontrollü bir PowerShell örneği:

Import-Module ActiveDirectory
$ou = "OU=Kullanicilar,OU=Merkez,DC=ornek,DC=local"
Get-ADUser -SearchBase $ou -Filter * -Properties mail |
  Where-Object { $_.mail -like "*@ornek.com.tr" } |
  ForEach-Object {
    Set-ADUser $_ -UserPrincipalName $_.mail -WhatIf
  }

-WhatIf çıktısını kontrol ettikten sonra parametreyi kaldırıp değişikliği uygulayın. DOMAIN\kullanici biçimindeki oturum açma (sAMAccountName) değişmez; UPN ile oturum açan kullanıcılar ve UPN’i kimlik olarak kullanan uygulamalar ise etkilenir. Değişikliği önceden duyurun. Sessiz UPN değişikliği destek talebi üretir.

Kurulum adımları ve staging mode sunucusu

Entra Connect Sync

1. Etki alanına üye, güncel bir Windows Server hazırlanır. DC üzerine kurulum desteklenir, ama ayrı bir üye sunucu işletim ve güvenlik açısından daha temizdir. Bu sunucuyu Tier 0 varlık olarak koruyun; ele geçirilirse AD ve bulut kimliği birlikte gider.
2. Microsoft Entra yönetim merkezinden güncel Entra Connect sürümü indirilir. Eski sürümlerin desteği belirli aralıklarla sona erdiği için kurulu sürümü Microsoft’un sürüm geçmişi sayfasıyla düzenli karşılaştırın.
3. Özelleştirilmiş kurulum seçilir; kimlik doğrulama yöntemi, ormanlar, OU filtresi, kaynak bağlantı özniteliği (varsayılan ms-DS-ConsistencyGuid) ve isteğe bağlı özellikler (Exchange hibrit, parola geri yazımı) belirlenir.
4. “Yapılandırma tamamlandığında senkronizasyonu başlat” seçeneği ilk kurulumda kapalı tutulabilir; böylece kapsam kontrol edildikten sonra ilk senkronizasyon başlatılır.

Staging mode: İkinci bir sunucu aynı yapılandırmayla kurulur ve sihirbazda staging mode etkinleştirilir. Bu sunucu içe aktarma ve senkronizasyon yapar, dışa aktarma yapmaz. Birincil sunucu arızalandığında veya yükseltme sırasında, staging sunucusunda bekleyen dışa aktarmalar incelenir ve staging mode kapatılarak sunucu aktif hale getirilir. Aynı anda iki aktif sunucu olmaz.

# Zamanlayıcı durumu ve son döngü
Get-ADSyncScheduler

# Bakım öncesi zamanlayıcıyı durdurma
Set-ADSyncScheduler -SyncCycleEnabled $false

# Değişiklik sonrası artımlı veya tam döngü
Start-ADSyncSyncCycle -PolicyType Delta
Start-ADSyncSyncCycle -PolicyType Initial

Set-ADSyncScheduler -SyncCycleEnabled $true

Entra Cloud Sync

1. Provizyon ajanı yüksek erişilebilirlik için en az iki (Microsoft’un önerisiyle tercihen üç) üye sunucuya kurulur ve her biri Entra ID’ye kaydedilir; ajan kurulum sihirbazı varsayılan olarak bir gMSA oluşturur.
2. Entra yönetim merkezinde Cloud Sync yapılandırması oluşturulur; kapsam OU veya grupla belirlenir, öznitelik eşlemeleri gerekirse ifadelerle düzenlenir.
3. “Provision on demand” ile tek bir kullanıcı test edilir; sonuç adım adım gösterilir. Ardından yapılandırma etkinleştirilir.

Senkronizasyon hatalarını okuma ve giderme

Hatalar sunucuda Synchronization Service Manager’ın Operations sekmesinde, Entra yönetim merkezinde ise Entra Connect Health altında görünür (Connect Health raporları için Entra ID P1 lisansı gerekir). Konsolda ilk bakılacak yer Operations sekmesindeki son export adımıdır. En sık karşılaşılanlar:

Çakışan değeri bulmak için AD’de doğrudan sorgu yapın:

Get-ADObject -Filter "proxyAddresses -eq 'smtp:ali.yilmaz@ornek.com.tr'" -Properties proxyAddresses |
  Select-Object DistinguishedName, ObjectClass

Hatayı giderdikten sonra artımlı döngü çalıştırın ve hatanın kaybolduğunu doğrulayın. Tek bir nesnenin neden senkronize olmadığını anlamak için Synchronization Service Manager’da Metaverse Search ve bağlayıcı alanı nesne özellikleri incelenir; kapsam filtresine takılan nesne bağlayıcı alanında “filtered” olarak görünür. Nesne hiç yoksa sorun filtrede. Varsa ama ilerlemiyorsa sorun kuralda.

Geçiş: Connect Sync’ten Cloud Sync’e

Mevcut bir Connect Sync kurulumundan Cloud Sync’e tek seferde geçilmez. Microsoft’un belgelediği pilot yaklaşımı şöyle:

1. Cloud Sync’in ihtiyaçları karşıladığını doğrulayın: hibrit join cihaz senkronizasyonu, PTA ve özel kural ihtiyacı yoksa geçiş anlamlıdır.
2. Pilot için bir OU seçin. Connect Sync’te bu OU kapsamdan çıkarılırken nesnelerin bulutta silinmemesi için Microsoft’un pilot dokümanındaki kural değişikliklerini uygulayın; zamanlayıcı bu sırada durdurulur.
3. Cloud Sync yapılandırmasını yalnız pilot OU’yu kapsayacak şekilde oluşturun, provision on demand ile doğrulayıp etkinleştirin.
4. Pilot nesneleri birkaç senkronizasyon döngüsü boyunca izleyin; oturum açma, parola değişikliği ve grup üyeliklerini test edin.
5. Kapsamı aşamalı genişletin; tüm nesneler taşındıktan sonra Connect Sync’i kaldırın.

Her aşamada aynı nesnenin iki araç tarafından aynı anda yönetilmediğinden emin olun. Kimlik altyapısı hazır olduğunda posta taşıma için Exchange Online geçiş yöntemleri, cihaz tarafı için Windows Autopilot ile cihaz kurulumu yazılarına geçebilirsiniz. Resmi referans olarak Microsoft’un Entra hibrit kimlik dokümantasyonu esas alınmalı. Hibrit kimlik tasarımı ve mevcut AD’nin değerlendirilmesi için altyapı danışmanlığı ve Microsoft 365 hizmetleri sayfalarına bakabilirsiniz.

Sık sorulan sorular

Entra Connect Sync ve Cloud Sync aynı tenant’ta birlikte çalışabilir mi?

Evet. Microsoft iki aracın aynı tenant’ta birlikte kullanılmasını destekler; örneğin bağlantısız bir ormanı Cloud Sync ile, ana ormanı Connect Sync ile senkronize etmek mümkündür. Kural, aynı nesnenin iki aracın kapsamına aynı anda girmemesidir; kapsam OU veya grup filtreleriyle net ayrılmalıdır.

Password Hash Synchronization parolaların kendisini buluta mı gönderir?

Hayır. PHS, AD’deki parola hash’inin kendisini değil, bu hash’ten ek tuzlama ve çok sayıda yinelemeyle türetilmiş bir değeri Entra ID’ye gönderir. Bu değerden şirket içi parola hash’i geri elde edilemez. PHS ayrıca sızdırılmış kimlik bilgisi tespiti gibi Entra ID Protection özelliklerinin çalışması için gereklidir.

Staging mode sunucusu lisans veya ek maliyet gerektirir mi?

Entra Connect Sync için ayrı bir Microsoft lisansı gerekmez; staging sunucusu yalnız ek bir Windows Server örneğidir. Aynı yapılandırmayla kurulur, içe aktarma ve senkronizasyon yapar ama Entra ID’ye ve AD’ye yazmaz. Birincil sunucu arızalandığında staging mode kapatılarak devreye alınır.

Senkronizasyon döngüsünü elle nasıl tetiklerim?

Entra Connect Sync sunucusunda PowerShell’de Start-ADSyncSyncCycle -PolicyType Delta komutu yalnız değişiklikleri senkronize eder. Kural veya filtre değişikliğinden sonra Start-ADSyncSyncCycle -PolicyType Initial ile tam senkronizasyon yapılır. Cloud Sync’te yapılandırma ekranındaki isteğe bağlı provizyon (provision on demand) ile tek bir kullanıcı test edilir.