Connect, Cloud Sync ve writeback: Senkronizasyonun güven ilişkileri.

1. Core Mechanism / Temel mekanizma

Senkronizasyon bir veri kopyalama ayrıntısı değil, iki yetki alanını birbirine bağlayan bir güven ilişkisidir. Köprüyü kuran bileşen, kaynağındaki veriyi okuyabilecek yetkiye; writeback söz konusuysa hedefteki veriyi değiştirebilecek yetkiye sahiptir. Bu nedenle sync sunucusu, provisioning agent ve writeback servis hesabı, taşıdıkları yetki kadar değerli varlıklardır. Senkronizasyon teknolojisi seçimi, kullanıcıların nasıl doğrulandığını belirlemez; o ayrı bir karardır.

Arabirimler ve belirtimler

• Entra Connect Sync: on-premises kurulan ve senkronizasyon orkestrasyonunu on-premises yürüten çözümdür. Password hash synchronization bu bileşenin bir uzantısıdır ve ADDS Connector account, hash'leri okuyabilmek için Replicate Directory Changes ve Replicate Directory Changes All izinlerine sahiptir. Cloud Sync de PHS etkinleştirebilir;12.02’deki ayrıntılı Connect Sync türetim zinciri Cloud Sync’in iç uygulaması hakkında bir iddia değildir.
• Entra Cloud Sync iki parçalıdır: provisioning agent on-premises AD DS ile konuşur; provisioning service yapılandırma, zamanlama ve orkestrasyonu cloud tarafında yürütür. Agent, Service Bus bağlantısını outbound başlatır. Mimari belgedeki iki dakikalık scheduler tanımı, bir nesnenin Entra ID’de iki dakikada görüneceği garantisi değildir.
• Cloud Sync akışı SCIM standardını kullanır: agent Azure Service Bus üzerinden kalıcı bir outbound bağlantı tutar, cloud servisinden gelen SCIM isteklerini alır, Active Directory'yi sorgular, yapılandırılan scoping ve attribute mapping kurallarına göre veriyi filtreleyip dönüştürür; cloud servisi sonucu işler ve watermark takibiyle artımlı güncellemeleri yönetir.
• Cloud Sync'te yüksek erişilebilirlik ve otomatik failover için birden çok provisioning agent kaydedilebilir; bu load balancing değildir ve senkronizasyonu aynı anda yalnız bir agent işler. Ayrıca birbirine bağlı olmayan birden çok forest tek bir tenant'a senkronize edilebilir.
• Password writeback: cloud'daki parola değişikliği veya sıfırlamasının gerçek zamanlı olarak on-premises dizine yazılmasıdır ve hem Entra Connect hem de Cloud Sync ile yapılandırılabilir. İşlem senkrondur; parola on-premises AD DS politikasına (geçmiş, karmaşıklık, yaş, password filter) göre denetlenir ve kullanıcı sonucu anında görür.
• Writeback Azure Service Bus relay üzerinden çalışır; tüm iletişim 443 portundan outbound'dur ve inbound firewall kuralı gerektirmez. Writeback isteklerini işleyen on-premises servis hesabı, protected group üyelerinin parolalarını değiştiremez.
• Connect Sync ile Cloud Sync aynı domain için birlikte yapılandırıldığında, o domain'den senkronize edilen kullanıcıların tüm password writeback işlemleri Cloud Sync agent'ı tarafından işlenir.

Köprünün yönü, ayrıcalığın yönünü belirler

Normal dizin akışında kullanıcı, grup ve kişi nesneleri on-premises AD DS’ten Entra ID’ye taşınır; PHS etkinse parola doğrulama verisi de bu yönde akar. Cloud’dan AD DS’e nesne provision etmek ayrı bir özelliktir: 3 Ekim 2026’da Microsoft Learn, kullanıcı provisioning’ini preview, grup provisioning’ini generally available olarak listeliyor. Hangi nesne türünün hangi kaynaktan yönetildiğini ayrıca belirlemek gerekir.

Her yön kendi yetkisini gerektirir. Okuma yönü için kaynağı okuyabilen bir kimlik; yazma yönü için hedefte değişiklik yapabilen bir kimlik gerekir. Bir ortamda hangi yönlerin açık olduğu yazılı değilse, ayrıcalık envanteri eksik demektir: writeback açıkken cloud tarafındaki bir yönetim işlemi on-premises parolayı değiştirebilir.

SSPR password writeback, bu nesne provisioning özelliğiyle aynı işlem değildir. SSPR belgesi Connect Sync ve Cloud Sync üzerinden writeback’i destekler. Entra ID→AD nesne provisioning sayfasındaki “password writeback yok” notu ise o modelin kapsamını anlatır; genel SSPR desteğinin kalktığı anlamına gelmez.

Connect Sync ile Cloud Sync arasındaki asıl fark mimaridir

Cloud Sync'in ayırt edici özelliği, provisioning orkestrasyonunun tamamen Microsoft Online Services tarafında yürütülmesidir. On-premises'te kalan şey, güvenli köprü görevi gören hafif agent'tır; yapılandırma, izleme ve yönetim cloud servisinden yapılır. Microsoft bu mimariyi, on-premises sync sunucusu yönetiminin karmaşıklığını ortadan kaldırması ve forest konsolidasyonu olmadan birden çok disconnected forest'ı tek tenant'a senkronize edebilmesiyle tarif eder.

Bu fark operasyonel olduğu kadar güvenliktir de. Connect Sync'te yapılandırma ve kurallar on-premises sunucuda yaşar; o sunucunun bütünlüğü senkronizasyon kurallarının bütünlüğüdür. Cloud Sync'te kurallar cloud'da tutulur; bu defa cloud yönetim yetkileri senkronizasyon davranışını belirler. Her iki modelde de 'kuralları kim değiştirebilir?' sorusu ayrı yanıtlanmalıdır.

Cloud Sync'te yüksek erişilebilirlik ve otomatik failover için birden çok agent kaydedilebilir; senkronizasyonu aynı anda yalnız bir agent işler. Connect Sync'te her tenant için yalnız bir sunucu aktif olabilir; ancak güncel tutulan staging-mode bir sunucu standby olarak bekletilip failover sırasında aktif role geçirilebilir. Bu nedenle iki ürünün kullanılabilirlik tasarımları farklıdır; hiçbiri active-active load balancing olarak tanımlanmamalıdır.

Writeback'in sınırları belgelidir

Password writeback güçlü bir kolaylıktır: kullanıcı cloud'da parolasını sıfırlar, değişiklik gerçek zamanlı olarak on-premises dizine yazılır ve on-premises politika kontrolleri uygulanır. İşlem senkron olduğu için kullanıcı politikaya uymayan bir parolada anında geri bildirim alır.

Bu akışın iki önemli sınırı vardır. Birincisi, writeback isteklerini işleyen on-premises servis hesabının protected group üyelerinin parolalarını değiştirememesidir; yöneticiler cloud'da kendi parolalarını değiştirebilir ama unutulmuş bir on-premises parolayı writeback ile sıfırlayamaz. İkincisi, staged rollout bir güvenlik grubu için etkinken on-premises domain'e writeback'in desteklenmemesidir.

Üçüncü bir ayrıntı coexistence'tır: Connect Sync ile Cloud Sync aynı domain için birlikte yapılandırıldığında, o domain'in kullanıcıları için writeback işlemlerini Cloud Sync agent'ı üstlenir. Bu davranış bilinmezse, bir sorun gidermede yanlış bileşenin logları incelenir.

Bir döngünün süresi, nesnenin görünme süresi değildir

Güncel Cloud Sync FAQ, PHS için 2–5 dakika, kullanıcı/grup provisioning için yaklaşık 10–20 dakika aralık veriyor. Aynı ürünün deep-dive sayfasında iki dakikalık scheduler tanımı da duruyor. Belgeler arasındaki bu farkı tek bir SLA gibi okuyamayız; iş yükünü ve baktığımız belgeyi adlandırmalıyız.

Örneğin AD DS’te bir attribute değiştiğinde, scope’a alınması, agent’ın sonucu döndürmesi ve cloud servisinin yazması ayrı aşamalardır. Bekleyen değişiklik sayısı görünürlük gecikmesini uzatabilir. Writeback ise kendi senkron isteğinin sonucunu döndürür; provisioning döngüsünü bekleyen bir nesne kopyalama işlemi değildir.

Durum ve veri akışı

1. Connect Sync kurulu bir ortamda PHS etkinse, ADDS Connector account replication yetkisiyle DC'den parola hash'lerini ister; bu akış dizinden hassas veri okuyan ayrıcalıklı bir yoldur.
2. Cloud provisioning service, isteği Service Bus’a koyar. Outbound bağlantıyı tutan agent SCIM isteğini alır, AD DS’i sorgular ve scope/mapping kurallarına göre filtrelenmiş yanıtı cloud servisine döndürür.
3. Entra ID’ye yazan taraf provisioning service’tir; agent doğrudan tenant dizinini güncellemez. Servis watermark ile artımlı ilerlemeyi takip eder. Döngü aralığı ile bu nesnenin görünme gecikmesi aynı ölçüm değildir.
4. Kullanıcı cloud'da parolasını sıfırladığında, writeback isteği Service Bus relay üzerinden on-premises bileşene ulaşır; parola on-premises AD DS politikasına göre denetlenir ve sonuç senkron olarak kullanıcıya döner.
5. Hedef hesap bir protected group üyesiyse writeback servis hesabı parolayı değiştiremez; istek bu sınır nedeniyle başarısız olur ve kurtarma yolu ayrı tasarlanmalıdır.

2. Exploitation / İstismar

Broken trust assumption

“Senkronizasyon yalnız veri kopyalayan arka plan bir işlemdir; sync sunucusu ve agent'lar sıradan uygulama sunucularıdır, writeback ise sadece bir kullanıcı kolaylığıdır” varsayımı.

Technical prerequisites

• Sync bileşenlerinin kullandığı kimliklerin yetkileri belgelenmemiştir; PHS etkinken connector hesabının replication izinleri ayrıcalık envanterinde görünmez.
• Writeback'in açık olduğu ve cloud tarafındaki bir parola sıfırlama işleminin on-premises dizine yazıldığı, yetki modelinde ayrı bir satır olarak yer almaz.
• Sync sunucusu ve provisioning agent sunucuları tier 0 varlık olarak sınıflandırılmamıştır; bu sunuculara yönetici erişimi geniş bir ekibe açıktır.

Exploitation mechanism / İstismar mekanizması

Bu varsayım, kimlik sınırının gerçekte nerede bittiğini gizler. Senkronizasyon köprüsünü işleten bileşen, kaynak dizinden okuma yetkisini taşır; PHS etkinken bu yetki, replication yoluyla hassas veri okuyabilen bir yetkidir. Writeback açıkken köprü ayrıca hedefte parola değiştirebilen bir yola sahiptir. Dolayısıyla sync sunucusuna ya da agent sunucusuna yönetici erişimi olan bir kişi, iki yetki alanının kesişiminde durur: bir tarafta dizin verisi, diğer tarafta cloud yönetim yüzeyi. Bu bileşen sıradan bir uygulama sunucusu gibi yönetilirse, domain controller'lar sertleştirilmiş olsa bile kimlik sınırı etkin biçimde daha zayıf bir sunucuya taşınmış olur. Aynı mantık cloud tarafı için de geçerlidir: Cloud Sync'te kurallar cloud'da tutulduğundan, ilgili cloud yönetim rollerini taşıyanlar senkronizasyon kapsamını ve dönüşümlerini değiştirebilir.

Köprü, en zayıf ucu kadar güçlüdür

Bir kuruluş domain controller'larını titizlikle korur ama sync sunucusunu standart sunucu havuzunda tutarsa, kimlik sınırı fiilen o havuza iner. Microsoft'un belgelediği PHS akışında connector hesabının replication izinleri kurulumda varsayılan olarak verilir; bu izinlerin varlığı tasarımın parçasıdır, anormallik değildir. Anormal olan, bu yetkiyi taşıyan bileşenin düşük güven seviyesinde işletilmesidir.

Bu ders saldırı yürütme adımları içermez. Savunma çıkarımı nettir: sync sunucuları ve provisioning agent sunucuları, yönetici erişimi, oturum açma kısıtı, yama, uygulama beyaz listesi ve izleme bakımından domain controller'larla aynı sınıfta ele alınmalıdır.

Writeback, cloud kararını on-premises etkiye çevirir

Writeback açıkken cloud tarafındaki bir parola sıfırlama işlemi on-premises hesabın parolasını değiştirir. Bu, yardım masası süreçleri için büyük bir kolaylıktır; aynı zamanda cloud yönetim yetkilerinin on-premises etkisi olduğu anlamına gelir. Yetki modeli bu etkiyi yazmıyorsa, 'yalnız cloud yöneticisi' diye tanımlanan bir rol aslında on-premises hesapları etkileyebilir.

Belgelenen sınır burada kritik bir denge sağlar: writeback servis hesabı protected group üyelerinin parolalarını değiştiremez. Bu sınır tasarımın güvenlik tarafıdır ve kaldırılmaya çalışılmamalıdır; ayrıcalıklı hesapların kurtarma yolu ayrı, denetimli ve on-premises bir süreç olarak tasarlanır.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Hangi köprülerin açık olduğunu tek bir tabloda tut: Connect Sync, Cloud Sync, PHS, password writeback ve varsa cloud-to-AD provisioning. Her satırda yön, kullanılan kimlik ve kapsam yazılmalıdır.
• Sync kimliklerinin yetkilerini düzenli doğrula; özellikle replication izinlerini taşıyan hesapları ayrı bir tier 0 listesinde izle.
• Provisioning agent envanterini tut: hangi sunucuda, hangi forest için, kaç agent kayıtlı ve hangisinin senkronizasyonu işlediği. Cloud Sync'te birden çok kayıtlı agent failover sağlar; tek agent tekil hata noktasıdır.
• Writeback açıksa hangi domain'lerin hangi bileşen tarafından işlendiğini kaydet; Connect Sync ve Cloud Sync aynı domain için birlikte yapılandırıldığında writeback'i Cloud Sync agent'ı işler.
• Protected group üyeleri için parola kurtarma yolunu ayrı yaz; bu hesaplar writeback ile sıfırlanamaz.

Events and relevant fields

• Replication izinlerini kullanan bir okuma, PHS etkin bir ortamda sync kimliği için beklenen davranıştır; aynı erişim deseninin farklı bir kimlik veya farklı bir kaynaktan gelmesi ayrı değerlendirilmelidir.
• Bir nesne geç görünüyorsa önce iş yükünü ayır: Cloud Sync FAQ’de PHS 2–5 dakika, kullanıcı/grup provisioning yaklaşık 10–20 dakikadır. Değişiklik hacmi gerçek gecikmeyi etkiler; iki dakika doldu diye işlemin tamamlandığını veya arızalandığını varsayma.
• Bir nesnenin cloud'da görünmemesi silinme anlamına gelmez; scoping kuralları veya attribute mapping nedeniyle kapsam dışı kalmış olabilir.
• Başarısız bir writeback işlemi her zaman bağlantı sorunu değildir; hedef hesap protected group üyesiyse bu sonuç belgelenmiş bir sınırdır.
• Agent'ların yalnız outbound bağlantı kullanması nedeniyle inbound kural beklentisiyle yapılan ağ analizleri yanlış yönlendirebilir; writeback iletişimi 443 üzerinden outbound'dur.

Senkronizasyon kapsamı bir güvenlik kararıdır

Scoping kuralları ve attribute mapping genellikle operasyonel bir ayar olarak görülür, oysa hangi nesnelerin ve hangi alanların cloud'a taşınacağını belirleyen güvenlik kararlarıdır. Kapsam gereğinden geniş olduğunda, on-premises'te sınırlı tutulan bilgi cloud yüzeyinde erişilebilir hale gelir; kapsam gereğinden dar olduğunda ise cloud tarafında eksik kimlik verisiyle alınan erişim kararları yanlış sonuç üretir.

Bu nedenle kapsam değişiklikleri değişiklik yönetiminden geçmeli ve kimin değiştirebildiği açıkça tanımlanmalıdır. Cloud Sync'te yapılandırmanın cloud'da tutulması bu soruyu daha da önemli hale getirir: artık on-premises sunucuya erişim olmadan da kural değiştirilebilir.

Sorun gidermede doğru bileşeni seç

Hibrit kimlik olaylarının önemli bir kısmı yanlış bileşende araştırıldığı için uzar. Bir attribute cloud'da güncellenmiyorsa sorun senkronizasyon kapsamında veya mapping'de olabilir; bir parola sıfırlama on-premises'e ulaşmıyorsa sorun writeback yolunda ya da hedef hesabın protected group üyeliğinde olabilir; cloud sign-in başarısızsa sorun tamamen ayrı bir eksende, sign-in yönteminde olabilir.

Runbook'ta bu üç ekseni ayıran tek bir karar ağacı bulunması, ortalama çözüm süresini belirgin biçimde kısaltır. Karar ağacının ilk sorusu her zaman şudur: belirti hangi yönde, okuma yönünde mi yazma yönünde mi, yoksa doğrulama yolunda mı?

Detection logic · KQL

SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4662
| where Properties contains "1131f6ad-9c07-11d1-f79f-00c04fc2dcd2"
| summarize operations = count() by Account, Computer, bin(TimeGenerated, 1h)
| order by TimeGenerated asc

Query assumptions

• Bu örnek Azure Monitor SecurityEvent tablosunu hedefler; belgede Properties türü string’dir ve alan boş olabilir. Toplayıcının 4662 Properties içeriğini bu alana nasıl eşlediğini doğrulamak gerekir. Sorgu gerçek bir workspace’te çalıştırılmadı.
• 4662 kaydının üretilmesi uygun audit policy ve nesne SACL yapılandırmasına bağlıdır; sorgunun sonuç döndürmemesi erişim olmadığı anlamına gelmez.
• contains, tireli GUID’i büyük/küçük harf ayrımı yapmadan substring olarak arar; has ise alfasayısal term arar. Bu yalnız aday satır filtresidir: GUID’in daha uzun bir metin içinde geçmesi de eşleşebilir. ObjectName, ObjectType, AccessMask, sonuç ve kimlik/kaynak bağlamı okunmadan replication işlemi veya niyet kanıtlanmaz.

False positives

• PHS etkin bir ortamda sync kimliğinin düzenli replication erişimi beklenen davranıştır; bu kayıtların varlığı tek başına kötü niyet göstermez.
• Yedekleme, izleme veya dizin denetim araçları da benzer erişim desenleri üretebilir; kimlik ve kaynak sunucu birlikte değerlendirilmelidir.
• Negatif örnek: audit policy eksikse gerçek bir replication erişimi hiç kaydedilmez; sorgunun boş dönmesi güvenlik kanıtı değildir.

Hardening

• Sync sunucusunu ve provisioning agent sunucularını tier 0 varlık olarak sınıflandır; yönetici erişimini ayrı ve izlenen bir yola bağla.
• Senkronizasyon kurallarını değiştirebilen cloud rollerini ayrıcalıklı erişim incelemesine dahil et; Cloud Sync'te yapılandırma cloud'da tutulur.
• Writeback kapsamını yalnız ihtiyaç duyulan domain ve kullanıcı gruplarıyla sınırla; kapsam kararını yazılı bir gerekçeyle sakla.
• Protected group üyeleri için writeback dışı, denetimli bir on-premises parola kurtarma yordamı tanımla.
• Cloud Sync'te yüksek erişilebilirlik için birden çok agent dağıt; tek agent'lı kurulumları kullanılabilirlik riski olarak kaydet.
• Coexistence senaryolarında hangi bileşenin writeback'i işlediğini belgele; sorun giderme runbook'unda doğru log kaynağına yönlendir.

Örnekler üzerinde oku / Read the examples

O:DAG:DAD:P(OA;CI;CR;1131f6aa-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-4071847660-1138144873-2902452632-1181)(OA;CI;CR;1131f6ad-9c07-11d1-f79f-00c04fc2dcd2;;S-1-5-21-4071847660-1138144873-2902452632-1181)(A;;RPLCLORC;;;AU)

İki yanlış kanı / Two reality checks

Sanılan: Senkronizasyon tek yönlüdür: veriler yalnız on-premises Active Directory'den Microsoft Entra ID'ye akar.

Gerçekte: Yönler ayrı yapılandırılır. SSPR writeback cloud’daki parola işlemini AD DS’e iletebilir; AD DS parola politikasını uygular. Entra ID→AD nesne provisioning ise başka bir özelliktir; güncel belgede kullanıcılar preview, gruplar GA’dır. Birinin etkin olması diğerini veya genel çift yönlü senkronizasyonu etkinleştirmez.

Sanılan: Password writeback açıksa cloud'dan her hesabın parolası sıfırlanabilir.

Gerçekte: Hayır. Microsoft Learn, writeback isteklerini işleyen on-premises servis hesabının protected group üyelerinin parolalarını değiştiremeyeceğini belirtir: bu kullanıcılar cloud'da kendi parolalarını değiştirebilir, ancak unutulmuş bir on-premises parola writeback ile sıfırlanamaz. Ayrıca bir güvenlik grubu için staged rollout etkinken on-premises domain'e writeback desteklenmez.

Kaynaklar / Sources

• Microsoft · What is Microsoft Entra Cloud sync?
  Cloud Sync components, cloud orchestration and high availability. Timing and SCIM ownership are linked separately to FAQ and deep-dive references.
• Microsoft · On-premises password writeback with self-service password reset
  Writeback'in Entra Connect veya cloud sync ile gerçek zamanlı çalışması; on-premises AD DS politika denetimi; senkron işlem ve anında geri bildirim; Azure Service Bus relay üzerinden 443 outbound; protected group üyeleri için servis hesabı sınırı; staged rollout notu; aynı domain'de coexistence'ta writeback'in Cloud Sync agent'ı tarafından işlenmesi.
• Microsoft · Implement password hash synchronization with Microsoft Entra Connect Sync
  ADDS Connector account'un Replicate Directory Changes ve Replicate Directory Changes All izinleri; MS-DRSR replication protokolüyle unicodePwd isteği; iki dakikalık senkronizasyon döngüsü.
• Microsoft · Active Directory extended rights: DS-Replication-Get-Changes-All
  Control access right'ın rightsGuid değeri 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 ve dizin değişikliklerinin tüm kapsamıyla okunmasına ilişkin tanımı.
• Microsoft · DS-Replication-Get-Changes extended right (AD Schema)
  CN DS-Replication-Get-Changes, Display-Name Replicating Directory Changes, Rights-GUID 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2; bir naming context'ten değişiklikleri replike etmek için gereken extended right.
• Microsoft · 4662(S, F) An operation was performed on an object
  Event XML ve Field Descriptions; ObjectServer=DS, Properties GUID alanı ve AccessMask; olayın yalnız ilgili nesnede SACL varken üretilmesi.
• Microsoft · Microsoft Entra Connect Sync: staging server and disaster recovery
  Connect Sync uses an active-passive model: only one server actively exports, while a staging-mode server imports and synchronizes without exports and can be promoted during failover. Cloud Sync's multiple registered agents provide high availability/automatic failover; only one processes synchronization at a time.
• Microsoft · Cloud Sync deep dive
  SCIM request/response through Service Bus and agent; service writes Entra ID; two-minute architecture description contrasted with current FAQ.
• Microsoft · Cloud Sync FAQ
  How often does cloud sync run?; one active agent
• Microsoft · Provision Entra ID objects to AD
  User preview / group GA; password writeback note scoped to object provisioning
• Microsoft · Kusto string operators
  Alphanumeric term boundaries; contains is case-insensitive substring scanning
• Microsoft · SecurityEvent table
  Properties string; EventID int; object-specific event population