Merhaba
Kurumların büyük bölümü kimlik altyapısını hala on-premises Active Directory üzerinde tutuyor, ancak kullanıcıların oturum açtığı uygulamaların neredeyse tamamı artık bulutta. Microsoft 365, Azure portalı ve SaaS uygulamaları için aynı kullanıcı adı ve parolayla, aynı güvenlik politikalarıyla oturum açabilmek hibrit kimlik (hybrid identity) mimarisinin temel amacı. Bu seride on-premises Active Directory ortamımızı Microsoft Entra Connect Sync ile Microsoft Entra ID’ye bağlayacak, Password Hash Synchronization, Seamless SSO ve Conditional Access ile uçtan uca çalışan bir hibrit kimlik ortamını Windows Server 2025 üzerinde sıfırdan kuracağız.

Seriyi yazmak için iyi bir zamandayız. Microsoft, Mart 2026 itibarıyla Microsoft Entra Connect Sync’in Windows Server 2025 üzerinde resmi olarak desteklendiğini duyurdu ve kurulum önkoşulları sayfasında artık Windows Server 2025 ya da Windows Server 2022 öneriliyor. Aynı dönemde ürünün kendisi de ciddi şekilde değişti: 2.5.76.0 sürümünden itibaren Entra Connect, Entra ID’ye parolası saklanan bir senkronizasyon hesabı yerine sertifikalı bir uygulama kimliğiyle (application-based authentication) bağlanıyor. Ayrıca Microsoft, en az 2.5.79.0 sürümünde olmayan tüm Entra Connect Sync kurulumlarının 30 Eylül 2026 itibarıyla senkronizasyonu durduracağını duyurdu. Yani eski bir sürümle çalışan ortamlar için bu seri aynı zamanda bir güncelleme hatırlatması.

Seri boyunca Active Directory’nin kurulumuna girmiyoruz; çalışan bir Active Directory ortamınız olduğunu varsayıyor ve odağı tamamen Entra tarafına veriyoruz. Bu bölümde alan adımızı tenant’a ekliyor, Active Directory tarafında senkronizasyondan önce kontrol etmemiz gerekenleri gözden geçiriyor ve Entra Connect’i kuracağımız sunucuyu hazırlıyoruz.

Lab Mimarisi

Lab ortamımızı VMware Workstation üzerinde üç sanal makineyle kuruyoruz. Aynı yapıyı Hyper-V ya da başka bir sanallaştırma platformunda da birebir kurabilirsiniz; platforma özgü adımlarda iki alternatifi de not olarak vereceğiz.

Entra Connect’i domain controller üzerine değil, ayrı bir üye sunucuya kuruyoruz. Microsoft, Entra Connect’in domain controller üzerine kurulmasını desteklese de gerçek ortamlarda iki rolü ayırmak hem yönetimi hem de saldırı yüzeyini sadeleştiriyor. Bununla birlikte W25ENTRA‘nın sıradan bir üye sunucu olmadığını baştan not edelim: Password Hash Synchronization kullanan bir Entra Connect sunucusu, domain’deki tüm parola karmalarına erişebilen bir hizmet hesabı çalıştırdığı için Active Directory yönetim katman modelinde Tier 0 varlık olarak korunmalı.

Gereksinimler

• Çalışan bir Active Directory ortamı. Lab’ımızda forest adı bakicubuk.tech, NetBIOS adı BAKICUBUK.
• Bir Microsoft Entra ID tenant’ı ve bu tenant’ta Global Administrator yetkili, onmicrosoft.com uzantılı cloud-only bir yönetici hesabı.
• Bölüm 3’teki Conditional Access politikaları için Microsoft Entra ID P1 lisansı. Microsoft 365 Business Premium ya da Entra ID P1 deneme sürümü lab için yeterli.
• Sahip olduğumuz ve DNS kayıtlarını yönetebildiğimiz bir alan adı. Biz bu seri için bakicubuk.tech alan adını kullanıyoruz.

Neden .local Değil?

Sahada karşılaştığımız Active Directory ortamlarının önemli bir kısmının forest adı sirket.local ya da sirket.lan gibi internette yönlendirilemeyen (non-routable) bir uzantıya sahip. Bu adlar on-premises tarafta sorunsuz çalışsa da Entra ID tarafında ciddi bir engel oluşturuyor: Entra Connect, kullanıcıların UPN (User Principal Name) uzantısının Entra ID’de doğrulanmış bir alan adıyla eşleşmesini bekliyor. .local uzantısı doğrulanamadığı için bu kullanıcılar Entra ID’ye tenant’ın onmicrosoft.com uzantısıyla oluşturuluyor ve buluta on-premises UPN’leriyle değil, bu adresle oturum açmak zorunda kalıyor.

Lab forest’ımız doğrudan sahip olduğumuz bakicubuk.tech alan adıyla kurulu olduğu için varsayılan UPN uzantısı zaten doğrulanabilir bir alan adı ve ek bir UPN düzenlemesine gerek kalmıyor. Forest’ınız .local uzantılıysa bölümün sonundaki “Mevcut .local Ortamlar İçin” başlığındaki adımları senkronizasyondan önce uygulamanız gerekiyor.

Adım 1: Alan Adını Tenant’a Ekleme ve Doğrulama

İlk işimiz bakicubuk.tech alan adını tenant’ımıza ekleyip doğrulamak. DNS yayılımı birkaç dakika sürebileceği için bu adımı en başta yapıp, domain controller kurulumuyla paralel ilerletmek zaman kazandırıyor. Alan adını Microsoft 365 admin center üzerinden ekliyoruz, çünkü buradaki sihirbaz doğrulamanın yanında Microsoft 365 servisleri için gereken DNS kayıtlarını da adım adım gösteriyor.

Microsoft 365 admin center’a Global Administrator hesabımızla oturum açıyoruz ve Settings > Domains (Ayarlar > Etki alanları) bölümüne geçiyoruz. Add domain (Etki alanı ekle) butonuna tıklayıp alan adı olarak bakicubuk.tech yazıyor ve Use this domain (Bu etki alanını kullan) ile devam ediyoruz.

Domain name (Etki alanı adı) alanına bakicubuk.tech yazıp Use this domain (Bu etki alanını kullan) ile devam ediyoruz.

Sihirbaz bir sonraki ekranda alan adının bize ait olduğunu doğrulamamızı istiyor. Alan adımızın DNS’i Cloudflare üzerinde barındırıldığı için Microsoft 365, Domain Connect protokolünü destekleyen bu sağlayıcıyı otomatik olarak tanıyor ve Sign in to Cloudflare (Cloudflare’de oturum aç) seçeneğini sunuyor. Verify (Doğrula) butonuna tıklıyoruz.

Açılan Cloudflare penceresinde oturum açtıktan sonra Microsoft’un eklemek istediği DNS kaydı listeleniyor: alan adının köküne (@) yazılacak MS=ms... değerli bir TXT kaydı. Bu yetkilendirmenin tek seferlik olduğu ve Microsoft’a sonraki değişiklikler için izin vermediği ekranda açıkça belirtiliyor. Authorize (Yetkilendir) ile onaylıyoruz.

Doğrulama tamamlandığında sihirbaz alan adının kurulumunun bittiğini bildiriyor. Done (Bitti) ile sihirbazı kapatıyoruz.

Domains listesine döndüğümüzde bakicubuk.tech alan adının eklendiğini görüyoruz. Status (Durum) sütununda No services selected (Hizmet seçilmedi) yazması sorun değil: bu ifade, alan adıyla birlikte Exchange Online gibi bir Microsoft 365 servisi yapılandırmadığımızı gösteriyor. Hibrit kimlik açısından Entra Connect’in tek beklentisi alan adının doğrulanmış olması; MX, SPF ve autodiscover gibi servis kayıtları yalnızca alan adını e-posta için kullanacaksak gerekiyor.

Lab’ımızda bakicubuk.tech varsayılan (Default) alan adı olarak görünüyor. Bu, portaldan oluşturulacak yeni cloud kullanıcılarının varsayılan olarak bu uzantıyı alacağı anlamına geliyor; senkronize kullanıcılar ise UPN’lerini zaten on-premises Active Directory’den alıyor.

Adım 2: Active Directory Ön Koşul Kontrolleri

Entra Connect kurulumuna geçmeden önce Active Directory tarafında dört noktayı kontrol ediyoruz. Aşağıdaki komutları W25DC üzerinde yönetici PowerShell’de çalıştırıyoruz.

UPN Uzantısı ve Forest Bilgisi

Get-ADForest | Select-Object Name, ForestMode, UPNSuffixes
Get-ADDomain | Select-Object DNSRoot, NetBIOSName, DomainMode

Forest adının tenant’ta doğruladığımız alan adıyla (bakicubuk.tech) aynı olduğunu görüyoruz. Forest adı farklıysa ya da .local uzantılıysa, doğrulanmış alan adının UPNSuffixes listesinde bulunması gerekiyor.

Senkronize Edilecek Kullanıcılar

Senkronizasyon kapsamını net şekilde sınırlayabilmek için buluta gidecek kullanıcıları ayrı bir OU’da topluyoruz. Lab’ımızda bu OU’nun adı LabUsers; Bölüm 2’de Entra Connect’e yalnızca bu OU’yu senkronize etmesini söyleyeceğiz. Böylece Administrator gibi yerleşik hesaplar ve hizmet hesapları buluta hiç gitmeyecek. Kullanıcıların UPN’lerinin doğrulanmış alan adıyla bittiğini kontrol ediyoruz:

Get-ADUser -SearchBase "OU=LabUsers,DC=bakicubuk,DC=tech" -Filter * |
  Select-Object SamAccountName, UserPrincipalName, Enabled

Tüm kullanıcıların UPN’i @bakicubuk.tech ile bitmeli. UPN’i boş olan ya da farklı bir uzantı taşıyan kullanıcılar Entra ID’ye onmicrosoft.com uzantısıyla oluşturulacağı için senkronizasyondan önce düzeltilmeli.

Active Directory Recycle Bin

Entra Connect kurulumunun son ekranında, Active Directory Recycle Bin etkin değilse bunu öneren bir uyarı görüntüleniyor. Hibrit bir ortamda Recycle Bin’in önemi daha da artıyor: yanlışlıkla silinen bir kullanıcıyı yeniden oluşturduğumuzda yeni bir nesne ortaya çıkıyor ve Entra ID tarafındaki eşleşme bozulabiliyor. Recycle Bin’den geri getirilen nesne ise aynı kimlik bilgileriyle döndüğü için senkronizasyon kaldığı yerden devam ediyor. Durumu kontrol edip etkin değilse açıyoruz:

Get-ADOptionalFeature -Filter 'Name -like "Recycle Bin*"' | Select-Object Name, EnabledScopes
Enable-ADOptionalFeature 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target 'bakicubuk.tech' -Confirm:$false

EnabledScopes alanı doluysa Recycle Bin zaten etkin demektir ve ikinci komuta gerek yoktur. Bu işlem geri alınamıyor, ancak Microsoft tarafından tüm ortamlar için öneriliyor.

Test İstemcisi

Bölüm 4’teki Seamless SSO testinde kullanacağımız W11CL01 istemcisinin domain’e bağlı olduğunu ve bilgisayar nesnesinin LabComputers OU’sunda bulunduğunu kontrol ediyoruz. Windows 11 Home sürümü domain’e katılamadığı için istemcinin Pro ya da Enterprise sürümü olması gerekiyor.

Get-ADComputer W11CL01 | Select-Object Name, DistinguishedName, Enabled

Adım 3: W25ENTRA Sunucusunu Hazırlama

Entra Connect kuracağımız sunucunun işletim sistemi seçimi önemli: Microsoft Entra Connect, tam grafik arayüzü olan bir sunucu gerektiriyor ve Server Core üzerinde desteklenmiyor. Bu nedenle W25ENTRA‘ya Windows Server 2025 Standard (Desktop Experience) kuruyoruz.

Sanal TPM Ekleme

Entra Connect’in güncel sürümleri Entra ID’ye bir uygulama kimliği ve sertifikayla bağlanıyor. Bu sertifikanın TPM 2.0 içinde saklanması Microsoft tarafından zorunlu değil ama şiddetle öneriliyor; TPM yoksa kurulum yazılım tabanlı bir sertifikaya geri düşüyor. Sertifikanın özel anahtarının sunucudan dışarı çıkarılamaması güvenlik açısından ciddi bir kazanım olduğu için sanal makineye kurulumdan önce sanal TPM ekliyoruz.

Sanal TPM’in nasıl ekleneceği kullandığımız sanallaştırma platformuna göre değişiyor, ancak tüm platformlarda iki ortak kural var: sanal makinenin UEFI firmware ile çalışması ve TPM eklenirken kapalı olması. BIOS (legacy) firmware ile kurulmuş bir sanal makinede sanal TPM eklenemiyor; kurulu bir işletim sistemini sonradan UEFI’ye geçirmek de sanal makineyi açılmaz hale getirebildiği için firmware seçimini işletim sistemi kurulumundan önce yapmak gerekiyor.

VMware Workstation (lab ortamımız): Workstation’da sanal TPM yalnızca şifrelenmiş sanal makinelerde destekleniyor, bu yüzden işlemi iki aşamada yapıyoruz: önce sanal makineyi şifreliyor, ardından TPM donanımını ekliyoruz. Başlamadan önce sanal makineyi tamamen kapatıyoruz (suspend değil, Shut Down Guest) ve VM Settings > Options > Advanced altında Firmware type (Firmware türü) değerinin UEFI olduğunu kontrol ediyoruz.

Sanal makineye sağ tıklayıp Settings (Ayarlar) ile Virtual Machine Settings penceresini açıyor, Options sekmesinde Access Control (Erişim denetimi) satırını seçiyoruz. Özet sütununda Not encrypted (Şifrelenmemiş) yazdığını görüyor ve sağ taraftaki Encrypt (Şifrele) butonuna tıklıyoruz.

Açılan Encrypt Virtual Machine penceresinde What to encrypt (Neyi şifreleyelim) bölümünde iki seçenek var.

• All the files (Tüm dosyalar) seçeneği sanal diskler (.vmdk) dahil sanal makinenin tüm dosyalarını şifreliyor; disk boyutuna bağlı olarak işlem uzun sürebiliyor ve disk performansını etkileyebiliyor.
• Only the files needed to support a virtual TPM (Yalnızca sanal TPM için gereken dosyalar) seçeneği ise yalnızca .nvram, .vmss, .vmem, .vmx ve .vmsn dosyalarını şifreliyor; sanal diskler şifrelenmediği için işlem saniyeler içinde tamamlanıyor.

Lab için Only the files needed to support a virtual TPM (Yalnızca sanal TPM için gereken dosyalar) seçeneği seçeneği işaretliyoruz.

Password (Parola) ve Confirm (Onayla) alanlarına şifreleme parolasını giriyoruz. Remember the password for this virtual machine in Credential Manager (Bu sanal makinenin parolasını Credential Manager’da hatırla) kutusunu işaretlersek Workstation parolayı Windows Credential Manager’da saklıyor ve sanal makineyi her açtığımızda parola sormuyor. Encrypt ile işlemi başlatıyoruz.

İşlem tamamlandığında Access Control satırının özeti Encrypted (Şifrelenmiş) olarak değişiyor ve sağ tarafta sanal makinenin kısmen şifrelendiğini (partially encrypted) belirten bilgi görünüyor. Bu, yalnızca TPM için gereken dosyaların şifrelendiği anlamına geliyor.

Şimdi TPM’i ekleyebiliriz. Hardware (Donanım) sekmesine geçip listenin altındaki Add (Ekle) butonuna tıklıyoruz.

Add Hardware Wizard (Donanım Ekleme Sihirbazı) penceresinde Hardware types (Donanım türleri) listesinden Trusted Platform Module seçeneğini seçip Finish (Bitir) butonuna tıklıyoruz. Bu seçenek listede yalnızca sanal makine şifrelenmiş ve UEFI firmware ile yapılandırılmışsa görünüyor.

Donanım listesinde Trusted Platform Module satırının Present (Mevcut) olarak eklendiğini görüyoruz. OK ile ayarları kaydedip sanal makineyi açıyoruz.

Microsoft Hyper-V: Sanal TPM yalnızca Generation 2 sanal makinelerde destekleniyor; Generation 1 olarak oluşturulmuş bir sanal makineye TPM eklenemiyor. Sanal makine kapalıyken Hyper-V Manager’da Settings > Security altında Enable Trusted Platform Module seçeneğini işaretliyoruz. Aynı işlem, Hyper-V rolünün kurulu olduğu fiziksel host üzerinde yönetici PowerShell’de şu komutlarla da yapılabiliyor:

(Get-VM -Name W25ENTRA).Generation
Set-VMKeyProtector -VMName W25ENTRA -NewLocalKeyProtector
Enable-VMTPM -VMName W25ENTRA

Bu komutlar sanal makinenin içinde değil, host üzerinde çalıştırılmalı. İlk komut 2 değerini döndürmüyorsa sanal makine Generation 1’dir.

VMware ESXi ve vCenter: vSphere ortamında sanal TPM için vCenter Server ve tanımlı bir key provider gerekiyor; en pratik seçenek vCenter ile birlikte gelen vSphere Native Key Provider. Tek başına yönetilen bir ESXi host’unda key provider olmadığı için sanal TPM eklenemiyor. Key provider hazır olduğunda sanal makinenin firmware’inin EFI olduğunu kontrol ediyor, sanal makine kapalıyken Edit Settings > Add New Device > Trusted Platform Module ile TPM’i ekliyoruz.

Proxmox VE: Sanal makinenin BIOS ayarı OVMF (UEFI) olmalı ve bir EFI disk tanımlı olmalı. Sanal makine kapalıyken Hardware > Add > TPM State seçeneğiyle, sürüm olarak v2.0 seçip TPM durumunun saklanacağı depolama alanını belirliyoruz. Aynı işlem Proxmox host’unda komut satırından da yapılabiliyor; örnekteki 105 yerine kendi sanal makine kimliğinizi yazın:

qm set 105 --tpmstate0 local-lvm:1,version=v2.0

Nutanix AHV: AHV, güncel AOS sürümlerinde UEFI ile açılan sanal makineler için sanal TPM’i destekliyor. Sanal makine kapalıyken bir CVM üzerinden acli ile etkinleştirebiliyoruz:

acli vm.update W25ENTRA virtual_tpm=true

AOS ve Prism Central sürümüne bağlı olarak aynı ayar Prism Central’da sanal makine düzenleme ekranında da seçenek olarak bulunuyor. Ortamınızdaki AOS sürümünün sanal TPM’i desteklediğini Nutanix dokümantasyonundan kontrol etmenizi öneriyoruz.

TPM’in Etkin Olduğunu Doğrulama

Sanal makine açıldıktan sonra işletim sisteminin TPM’i gördüğünü ve kullanıma hazır olduğunu doğruluyoruz. W25ENTRA üzerinde yönetici PowerShell’de:

Get-Tpm | Select-Object TpmPresent, TpmReady, TpmEnabled, TpmActivated, ManufacturerIdTxt
Get-CimInstance -Namespace root/cimv2/Security/MicrosoftTpm -ClassName Win32_Tpm |
  Select-Object SpecVersion, IsEnabled_InitialValue, IsActivated_InitialValue

İlk komutta TpmPresent, TpmReady, TpmEnabled ve TpmActivated değerlerinin hepsi True olmalı. VMware sanal TPM’lerinde ManufacturerIdTxt alanında üretici olarak VMware görünüyor. İkinci komuttaki SpecVersion alanının 2.0 ile başlaması, TPM’in Entra Connect’in beklediği 2.0 sürümünde olduğunu gösteriyor.

Aynı bilgiyi grafik arayüzden görmek için Run (Çalıştır) penceresine tpm.msc yazıp TPM Management on Local Computer (Yerel Bilgisayarda TPM Yönetimi) konsolunu açabiliyoruz. Status (Durum) bölümünde The TPM is ready for use (TPM kullanıma hazır) ifadesi, TPM Manufacturer Information bölümünde de Specification Version (Belirtim Sürümü) olarak 2.0 görünmeli.

TpmPresent değeri False geliyorsa TPM sanal makineye eklenmemiş ya da sanal makine UEFI ile açılmıyor demektir; sanal makine ayarlarını tekrar kontrol edin. TpmPresent True ancak TpmReady False ise TPM’in işletim sistemi tarafından hazırlanması tamamlanmamış olabilir; bu durumda Initialize-Tpm komutunu çalıştırıp sunucuyu yeniden başlatmak genellikle yeterli oluyor.

Mevcut .local Ortamlar İçin

Sahada forest’ı yeniden adlandırmak çoğu zaman mümkün değil. Mevcut forest’ınız .local uzantılıysa, Entra Connect kurulumuna geçmeden önce doğrulanmış alan adınızı alternatif UPN suffix olarak ekleyip, senkronize edilecek kullanıcıların UPN’ini bu uzantıya çevirmeniz gerekiyor. Aşağıdaki örnekte sirket.local forest’ına bakicubuk.tech uzantısını ekliyor ve yalnızca belirli bir OU’daki kullanıcıların UPN’ini değiştiriyoruz:

Get-ADForest | Set-ADForest -UPNSuffixes @{Add="bakicubuk.tech"}
(Get-ADForest).UPNSuffixes

$OU = "OU=Kullanicilar,DC=sirket,DC=local"
Get-ADUser -SearchBase $OU -Filter "UserPrincipalName -like '*@sirket.local'" |
  ForEach-Object {
    $newUpn = $_.UserPrincipalName -replace '@sirket\.local$','@bakicubuk.tech'
    Set-ADUser $_ -UserPrincipalName $newUpn
  }
Get-ADUser -SearchBase $OU -Filter * | Select-Object SamAccountName, UserPrincipalName

UPN değişikliği kullanıcıların on-premises oturum açmasını etkilemiyor; kullanıcılar SIRKET\ayse.demir biçimiyle oturum açmaya devam edebiliyor. Bu ortamlarda Entra Connect sihirbazının Microsoft Entra sign-in configuration ekranında .local uzantısı Not Added olarak görünmeye devam edecek ve Continue without matching all UPN suffixes to verified domains kutusunu işaretlemeniz gerekecek. Senkronize edilecek tüm kullanıcılar doğrulanmış uzantıyı kullandığı sürece bu kutuyu işaretlemek güvenli; sorun, kutuyu işaretleyip UPN’leri düzeltmeden devam etmek.

Özet ve Sonraki Bölüm

Bu bölümde hibrit kimlik yapısının temelini hazırladık: bakicubuk.tech alan adını tenant’ımıza ekleyip doğruladık, Active Directory tarafında UPN uzantılarını, senkronize edilecek kullanıcıları ve Recycle Bin durumunu kontrol ettik, Entra Connect’i kuracağımız W25ENTRA sunucusunu sanal TPM ile hazırlayıp domain’e kattık.

Bölüm 2’de W25ENTRA üzerinde ön kontrolleri yapıp Microsoft Entra Connect Sync kurulum sihirbazının her ekranını tek tek ele alacak, hangi seçeneği neden seçtiğimizi açıklayacağız.