Merhaba

Serinin son bölümüne geldik. Şu ana kadar bakicubuk.tech alan adını tenant’ımızda doğruladık, Microsoft Entra Connect Sync ile kullanıcılarımızı Entra ID’ye senkronize ettik ve Conditional Access politikalarıyla tüm kullanıcılardan MFA istemeye başladık. Bölüm 2’de Entra Connect kurulumunda Seamless SSO’yu etkinleştirmiştik, ancak özelliğin istemci tarafında çalışması için bir grup ilkesi daha gerekiyor. Bu bölümde grup ilkesini yapılandırıyor, domain’e bağlı W11CL01 istemcisinden uçtan uca testi yapıyor ve Seamless SSO’nun kullandığı AZUREADSSOACC hesabını AES ile sıkılaştırıyoruz.

Seamless SSO Nasıl Çalışır?

Seamless SSO etkinleştirildiğinde Entra Connect, on-premises Active Directory’de AZUREADSSOACC adında bir bilgisayar hesabı oluşturuyor, bu hesaba Entra ID oturum açma sürecinde kullanılacak Kerberos SPN’lerini tanımlıyor ve hesabın Kerberos şifre çözme anahtarını güvenli şekilde Entra ID ile paylaşıyor. Bu hesap, Entra ID’yi on-premises Kerberos dünyasında temsil ediyor.

Domain’e bağlı bir bilgisayarda oturum açmış kullanıcı tarayıcıda Entra ID oturum açma sayfasına geldiğinde, sayfa arka planda autologon.microsoftazuread-sso.com adresine bir istek gönderiyor. Tarayıcı bu adresi Intranet bölgesinde gördüğü için domain controller’dan AZUREADSSOACC hesabı adına bir Kerberos bileti alıp Entra ID’ye iletiyor. Entra ID, paylaşılan anahtarla bileti çözüyor, kullanıcıyı tanıyor ve parola sormadan oturum açma işlemini tamamlıyor. Conditional Access politikaları bu akışın ardından değerlendirildiği için MFA gerekliliği ortadan kalkmıyor; kullanıcı yalnızca parola girmiyor.

Tarayıcının Kerberos biletini yalnızca Intranet bölgesindeki adreslere göndermesi, grup ilkesine neden ihtiyaç duyduğumuzu da açıklıyor: autologon.microsoftazuread-sso.com adresini kullanıcıların Intranet bölgesine eklememiz gerekiyor.

Adım 1: Seamless SSO Durumunu Kontrol Etme

Önce özelliğin tenant tarafında etkin olduğunu doğruluyoruz. Entra admin center’da Entra ID > Entra Connect > Connect Sync sayfasını açıyoruz.

Sayfa iki ana bölümden oluşuyor:

• Provision from Active Directory: Senkronizasyonun durumu. Sync status bölümü Enabled, Last sync bölümü Less than 1 hour ago ve Password Hash Sync bölümü Enabled görünüyor; yani Bölüm 2’de kurduğumuz senkronizasyon ve parola karması eşitlemesi çalışıyor.
• User sign-in: Kullanıcı oturum açma yöntemleri. Federation ve Pass-through authentication  bölümü Disabled, Email as alternate login ID bölümü Disabled. Bizim için önemli satır Seamless single sign-on bölümü Enabled, 1 domain.

Buradaki 1 domain, Bölüm 2’de Entra Connect sihirbazının Enable single sign-on adımında bilgilerini girdiğimiz bakicubuk.tech forest’ını ifade ediyor. Seamless single sign-on bağlantısına tıklarsanız etkin olan domain’i ve Kerberos şifre çözme anahtarının son yenilenme tarihini görebilirsiniz; bu tarihe Adım 6’da tekrar döneceğiz.

Tenant tarafı hazır. Ancak Seamless SSO’nun çalışması için istemcideki tarayıcının Kerberos biletini Microsoft’un autologon adresine göndermeye izin vermesi gerekiyor; bunu grup ilkesiyle sağlayacağız.

Adım 2: Grup İlkesini Oluşturma

W25DC üzerinde Server Manager > Tools > Group Policy Management ile konsolu açıyoruz. Grup ilkesindeki ayarların tamamı User Configuration (Kullanıcı Yapılandırması) altında olduğu için ilke, bilgisayar nesnelerinin değil kullanıcı nesnelerinin bulunduğu OU (Organization Unit)’ya bağlandığında etkili oluyor. Senkronize ettiğimiz kullanıcılar LabUsers OU (Organization Unit)’sunda olduğu için ilkeyi doğrudan bu OU (Organization Unit)’ya bağlıyoruz. Tüm domain kullanıcılarına uygulamak isterseniz ilkeyi domain köküne bağlamak da doğru bir tercih.

Forest: bakicubuk.tech > Domains > bakicubuk.tech altında LabUsers OU (Organization Unit)’suna sağ tıklayıp Create a GPO in this domain, and Link it here seçeneğini seçiyoruz. Bu seçenek GPO’yu oluşturmakla kalmıyor, aynı adımda seçili OU (Organization Unit)’ya bağlıyor da. Link an Existing GPO seçeneği ise daha önce oluşturulmuş bir GPO’yu bu OU’ya bağlamak için kullanılır.

New GPO penceresinde Name alanına Seamless SSO Settings yazıyoruz. Source Starter GPO değeri (none) kalıyor; starter GPO’lar hazır ayar şablonlarıdır ve bu senaryoda ihtiyacımız yok. OK ile GPO (Group Policy Object)’yu oluşturuyoruz.

GPO, LabUsers altında Linked Group Policy Objects sekmesinde Link Order bölümü 1, Enforced bölümü No, Link Enabled bölümü Yes ve GPO Status bölümü Enabled olarak listeleniyor.

GPO’ya sağ tıklayıp Edit ile Group Policy Management Editor’ü açıyoruz.

Editor’de iki ayar yapacağız.

Site to Zone Assignment List

User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page yolunu izliyoruz. Sağ bölmedeki listede Site to Zone Assignment List ayarının durumu Not configured. Ayara çift tıklıyoruz.

Ayarı Enabled yapıyoruz. Pencerenin sağındaki yardım metni Internet Explorer’ın dört güvenlik bölgesini açıklıyor: (1) Intranet zone, (2) Trusted Sites zone, (3) Internet zone ve (4) Restricted Sites zone. Options altındaki Enter the zone assignments here satırında Show düğmesine tıklıyoruz.

Show Contents penceresinde aşağıdaki değeri giriyor ve OK ile kapatıyoruz. Ardından ayar penceresini de OK ile kaydediyoruz.

Value alanındaki 1, adresin Intranet bölgesine atanacağı anlamına geliyor. Tarayıcı yalnızca Intranet bölgesindeki sitelere Windows oturumundaki Kerberos kimliğini kendiliğinden gönderdiği için bu atama Seamless SSO’nun temelini oluşturuyor. Adresin başındaki https:// kısmını ve adresin tam yazımını kontrol edin; yazım hatası olursa ilke uygulanmış görünse de SSO çalışmaz. Bu ayar Internet Explorer menüsü altında yer alsa da Windows üzerindeki Microsoft Edge ve Google Chrome da bölge atamalarını bu yapılandırmadan okuyor.

Listede Site to Zone Assignment List ayarının durumu artık Enabled.

Allow Updates to Status Bar via Script

Aynı yolda User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone klasörüne geçiyoruz. Burada Intranet bölgesine özel 58 ayar listeleniyor. Allow updates to status bar via script ayarının durumu Not configured; ayara çift tıklıyoruz.

Ayarı Enabled yapıyor, Options altındaki Status bar updates via script değerinin Enable olduğunu kontrol ediyor ve Apply, ardından OK ile kaydediyoruz. Seamless SSO oturum açma sayfası, Kerberos bileti alma sürecini tarayıcıda çalışan bir betik aracılığıyla yürütüyor; Microsoft’un Seamless SSO dokümanı bu ayarın da etkinleştirilmesini istiyor.

Intranet Zone listesinde ayarın durumu Enabled olarak görünüyor. Group Policy Management Editor’ü kapatabiliriz; değişiklikler kaydedildi.

Adım 3: İstemcide İlkenin Uygulandığını Doğrulama

W11CL01‘e senkronize kullanıcımız BAKICUBUK\nihat.cubuk ile oturum açıyoruz. Grup ilkesi istemcide varsayılan olarak 90 dakikalık aralıklarla (0 ile 30 dakika arası rastgele gecikmeyle) yenilendiği için beklemek yerine güncellemeyi elle tetikliyoruz:

gpupdate /force

Komut önce Computer Policy, ardından User Policy güncellemesini yapıyor ve her biri için update has completed successfully mesajını veriyor. User Policy kısmı birkaç saniye sonra tamamlanabilir; ikinci mesajı görmeden pencereyi kapatmayın. Kontrolleri, farklı bir yönetici hesabıyla yükseltilmiş bir pencerede değil, nihat.cubuk ile açılmış normal bir PowerShell penceresinde yapmak gerekiyor; aksi halde kullanıcı ilkesi o yönetici hesabı için değerlendirilir.

Ardından kullanıcıya uygulanan ilkeleri listeliyoruz:

gpresult /r /scope user

Çıktının USER SETTINGS bölümünde kullanıcının CN=Nihat Cubuk,OU=LabUsers,DC=bakicubuk,DC=tech olarak göründüğünü, ilkenin W25DC.bakicubuk.tech üzerinden uygulandığını ve Applied Group Policy Objects altında Seamless SSO Settings ilkesinin listelendiğini görüyoruz. Filtered out listesindeki Local Group Policy: Not Applied (Empty) satırı, istemcinin yerel grup ilkesinde ayar olmadığını gösteriyor ve normal.

Son olarak bölge atamasının kullanıcı kayıt defterine yazıldığını kontrol ediyoruz:

Get-ItemProperty -Path 'HKCU:\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMapKey' -ErrorAction SilentlyContinue

Çıktıda https://autologon.microsoftazuread-sso.com : 1 satırı görünüyor. Kaydın HKEY_CURRENT_USER altında, Policies anahtarında olması hem ayarın ilkeden geldiğini hem de User Configuration altında yapıldığını doğruluyor. Ayar Computer Configuration altında yapılmış olsaydı değer HKEY_LOCAL_MACHINE altına yazılırdı.

Adım 4: Uçtan Uca Test

Serinin tüm parçalarını bir araya getiren test bu. W11CL01‘de Nihat Cubuk ([email protected]) kullanıcısının oturumu açıkken Microsoft Edge’i normal (InPrivate olmayan) bir pencerede açıyor ve myapplications.microsoft.com adresine gidiyoruz. Oturum açma sayfasında kullanıcı adı olarak [email protected] yazıp Next diyoruz.

Next‘e bastığımızda parola ekranı hiç gelmiyor. Tarayıcı arka planda https://autologon.microsoftazuread-sso.com adresine Kerberos biletiyle başvuruyor, Entra ID bu bileti AZUREADSSOACC bilgisayar hesabının anahtarıyla doğruluyor ve parolayı atlıyor. Sayfa doğrudan bir sonraki adıma geçiyor.

Lab’da Nihat Cubuk ([email protected]) kullanıcısı Bölüm 3’te MFA kaydını tamamlamadığı için bu adımda Let’s keep your account secure ekranı çıkıyor. Parolanın sorulmadan bu ekrana gelinmesi, Seamless SSO’nun çalıştığını gösteriyor; CA002 politikası ise kullanıcının henüz bir MFA yöntemi olmadığı için kayıt istiyor. MFA kaydı zaten tamamlanmış bir kullanıcıda bu ekranın yerine doğrudan Microsoft Authenticator onay isteği gelir.

Next ile kayıt sihirbazını başlatıyoruz. Kullanıcı telefonuna Microsoft Authenticator uygulamasını yükleyip ekrandaki QR kodu okutuyor ve test bildirimini onaylıyor. Kayıt tamamlandığında mysignins.microsoft.com/register adresinde Set up complete ekranı görünüyor ve Microsoft Authenticator (Default sign-in method) yöntemi iPhone cihazıyla listeleniyor. Kullanıcı kayıtlı yöntemlerini daha sonra security settings bağlantısından mysignins.microsoft.com görüntüleyip değiştirebilir. Done ile devam ediyoruz.

Kayıt tamamlandıktan sonra tarayıcı kullanıcıyı başta istediği adrese, myapplications.microsoft.com‘a yönlendiriyor. My Apps portalı Nihat Cubuk ([email protected]) kullanıcısıyla açılıyor. Kullanıcı bu süreçte bir kez bile parolasını girmedi.

Parola sorulmaması ve yalnızca MFA istenmesi, hibrit kimlik mimarisinin tam olarak hedeflediği deneyim: kullanıcı domain’e bağlı bilgisayarında zaten kimliğini kanıtladığı için parolasını tekrar girmiyor, ancak Conditional Access politikası gereği ikinci faktör hala isteniyor. Seamless SSO kullanıcı deneyimini kolaylaştırırken güvenlik politikalarını atlamıyor.

Adım 5: Kerberos Biletini ve Oturum Açma Kaydını Doğrulama

Seamless SSO’nun gerçekten devreye girdiğini W11CL01 üzerinde Kerberos biletlerini listeleyerek doğrulayabiliriz:

klist

Çıktıda Nihat Cubuk ([email protected]) kullanıcısına ait üç bilet görüyoruz:

• #1 krbtgt/BAKICUBUK.TECH: Kullanıcının Windows’a oturum açarken W25DC’den aldığı Ticket Granting Ticket (TGT). Diğer tüm hizmet biletleri bu bilet kullanılarak alınıyor.
• #2 HTTP/autologon.microsoftazuread-sso.com: Seamless SSO’nun bileti. Tarayıcı My Apps oturum açma sırasında W25DC’den bu hizmet için bir bilet istedi ve Entra ID’ye iletti. Bu bilet, AD’deki AZUREADSSOACC bilgisayar hesabının anahtarıyla şifreleniyor ve Entra ID aynı anahtarla çözüp kullanıcıyı tanıyor. Start Time değeri (1:24:31) tarayıcıda oturum açtığımız zamanla örtüşüyor.
• #3 cifs/W25DC.bakicubuk.tech: Grup ilkesinin SYSVOL’dan okunması için alınan dosya paylaşımı bileti.

Seamless SSO’nun çalıştığının istemci tarafındaki kanıtı #2 numaralı bilet. Bu satır yoksa tarayıcı autologon adresine Kerberos bileti göndermemiş demektir; bu durumda önce Adım 3’teki bölge atamasını kontrol etmek gerekir.

Biletin KerbTicket Encryption Type değeri AES-256-CTS-HMAC-SHA1-96. Eski ortamlarda bu değer çoğunlukla RSADSI RC4-HMAC(NT) olarak görünüyordu, çünkü AZUREADSSOACC hesabında şifreleme türü tanımlı değilse domain varsayılanı kullanılıyor ve bu varsayılan uzun süre RC4’tü. Lab’ımızda bilet sıkılaştırma öncesinde bile AES-256 ile şifrelenmiş durumda; bunun nedenini ve hesabı yine de neden açıkça AES ile sınırladığımızı Adım 6’da ele alacağız.

Entra tarafında ise Entra admin center > Entra ID > Users > Sign-in logs sayfasında User contains filtresine nihat yazıyor ve User sign-ins (interactive) sekmesine bakıyoruz. Nihat Cubuk ([email protected]) için dört kayıt görünüyor:

• My Apps, Success: Bu adımdaki Seamless SSO ile yapılan oturum açma.
• Microsoft Account Controls V2, Success: Hemen ardından mysignins.microsoft.com üzerinde yapılan MFA kaydı.
• My Apps, Interrupted (50072): Bölüm 3’teki ilk oturum açma. 50072 kodu, kullanıcının MFA kaydı yapması gerektiği için oturumun kesintiye uğradığını gösteriyor; hata değil, beklenen bir durum.
• My Apps, Failure: Bölüm 3’te politikalar etkinleştirilmeden önce yapılan deneme.

Listeyi sağa kaydırdığımızda Conditional Access ve Authentication requirement sütunları görünüyor. Seamless SSO ile yapılan My Apps oturumunda Conditional Access değeri Success, Authentication requirement değeri Multifactor authentication. Bu, CA002 politikasının uygulandığını ve MFA gerekliliğinin karşılandığını gösteriyor. En alttaki eski denemede ise Conditional Access Not Applied ve Single-factor authentication görünüyor; bu kayıt politikaların henüz On olmadığı döneme ait.

Tek bir kaydın ayrıntılarını görmek için satıra tıklayabilirsiniz. Açılan panelin Conditional Access sekmesinde hangi politikaların uygulandığı, Authentication Details sekmesinde ise birinci ve ikinci faktörün hangi yöntemle karşılandığı listelenir.

Adım 6: AZUREADSSOACC Hesabını Sıkılaştırma

AZUREADSSOACC hesabı, Entra ID adına Kerberos biletlerinin şifrelendiği anahtarı taşıyor. Bu anahtarı ele geçiren bir saldırgan, domain’deki herhangi bir kullanıcı adına Entra ID’ye oturum açmak için sahte Kerberos biletleri üretebilir. Bu nedenle hesabı iki açıdan sıkılaştırıyoruz: şifreleme türünü AES ile sınırlamak ve Kerberos şifre çözme anahtarını düzenli olarak yenilemek.

Seamless SSO; AES256_HMAC_SHA1, AES128_HMAC_SHA1 ve RC4_HMAC_MD5 şifreleme türlerini destekliyor ve Microsoft, hesabın AES türlerinden biriyle, tercihen AES256 ile yapılandırılmasını öneriyor. Microsoft ayrıca Temmuz 2026 Windows Server güncellemesiyle Active Directory’deki varsayılan Kerberos şifreleme türünün RC4’ten AES-256’ya geçtiğini ve RC4 ile çalışmaya devam eden ortamlarda Seamless SSO sorunları yaşanabileceğini belirtiyor. Bu konu AD Sıkılaştırma serimizin Kerberos için AES zorlaması bölümüyle doğrudan bağlantılı. Lab’ımızda Adım 5’teki klist çıktısında autologon biletinin zaten AES-256 ile şifrelendiğini görmemizin nedeni de büyük ihtimalle bu: Windows Server 2025 domain controller’ımız güncel ve hesapta şifreleme türü tanımlı olmadığı için yeni AES-256 varsayılanı kullanılıyor. Güncellemeleri geride kalmış ya da DefaultDomainSupportedEncTypes değeri özelleştirilmiş ortamlarda aynı bilet RC4 ile şifrelenebilir; bu yüzden hesabı domain varsayılanına bırakmak yerine açıkça AES ile sınırlıyoruz.

Önce hesabın mevcut şifreleme türü değerine bakıyoruz:

Get-ADComputer AZUREADSSOACC -Properties msDS-SupportedEncryptionTypes |
  Select-Object Name, msDS-SupportedEncryptionTypes

Lab’ımızda W25DC üzerinde komutu çalıştırdığımızda msDS-SupportedEncryptionTypes değerinin boş olduğunu görüyoruz. Yani hesap için özel bir şifreleme türü tanımlanmamış ve domain varsayılanı kullanılıyor. Adım 5’te autologon biletinin AES-256 ile şifrelenmiş olması da bu varsayılandan geliyor; hesabın kendisinde AES zorunluluğu yok.

Microsoft’un dokümanına göre RC4’ten AES’e geçerken önce hesabın Kerberos şifre çözme anahtarının yenilenmesi gerekiyor, aksi halde Seamless SSO çalışmayı durduruyor. Bu yüzden sıralamamız şöyle: önce anahtarı yeniliyor, ardından şifreleme türünü AES ile sınırlıyoruz.

Kerberos Şifre Çözme Anahtarını Yenileme

Anahtar yenileme işlemini W25ENTRA üzerinde, Entra Connect ile birlikte gelen AzureADSSO PowerShell modülüyle yapıyoruz. Run as administrator (Yönetici olarak çalıştır) açılmış bir PowerShell penceresinde modülü içe aktarıp Entra ID’ye bağlanıyoruz:

cd "$env:ProgramFiles\Microsoft Azure Active Directory Connect"
Import-Module .\AzureADSSO.psd1
New-AzureADSSOAuthenticationContext

Get-ChildItem "C:\Program Files\Microsoft Azure*" -Recurse -Filter "Microsoft.IdentityModel.Abstractions.dll" -ErrorAction SilentlyContinue |
  ForEach-Object { "{0}  ->  {1}" -f $_.VersionInfo.FileVersion, $_.FullName }

Add-Type -Path "C:\Program Files\Microsoft Azure AD Connect Health Agent\Modules\AdHealthConfiguration\Microsoft.IdentityModel.Abstractions.dll"

Bu geçici bir çözüm; sorun Entra Connect’in sonraki sürümlerinde giderilebilir. Add-Type ile yüklenen kütüphane yalnızca o PowerShell oturumunda geçerli olduğu için sistemde kalıcı bir değişiklik yapmıyor.

Add-Type, Import-Module ve New-AzureADSSOAuthenticationContext komutları hatasız çalıştığında Registry configuration used to set endpoints for DSSO in cloud : Worldwide bilgi satırı görünüyor ve bir Microsoft Azure oturum açma penceresi açılıyor. Worldwide, komutların genel Microsoft bulutundaki uç noktalara bağlandığını gösteriyor; US Government ya da 21Vianet gibi ulusal bulutlarda bu değer farklı olur.

Açılan pencerede Hybrid Identity Administrator ya da Global Administrator rolüne sahip bir hesapla oturum açıyoruz. Lab’da [email protected] hesabını kullanıyoruz ve Next diyoruz.

Bu hesap bir bulut hesabı olduğu için Seamless SSO devreye girmiyor ve parola isteniyor. Sign in diyoruz.

Parolanın ardından Bölüm 3’te etkinleştirdiğimiz CA002 politikası gereği Microsoft Authenticator onayı isteniyor. Ekrandaki sayıyı telefondaki Authenticator uygulamasına girerek onaylıyoruz. Sayı eşleştirme (number matching), kullanıcının kendi başlatmadığı bir oturum açma isteğini yanlışlıkla onaylamasını engelliyor. Yönetim araçlarının da Conditional Access politikalarına tabi olduğunu burada görmüş oluyoruz.

Oturum açıldıktan sonra mevcut durumu kontrol ediyor ve domain yöneticisi kimlik bilgilerini alıyoruz:

Get-AzureADSSOStatus | ConvertFrom-Json
$creds = Get-Credential -UserName 'BAKICUBUK\administrator' -Message 'Domain Admin'

Get-AzureADSSOStatus çıktısında Enable: True, Exists: True, Domains: {bakicubuk.tech} ve IsSuccessful: True görünüyor; Seamless SSO bakicubuk.tech forest’ı için etkin. Get-Credential komutu açtığı pencerede şifre bilgisini istiyor. Bu komut kullanıcı adını DOMAIN\kullanıcı biçiminde bekliyor; UPN biçimi ([email protected]) kabul edilmiyor. Hesabın Domain Admin yetkisine sahip olması gerekiyor, çünkü komut AZUREADSSOACC bilgisayar hesabının parolasını değiştirecek.

Son olarak anahtarı yeniliyoruz:

Update-AzureADSSOForest -OnPremCredentials $creds

Çıktı adım adım ne yapıldığını gösteriyor: komut önce global catalog’da AZUREADSSOACC hesabını arıyor ve CN=AZUREADSSOACC,CN=Computers,DC=bakicubuk,DC=tech konumunda buluyor. Ardından hesap üzerinde Account Admins ve Enterprise Admins için tam denetim yetkisini yeniden tanımlıyor, hesabın parolasını, yani Kerberos şifre çözme anahtarını yeniliyor ve yeni anahtarı Entra ID ile paylaşıyor. “Successfully updated SSO computer account properties” ve “The operation completed successfully” satırları işlemin tamamlandığını gösteriyor.

Microsoft bu anahtarın en az 30 günde bir yenilenmesini öneriyor. Anahtar yenileme işlemi kullanıcıları kesintiye uğratmadığı için takvime bağlanmış rutin bir bakım görevi olarak planlanabilir.

Şifreleme Türünü AES ile Sınırlama

>Anahtarı yeniledikten sonra W25DC üzerinde hesabın şifreleme türünü AES128 ve AES256 ile sınırlıyoruz:

Set-ADComputer AZUREADSSOACC -Replace @{'msDS-SupportedEncryptionTypes'=24}
Get-ADComputer AZUREADSSOACC -Properties msDS-SupportedEncryptionTypes |
  Select-Object Name, msDS-SupportedEncryptionTypes

Çıktıda msDS-SupportedEncryptionTypes değeri artık 24. Bu değer, 8 (AES128) ve 16 (AES256) bayraklarının toplamı; RC4’ü temsil eden 4 bayrağı içermediği için hesap artık RC4 ile şifrelenmiş bilet kabul etmiyor.

Yalnızca AES256’ya izin vermek isterseniz değeri 16 olarak ayarlayabilirsiniz. Değişikliği test etmek için W11CL01’de mevcut biletleri temizliyor, tarayıcıda tekrar oturum açıyor ve bileti yeniden listeliyoruz:

klist purge
klist

klist purge tüm biletleri siliyor. Tarayıcıda My Apps’e yeniden oturum açtıktan sonra klist çıktısında iki bilet görüyoruz: yeniden alınan krbtgt bileti (TGT) ve HTTP/autologon.microsoftazuread-sso.com bileti. İki biletin Start Time değeri de temizlikten sonraki saati gösteriyor; yani autologon bileti şifreleme türünü sınırladıktan sonra W25DC’den yeniden alınmış. KerbTicket Encryption Type ve Session Key Type değerleri AES-256-CTS-HMAC-SHA1-96.

Lab’ımızda bu değer Adım 5’te de AES-256’ydı; fark, artık bu sonucun domain varsayılanına değil hesaba açıkça tanımlanmış şifreleme türüne dayanması. İleride domain varsayılanı değişse ya da RC4’e izin veren bir yapılandırma devreye girse bile AZUREADSSOACC yalnızca AES ile çalışır. Kullanıcı tarafında hiçbir değişiklik olmadı: oturum açma yine parola sorulmadan gerçekleşti.

Sorun Giderme

Serinin Özeti

Dört bölümlük bu seride Windows Server 2025 üzerinde uçtan uca çalışan bir hibrit kimlik ortamı kurduk:

• Forest’ımızla aynı adı taşıyan bakicubuk.tech alan adını tenant’ta doğrulayarak kullanıcıların on-premises UPN’leriyle buluta oturum açabilmesini garanti altına aldık.
• Entra Connect Sync’in güncel sürümünü Customize ile kurduk; senkronizasyon kapsamını tek bir OU ile sınırladık, Password Hash Synchronization ve Seamless SSO’yu etkinleştirdik.
• Entra Connect’in Entra ID’ye parolalı bir hesap yerine TPM korumalı sertifikalı bir uygulama kimliğiyle bağlandığını doğruladık.
• Security Defaults’tan Conditional Access’e geçip break-glass hesaplarını ve istisnalarını belgelenmiş şekilde yönettik.
• Domain’e bağlı bir istemciden parola girmeden, yalnızca MFA ile oturum açılabildiğini doğruladık AZUREADSSOACC hesabının Kerberos anahtarını yeniledik ve hesabı AES ile sıkılaştırdık.

Bu yapıyı üretim ortamına taşırken bir sonraki adımlar olarak staging mode’da ikinci bir Entra Connect sunucusu kurmayı, cihazlar için Microsoft Entra hybrid join yapılandırmayı, Entra Connect ile birlikte kurulan Connect Health agent’ı üzerinden senkronizasyonu izlemeyi ve Entra Connect sunucusunu Tier 0 kapsamında sıkılaştırmayı öneriyoruz. Microsoft Entra Cloud Sync’in sizin senaryonuz için daha hafif bir alternatif olup olmadığını da değerlendirmeye değer.