Entra ID Seamless SSO: Kerberos Tabanlı Kimlik Doğrulama Katmanı

Hibrit kimlik mimarisi kuran sistem yöneticilerinin yakından bildiği bir davranış vardır. Domain-Joined bir Windows istemcide oturum açan kullanıcı, ardından tarayıcısı üzerinden Outlook on the Web, SharePoint Online ya da OneDrive for Business gibi bulut servislerine eriştiğinde herhangi bir kimlik bilgisi girmeden oturum açar. Bu şeffaf deneyimin arka planında çalışan bileşenin adı Microsoft Entra Seamless Single Sign-On (Seamless SSO)'dur ve Microsoft Entra ID ekosistemindeki en yanlış konumlandırılan bileşenlerden biridir.

Seamless SSO, Microsoft Entra ID'ye kullanıcı oturumlarını sessizce ileten Kerberos tabanlı bir kimlik doğrulama mekanizmasıdır. Microsoft Learn'in resmi dokümantasyonu bu mekanizmayı "Opportunistic" olarak tanımlar. Yani Seamless SSO, çalışabildiği her senaryoda devreye girer ve kullanıcı kimliğini doğrudan Kerberos bileti üzerinden Microsoft Entra ID'ye karşı doğrular. Çalışamadığı senaryolarda ise akış, Tenant'ın aktif sign-in method'una (PHS veya PTA) düşer.

En sık karşılaşılan kavramsal hata, Seamless SSO'nun Password Hash Synchronization (PHS) veya Pass-through Authentication (PTA) ile aynı anda paralel çalıştığı varsayımıdır. Oysa Seamless SSO devreye girdiğinde kullanıcı kimliği doğrudan Kerberos bileti üzerinden doğrulanır ve PHS veya PTA tarafından herhangi bir parola doğrulama işlemi yapılmaz.

PHS ve PTA, yalnızca Seamless SSO'nun devreye giremediği senaryolarda fallback kimlik doğrulama yöntemi olarak çalışır. Bu senaryolar arasında cihazın Domain-Joined olmaması, kullanıcının kurumsal ağ dışında olması ve Domain Controller'a Kerberos isteği gönderememesi, Integrated Windows Authentication (IWA) desteklemeyen ya da bu özelliği yapılandırılmamış bir tarayıcı kullanılması veya kullanıcının açıkça kullanıcı adı ve parola girmesi gibi durumlar yer alır. Yani Seamless SSO ile PHS/PTA paralel çalışan iki katman değil, sıralı olarak değerlendirilen iki ayrı kimlik doğrulama yoludur.

Türkçe kaynaklarda Seamless SSO ile PHS/PTA arasındaki ilişki üzerine iki kritik konu sıklıkla yanıltıcı biçimde aktarılır. Birincisi, hangi yöntemin varsayılan olarak devreye girdiği. İkincisi, aktif yöntem başarısız olduğunda PHS ve PTA arasında otomatik bir failover gerçekleşip gerçekleşmediği. Pratikte verilen yanıtların büyük kısmı, Microsoft'un belgelendirdiği gerçek protokol akışıyla örtüşmez. Microsoft, Entra Pass-through Authentication FAQ dokümantasyonunda bu noktayı açıkça netleştirmiştir. PTA'dan PHS'ye otomatik bir failover bulunmaz. Yöntem değişikliği yalnızca Tenant düzeyinde, Hybrid Identity Administrator yetkisiyle gerçekleştirilen manuel bir operasyondur.

Mekanizmanın merkezinde, Microsoft Entra Connect kurulumu sırasında on-premises Active Directory üzerinde otomatik olarak oluşturulan AZUREADSSOACC isimli özel bir Computer hesabı yer alır. Bu hesap, Kerberos kimlik doğrulamasında kullanılan Kerberos Decryption Key'i barındırır. Anahtar kurulum sırasında üretilir, Microsoft Entra ID Tenant'ına güvenli biçimde aktarılır ve sonrasında kullanıcı kimlik doğrulamalarının görünmeyen omurgasını oluşturur. Microsoft, güvenlik gereği bu anahtarın en az 30 günde bir manuel olarak yenilenmesini (Key Rollover) önerir, ancak Seamless SSO için otomatik bir rollover mekanizması mevcut değildir. Bu nedenle AZUREADSSOACC hesabı, ortamın Tier 0 (Control Plane) varlıkları arasında değerlendirilmeli ve buna uygun şekilde sıkılaştırılmalıdır.

Modern Endpoint stratejisi açısından da Seamless SSO'nun kapsamının doğru anlaşılması gerekir. Seamless SSO, esas olarak Domain-Joined Windows 7 ve Windows 8.1 istemciler için tasarlanmıştır. Windows 10, Windows 11 ve Windows Server 2016 ve üzeri sürümlerde çalışan Microsoft Entra Joined ya da Microsoft Entra Hybrid Joined cihazlar için Microsoft, Kerberos tabanlı Seamless SSO yerine Primary Refresh Token (PRT) tabanlı SSO yaklaşımını önerir. Microsoft Learn ayrıca şunu da netleştirir. Eğer hem Microsoft Entra Join hem de Seamless SSO etkinse, Entra Join üzerinden gelen SSO Seamless SSO'dan önce devreye girer. Dolayısıyla Seamless SSO, modern istemci ortamlarında giderek daralan ancak hibrit senaryoların önemli bir kısmında hala aktif olarak kullanılan bir katmandır. Bu yazıda Seamless SSO'nun mimarisi, Kerberos tabanlı çalışma prensibi, PHS ve PTA ile birlikte nasıl konumlandığı, AZUREADSSOACC hesabının rolü, Kerberos Decryption Key Rollover operasyonları, istemci tarafı GPO gereksinimleri ve modern Windows istemcilerde PRT tabanlı SSO ile olan ilişkisi teknik detayıyla ele alınacaktır.

Seamless SSO, Wizard'da Bir Sign-In Method Değildir

Seamless SSO ile ilgili anlaşılması gereken ilk ve en kritik konu, Seamless SSO'nun Microsoft Entra Connect kurulum Wizard'ında PHS, PTA veya Federation gibi bir sign-in method olarak konumlandırılmadığıdır. Wizard'ın User Sign-In adımında karşımıza çıkan Password Hash Synchronization, Pass-through Authentication, Federation with AD FS, Federation with PingFederate ve Do not configure seçenekleri, kullanıcı parolasının nerede ve nasıl doğrulanacağını belirleyen sign-in method'lardır. Bir Tenant'ta, Staged Rollout ile geçici test senaryoları hariç, bu method'lardan yalnızca biri active sign-in method olarak çalışır.

Seamless SSO ise bu listenin parçası değildir. Wizard'ın aynı ekranında Enable single sign-on başlığı altında yer alan ve sign-in method seçiminden tamamen bağımsız çalışan ayrı bir Checkbox olarak konumlanır. Bu nedenle PHS ile birlikte de, PTA ile birlikte de, hatta her ikisi birlikte yapılandırıldığında (PTA primary + PHS backup) da Seamless SSO aktifleştirilebilir.

Mimari olarak Seamless SSO, kullanıcının Domain-Joined bir cihazda zaten aktif bir Kerberos Ticket-Granting Ticket (TGT)'sine sahip olduğu senaryolarda devreye giren ve kullanıcı kimliğini Microsoft Entra ID'ye karşı Kerberos bileti üzerinden doğrulayan bir kimlik doğrulama katmanıdır. Microsoft'un kendi dokümantasyonu, Entra ID'nin Kerberos biletini Decrypt edip kullanıcı kimliğini doğruladığını ve oturum açma işlemini tamamladığını açıkça ifade eder. Yani Seamless SSO teknik olarak bir kimlik doğrulama mekanizmasıdır, ancak PHS veya PTA gibi parola tabanlı bir mekanizma değildir. Kullanıcı parola girmediği için ekranda görünen sessiz oturum açma deneyimi, arka planda gerçekleşen Kerberos tabanlı kimlik doğrulamanın dışa yansıyan sonucudur.


 

AZUREADSSOACC Computer Account, Seamless SSO'nun Kalbi

Seamless SSO'nun çalışma mantığını anlamak için öncelikle AZUREADSSOACC isimli özel bir Computer account'tan bahsetmek gerekir. Entra Connect Sync kurulumu sırasında Enable single sign-on seçeneği işaretlendiğinde, sihirbaz senkronize edilen her AD Forest için on-premises Active Directory üzerinde otomatik olarak AZUREADSSOACC adında bir Computer hesabı oluşturur. Birden fazla Forest senkronize ediliyorsa, her Forest kendi benzersiz Kerberos Decryption Key'ine sahip kendi AZUREADSSOACC hesabını alır.

Bu hesabın ismi Microsoft tarafından sabittir ve şu anlama gelir:

✔ AZUREAD → Azure Active Directory (güncel adıyla Microsoft Entra ID)

✔ SSO → Single Sign-On

✔ ACC → Account

Bu hesap, Entra ID'nin On-Prem AD içindeki temsilcisidir. Kerberos altyapısında olağan bir Computer hesabıdır, ancak özel bir misyona sahiptir. Entra ID, kendisine gelen Kerberos Service Ticket'larını bu hesabın Kerberos şifreleme anahtarı (Key) ile Decrypt eder.

AZUREADSSOACC Key'inin Mantığı

AD'deki her hesap gibi AZUREADSSOACC'un da bir parolası vardır ve bu paroladan türetilen bir Kerberos şifreleme anahtarı oluşur. Microsoft Learn dokümantasyonuna göre Seamless SSO; AES256_HMAC_SHA1, AES128_HMAC_SHA1 ve RC4_HMAC_MD5 şifreleme türlerini destekler. Microsoft'un güçlü tavsiyesi, AES256_HMAC_SHA1 kullanılmasıdır. Şifreleme türü, hesabın msDS-SupportedEncryptionTypes attribute'unda saklanır.

Bu Key'in operasyonel davranışı aşağıdaki gibidir:

✔ Kurulum sırasında üretilir ve bir sonraki Key Rollover işlemine kadar değişmez.

✔ Üretildikten hemen sonra Microsoft Entra ID Tenant'ına güvenli biçimde aktarılır ve bulutta saklanır.

✔ Her kullanıcı erişiminde yeniden üretilmez veya değiştirilmez.

✔ Tüm kullanıcılar için aynıdır, çünkü Key kullanıcıya değil, AZUREADSSOACC hesabına aittir.

👉 SORU: "Madem Key tüm kullanıcılar için aynı, kullanıcının kim olduğu nasıl anlaşılıyor?"

👉 CEVAP: Kullanıcının kimliği, Service Ticket'ı şifreleyen Key'den değil, Ticket'ın içerisindeki şifrelenmiş bilgiden anlaşılır. Key sadece zarfı açar. İçerideki "bu kişi şu kullanıcıdır" bilgisi orada yazılıdır. Daha teknik bir ifadeyle, Microsoft Entra ID kullanıcıyı bulutta eşleştirmek için Kerberos biletindeki securityIdentifier claim'ini kullanır.

30 Günlük Key Rollover Önerisi

Microsoft, AZUREADSSOACC Computer hesabının Kerberos Decryption Key'inin en az 30 günde bir manuel olarak rollover edilmesini önerir. Bu işlem otomatik değildir ve Entra Connect sunucusunda AzureADSSO PowerShell modülü üzerinden Update-AzureADSSOForest cmdlet'i ile gerçekleştirilir. İşlem için hem Domain Admin hem de Hybrid Identity Administrator yetkisi gereklidir. Eğer rollover işlemini yürüten hesap Domain Admin değilse ve AZUREADSSOACC hesabını yönetmek için özel olarak delege edilmişse, cmdlet'in -PreserveCustomPermissionsOnDesktopSsoAccount parametresiyle çalıştırılması gerekir. Bu parametre, hesap üzerindeki custom ACL tanımlarının korunmasını sağlar. Aksi durumda cmdlet varsayılan ACL'leri yeniden uygular ve organizasyonun delegation modeli bozulabilir.

Rollover sırasında bir başka teknik nokta da Encryption Type'tır. Eğer AZUREADSSOACC hesabı RC4_HMAC_MD5 olarak yapılandırılmışsa ve AES256_HMAC_SHA1'e geçilmek isteniyorsa, önce Key Rollover yapılmalıdır. Encryption Type doğrudan değiştirildiğinde Seamless SSO çalışmayı durdurur. Microsoft, güvenlik açısından AES256_HMAC_SHA1 kullanılmasını önerir.

AZUREADSSOACC hesabı ve onu yöneten Entra Connect sunucusu, organizasyonun Tier 0 / Control Plane varlıkları arasında değerlendirilmeli ve buna uygun şekilde sıkılaştırılmalıdır. Bu hesabın Key'inin ele geçirilmesi, organizasyondaki tüm Entra ID kullanıcıları için Kerberos Service Ticket forge edilmesine olanak tanır. Bu nedenle Microsoft, hesap üzerinde Kerberos delegation'ın devre dışı bırakılmasını ve Domain Admins dışında hiçbir hesabın delegation iznine sahip olmamasını şart koşar.

Seamless SSO Akışı, Adım Adım Kerberos Mantığı

Seamless SSO'nun arka planda nasıl çalıştığını anlamak için, sürecin Windows oturum açma anından bulut servisine erişime kadar olan iki aşamasını ayrı ayrı incelemek gerekir.

Aşama 1- Windows'a Giriş (Standart Kerberos)

Kullanıcı işe gelir, masasındaki Domain-Joined iş bilgisayarını açar ve kullanıcı adı ile parolasıyla Windows'a giriş yapar. Bu anda bilgisayar arka planda standart Kerberos akışını işletir.

✔ AS-REQ: Kullanıcının parolasından bir Derived Key türetilir. Timestamp bu Key ile şifrelenir ve Cipher olarak Domain Controller (KDC) üzerine gönderilir.

✔ AS-REP: KDC doğrulamayı yapar, kullanıcıya bir Session Key ve Ticket-Granting Ticket (TGT) verir.

Kullanıcı bunların hiçbirinin farkında değildir. Sadece Windows oturumu açılmıştır. Bu noktaya kadar olan süreç, Seamless SSO'ya özel değildir. Her Domain-Joined Windows cihazında oturum açma sırasında aynı standart Kerberos akışı işler.

Aşama 2- Bulut Servisine Erişim (Seamless SSO Devreye Girer)

Kullanıcı, tarayıcıdan Outlook on the Web veya SharePoint Online gibi bir Entra ID korumalı uygulamaya erişmek ister. Bu noktadan itibaren Seamless SSO mekanizması devreye girer.

1- Entra ID Login Sayfasına Yönlendirme

Tarayıcı, Entra ID Login Endpoint'ine yönlendirilir. Entra ID, kullanıcının cihazının organizasyonun Managed Domain'ine ait olduğunu tespit eder ve https://autologon.microsoftazuread-sso.com adresine yönlendirme yapar. Bu URL, Group Policy üzerinden tarayıcının Intranet Zone'una eklenmiş olmalıdır.

2- Service Ticket Talebi

Kullanıcının iş bilgisayarı, Aşama 1'de almış olduğu TGT'yi kullanarak KDC'den (Domain Controller) bir Kerberos Service Ticket ister. Bu Ticket, AZUREADSSOACC hesabı için talep edilir.

3- AD Service Ticket Üretir

KDC üç işlemi sırayla gerçekleştirir.

✔ Bir Kerberos zarfı hazırlar ve içine "bu kişi şu kullanıcıdır" bilgisini (securityIdentifier claim'i ile birlikte) yazar.

✔ Bu zarfı, AZUREADSSOACC hesabının Kerberos Key'i ile şifreler (mühürler).

✔ Şifrelenmiş zarfı, kullanıcının bilgisayarına teslim eder.

4- Ticket Entra ID'ye İletilir

Kullanıcının bilgisayarı bu zarfı açamaz, çünkü AZUREADSSOACC Key'i kendisinde değildir. Bilgisayar, zarfı olduğu gibi Entra ID'ye iletir.

5- Entra ID Ticket'ı Decrypt Eder

Entra ID, kurulum sırasında kendisine kopyalanan AZUREADSSOACC Key'ini kullanarak Service Ticket'ı Decrypt eder. İçindeki securityIdentifier claim'ini okur, ilgili kullanıcıyı bulut tarafındaki kullanıcı nesnesi ile eşleştirir ve kimliği doğrular. Ardından erişim Token'ı üreterek uygulamaya teslim eder.

🎯 SONUÇ

Kullanıcı hiçbir yere parola girmemiştir. Sadece sabah Windows'a giriş yapmıştır. Gerisini bilgisayarı ve Entra ID kendi aralarında halletmiştir.

Standart Kerberos ile Seamless SSO Arasındaki Tek Fark

Standart Kerberos akışında kullanıcı, bir File Server'a erişmek istediğinde TGT'yi kullanarak File Server'ın AD hesabı için bir Service Ticket alır ve bu Ticket'ı File Server'a sunar. Seamless SSO'da ise kullanıcı bir bulut servisine erişmek istediğinde, aynı TGT'yi kullanarak AZUREADSSOACC hesabı için Service Ticket alır ve bu Ticket'ı Microsoft Entra ID'ye sunar.

Mekanizma birebir aynıdır. Tek fark, Ticket'ın kime hitaben yazıldığı (Target SPN) ve kime sunulduğudur. Microsoft'un kendi ifadesiyle, "Seamless SSO works the same way as any other sign-in that uses Integrated Windows Authentication (IWA)."

Seamless SSO Hangi Cihazlarda Çalışır, Hangilerinde Çalışmaz?

Seamless SSO'nun çalışma kapsamı, cihazın AD Join durumu ile doğrudan ilgilidir, çünkü mekanizma tamamen Kerberos tabanlıdır ve Kerberos TGT'nin alınabilmesi için cihazın on-premises Active Directory'ye Domain-Joined olması gerekir.

Entra Hybrid Joined & Entra Joined Cihazlar İçin Önemli Ayrım

Microsoft Entra Hybrid Joined cihazlar hem on-premises AD'ye hem de Entra ID'ye Join durumdadır. On-Prem AD'ye Join oldukları için Kerberos TGT alabilirler ve teknik olarak Seamless SSO çalışabilir. Ancak modern Windows 10/11 Hybrid Joined cihazlarda Microsoft, Primary Refresh Token (PRT) mekanizmasını önerir. Microsoft Entra Hybrid Joined cihazlar hem on-premises AD'ye hem de Entra ID'ye Join durumdadır ve On-Prem AD'ye Join oldukları için Kerberos TGT alabilirler ve teknik olarak Seamless SSO çalışabilir. Ancak modern Windows 10/11 Hybrid Joined cihazlarda Microsoft, Primary Refresh Token (PRT) mekanizmasını önerir ve resmi dokümantasyonunda önceliklendirme kuralını doğrudan tanımlar. Bir cihazda hem PRT hem Seamless SSO etkin olduğunda, Microsoft Entra Join üzerinden gelen PRT tabanlı SSO her zaman Seamless SSO'dan önce devreye girer.

Microsoft Entra Joined (Cloud Joined) cihazlar ise yalnızca Entra ID'ye Join durumdadır. On-Prem AD ile herhangi bir ilişkileri yoktur. Bu cihazlarda AD'den Kerberos TGT alınamaz, dolayısıyla Seamless SSO da çalışmaz. Ancak bu durum bir eksiklik değildir, çünkü Cloud Joined cihazlarda Seamless SSO'ya zaten ihtiyaç yoktur. Bu cihazlar Windows oturum açma sırasında doğrudan Entra ID kimliğiyle giriş yapar ve bir PRT (Primary Refresh Token) alır. PRT, bulut tarafında TGT'nin yaptığı işin karşılığıdır. Kullanıcı bir kez giriş yapar, sonrasında bulut servislerine parola girmeden erişir.

Seamless SSO'nun Çalışmadığı Senaryolar

Microsoft Seamless SSO'yu opportunistic bir özellik olarak adlandırır. Aşağıdaki durumlarda devreye giremez ve akış kullanıcıdan parola istemeye düşer.

✔ Non-Domain-Joined cihazlardan erişim (kişisel bilgisayar, telefon, BYOD).

✔ Dış ağdan (kurumsal Network dışından) erişim. Domain Controller'a Kerberos isteği gönderilemediği için.

✔ Time skew. Cihaz ile Domain Controller arasındaki zaman farkı 5 dakikayı aştığında.

✔ IWA desteklemeyen ya da yapılandırılmamış tarayıcı. macOS ve Linux üzerindeki varsayılan tarayıcılar veya GPO'ları uygulanmamış istemciler.

✔ Internet Explorer Enhanced Protected Mode. Microsoft Learn açıkça belirtir, EPM açıkken Seamless SSO çalışmaz.

✔ Conditional Access tarafından zorlanan MFA challenge. Seamless SSO username'i otomatik doldurabilir, ancak MFA'nın gerektirdiği ek doğrulama adımı için kullanıcı parolasını veya MFA factor'ünü girer.

✔ Modern Authentication kullanmayan eski protokoller (POP, IMAP ile Basic Auth gibi legacy protokoller).

Bu durumların hiçbirinde Seamless SSO çalışmadığı için akış, Tenant'ın aktif sign-in method'una (PHS veya PTA) düşer ve parola tabanlı doğrulama bu method üzerinden gerçekleşir.

Domain-Joined Cihazlar İçin Zorunlu GPO Yapılandırması

Entra Connect Sync sihirbazında Enable single sign-on seçeneğinin işaretlenmesi ve on-premises Active Directory üzerinde AZUREADSSOACC Computer hesabının oluşturulması, Seamless SSO'nun çalışmaya hazır hale gelmesi için tek başına yeterli değildir. Bu adımlar yalnızca sunucu tarafı yapılandırmasını tamamlar. Mekanizmanın istemci tarafında devreye girebilmesi için, kullanıcı cihazlarındaki tarayıcının üç farklı Group Policy ayarı üzerinden doğru şekilde yapılandırılmış olması gerekir.

Bu ayarlar sayesinde tarayıcı, Kerberos Service Ticket'ı autologon.microsoftazuread-sso.com Endpoint'ine otomatik olarak gönderebilir. Aksi halde Kerberos Ticket güvenli olmayan bir Endpoint'e iletilmez ve kullanıcıdan parola istenmeye geri dönülür.

Söz konusu üç GPO ayarı, kurumsal Naming Convention disiplinine uygun şekilde tek bir GPO nesnesi içinde organize edilebilir. Aşağıdaki örnekte bu nesne Seamless-SSO-Configuration adıyla oluşturulmuş ve Ist-All-Departments OU'suna link edilmiştir. Üç ayarın da User Configuration altında uygulanması, Microsoft Learn'in resmi Quickstart: Microsoft Entra seamless single sign-on dokümantasyonunda belirtilen yapılandırma yoluyla birebir örtüşür ve aynı zamanda Registry Item GPP'nin (HKEY_CURRENT_USER hive'ı kullandığı için) doğal olarak User Configuration altında bulunması nedeniyle bütünlük sağlar.

Naming Convention disiplinine sahip kurumsal ortamlarda bu yapı, scope ayrımı amacıyla birden fazla GPO nesnesine de bölünebilir. Ancak böyle bir bölünme tercih edildiğinde aynı policy'nin (örneğin Site to Zone Assignment List) birden fazla GPO içinde tanımlanmasından kaçınılmalıdır. Bunun nedeni bir sonraki bölümde detaylı olarak açıklanmıştır.

Yukarıdaki Group Policy Management ekranında Seamless-SSO-Configuration GPO nesnesinin Ist-All-Departments OU'suna link edilmiş olduğu, Security Filtering alanında varsayılan Authenticated Users grubunun bulunduğu ve nesnenin organizasyonun mevcut baseline GPO hiyerarşisi içinde konumlandığı görülmektedir. GPO nesnesi oluşturulup ilgili OU'ya link edildikten sonra sıra, içerisinde tanımlanması gereken üç ayrı Policy ayarına gelir. Aşağıdaki adımlar Microsoft Learn'in resmi dokümantasyonunda belirtilen sıraya göre uygulanır.

1- Site to Zone Assignment List Policy

Bu Policy, autologon.microsoftazuread-sso.com URL adresinin tarayıcının Intranet Zone'una dahil edilmesini sağlar. Yapılandırma yolu aşağıdaki gibidir.

İlgili Policy'ye gelindiğinde, varsayılan olarak Not configured durumunda olduğu görülür.

Policy üzerine çift tıklanarak açılan pencerede Enabled seçeneği işaretlenir ve Options bölümündeki Show... butonuna tıklanır.

Açılan Show Contents penceresinde Value name kolonuna https://autologon.microsoftazuread-sso.com URL adresi, Value kolonuna ise Intranet Zone'u ifade eden 1 değeri girilir.

https://autologon.microsoftazuread-sso.com  →  1

Yapılandırma tamamlandıktan sonra Policy'nin State kolonu Enabled olarak güncellenir.

2- Allow Updates to Status Bar via Script Policy

Bu Policy, Seamless SSO'nun JavaScript tabanlı transparent Authentication akışının düzgün çalışması için gereklidir. Tarayıcının status bar üzerinden script güncellemelerine izin vermesi sağlanır.

Yapılandırma yolu aşağıdaki gibidir.

İlgili Policy'ye gelindiğinde, varsayılan olarak Not configured durumunda olduğu görülür.

Policy üzerine çift tıklanarak açılan pencerede Enabled seçeneği işaretlenir ve Options bölümündeki Status bar updates via script dropdown menüsünden Enable seçilir.

Yapılandırma tamamlandıktan sonra Policy'nin State kolonu Enabled olarak güncellenir.

3- Registry Item Group Policy Preference

Site to Zone Assignment List Policy'sinin başka GPO'lar tarafından override edilebileceği veya çoklu GPO katmanlarının bulunduğu kompleks ortamlarda Microsoft, ek olarak Group Policy Preferences üzerinden Registry tabanlı bir kayıt da önerir. Bu kayıt, Internet Explorer ZoneMap yapılandırma ayarlarını doğrudan Registry seviyesinde tanımlayarak Intranet Zone atamasının her koşulda korunmasını garanti altına alır. Bir önceki bölümde belirtilen merge davranışı nedeniyle bu adım, özellikle birden fazla baseline GPO'nun aynı OU üzerinde uygulandığı ortamlarda kritik bir güvence katmanı sağlar.

Yapılandırma yolu aşağıdaki gibidir.

Açılan New Registry Properties penceresinde aşağıdaki değerler tanımlanır.

Action      : Update
Hive        : HKEY_CURRENT_USER
Key Path    : Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon
Value Name  : https
Value Type  : REG_DWORD
Value Data  : 00000001

Kayıt oluşturulduktan sonra Registry Preference listesi aşağıdaki şekilde görüntülenir. Action kolonu Update, Hive kolonu HKEY_CURRENT_USER ve Type kolonu REG_DWORD olarak işaretli olmalıdır.

Tarayıcı Bazlı Yapılandırma Notları

Yukarıdaki Group Policy ayarları, Windows seviyesindeki Internet Settings yapılandırma ayarlarını okuyan tüm tarayıcılar için geçerlidir. Ancak her tarayıcı bu ayarı aynı şekilde kullanmaz ve bazı tarayıcılar için ek yapılandırma gerekir.

Normal Pencere

Private Mode

Private Mode davranışını anlamak için önce Ambient Authentication kavramına değinmek gerekir. Ambient Authentication, tarayıcının kullanıcıya parola sormadan otomatik olarak gönderdiği kimlik bilgilerini ifade eder. Bu kimlik bilgileri üç türde olabilir. Kerberos bileti, Active Directory'den alınan TGT üzerinden üretilen Service Ticket. NTLM kimlik bilgileri, Integrated Windows Authentication akışında otomatik gönderilen hash. Client TLS sertifikaları, kullanıcının sertifika store'unda bulunan ve karşı tarafa otomatik sunulan kimlik sertifikaları. Seamless SSO'nun "sessiz oturum açma" davranışı, bu mekanizmaların birincisine, yani Kerberos biletine dayanır.

Chromium tabanlı tarayıcılar (Google Chrome, Brave, Vivaldi vb.), private/incognito modlarında varsayılan olarak Ambient Authentication'ı bloklar. Bunun nedeni mahremiyet vaadidir. Kullanıcı Private Modeu kimliğini ifşa etmeden gezinmek için tercih ettiğinde, tarayıcının arka planda otomatik kimlik bilgisi göndermesi bu vaadi anlamsız hale getirir. Bu nedenle Chromium ekibi, 2020 civarında Private Mode'da Ambient Auth'u varsayılan olarak engellemeye başlamıştır.

Microsoft Edge, aynı Chromium kod tabanı üzerine inşa edilmiş olmasına rağmen InPrivate ve Guest modlarında Ambient Authentication'a varsayılan olarak izin verir. Bu, Microsoft mühendislerinin bilinçli bir tasarım kararıdır. Kurumsal müşterilerin InPrivate kullanırken bile Microsoft 365'e sorunsuz oturum açabilmesi öncelikli tutulmuştur.

Kurumsal Seamless SSO senaryolarında, Chromium'ın varsayılan bloklaması bir sorun yaratır. Çünkü çalışanlar Incognito modda da Microsoft 365'e erişebilmelidir. Bu davranış AmbientAuthenticationInPrivateModesEnabled policy'si ile aşağıdaki tablo doğrultusunda yapılandırılabilir.

GPO'lar uygulandıktan sonra istemci cihazlarda gpupdate /force komutu çalıştırılarak yapılandırmanın anında devreye girmesi sağlanır. Komut çalıştırıldıktan sonra tarayıcının kapatılıp yeniden açılması veya kullanıcının oturumunu kapatıp yeniden açması, ayarların tarayıcı tarafından okunması açısından gereklidir. Doğrulama için Internet Options → Security → Local Intranet → Sites → Advanced ekranında autologon.microsoftazuread-sso.com adresinin listede yer aldığı kontrol edilebilir. Ardından https://myapps.microsoft.com adresine erişildiğinde parola istenmeden oturum açılıyorsa Seamless SSO çalışıyor demektir.

Yapılandırmanın Doğrulanması

Yapılandırmanın başarılı şekilde uygulandığını doğrulamak için Domain-Joined bir cihazda aşağıdaki adımlar takip edilebilir.

✔ Internet Options ekranı kontrolü: Internet Explorer veya Microsoft Edge'in Internet Options > Security sekmesinde Local Intranet zone seçilir, Sites > Advanced butonuna tıklanır ve https://autologon.microsoftazuread-sso.com URL'inin listede yer aldığı doğrulanır.

✔ Tarayıcı testi: Domain-Joined cihazdan https://myapps.microsoft.com veya https://outlook.office.com adresine gidilir. Eğer Seamless SSO doğru yapılandırılmışsa kullanıcıdan ne kullanıcı adı ne de parola istenir. Oturum sessizce açılır.

✔ Kerberos Ticket kontrolü: Komut satırında klist komutu çalıştırıldığında, çıktı arasında HTTP/autologon.microsoftazuread-sso.com SPN'i için bir Service Ticket görülmelidir. Bu, Kerberos akışının doğru şekilde işlediğinin kanıtıdır.

✔ Sign-in Logs kontrolü: Microsoft Entra Admin Center > Users > Sign-in logs üzerinden ilgili kullanıcının non-interactive sign-in kayıtlarında Authentication Method Detail alanında Seamless SSO ile ilgili bir kayıt bulunmalıdır.

Entra ID'nin Login Karar Akışı, Hiçbir Zaman "İkisini de Dene" Yoktur

Seamless SSO konusunda en yaygın yanlış anlamalardan biri, "PHS ve PTA birlikte etkinse, Entra ID önce birini dener, başarısız olursa diğerine düşer" varsayımıdır. Bu kesinlikle yanlıştır. Microsoft Entra Pass-through Authentication FAQ dokümantasyonu net biçimde belirtir. "Pass-through Authentication doesn't automatically failover to password hash synchronization."

Entra ID, Login isteği geldiğinde şu deterministik karar akışını işletir.

Login isteği geldi (UPN: user@contoso.com, parola)
    │
    ▼
Entra ID, contoso.com domain'inin AuthenticationType'ı ne?
    │
    ├─ Federated  ─→  ADFS'e redirect
    │
    └─ Managed    ─→  Devam
                       │
                       ▼
                   Bu kullanıcı Staged Rollout'ta mı?
                       │
                       ├─ Evet, PHS grubunda  ─→  PHS akışı
                       │
                       ├─ Evet, PTA grubunda  ─→  PTA akışı
                       │
                       └─ Hayır  ─→  Tenant default method
                                       │
                                       ├─ PHS ise  ─→  PHS akışı
                                       │
                                       └─ PTA ise  ─→  PTA akışı

Hiçbir noktada "ikisini de dene" veya "biri başarısız olursa diğerine düş" mantığı yoktur. Tenant'ın tek bir aktif sign-in method'u vardır ve parola tabanlı kimlik doğrulama her zaman bu method üzerinden gerçekleşir.

Peki PHS ve PTA Birlikte Seçildiğinde Ne Olur?

Entra Connect Sync kurulum Wizard'ında, User Sign-In adımında PTA seçildikten sonra Optional Features adımında Password Hash synchronization Checkbox'ı da işaretlenebilir. Bu yapılandırma, iki farklı katmanı temsil eder.



✔ User Sign-In adımındaki PTA seçimi: Tenant'ın active sign-in method'unu PTA olarak belirler. Yani kullanıcı parola girdiğinde doğrulama On-Prem AD'ye gider.

✔ Optional Features adımındaki PHS seçimi: Sadece Hash senkronizasyon motorunu (engine) etkinleştirir. Sign-in method'u değiştirmez. PHS bu konfigürasyonda "hot standby" rolündedir.

Bu kombinasyon, Microsoft'un PTA dokümantasyonunda şiddetle tavsiye ettiği production pattern'idir ve resmi adıyla "PHS as a backup Authentication option" olarak bilinir.

PTA + PHS Backup Konfigürasyonunun Üç Temel Faydası

1- Disaster Recovery, Anlık Manuel Failover Hazırlığı

PTA altyapısı çökerse (tüm Authentication Agent'lar erişilemez, On-Prem AD down, network kopması vb.), admin PowerShell veya Entra Connect Wizard ile sign-in method'unu PHS'e çevirebilir. PHS Hash'leri Entra ID'de zaten senkronize halde olduğu için switch işlemi anında etki eder ve kullanıcılar bulut kaynaklarına erişmeye devam eder.

Eğer Optional Features adımında PHS işaretli olmasaydı, bu komut çalıştırıldığında Hash'ler Entra ID'de bulunmadığı için kullanıcılar oturum açamayacaktı. Önce PHS'in etkinleştirilmesi, Hash'lerin senkronize olması beklenmeli, sonra method değiştirilmeli olurdu. Bu da DR senaryosunda kabul edilemez bir gecikme demektir.

2- Leaked Credentials Detection

Microsoft Entra ID Identity Protection içindeki Leaked Credentials Detection özelliği, dark web'de sızdırılmış credential'ları Entra ID'deki PHS Hash'leri ile karşılaştırır. Bu özellik, PHS Hash'leri olmadan çalışmaz. Microsoft'un PHS dokümantasyonu açıkça belirtir, sızıntı tespiti yalnızca PHS etkinleştirildikten sonra bulunan yeni sızıntılar için çalışır.

PTA tek başına çalışırken (PHS olmadan) bu detection devre dışıdır. Ancak Optional Features'da PHS işaretliyse, Hash'ler senkronize olur ve detection aktif hale gelir.

3- Cyber Resiliency, Hybrid Identity'nin Sigortası

Production ortamlarda PHS backup'ı, organizasyonun cyber resilience stratejisinin temel parçasıdır. Bir ransomware saldırısı On-Prem AD'yi vurduğunda.

✔ PTA tek başınaysa → Microsoft 365 erişimi de kesilir. Kullanıcılar bulut kaynaklarına erişemez, incident response süreci çok daha zor yürütülür.

✔ PTA + PHS backup ise → Admin sign-in method'unu PHS'e çevirir, kullanıcılar M365'e erişmeye devam eder, incident response süreci bulut kaynaklarıyla yürütülebilir.

PTA İçin Yüksek Erişilebilirlik (HA) Gereksinimleri

Microsoft Learn'in PTA Quickstart dokümantasyonu, production ortamlar için minimum 3 Authentication Agent kurulmasını önerir (Tenant başına sistem limiti 40 Agent'tır). Authentication Agent kurulu olan tüm sunucular Tier 0 sistem olarak değerlendirilmeli ve Domain Controller'lar için uygulanan sıkılaştırma stratejisi ile aynı şekilde korunmalıdır. Authentication Agent'lar, Microsoft Entra ID'ye Service Bus üzerinden persistent HTTPS bağlantısı (TCP 443) kurar ve gelen istekleri polling ile değil, sürekli açık bu bağlantı üzerinden çeker.

Cloud-Only Break-Glass Admin Hesabı Zorunluluğu

PTA kullanıldığı senaryolarda Microsoft, kurulum Wizard'ının User Sign-In ekranında açıkça şu uyarıyı yapar.

Bu uyarı, doğrudan DR senaryosuyla ilgilidir. PTA çökerse, On-Prem hesabınızla Entra ID'ye giriş yapıp PHS'e geçiş yapamazsınız, çünkü tüm Authentication zaten PTA'ya bağlıdır. Bu nedenle.

✔ Cloud-Only (yani On-Prem'de karşılığı olmayan) bir admin hesabı oluşturulmalıdır.

✔ Bu hesaba Hybrid Identity Administrator veya Global Administrator rolü atanmalıdır.

✔ Hesap break-glass account olarak güvenli bir yerde saklanmalı (FIDO2 Security Key veya Temporary Access Pass ile korunarak).

✔ Microsoft'un best practice'i, en az 2 break-glass hesap, farklı kimlik doğrulama yöntemleriyle korunmuş halde tutulmalıdır.

Senaryo Karşılaştırması, PHS + Seamless SSO vs PTA + Seamless SSO

Burada anlaşılması kritik olan nokta şudur. "PHS + Seamless SSO" ve "PTA + Seamless SSO" kombinasyonları aynı Tenant'ın iki farklı durumu değildir, iki ayrı Tenant konfigürasyonunu temsil eder.

Senaryo 1, PHS + Seamless SSO

Domain-Joined Computer, kurumsal Network içinden:

Bu kombinasyonda Tenant'ın aktif sign-in method'u Password Hash Synchronization'dır. On-Prem Active Directory'deki kullanıcı parolalarının NT hash'leri (MD4), per-user salt ile birleştirilip PBKDF2 fonksiyonundan 1.000 iterasyon HMAC-SHA256 ile geçirildikten sonra Microsoft Entra ID'ye TLS üzerinden senkronize edilir. Bu yapıda parola tabanlı kimlik doğrulama tamamen bulut tarafında gerçekleştirilir.

Seamless SSO ise bu mimarinin yanında ayrı bir Kerberos tabanlı kimlik doğrulama katmanı olarak çalışır. Domain-Joined cihazlardan gelen erişimleri Kerberos bileti üzerinden parolasız hale getirir. Seamless SSO devrede olduğu sürece PHS Hash'leri kullanılmaz.

Aşağıdaki diyagram, PHS mimarisinin temel akışını ve opsiyonel Password Writeback yönünü gösterir. Kullanıcının cihazının Domain-Joined olup olmamasına göre kimlik doğrulama akışı iki farklı yol izler.



Kullanıcı, On-Prem AD'ye Domain-Joined olan iş bilgisayarından Entra ID korumalı bir uygulamaya eriştiğinde, tarayıcı arka planda Kerberos Service Ticket'ı otomatik olarak autologon.microsoftazuread-sso.com Endpoint'ine iletir. Entra ID, AZUREADSSOACC hesabının paylaşılan Key'i ile Ticket'ı Decrypt eder ve kullanıcının kimliğini Kerberos üzerinden doğrular. Bu akışta parola hiç devreye girmediği için PHS Hash'leri kullanılmaz, kimlik doğrulama tamamen Kerberos üzerinden tamamlanır.

Kullanıcı  ─→  Entra ID Login page
                    │
                    ▼
Tarayıcı   ─→  autologon.microsoftazuread-sso.com
                    │
                    ▼
Kerberos Ticket otomatik gönderilir
                    │
                    ▼
Entra ID Ticket'ı AZUREADSSOACC Key'i ile açar
                    │
                    ▼
✅ Kimlik doğrulandı (PHS devreye GİRMEDİ)
                    │
                    ▼
Token issue edilir

Non-Domain-Joined Computer veya Dış Ağ (Seamless SSO Çalışmaz):

Kullanıcı, kişisel bir cihazdan veya kurumsal Network dışından Entra ID'ye eriştiğinde Domain Controller'a Kerberos isteği gönderemez, dolayısıyla Seamless SSO devreye giremez. Bu durumda kullanıcı, Entra ID Login sayfasında kullanıcı adı ve parolasını manuel olarak girer. Entra ID, girilen parolayı aynı MD4 + salt + PBKDF2 + HMAC-SHA256 dönüşümünden geçirir ve bulutta sakladığı hash ile karşılaştırır. Doğrulama tamamen bulut tarafında gerçekleşir, On-Prem AD'ye herhangi bir bağlantı kurulmaz.

Kullanıcı  ─→  Entra ID Login page
                    │
                    ▼
Kullanıcı adı + parola girer
                    │
                    ▼
Entra ID, parolayı aynı dönüşümden geçirir ve hash ile karşılaştırır
                    │
                    ▼
✅ Kimlik doğrulandı (PHS akışı)
                    │
                    ▼
Token issue edilir

Senaryo 2, PTA + Seamless SSO

Domain-Joined Computer, kurumsal Network içinden:

Bu kombinasyonda Tenant'ın aktif sign-in method'u Pass-through Authentication'dır. Parola Hash'leri Entra ID'ye senkronize edilmez. Bunun yerine kullanıcının girdiği parola, on-premises Active Directory üzerinde kurulu Authentication Agent tarafından gerçek zamanlı olarak Domain Controller'a iletilerek doğrulanır. Bu mimaride parola hiçbir zaman buluta kalıcı olarak taşınmaz, yalnızca doğrulama anında Service Bus üzerinden Agent'ın public key'i ile şifrelenmiş şekilde iletilir ve On-Prem AD'de validate edilir.

Seamless SSO ise bu mimarinin yanında ayrı bir Kerberos tabanlı kimlik doğrulama katmanı olarak çalışır. Domain-Joined cihazlardan gelen erişimleri Kerberos bileti üzerinden parolasız hale getirir.

Aşağıdaki diyagram, PTA mimarisinin temel akışını gösterir. Kullanıcının cihazının Domain-Joined olup olmamasına göre kimlik doğrulamanın hangi katmanda gerçekleştiği farklılık gösterir.



Bu senaryoda kimlik doğrulama akışı, Senaryo 1 ile birebir aynı şekilde işler. Domain-Joined cihazdan yapılan erişimde tarayıcı Kerberos Ticket'ı otomatik gönderir, Entra ID Ticket'ı AZUREADSSOACC Key'i ile Decrypt eder ve kimlik doğrulanır. Tenant'ın aktif sign-in method'u PTA olmasına rağmen, Seamless SSO başarılı olduğu için Authentication Agent'a herhangi bir istek iletilmez ve On-Prem AD'ye doğrulama trafiği gitmez.

Kullanıcı  ─→  Entra ID Login page
                    │
                    ▼
Tarayıcı   ─→  autologon.microsoftazuread-sso.com
                    │
                    ▼
Kerberos Ticket otomatik gönderilir
                    │
                    ▼
Entra ID Ticket'ı AZUREADSSOACC Key'i ile açar
                    │
                    ▼
✅ Kimlik doğrulandı (PTA devreye GİRMEDİ)
                    │
                    ▼
Token issue edilir

Non-Domain-Joined Computer veya Dış Ağ (Seamless SSO Çalışmaz):

Seamless SSO devre dışı kaldığında ve kullanıcı parolasını manuel girdiğinde, Tenant'ın aktif sign-in method'u olan PTA devreye girer. Microsoft Entra Security Token Service (Entra STS), Tenant'a kayıtlı tüm Authentication Agent'ların public key'lerini Azure SQL Database'den çeker ve parolayı her Agent için ayrı ayrı şifreler. Şifrelenmiş parola değerleri, Tenant'a özel Service Bus queue'una yerleştirilir. Bu queue'ya persistent bağlantı kurmuş olan Authentication Agent'lardan biri talebi alır, kendi private key'i ile parolayı Decrypt eder ve LogonUser Win32 API çağrısını LOGON32_LOGON_NETWORK Logon Type'ı ile kullanarak On-Prem Domain Controller'a doğrulama isteği gönderir. DC'den dönen sonuç (success, failure, password Expired, user locked out) Entra ID'ye iletilir ve Token üretimi buna göre yapılır.

Kullanıcı  ─→  Entra ID Login page
                    │
                    ▼
Kullanıcı adı + parola girer
                    │
                    ▼
Entra STS, parolayı her Agent'ın public key'i ile şifreler
                    │
                    ▼
Şifreli parola değerleri, Service Bus queue'una yerleştirilir
                    │
                    ▼
Authentication Agent persistent connection üzerinden talebi alır
                    │
                    ▼
Agent private key ile Decrypt eder ─→ LogonUser API ─→ On-Prem DC
                    │
                    ▼
✅/❌ Sonuç Entra ID'ye döner (success / failure / Expired / locked)
                    │
                    ▼
Token issue edilir (başarılıysa)

Hangi Kombinasyon Hangi Senaryoda Tercih Edilmeli?

PHS + Seamless SSO Tercih Edilir Çünkü:

✔ On-Prem altyapıya kimlik doğrulama için bağımlılık yoktur.

✔ Disaster Recovery senaryolarında bulut kaynaklarına erişim devam eder.

✔ Leaked Credentials Detection çalışır.

✔ Authentication Agent yönetimi, patch cycle, HA tasarımı gibi operasyonel yükler yoktur.

✔ Microsoft'un stratejik yönelimi bu yöndedir.

PTA + Seamless SSO Tercih Edilir Çünkü:

✔ Regulatory / compliance gereksinimi parolanın On-Prem'de doğrulanmasını zorunlu kılıyor.

✔ On-Prem Logon Restrictions (logon hours, workstation restrictions) gerçek zamanlı uygulanmalı.

✔ Organizasyon, parola Hash'inin buluta çıkmasına politika olarak izin vermiyor.

✔ Hesap disable / password reset işlemlerinin anında etki etmesi kritik.

Microsoft'un Stratejik Tutumu

Microsoft, 2020'lerin başından itibaren resmi dokümantasyonunda şu öneriyi netleştirmiştir. Özel bir gereksinim olmadıkça PHS + Seamless SSO tercih edilmelidir. Migration best practices dokümantasyonu doğrudan şu ifadeyi kullanır. "We recommend using PHS for cloud Authentication."

Bunun temel sebebi sadece operasyonel basitlik değil, aynı zamanda Cyber Resiliency'dir. On-Prem AD bir ransomware saldırısına uğradığında, PHS ile kullanıcılar Microsoft 365'e hala erişebilir ve incident response süreci bulut kaynaklarıyla yürütülebilir. PTA tek başına kullanıldığında bu mümkün değildir.

Bilinen Sınırlamalar ve Dikkat Edilmesi Gereken Noktalar

✔ AZUREADSSOACC Key rollover 30 günde bir manuel olarak yapılmalıdır. Update-AzureADSSOForest cmdlet'i aynı Forest için arka arkaya birden fazla kez çalıştırılmamalıdır. Aksi durumda Kerberos biletleri Expire olana kadar Seamless SSO durur.

✔ Seamless SSO Non-Domain-Joined cihazlarda, kurumsal Network dışından yapılan erişimlerde, time skew 5 dakikayı aştığında ve Integrated Windows Authentication desteklemeyen tarayıcılarda çalışmaz. Bu durumda Tenant'ın active sign-in method'u (PHS veya PTA) devreye girer.

✔ Seamless SSO, Modern Authentication (OAuth2 / OpenID Connect) gerektirir. Basic Auth ile çalışan POP / IMAP gibi legacy protokoller Seamless SSO'dan yararlanamaz. Microsoft 365 ortamlarında Basic Auth zaten büyük ölçüde deprecated durumdadır.

✔ Microsoft Entra Hybrid Join ve Microsoft Entra Join yaygınlaştığında, Primary Refresh Token (PRT) Seamless SSO'nun yerini büyük ölçüde alır. Microsoft Learn açıkça belirtir, hem PRT hem Seamless SSO etkinse PRT önceliklidir.

✔ PTA + PHS birlikte enabled olsa bile, Tenant sign-in method'u hangisiyse trafiği o alır. Diğeri sadece hot standby olarak hazır bekler.

✔ Cloud-Only hesaplar (On-Prem karşılığı olmayan, örneğin break-glass admin hesapları) her zaman cloud Authentication kullanır, sign-in method ayarından etkilenmez.

✔ İki sign-in method'unu aynı anda farklı kullanıcılar için test etmek için kullanılan Staged Rollout, Microsoft tarafından geçici bir test aracı olarak tanımlanmıştır. Kalıcı bir mimari değildir ve cutover tamamlandıktan sonra devre dışı bırakılmalıdır.

✔ Mandatory Upgrade: Microsoft Entra Connect Sync, 30 Eylül 2026 tarihine kadar minimum 2.5.79.0 sürümüne yükseltilmelidir. Bu tarihten sonra eski sürümlerde tüm senkronizasyon servisleri durur. Bu kısıtlama Seamless SSO'yu da kapsayan tüm Entra Connect altyapısını etkiler.

Konfigürasyon Doğrulaması

PTA + PHS backup + Seamless SSO konfigürasyonu doğru kurulduğunda, Microsoft Entra Admin Center > Microsoft Entra Connect sayfasında şu durum gözlemlenmelidir.

✔ Pass-through Authentication: Enabled

✔ Password Hash Sync: Enabled

✔ Seamless single sign-on: Enabled

Burada her iki sign-in method'un da "Enabled" görünmesi, ikisinin de paralel çalıştığı anlamına gelmez. Sadece her ikisinin de etkinleştirilmiş olduğunu, yani PTA aktif method olarak çalışırken PHS Hash'lerinin de buluta senkronize edildiğini gösterir.

Key Takeaways

✔ Seamless SSO bir sign-in method değildir, ancak teknik olarak Kerberos tabanlı bir kimlik doğrulama katmanıdır. PHS veya PTA ile birlikte konumlanır, ancak alternatifi değildir.

✔ Seamless SSO devreye girdiğinde kimlik doğrulama tamamen Kerberos üzerinden tamamlanır ve ne PHS ne de PTA devreye girer. Microsoft bu mekanizmayı opportunistic olarak adlandırır.

✔ Sign-in method farkı (PHS vs PTA), yalnızca Seamless SSO devre dışı kaldığında (kişisel cihaz, dış ağ, time skew, IWA desteklemeyen tarayıcı vb.) ortaya çıkar.

✔ Seamless SSO etkinleştirildiğinde, On-Prem AD'de otomatik olarak AZUREADSSOACC Computer hesabı oluşturulur. Bu hesabın Kerberos Decryption Key'i Entra ID'ye kopyalanır ve mekanizmanın temelini oluşturur. Birden fazla Forest varsa, her Forest kendi benzersiz Key'ine sahip kendi hesabını alır.

✔ AZUREADSSOACC Key'i 30 günde bir manuel olarak rollover edilmelidir. İşlem Update-AzureADSSOForest cmdlet'i ile yapılır ve aynı Forest için arka arkaya iki kez çalıştırılmamalıdır.

✔ Microsoft, AZUREADSSOACC için AES256_HMAC_SHA1 şifreleme türünü önerir. RC4'ten AES'e geçişten önce mutlaka Key Rollover yapılmalıdır.

✔ Entra ID, Login sırasında "ikisini de dene" mantığı uygulamaz. Tenant'ın tek bir aktif sign-in method'u vardır ve PTA'dan PHS'e otomatik failover bulunmaz.

✔ Production'da PTA kullanılıyorsa, PHS'in Optional Features adımında backup olarak mutlaka enable edilmesi gerekir. Bu DR, Leaked Credentials Detection ve Cyber Resiliency için kritiktir.

✔ PTA kullanılan ortamlarda Cloud-Only break-glass admin hesabı zorunludur. PTA tüm Authentication'a hakimken On-Prem'e bağımlı bir admin hesabıyla DR yönetilemez. Microsoft, en az 2 break-glass hesap kullanılmasını best practice olarak önerir.

✔ Production PTA ortamlarında minimum 3 Authentication Agent kurulmalı ve bu sunucular Tier 0 sistem olarak sıkılaştırılmalıdır.

✔ Microsoft'un güncel stratejik tavsiyesi, özel bir gereksinim yoksa PHS + Seamless SSO tercih edilmelidir. Cyber Resiliency açısından PHS açık ara daha dayanıklıdır.

✔ Microsoft Entra Hybrid Joined ve Microsoft Entra Joined cihazlarda PRT (Primary Refresh Token) mekanizması devreye girer ve Seamless SSO'nun yerini alır. Microsoft Learn, her ikisi etkin olduğunda PRT'nin önceliğe sahip olduğunu açıkça belirtir.

Bu makalede Microsoft Entra ID ortamlarında Seamless SSO'nun ne olduğunu, hangi protokol üzerinde çalıştığını ve Wizard düzeyinde neden bir sign-in method olarak konumlandırılmadığını detaylıca inceledik. Seamless SSO'nun temelinde Entra Connect Sync kurulumu sırasında on-premises Active Directory üzerinde otomatik olarak oluşturulan AZUREADSSOACC Computer hesabının yattığını ve bu hesabın Kerberos şifreleme anahtarının Domain-Joined cihazlardan gelen Service Ticket'ları Entra ID tarafında Decrypt etmek için kullanıldığını ele aldık.

Seamless SSO ile sıkça karıştırılan Password Hash Synchronization ve Pass-through Authentication'ın birer sign-in method olduğunu, bir Tenant'ta aynı anda yalnızca birinin aktif olduğunu ve Entra ID'nin "ikisini de dene" mantığı uygulamadığını netleştirdik. Seamless SSO başarılı olduğunda kimliğin Kerberos üzerinden doğrulandığını, dolayısıyla ne PHS ne de PTA'nın devreye girdiğini, bu iki yöntemin yalnızca Seamless SSO'nun çalışmadığı durumlarda fallback olarak aktif hale geldiğini gördük.

PTA kullanılan production ortamlarda PHS'in backup olarak etkinleştirilmesinin neden zorunlu olduğunu, Cloud-Only break-glass admin hesabının Disaster Recovery senaryolarındaki kritik rolünü ve Microsoft'un cyber resiliency perspektifinden neden PHS + Seamless SSO kombinasyonunu tercih ettiğini açıkladık. Modern Microsoft Entra Hybrid Joined ve Microsoft Entra Joined cihazlarda ise Primary Refresh Token mekanizmasının Seamless SSO'nun yerini büyük ölçüde aldığını, ancak klasik Domain-Joined cihaz parkına sahip ortamlar için bu mekanizmanın hala kritik bir Kerberos tabanlı kimlik doğrulama katmanı olduğunu vurguladık.

Faydalı olması dileğiyle...