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

Hibrit kimlik mimarisi kuran çoğu sistem yöneticisi şu sahneyi yaşamıştır. Sabah ofise gelen bir kullanıcı bilgisayarını açar, Windows'a giriş yapar ve birkaç dakika sonra tarayıcısından Outlook Web'i, SharePoint Online'ı veya OneDrive'ı açar. Hiçbir yere parola girmemiştir. Her şey arka planda sessizce halledilmiştir.

Peki gerçekten ne olmuştur? Kullanıcının kimliği nasıl doğrulanmıştır? Password Hash Synchronization (PHS) mi yoksa Pass-through Authentication (PTA) mı devreye girmiştir? Yoksa hiçbiri mi?

İşte tam bu noktada, çoğu Türkçe kaynakta yanlış cevaplanan ya da yüzeysel geçilen bir konu olan Seamless Single Sign-On (Seamless SSO) karşımıza çıkar.

Seamless SSO, Microsoft Entra ID ekosistemindeki en çok yanlış anlaşılan bileşenlerden biridir. Bir kimlik doğrulama yöntemi olarak algılanır, oysa öyle değildir. PHS veya PTA ile birlikte kullanıldığında "hangisi önce devreye girer, biri başarısız olursa diğerine düşer mi?" sorularına verilen yanıtların büyük çoğunluğu, gerçek protokol akışıyla örtüşmez. On-Prem Active Directory üzerinde otomatik olarak oluşturulan AZUREADSSOACC isimli sessiz ama kritik bir computer hesabı vardır ki, mekanizmanın tüm ağırlığını taşır. Bu hesabın Kerberos şifreleme anahtarı, kurulum sırasında tek bir kez üretilir, Entra ID Tenant'ına kopyalanır ve sonrasında binlerce kullanıcının kimlik doğrulamasının arka planında sessizce çalışmaya başlar. Microsoft, bu anahtarın 30 günde bir manuel olarak rotate edilmesini önerir, ancak otomatik bir mekanizma yoktur. Peki neden?

Bu makalede Seamless SSO'nun protokol seviyesindeki çalışma mantığını adım adım inceleyeceğim. AZUREADSSOACC hesabının Kerberos altyapısındaki rolünü, standart Kerberos akışı ile Seamless SSO arasındaki tek teknik farkı, hangi cihaz tiplerinde mekanizmanın devreye girip hangilerinde girmediğini ele alacağım. Entra ID'nin login karar akışının neden deterministik olduğunu, "ikisini de dene" mantığının neden hiçbir zaman var olmadığını, PTA kullanılan production ortamlarda PHS as a backup authentication option pattern'inin neden zorunlu olduğunu ve Disaster Recovery senaryolarında Cloud-Only break-glass admin hesabı zorunluluğunun arkasındaki gerçek tehdidi açıklayacağım. Ayrıca Microsoft'un Cyber Resiliency perspektifinden hangi konfigürasyonu neden önerdiğini ve modern Hybrid Entra Joined cihazlarda Primary Refresh Token (PRT)'nin Seamless SSO'nun yerini nasıl aldığını detaylıca ele alacağım.

Seamless SSO Bir Authentication Method Değildir

Seamless SSO ile ilgili anlaşılması gereken ilk ve en kritik konu, Seamless SSO'nun bir kimlik doğrulama yöntemi olmadığıdır. Microsoft Entra ID kurulum Wizardnda Password Hash Synchronization, Pass-through Authentication ve Federation gibi seçenekler birer authentication method'dur ve bir Tenant'ta aynı anda yalnızca biri active sign-in method olarak çalışır. Seamless SSO ise tamamen ayrı bir katmanda yer alır.

Seamless SSO, kullanıcının zaten Domain-Joined bir cihazda aktif bir Kerberos Ticket-Granting Ticket (TGT)'sine sahip olduğu durumlarda, Entra ID Login sayfasında kullanıcı adı ve parola girmesini engelleyen bir kullanıcı deneyimi (UX) katmanıdır. Yani Seamless SSO, kimlik doğrulamayı Kerberos üzerinden yapar; PHS veya PTA gibi parola tabanlı bir mekanizma değildir.

Bu ayrım, Entra Connect Sync kurulum Wizardnın arayüzünde de net biçimde görülür. User Sign-In adımında karşımıza çıkan ekranda, kimlik doğrulama yöntemi olarak Password Hash Synchronization, Pass-through authentication, Federation with AD FS, Federation with PingFederate veya Do not configure seçeneklerinden biri seçilirken, Enable single sign-on seçeneği bunlardan tamamen bağımsız bir Checkbox olarak yer alır. Yani PHS ile birlikte de, PTA ile birlikte de, hatta her ikisi birlikte (PTA primary + PHS backup) seçildiğinde de Seamless SSO aktifleştirilebilir. 


 

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 On-Prem Active Directory üzerinde otomatik olarak AZUREADSSOACC adında bir Computer hesabı oluşturur.

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ı (AES-256 Derived Key) oluşur. Bu Key:

✔ Tek bir kez Entra Connect kurulumu sırasında üretilir.

✔ Üretildikten hemen sonra Entra ID Tenant'ına kopyalanır ve bulutta kalıcı olarak 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; içerideki "bu kişi şu kullanıcıdır" bilgisi orada yazılıdı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; Entra Connect sunucusunda PowerShell üzerinden yapılır. Key rollover yapılmasa bile Seamless SSO çalışmaya devam eder, ancak bu durum güvenlik best practice'lerine aykırıdır ve uzun vadede Tier 0 / Control Plane varlığı olan bu hesabın saldırı yüzeyini artırır.

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ı'in 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ı'e 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 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ı'in 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ı'in 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 Kullanıcı'tir" bilgisini yazar.

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

✔ Şifrelenmiş zarfı, Kullanıcı'in 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 "Kullanıcı" bilgisini okur, kullanıcının kimliğini doğrular ve Token üreterek erişim verir.

🎯 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'ı Entra ID'ye sunar.

Mekanizma birebir aynıdır. Tek fark, Ticket'ın kime hitaben yazıldığı (target SPN) ve kime sunulduğudur.

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-Prem Active Directory'ye Domain-Joined olması gerekir.

Hybrid ve Cloud Joined Cihazlar İçin Önemli Ayrım

Hybrid Joined cihazlar, hem On-Prem AD'ye hem de Entra ID'ye Joined durumdadır. On-Prem AD'ye Joined oldukları için Kerberos TGT alabilirler ve teknik olarak Seamless SSO çalışabilir. Ancak modern Windows 10/11 Hybrid Joined cihazlarda Primary Refresh Token (PRT) mekanizması Seamless SSO'nun yerini büyük ölçüde almıştır.

Entra ID Joined (Cloud Joined) cihazlar ise yalnızca Entra ID'ye Joined 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

Seamless SSO aşağıdaki durumlarda devreye girmez ve kullanıcıdan parola istenir:

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

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

✔ Private browsing (incognito) modu — Tarayıcı Kerberos Ticket göndermez.

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

Bu durumlarda kullanıcı, Entra ID Login sayfasında kullanıcı adı ve parolasını manuel olarak girer. İşte tam bu noktada, Tenant'ın active sign-in method'u (PHS veya PTA) devreye girer.

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-Prem 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.

Bu üç GPO ayarı, kurumsal Naming Convention disiplinine sahip ortamlarda iki ayrı GPO nesnesi içinde organize edilir.

1- Computer Configuration altında uygulanan Site to Zone Assignment List ve Allow Updates to Status Bar via Script ayarları C-COR-WKS-SEAMLESS-SSO-CORE adlı GPO'da,

2- User Configuration altında uygulanan Registry Item Group Policy Preference ayarı ise U-COR-USR-SEAMLESS-SSO-CORE adlı GPO'da tanımlanır.

Bu ayrım, GPO listesinde her bir nesnenin hangi nesne tipini hedeflediğini açıkça gösterir ve operasyonel yönetilebilirliği önemli ölçüde artırır.


Yukarıdaki Group Policy Management ekranında her iki GPO nesnesinin de Turkey OU'suna link edilmiş olduğu ve organizasyonun mevcut baseline GPO'larıyla aynı hiyerarşik düzlemde yer aldığı görülmektedir. GPO nesneleri oluşturulup ilgili OU'ya link edildikten sonra sıra, her bir GPO içinde tanımlanması gereken üç ayrı Policy ayarına gelir. Aşağıdaki adımlar, Microsoft Learn'in resmi Quickstart: Microsoft Entra seamless single sign-on dokümantasyonunda belirtilen sıraya göre uygulanır ve her adımın hangi GPO nesnesi içinde tanımlanacağı açıkça belirtilmiştir.

1- Site to Zone Assignment List Policy

Bu Policy, autologon.microsoftazuread-sso.com ve aadg.windows.net.nsatc.net URL'lerinin tarayıcının Intranet Zone'una dahil edilmesini sağlar.

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

Computer Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Site to Zone Assignment List

Policy Enabled hale getirilir ve aşağıdaki URL'ler Intranet Zone (Zone değeri 1) olarak tanımlanır.

https://autologon.microsoftazuread-sso.com  →  1
https://aadg.windows.net.nsatc.net          →  1

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:

Computer Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone > Allow updates to status bar via script

Policy Enabled hale getirilir ve dropdown menüden Enable seçilir.

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 konfigürasyonunu doğrudan registry seviyesinde tanımlayarak Intranet Zone atamasının her koşulda korunmasını garanti altına alır.

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

User Configuration > Preferences > Windows Settings > Registry > New > Registry Item

Açılan pencerede 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

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

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

✔ Microsoft Edge, Internet Explorer ve Google Chrome (Windows üzerinde): Yukarıdaki üç GPO ayarı yeterlidir. Bu tarayıcılar Windows seviyesindeki Internet Settings'i otomatik olarak okur ve aynı Intranet Zone konfigürasyonunu paylaşır.

✔ Mozilla Firefox: Firefox, Windows Internet Settings'i okumaz. about:config üzerinden network.negotiate-auth.trusted-uris değerine autologon.microsoftazuread-sso.com manuel olarak eklenmelidir. Kurumsal ortamlarda bu, Firefox policies.json dosyası veya Firefox ADMX template'leri ile merkezi olarak dağıtılabilir.

✔ Microsoft 365 Win32 client'ları (Outlook, Word, Excel vb): Yalnızca versiyon 16.0.8730.xxxx ve üzeri Seamless SSO'yu non-interactive flow ile destekler. Daha eski sürümlerde kullanıcıdan en azından kullanıcı adı istenir; tam parolasız oturum açma sağlanmaz.

✔ OneDrive for Business client: Silent sign-on için ayrıca OneDrive Silent Configuration özelliği etkinleştirilmelidir. Bu özellik Group Policy üzerinden veya Intune ile dağıtılabilir.

✔ Private browsing modu (incognito): Seamless SSO bu modda çalışmaz. Tarayıcı Kerberos Ticket göndermez ve kullanıcıdan parola istenir.

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.

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.

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.

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 Wizardnda, 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 authentication 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. Authentication 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.

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.

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

PTA kullanıldığı senaryolarda Microsoft, kurulum Wizardnı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ı (genellikle FIDO2 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:

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ı kendi içinde senkronize edilmiş PHS Hash değeriyle karşılaştırır ve 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ı kendi içindeki Hash ile karşılaştırır (PHS akışı)
                    │
                    ▼
✅ Kimlik doğrulandı
                    │
                    ▼
Token issue edilir

Senaryo 2: PTA + Seamless SSO

Domain-Joined Computer, kurumsal Network içinden:

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. Entra ID, parolayı Public Key ile şifreleyerek Service Bus üzerinden Authentication Agent'a iletir. Agent, parolayı kendi private Key'i ile Decrypt eder ve LogonUser Win32 API çağrısı üzerinden On-Prem Domain Controller'a doğrulama isteği gönderir. DC'den dönen sonuç (başarılı veya başarısız) 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 ID, parolayı Public Key ile şifreler
                    │
                    ▼
Parola, Authentication Agent'a iletilir (Service Bus üzerinden)
                    │
                    ▼
Authentication Agent Decrypt eder ─→ LogonUser API ─→ On-Prem DC
                    │
                    ▼
✅/❌ Sonuç Entra ID'ye döner
                    │
                    ▼
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.

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. Otomatik değildir.

✔ Seamless SSO private browsing modunda ve Non-Domain-Joined cihazlarda çalışmaz. Bu durumda Tenant'ın active sign-in method'u (PHS veya PTA) devreye girer.

✔ Seamless SSO, Modern Authentication (OAuth2 / OpenID Connect) gerektirir. Legacy protokoller (Basic Auth ile POP / IMAP gibi) Seamless SSO'dan yararlanamaz.

✔ Hybrid Entra Join ve Entra Join yaygınlaştığında, Primary Refresh Token (PRT) Seamless SSO'nun yerini büyük ölçüde alır. PRT zaten Hybrid Joined senaryolarda daha güçlü SSO sağlar. Seamless SSO, Hybrid Join olmayan klasik Domain-Joined cihazlar için hala değerlidir.

✔ 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 istiyorsanız, mekanizma Staged Rollout'tur. Bu geçici bir test aracıdır, kalıcı bir mimari değildir.

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 authentication 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 authentication method değildir; Kerberos tabanlı bir kullanıcı deneyimi katmanıdır. PHS veya PTA ile birlikte çalışır.

✔ Seamless SSO etkinleştirildiğinde, On-Prem AD'de otomatik olarak AZUREADSSOACC Computer hesabı oluşturulur. Bu hesabın Kerberos Key'i Entra ID'ye kopyalanır ve mekanizmanın temelini oluşturur.

✔ AZUREADSSOACC Key'i 30 günde bir manuel olarak rollover edilmelidir. Bu işlem otomatik değildir.

✔ Seamless SSO başarılı olduğunda, kimlik doğrulama Kerberos ile tamamlanır ve ne PHS ne de PTA devreye girer.

✔ Authentication method farkı (PHS vs PTA), yalnızca Seamless SSO devre dışı kaldığında (kişisel cihaz, dış ağ, private browsing) ortaya çıkar.

✔ Entra ID, Login sırasında "ikisini de dene" mantığı uygulamaz. Tenant'ın tek bir aktif sign-in method'u vardır.

✔ 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'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.

✔ Hybrid Entra Joined ve Entra Joined cihazlarda PRT (Primary Refresh Token) mekanizması devreye girer ve Seamless SSO'nun yerini alır.

Bu makalede Microsoft Entra ID ortamlarında Seamless SSO'nun ne olduğunu, hangi protokol üzerinde çalıştığını ve neden bir kimlik doğrulama yöntemi olmadığını detaylıca inceledik. Seamless SSO'nun temelinde Entra Connect Sync kurulumu sırasında On-Prem 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 authentication method olduğunu, bir Tenant'ta aynı anda yalnızca birinin aktif sign-in method olarak çalıştığını 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 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 Hybrid Entra Joined ve 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 kullanıcı deneyimi katmanı olduğunu vurguladık.

Faydalı olması dileğiyle...