Hybrid kimlikte vereceğin ilk ve en kritik karar senkronizasyon aracı değil — kimlik doğrulama yöntemi. Çünkü bu karar, kullanıcının buluttaki tüm verisine erişimini kontrol eden katmandır; Conditional Access’ten MFA’ya, sızan parola tespitinden felaket kurtarmaya kadar üstüne ne kurarsan kur, temeli bu seçimdir. Microsoft’un kendi diliyle: "hafife alınacak bir karar değil."
Üç seçenek var: Password Hash Synchronization (PHS), Pass-through Authentication (PTA) ve Federation (AD FS). Çoğu rehber bunları "artıları-eksileri" diye sıralar ve seni yine kararsız bırakır. Ben tersten gideceğim: önce net cevabı vereceğim, sonra o cevabın neden böyle olduğunu — hesap durumu uygulaması, güvenlik özellikleri ve felaket senaryosu üzerinden — göstereceğim.
Kısa cevap
Hangi yöntemi seçersen seç, Password Hash Sync’i (PHS) etkinleştir. Microsoft’un net önerisi budur ve sahada defalarca doğrulanmıştır.
- Yeni veya standart bir ortamsan: PHS + Seamless SSO ile başla. En az altyapı, en yüksek dayanıklılık.
- On-prem hesap durumunu (kilit, süre dolumu, oturum saatleri) oturum anında zorunlu kılman gereken bir güvenlik şartın varsa: PTA — ama yanında yedek olarak yine PHS’i aç.
- Yalnızca Entra’nın yerel olarak karşılamadığı özel bir ihtiyacın varsa (üçüncü taraf MFA’nın federation istemesi,
sAMAccountNameile oturum, üçüncü taraf kimlik sağlayıcı): Federation — ve yine yedek olarak PHS’i aç.
Gördüğün gibi her yolun sonunda PHS var. Nedenini aşağıda üç başlıkta göreceksin.
Üç yöntem, kısaca
Password Hash Synchronization (PHS) — Kullanıcı parolasının hash’inin hash’i Entra’ya senkronlanır (parola asla açık metin ya da geri döndürülebilir biçimde tutulmaz). Doğrulama bulutta yapılır. On-prem’e yalnızca senkron sırasında (varsayılan ~2 dakikada bir) bağlıdır; oturum açma anında değil. En az emek, en az altyapı.
Pass-through Authentication (PTA) — Parola doğrulaması on-prem’de, hafif bir agent aracılığıyla yapılır; parola hash’i bulutta tutulmaz. Oturum açma, on-prem AD’nin ayakta olmasına bağımlıdır. Agent gerektirir.
Federation (AD FS) — Entra, doğrulamayı ayrı ve güvenilen bir sisteme (AD FS) devreder. Doğrulama tamamen on-prem’de olur. En büyük altyapı ayak izi; işletmesi ve sorun gidermesi en karmaşık yöntem.
Karşılaştırma tablosu
| Ölçüt | PHS | PTA | Federation (AD FS) |
|---|---|---|---|
| Doğrulama nerede olur? | Bulutta (hash karşılaştırması) | Bulutta, on-prem agent ile güvenli doğrulama sonrası | On-prem |
| Connect dışında ek sunucu? | Yok | Her ek agent için bir sunucu (önerilen 3 agent) | 2+ AD FS + 2+ WAP (DMZ) |
| TLS/SSL sertifikası? | Hayır | Hayır | Evet |
| On-prem çökerse bulut oturumu? | Çalışır | Durur | Durur |
| Hesap durumu anında uygulanır mı? | Yalnızca devre dışı (~30 dk gecikme) | Evet: devre dışı, kilit, süre dolumu, oturum saatleri | Evet (PTA ile aynı) |
| Sızan parola raporu (ID Protection) | Evet (P2) | PHS gerekir | PHS gerekir |
| Smart lockout | Evet | Evet | AD FS extranet lockout |
| Kurulum/işletme yükü | En düşük | Orta | En yüksek |
Kritik fark #1: hesap durumunu ne zaman uygular?
Bir kullanıcıyı on-prem’de devre dışı bıraktığında ne olur?
- PHS: Değişiklik hemen yansımaz. Kullanıcı, durum Entra’ya senkronlanana kadar (devre dışı için ~30 dakikaya varan gecikme) bulut uygulamalarına erişmeye devam edebilir. Ayrıca parola süresi dolumu ve hesap kilidi durumları Entra’ya senkronlanmaz. Toplu devre dışı bırakma yaptıysan, elle bir senkron turu tetiklemek iyi bir alışkanlıktır.
- PTA ve Federation: On-prem hesap politikasını oturum anında uygular. Devre dışı, kilitli, süresi dolmuş hesap ya da izin verilen oturum saatleri dışındaki giriş anında reddedilir.
Yani "işten çıkan kullanıcının bulut erişimi saniyesinde kesilsin" gibi sıkı bir şartın varsa, bu tek başına PTA (ya da Federation) gerekçesi olabilir. Yoksa PHS’in gecikmesi çoğu ortam için kabul edilebilir — ve toplu işlemlerde elle senkronla telafi edilir.
Kritik fark #2: bazı güvenlik özellikleri PHS’siz çalışmaz
- Microsoft Entra ID Protection — sızan kimlik bilgileri (leaked credentials) raporu, hangi yöntemi seçersen seç PHS gerektirir (ve Entra ID P2). Microsoft karanlık ağda satılan kullanıcı/parola listelerini sürekli tarar; senin kullanıcılarından biri bu listede varsa ancak PHS açıksa yakalayabilir.
- Smart password lockout PHS ve PTA’da gelir.
- Microsoft Entra Domain Services da PHS gerektirir.
Sonuç şu: Federation ya da PTA kullanıyor olsan bile, modern tehdit korumasının bir kısmını kaybetmemek için PHS’i yedek olarak açık tutman gerekir. Bu, "ya o ya bu" değil; PHS çoğu zaman diğerinin yanında koşar.
Kritik fark #3: on-prem çökerse ne olur?
Bir fidye yazılımı (ransomware) saldırısı ya da felaket on-prem sunucularını indirdiğinde:
- Yalnızca PTA/Federation olan ve PHS’i açmamış kurumlar: Bulut oturumu da on-prem’e bağlı olduğu için erişim kesilir. Microsoft’un saha gözlemi net — bu kurumlar iletişim için güvenilmez dış e-posta sistemlerine mecbur kaldı ve on-prem kimlik altyapısını geri getirmek haftalar aldı.
- PTA/Federation’ın yanında PHS’i önceden açmış kurumlar: Birincil yöntem çökünce PHS’e geçip (Connect ile elle) saatler içinde yeniden çevrimiçi oldular; Microsoft 365 e-postasına erişerek krizi yönetebildiler.
Buradaki ders tek cümle: PHS, yalnızca bir kimlik doğrulama yöntemi değil, aynı zamanda felaket sigortandır. Ücretsiz, basit ve açık olması dakikalar meselesi. Açmamak için geçerli bir neden yok.
Not: PHS’e geçiş (failover) otomatik değildir; Connect üzerinden oturum açma yöntemini elle değiştirirsin. Bunu krize girmeden önce bir kez prova et.
Hangisini ne zaman seçmeli?
PHS’i seç, eğer: yeni/standart bir ortamsan, en az altyapı ve en yüksek dayanıklılık istiyorsan, ID Protection sızan parola tespiti senin için önemliyse (zaten her halükarda açılmalı).
PTA’yı seç, eğer: on-prem hesap durumunu oturum anında zorunlu kılman gerekiyorsa, parola hash’inin bulutta hiç bulunmamasını istiyorsan — ama yine de 3 agent ve yedek PHS ile kur.
Federation’ı seç, eğer: Entra’nın yerel olarak karşılamadığı özel bir şartın varsa (federation isteyen üçüncü taraf MFA, üçüncü taraf kimlik sağlayıcı, sAMAccountName ile oturum), zaten olgun bir AD FS yatırımın varsa. Yeni kurulumlarda genellikle gerekçesi yoktur: maliyeti, karmaşıklığı ve sorun giderme yükü yüksektir. Microsoft bulut kimlik doğrulamasını (PHS/PTA) önerir; federation’dan buluta geçiş için Staged Rollout ile pilot yapabilirsin.
Sahadan notlar
- "Önce PTA, PHS’siz" kurma. Yedeksiz PTA, ilk ciddi on-prem arızasında seni buluttan da eder.
- PTA’da tek agent bırakma. Connect sunucusundaki agent + 2 ek agent = 3. Biri bakımdayken biri düşerse hâlâ ayaktasın.
- Agent’ları DMZ’ye koyma. PTA agent’ları DC’lere kısıtsız ağ erişimi ister; perimeter ağına kurulması desteklenmez.
- PHS gecikmesini süreçle telafi et. Toplu devre dışı bırakmalardan sonra elle senkron turu.
- Not: Kimlik doğrulama yöntemi, senkron aracından (Connect Sync ya da Cloud Sync) bağımsızdır; Connect Sync kurulumu bu kararı değiştirmez.
Sonuç
Üç yöntem de geçerli ama eşit değil. PHS en az yükle en yüksek dayanıklılığı verir ve modern güvenlik özelliklerinin kapısını açar; PTA, on-prem hesap politikasını anında uygulaman gerektiğinde devreye girer; Federation ise yalnızca Entra’nın yerel olarak karşılamadığı özel bir şart varsa anlamlıdır. Hepsinin ortak paydası: PHS’i mutlaka aç — birincil yöntemin olarak ya da en azından felaket yedeğin olarak. Yöntemi seçtikten sonra sırada MFA ve Conditional Access ile erişimi koşullandırmak var.
