PHS, PTA ve federation: Kullanıcı hangi tarafta, nasıl doğrulanır?

1. Core Mechanism / Temel mekanizma

Hibrit kimlikte authentication method, senkronizasyon teknolojisinden bağımsız bir karardır. Microsoft Learn bunu açıkça belirtir: sign-in yöntemleri Entra Connect Sync ile Cloud Sync'ten hangisinin kullanıldığına bakılmaksızın uygulanır ve senkronizasyon teknolojisi seçimi sign-in davranışını değiştirmez. On-premises kaynaklı bir hybrid user için nesne AD DS'te doğar ve cloud'a senkronize edilir; değişen şey parolanın nerede doğrulandığıdır.

Arabirimler ve belirtimler

• PHS bir sign-in yöntemidir: Entra ID, senkronize edilen parola türevi veriyle doğrulama yapar. Connect Sync ve Cloud Sync PHS destekler. Aşağıdaki ayrıntılı türetim zinciri ve iki dakikalık döngü Connect Sync için belgelenmiştir; Cloud Sync’in iç uygulaması hakkında aynı ayrıntıları varsayma.
• Connect Sync uygulamasında pHS zinciri belgelidir: agent, unicodePwd değerini MS-DRSR replication protokolüyle bir DC'den ister; DC, MD4 hash'ini RPC session key'in MD5 hash'i ve bir salt ile şifreleyip gönderir; agent 16 baytlık hash'i 64 bayta genişletir, 10 baytlık per-user salt ekler ve 1.000 iterasyonlu PBKDF2/HMAC-SHA256 ile 32 baytlık sonucu üretir. Sonuca per-user salt ve iterasyon sayısı eklenerek TLS üzerinden Entra ID'ye iletilir.
• Connect Sync PHS için AD DS connector hesabının belgelenen replication izinleri gerekir. Entra ID’ye orijinal MD4 değeri veya clear-text parola değil, türetim sonucu senkronize edilir. Bu bileşen sıradan bir kullanıcı verisi okuyucusu değildir; ayrıcalıklı altyapının parçasıdır.
• PTA: Entra ID'ye yapılan sign-in sırasında parola doğrudan on-premises Active Directory'ye karşı doğrulanır. Doğrulamayı on-premises sunuculara kurulan hafif bir agent yapar; agent yalnız outbound bağlantı açar ve Entra ID ile iletişimini certificate-based authentication ile kurar.
• Federation: Entra ID doğrulama sürecini ayrı ve güvenilen bir authentication system'e, tipik olarak on-premises AD FS'e devreder. Federation service SAML assertion üretir; Entra ID bu assertion'ı doğrular ve kendi token'ını üretir. Federation, Entra ID'nin doğal olarak desteklemediği üçüncü taraf MFA gibi gereksinimler için seçilebilir.
• PTA veya federation ana yöntemse PHS ayrıca yedek olarak yapılandırılabilir. Geçiş otomatik değildir; hazırlanmış bir süreçle sign-in yöntemi değiştirilir. Leaked credentials özelliğinin PHS gereksinimi de seçilen ana yöntemden ayrı değerlendirilir.

Soru 'parola nerede?' değil, 'doğrulama nerede?'

Üç yöntemi ayıran temel soru, credentials'ı hangi bileşenin doğruladığıdır. PHS'te bu bileşen Entra ID'dir; kullanıcı cloud'a parolasını girer ve Entra ID bunu sakladığı türetilmiş değerle karşılaştırır. PTA'da doğrulama on-premises Active Directory'ye karşı yapılır ve agent bu isteğin/yanıtın taşınmasına aracılık eder. Federation'da AD FS gibi güvenilen bir authentication system kullanıcıyı doğrular ve SAML assertion üretir; Entra ID assertion'ı doğruladıktan sonra kendi token'ını verir.

Bu ayrım erişilebilirliği doğrudan etkiler. PHS'te parola hash'i Entra ID'ye senkronize edildiyse, on-premises identity bileşenleri erişilemez olduğunda cloud sign-in devam edebilir. PTA ve federation'da ise doğrulama yolu on-premises bileşene bağlıdır. Microsoft, PHS'in PTA veya federation için ayrı bir yedek authentication method olarak yapılandırılabileceğini belirtir; arıza halinde otomatik geçiş olmaz. Staged rollout, geçiş öncesi cloud authentication'ı sınamak için ayrı bir yöntemdir.

PHS'te senkronize edilen şey tam olarak ne?

Aşağıdaki parametre zinciri Microsoft Entra Connect Sync uygulamasını anlatır. Cloud Sync de PHS etkinleştirebilir; yöntemi desteklemesi, aşağıdaki her iç uygulama ayrıntısının aynı olduğunu kanıtlamaz.

PHS tartışmalarındaki en yaygın hata, “parolamız cloud'a gidiyor” cümlesidir. Belgelenen akış bunu desteklemez. Agent, DC'den gelen zarfı açtığında elindeki değer clear text parola değil MD4 hash'tir; belge, agent'ın hiçbir zaman clear text parolaya erişmediğini yazar. Ardından hash 64 bayta genişletilir, 10 baytlık per-user salt eklenir ve 1.000 iterasyon HMAC-SHA256 ile PBKDF2'den geçirilir.

Entra ID'ye 32 baytlık sonuç, per-user salt ve iterasyon sayısı TLS üzerinden iletilir. Microsoft Learn, orijinal MD4 hash'in iletilmediğini ve türetilmiş değerin ele geçirilse bile on-premises pass-the-hash saldırısında kullanılamayacağını belirtir.

Buradaki MD5 kullanımı da ayrı bir yanlış okuma kaynağıdır. MD5, parolanın korunması için değil, DC'nin replication protokolüyle uyumluluk için kullanılır ve bu kullanım DC ile agent arasındaki on-premises iletişimle sınırlıdır.

unicodePwd (MD4)
  -> DC: MD5(RPC session key + salt) ile zarflanir
  -> Agent: zarfi acar, MD4 elde eder (clear text yok)
  -> 16 bayt -> 32 karakter hex -> UTF-16 -> 64 bayt
  -> + 10 bayt per-user salt
  -> PBKDF2 / HMAC-SHA256, 1000 iterasyon -> 32 bayt
  -> 32 bayt + salt + iterasyon sayisi -> TLS uzerinden Entra ID

PTA'nın bedeli bir sunucu değil, bir karar yolu

PTA bazen “hash cloud'a gitmiyor” gerekçesiyle seçilir. PTA doğrulama yolunda parola on-premises Active Directory'ye karşı doğrulanır ve Microsoft'a göre on-premises password cloud'da saklanmaz. Bu ifade, ayrıca yapılandırılan PHS'in senkronize ettiği türetilmiş password hash'i kapsamaz. PTA'nın karşılığında her cloud sign-in on-premises agent'ların erişilebilirliğine bağlı hale gelir; Microsoft yüksek erişilebilirlik için birden çok sunucuda agent önerir.

PTA'nın ikinci ayırt edici özelliği, on-premises hesap durumunun anında uygulanmasıdır. Hesap süresi dolmuş, devre dışı bırakılmış, parolası süresi geçmiş, kilitlenmiş veya oturum açma saatleri kısıtlı kullanıcılar için AD seviyesinde kararın her sign-in'de uygulanması gerekiyorsa, karar yolunun on-premises olması bir gerekliliktir.

PTA, Conditional Access ve MFA gibi cloud kontrolleriyle birlikte çalışır; seamless SSO ile birleştirilebilir. Yani PTA bir “cloud'suz” model değildir: cloud politika değerlendirmesi yine Entra ID'de olur, yalnız parola doğrulaması on-premises'tedir.

Durum ve veri akışı

1. Kullanıcı bir cloud uygulamasına gider; uygulama Entra ID'ye yönlendirir. Entra ID, kullanıcının domain'i için yapılandırılmış sign-in yöntemine bakar.
2. Connect Sync PHS örneğinde Entra ID, paroladan türetilen değeri sakladığı değerle karşılaştırır; eşleşme bu parola doğrulamasını tamamlar. Deneme sırasında erişilebilir bir on-premises DC gerekmez.
3. PTA yapılandırıldıysa doğrulama isteği on-premises agent'a iletilir; agent parolayı Active Directory'ye karşı doğrular ve sonucu Entra ID'ye geri taşır. Agent yalnız outbound bağlantı kullanır.
4. Buradaki AD FS yolunda farm kullanıcıyı doğrular ve SAML assertion imzalar. Entra ID assertion’ı doğrular; assertion reddi, Conditional Access uygulanmadan authentication’ı sonlandırır.
5. İlk faktör doğrulaması tamamlandıktan sonra Entra ID, geçerli Conditional Access policy’lerini uygular. Parola veya assertion reddi ile policy engeli ayrı sonuçlardır. Bu kontrollerin geçilmesi token akışını sürdürür; uygulamadaki her kaynağa erişim hakkını kanıtlamaz.

2. Exploitation / İstismar

Broken trust assumption

“PHS parolamızı cloud'a gönderir, dolayısıyla PTA ve federation otomatik olarak daha güvenlidir” varsayımı; buna bağlı olarak sign-in yönteminin tek başına bir güvenlik seviyesi belirlediği ve senkronizasyon teknolojisi seçiminin doğrulama davranışını değiştirdiği sanısı.

Technical prerequisites

• PHS'te Entra ID'ye iletilen değerin ne olduğu ve bu değerin on-premises bir pass-the-hash saldırısında kullanılamayacağı ekipçe bilinmemektedir.
• PTA ve federation'da doğrulama yolunun on-premises bileşenlere bağlı olduğu ve bu bileşenlerin cloud erişiminin önkoşulu haline geldiği risk kaydında yoktur.
• ADDS Connector account'un Replicate Directory Changes ve Replicate Directory Changes All izinlerine sahip olduğu ve sync sunucusunun bu nedenle yüksek değerli bir hedef olduğu ayrıcalık envanterine girmemiştir.

Exploitation mechanism / İstismar mekanizması

Yöntemin etiketinden önce kararı veren bileşene ve bağımlılıklarına bak. Connect Sync PHS’te Entra ID senkronize edilmiş türevi doğrular; ayrıcalıklı connector hesabı ve sync sunucusu bu veriyi taşır. PTA validation path’inde on-premises agent parolayı AD DS’e karşı denetler. Aynı ortamda PHS ayrıca etkin olabilir; PTA seçili olması cloud’da hiçbir parola türevi veri bulunmadığını kanıtlamaz. AD FS örneğinde farm kullanıcıyı doğrulayıp SAML assertion imzalar; Entra ID assertion’ı doğrulayarak kendi token’ını verir. İmzalama yapılandırması, claim rule’lar, agent sağlığı ve cloud policy farklı sahipleri olan ayrı kontrol noktalarıdır.

Sync kimliği bir yan bileşen değildir

PHS'in çalışması için ADDS Connector account'un Replicate Directory Changes ve Replicate Directory Changes All izinlerine sahip olması gerekir; Microsoft Learn bu izinlerin kurulumda varsayılan olarak verildiğini yazar. Bu, dizinden hassas replication verisi okuyabilen bir yetkidir ve bu yetkiyi taşıyan kimliğin barındığı sunucu, domain controller'larla aynı koruma seviyesini hak eder.

Bu ders kimlik materyali çıkarma yöntemi öğretmez. Savunma açısından doğru çıkarım şudur: sync sunucusu ve sync kimliği, erişim denetimi, yönetici oturumu, yama ve izleme bakımından tier 0 varlık olarak ele alınmalı; bu bileşene yönetici erişimi olan herkes kimlik sınırının içinde sayılmalıdır.

Yöntem değişikliği bir risk transferidir

Federation'dan cloud authentication'a geçiş ya da tersi, risk azaltma değil risk transferidir. Federation'da on-premises farm'ın korunması kritiktir; cloud authentication'da ise cloud tarafındaki politika, oturum ve token yönetimi öne çıkar. Microsoft, yöntem değişikliğinin planlama, test ve olası kesinti gerektirdiğini belirtir ve staged rollout ile seçili kullanıcı gruplarında test edilmesini önerir.

Geçiş planında sık atlanan ayrıntı, PHS'in federation yanında yedek olarak etkinleştirilebilmesidir. Bu yedek, birincil sign-in yöntemi arızalandığında devreye alınabilmesi için arıza öncesinde yapılandırılmış olmalıdır; kesinti anında aceleyle kurulacak bir önlem değildir.

3. Defense & Detection / Savunma ve tespit

Telemetry scope

• Her federated ya da managed domain için seçilmiş sign-in yöntemini ve bu yöntemin ne zaman değiştiğini kayıt altına al; yöntem değişikliği bir mimari değişikliktir.
• PHS kullanılıyorsa ADDS Connector account'un izinlerini ve bu kimliğin çalıştığı sunucunun yönetici erişim listesini tier 0 envanterinde tut.
• PTA kullanılıyorsa kurulu agent'ların sayısını, bulundukları sunucuları ve sağlık durumunu izle; tek agent bir tekil hata noktasıdır.
• AD FS örneğinde token-signing certificate geçerliliğini, federation trust’ı ve claim rule değişikliklerini izle. Bunlar Entra ID’nin doğruladığı imzalı assertion’ı etkiler; AD FS, Entra ID’nin verdiği token’ı imzalamaz.
• ID Protection'ın leaked credentials raporu bekleniyorsa, bu raporun hangi sign-in yöntemi seçilirse seçilsin password hash sync gerektirdiği yazılı olsun.

Events and relevant fields

• Cloud sign-in başarısızlıklarındaki ani artış, PTA ya da federation kullanılan ortamlarda doğrulama yolundaki on-premises bileşenin erişilebilirliğiyle ilgili olabilir; tek başına credential saldırısı kanıtı değildir.
• Connect Sync PHS için iki dakikalık senkronizasyon döngüsü belgelenmiştir. Bu, değişikliğin uçtan uca görünürlüğü için garanti değildir: hatalar güncellemeyi geciktirebilir; açık oturum tekrar parola istemeyebilir.
• Parola senkronizasyonu sırasında hata oluşursa bir kayıt event viewer'a düşer; bu kayıtların yokluğu senkronizasyonun doğru çalıştığının kanıtı değildir.
• Keep me signed in seçeneğiyle oluşan oturum çerezleri, doğrulama yöntemi ne olursa olsun kullanıcıya yeniden parola sorulmamasına yol açabilir; bu durum doğrulama akışının atlandığı anlamına gelmez.

Kesinti tatbikatını yöntemle eşleştir

Kesinti tatbikatını yapılandırılmış yönteme göre kur. PHS daha önce senkronize edilmiş parolaları doğrulamayı sürdürebilir; yeni parola değişiklikleri senkronizasyonu bekler. PTA, agent/AD DS doğrulama yoluna bağlıdır. AD FS örneğinde erişilemeyen farm veya geçersiz imzalama yapılandırması kullanılabilir bir federation assertion alınmasını engeller. PHS yedeği önceden yapılandırma ve ayrıca yöntem değiştirme kararı ister; otomatik kesinti yanıtı değildir.

Bu senaryoların her biri farklı bir kurtarma yolu gerektirir ve ortak bir runbook'a sığmaz. Tatbikat raporunda hangi yöntemin, hangi bileşenin ve hangi süre boyunca test edildiği yazılmazsa, sonraki ekip yanlış bir hazırlık seviyesi varsayar.

Senkronizasyon teknolojisi ile sign-in yöntemini ayır

Microsoft Learn, hibrit kimlik doğrulama yöntemlerinin kullanılan senkronizasyon teknolojisinden bağımsız olduğunu ve teknoloji seçiminin sign-in davranışını belirlemediğini açıkça yazar. Buna rağmen pratikte iki konu sık sık tek karar gibi tartışılır ve “Cloud Sync'e geçersek doğrulama da değişir mi?” sorusu belirsiz kalır.

Bu ayrımın belgelenmesi hem değişiklik yönetimini hem de olay incelemesini kolaylaştırır. Senkronizasyonla ilgili bir aksama nesne ve attribute akışını etkiler; sign-in yöntemiyle ilgili bir aksama doğrulamayı etkiler. İki belirti benzer görünse de kök nedenleri ve sahipleri farklıdır.

Detection logic · KQL

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != "0"
| summarize failures = count(), users = dcount(UserPrincipalName) by bin(TimeGenerated, 15m), ResultType
| order by TimeGenerated asc

Query assumptions

• Sorgu çalıştırılmadı. Bağlantısı verilen SigninLogs şemasında ResultType string’dir; "0" başarıyı belirtir, bu yüzden örnekte string karşılaştırılır. Kullanım öncesinde toplanan tabloyu doğrula; toplama sonucu PHS, PTA, federation veya policy hatasını tek başına ayırt etmez.
• Sorgu, hatanın PHS, PTA ya da federation hangi yolda oluştuğunu ayırt etmez; doğrulama yolunun hangi bileşende kesildiği ayrı kaynaklardan okunmalıdır.
• On-premises agent ve federation farm sağlığına ait kayıtlar bu tabloda yer almayabilir; korelasyon için ayrı veri kaynağı gerekir.

False positives

• Planlı bir bakım penceresi sırasında artan başarısız sign-in sayısı saldırı değil, beklenen kesinti sonucu olabilir.
• Bir uygulamanın yeniden kimlik doğrulama davranışı değiştiğinde hata sayısı artabilir; bu, kimlik altyapısında bir değişiklik olduğu anlamına gelmez.
• Negatif örnek: PHS kullanılan bir ortamda on-premises kesinti sırasında cloud sign-in başarıyla sürebilir; başarı sayısının yüksek kalması on-premises sağlığının kanıtı değildir.

Hardening

• Her yöntemde kararı veren bileşeni ve bağımlılıklarını değerlendir; yöntem adı tek başına güvenlik derecesi değildir.
• PHS kullanılıyorsa sync sunucusunu ve sync kimliğini domain controller seviyesinde koru; yönetici erişimini ayrı ve izlenen bir yola bağla.
• PTA kullanılıyorsa birden çok sunucuya agent kurarak yüksek erişilebilirlik sağla ve agent sunucularını ayrıcalıklı altyapı olarak sınıflandır.
• Federation'dan cloud authentication'a geçişi staged rollout ile sınırlı kullanıcı gruplarında test et; geçiş planına geri dönüş adımını yaz.
• Birincil yöntem arızalanırsa devreye alınacak yedek yapılandırmayı arıza öncesinde kur ve tatbikatını yap.
• Kullanıcı iletişiminde 'parolanız cloud'a gönderiliyor' gibi teknik olarak yanlış ifadeler yerine doğrulamanın nerede yapıldığını anlatan net bir açıklama kullan.

Örnekler üzerinde oku / Read the examples

30 24 0c 03 50 48 53 0c 06 50 42 4b 44 46 32 0c 0b 48 4d 41 43 2d 53 48 41 32 35 36 02 02 03 e8 02 01 0a 02 01 20

İki yanlış kanı / Two reality checks

Sanılan: Password hash synchronization kullanıcıların parolalarını buluta gönderir; bu yüzden pass-through authentication her ortamda daha güvenli bir seçimdir.

Gerçekte: PHS clear-text parolayı veya orijinal MD4 değerini değil, parola türevi veriyi senkronize eder. Bu dersteki parametre zinciri Connect Sync için belgelenmiştir; Cloud Sync de PHS destekler, fakat aynı iç ayrıntıları varsaymıyoruz. PTA on-premises doğrulama yoluna bağlıdır ve ayrıca etkinleştirilmiş PHS ile birlikte bulunabilir. Bu yüzden PTA seçmek, cloud’da parola türevi veri olmadığını veya her ortamda daha güvenli olduğunu kanıtlamaz.

Sanılan: Entra Connect Sync yerine Cloud Sync'e geçmek, kullanıcıların nasıl doğrulandığını da değiştirir.

Gerçekte: Hayır. Microsoft Learn, hibrit kimlik doğrulama yöntemlerinin kullanılan senkronizasyon teknolojisinden bağımsız olarak uygulandığını ve senkronizasyon teknolojisi seçiminin sign-in davranışını belirlemediğini yazar. Senkronizasyon nesne ve attribute akışını yönetir; PHS, PTA veya federation seçimi ise doğrulamanın nerede yapıldığını belirleyen ayrı bir karardır.

Kaynaklar / Sources

• Microsoft · Implement password hash synchronization with Microsoft Entra Connect Sync
  Detailed description of how password hash synchronization works: MS-DRSR ile unicodePwd isteği, Replicate Directory Changes / Replicate Directory Changes All izinleri, MD5+salt zarfı, 64 bayta genişletme, 10 baytlık per-user salt, 1.000 iterasyon PBKDF2/HMAC-SHA256, orijinal MD4'ün iletilmemesi, iki dakikalık döngü.
• Microsoft · What is password hash synchronization with Microsoft Entra ID?
  PHS'in sign-in yöntemi olarak tanımı; federation yanında yedek olarak yapılandırılabilmesi; leaked credential detection ile ilişkisi.
• Microsoft · Microsoft Entra Connect: Pass-through Authentication
  Parolanın doğrudan on-premises Active Directory'ye karşı doğrulanması; on-premises parolaların cloud'da saklanmaması; yalnız outbound bağlantı açan hafif agent; certificate-based agent authentication; birden çok agent ile yüksek erişilebilirlik; Conditional Access ve MFA ile birlikte çalışma.
• Microsoft · Authentication for Microsoft Entra hybrid identity solutions
  Scope of this article notu: sign-in yöntemlerinin senkronizasyon teknolojisinden bağımsız olması; cloud authentication ve federated authentication tanımları; on-premises hesap durumunun her sign-in'de uygulanması gereksinimi; ID Protection'ın password hash sync gereksinimi; staged rollout ile geçiş testi.
• Microsoft · Cloud Sync deep dive
  Optional PHS support; no equivalence claim for internal algorithm
• Microsoft · Hybrid authentication resilience
  Federation assertion validated by Entra
• Microsoft · SigninLogs schema
  ResultType string,0success; query not executed
• Microsoft · Conditional Access overview
  Enforcement after first-factor authentication