Merhaba

Serinin ilk bölümünde bakicubuk.tech alan adını tenant’ımıza ekleyip doğruladık, Active Directory tarafındaki ön koşulları kontrol ettik ve Entra Connect’i kuracağımız W25ENTRA sunucusunu sanal TPM ile hazırladık. Bu bölümde W25ENTRA üzerinde Microsoft Entra Connect Sync’i kuruyoruz. Sihirbazın her ekranında karşımıza çıkan seçenekleri tek tek açıklayacak, hangisiyle neden devam ettiğimizi gerekçeleriyle anlatacağız. Eski sürümlerden bilinen TLS 1.2, MFA ve senkronizasyon hesabı sorunlarının güncel sürümde nasıl ortadan kalktığını da yeri geldikçe göstereceğiz.

Adım 1: Ön Kontroller

Microsoft Entra Connect’in güncel sürümü, işletim sistemi tarafında .NET Framework ve TLS 1.2 desteği bekliyor. Eski sürümlerde (2.3.20.0 ile 2.4.129.0 arası) kurulum sihirbazı TLS 1.2’nin registry üzerinden açıkça zorlanmış olmasını şart koşuyor ve bu değerler yoksa “Incorrect version of TLS” hatasıyla kurulumu durduruyordu. Microsoft’un TLS dokümanına göre 2.4.131.0 ve sonraki sürümler bu zorlamayı kurulumdan önce istemiyor.

Yine de kuruluma başlamadan önce sunucunun durumunu görmek iyi bir alışkanlık. W25ENTRA üzerinde yönetici PowerShell’de aşağıdaki kontrolü çalıştırıyoruz; komut Microsoft’un listelediği tüm TLS registry değerlerini, .NET Framework sürümünü ve TPM durumunu tek seferde gösteriyor:

$keys = @(
  @{Path='HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319'; Names='SystemDefaultTlsVersions','SchUseStrongCrypto'},
  @{Path='HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319'; Names='SystemDefaultTlsVersions','SchUseStrongCrypto'},
  @{Path='HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server'; Names='Enabled','DisabledByDefault'},
  @{Path='HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client'; Names='Enabled','DisabledByDefault'}
)
$result = foreach ($k in $keys) {
  foreach ($n in $k.Names) {
    $v = (Get-ItemProperty -Path $k.Path -Name $n -ErrorAction SilentlyContinue).$n
    [pscustomobject]@{Path=$k.Path; Name=$n; Value= if ($null -eq $v) {'Not Found'} else {$v}}
  }
}
$result | Format-Table -AutoSize -Wrap

(Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full').Release
Get-Tpm | Select-Object TpmPresent, TpmReady

Temiz bir Windows Server 2025 kurulumunda registry değerlerinin tamamının Not Found gelmesi normal. Bu, TLS 1.2’nin kapalı olduğu anlamına gelmiyor; değerler hiç yazılmamış ve işletim sistemi varsayılanları devrede. Windows Server 2025, .NET Framework 4.8.1 ile geliyor ve lab’ımızda .NET Release değeri 533509 olarak göründü. Bu değer Entra Connect’in beklediği sürümün çok üzerinde.

foreach ($p in 'HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319','HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319') {
  New-Item -Path $p -Force | Out-Null
  Set-ItemProperty -Path $p -Name 'SystemDefaultTlsVersions' -Value 1 -Type DWord
  Set-ItemProperty -Path $p -Name 'SchUseStrongCrypto' -Value 1 -Type DWord
}
foreach ($side in 'Server','Client') {
  $p = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\$side"
  New-Item -Path $p -Force | Out-Null
  Set-ItemProperty -Path $p -Name 'Enabled' -Value 1 -Type DWord
  Set-ItemProperty -Path $p -Name 'DisabledByDefault' -Value 0 -Type DWord
}
Restart-Computer

Adım 2: Kurulum Paketini İndirme

Microsoft, Entra Connect Sync’in yeni sürümlerini artık Microsoft Download Center üzerinden dağıtmıyor; kurulum paketi yalnızca Microsoft Entra admin center’daki Microsoft Entra Connect bölmesinden indirilebiliyor. İnternette farklı kaynaklarda dolaşan eski MSI dosyalarını kullanmak, bu bölümde anlatacağımız güncel davranışlar yerine eski sürümlerin hatalarıyla karşılaşmak anlamına geliyor.

W25ENTRA üzerinde Microsoft Edge ile Microsoft Entra admin center’a Global Administrator ya da Hybrid Identity Administrator hesabıyla oturum açıyoruz. Sol menüde Entra ID > Entra Connect bölümüne geçiyor, Get started (Başlarken) sayfasında Manage (Yönet) sekmesini seçiyoruz.

Sayfanın üst kısmındaki Action Required (Eylem gerekli) uyarısı, Bölüm 1’de değindiğimiz son tarihi portal üzerinden de teyit ediyor: 2.5.79.0’dan eski Entra Connect sürümleri 30 Eylül 2026 itibarıyla kullanım dışı kalıyor. Manage sekmesinde iki senkronizasyon seçeneği yan yana sunuluyor.

• Manage from the cloud: Cloud Sync bölümü, hafif bir provisioning agent ile çalışan ve yapılandırması tamamen buluttan yönetilen Microsoft Entra Cloud Sync içindir.
• Manage from on-premises: Connect Sync bölümü ise bu seride kuracağımız, karmaşık topolojileri, özel senkronizasyon kurallarını ve Seamless SSO’yu destekleyen Microsoft Entra Connect Sync içindir.

Download Connect Sync Agent (Connect Sync Agent’ı indir) butonuna tıklıyoruz.

Sağ tarafta açılan Download Connect Sync Agent panelinde, ajanı indirmenin hizmet koşullarını kabul etmek anlamına geldiği belirtiliyor. Accept terms & download (Koşulları kabul et ve indir) butonuna tıklıyoruz.

Microsoft Edge, indirilecek dosya için ne yapmak istediğimizi soruyor. Save (Kaydet) ile dosyayı Downloads (İndirilenler) klasörüne kaydediyoruz.

İndirme tamamlandığında dosya Downloads listesinde görünüyor. Open file (Dosyayı aç) ile kurulumu doğrudan buradan başlatabiliyoruz.

İndirilen dosyayı çalıştırdığımızda önce bileşenler kuruluyor, ardından yapılandırma sihirbazı açılıyor.

Welcome ekranında lisans koşullarını kabul edip Continue ile ilerliyoruz.

Adım 3: Express Settings Yerine Customize

Sihirbazın ilk karar ekranı Express Settings (Hızlı ayarlar). Express, tek forest’lı basit ortamlar için hazırlanmış bir kısayol: tüm domain’i ve tüm OU (Organizational Unit)’ları senkronize ediyor, oturum açma yöntemi olarak Password Hash Synchronization‘ı seçiyor ve bu kararlara müdahale etme imkanı vermiyor. Özellikle senkronizasyon kapsamını sınırlayamamak, yerleşik hesapların ve hizmet hesaplarının da buluta gitmesi demek.

Bu yüzden Use express settings (Hızlı ayarları kullan) yerine Customize (Özelleştir) butonuyla devam ediyoruz. Serinin geri kalanında yaptığımız her seçim, Express’in bizim yerimize verdiği kararların bilinçli karşılıkları olacak.

Adım 4: Install Required Components (Gerekli Bileşenleri Yükle)

Customize ile devam ettiğimizde sihirbaz, sunucuda mevcut bir senkronizasyon servisi olmadığını tespit ediyor ve Microsoft Entra Connect Sync servisini kuracağını söylüyor.

Bu ekranda beş seçenek var; hiçbirini işaretlemezsek sihirbaz tüm bileşenleri varsayılan değerlerle kuruyor.

• Specify a custom installation location (Özel kurulum konumu belirt): Varsayılan olarak Entra Connect C:\Program Files\Microsoft Azure AD Sync altına kuruluyor. Uygulama dosyalarını ve yerel veritabanını farklı bir diske almak istediğimizde bu seçeneği işaretliyoruz. Kurumsal ortamlarda sistem diskini sade tutmak için tercih edilebilir, lab için gerek yok.
• Use an existing SQL Server (Mevcut bir SQL Server kullan): İşaretlemezsek sihirbaz SQL Server Express LocalDB kuruyor. Express sürümünün 10 GB veritabanı sınırı var ve Microsoft bunu yaklaşık 100.000 nesneye kadar olan dizinler için yeterli görüyor. Daha büyük ortamlarda ya da veritabanını merkezi bir SQL altyapısında (Örneğin Always On) tutmak istediğimizde bu seçenekle tam sürüm bir SQL Server örneği gösteriyoruz.
• Use an existing service account (Mevcut bir hizmet hesabı kullan): Senkronizasyon servisi varsayılan olarak sihirbazın otomatik oluşturduğu bir Virtual Service Account (NT SERVICE\ADSync) ile çalışıyor; parolası yönetilmesi gereken bir hesap yok. Uzak bir SQL Server kullanacaksak ya da kurum politikası gereği bir group Managed Service Account (gMSA) ile çalışmak istiyorsak bu seçeneği işaretliyoruz.
• Specify custom sync groups (Özel senkronizasyon grupları belirt): Kurulum, sunucu üzerinde yerel olarak ADSyncAdmins, ADSyncOperators, ADSyncBrowse ve ADSyncPasswordSet gruplarını oluşturuyor ve Entra Connect yönetim yetkilerini bu gruplar üzerinden veriyor. Bu grupları önceden domain’de oluşturduysak ve yetkileri merkezi yönetmek istiyorsak bu seçenekle mevcut grupları gösteriyoruz.
• Import synchronization settings (Senkronizasyon ayarlarını içe aktar): Başka bir Entra Connect sunucusundan dışa aktarılmış JSON yapılandırma dosyasını içe aktarmak için kullanılıyor. Özellikle eski bir sunucudan yenisine geçişte (swing migration) aynı filtreleme ve kural ayarlarını elle tekrar yapmamak için işimize yarıyor. Sıfırdan kurulumda anlamı yok.

Bizim lab’ımızda sıfırdan tek sunuculu bir kurulum yaptığımız ve nesne sayısı Express sınırının çok altında kaldığı için hiçbir seçeneği işaretlemeden Install (Yükle) ile devam ediyoruz.

Adım 5: User Sign-in (Kullanıcı Oturum Açma)

Bu ekranda kullanıcılarımızın Microsoft Entra ID’ye, dolayısıyla Microsoft 365 ve diğer bulut uygulamalarına oturum açarken parolalarının nerede doğrulanacağını seçiyoruz. Bu karar hibrit kimlik mimarisinin en temel kararı, çünkü on-premises ortamda bir kesinti yaşandığında kullanıcıların buluta erişip erişemeyeceğini doğrudan belirliyor.

• Password Hash Synchronization (Parola karması eşitleme): Entra Connect, kullanıcıların parolasının kendisini değil, Active Directory’de tutulan parola karmasının tekrar tuzlanıp karma işleminden geçirilmiş bir türevini Entra ID’ye gönderiyor. Parola doğrulaması tamamen bulutta yapılıyor. En büyük avantajı dayanıklılık: domain controller’lar ya da Entra Connect sunucusu erişilemez olsa bile kullanıcılar buluta oturum açmaya devam ediyor. Ayrıca Entra ID Protection’ın sızdırılmış kimlik bilgisi tespiti (leaked credentials) yalnızca bu yöntemle çalışıyor. Ek altyapı gerektirmiyor ve Microsoft’un önerdiği yöntem.
• Pass-through authentication (Doğrudan kimlik doğrulama): Parola bulutta saklanmıyor; oturum açma isteği on-premises ortamda kurulu hafif bir ajana iletiliyor ve ajan parolayı doğrudan Active Directory’ye karşı doğruluyor. Hesap kilitleme, oturum açma saatleri ve parola süresi gibi on-premises politikaların anında uygulanması gereken ya da parola türevinin bile buluta gitmemesini şart koşan kurumlar bu yöntemi tercih ediyor. Bedeli ise bağımlılık: ajanlara ulaşılamazsa kimse oturum açamıyor. Bu yüzden yüksek erişilebilirlik için birden fazla ajan kurmak gerekiyor.
• Federation with AD FS (AD FS ile federasyon): Kimlik doğrulama tamamen on-premises AD FS sunucu çiftliğine devrediliyor. Akıllı kart, sertifika tabanlı ya da üçüncü taraf MFA gibi gelişmiş senaryolar için geçmişte tek seçenekti. Ancak AD FS ve Web Application Proxy sunucuları, sertifika yönetimi ve yüksek erişilebilirlik gibi ciddi bir altyapı yükü getiriyor. Microsoft bugün bu senaryoların çoğunu bulutta karşılayabildiği için AD FS’ten bulut kimlik doğrulamasına geçişi öneriyor.
• Federation with PingFederate (PingFederate ile federasyon): AD FS ile aynı mantıkta çalışıyor, yalnızca federasyon sunucusu olarak Ping Identity’nin ürünü kullanılıyor. Ortamda zaten PingFederate varsa anlamlı.
• Do not configure (Yapılandırma): Sihirbaz herhangi bir oturum açma yöntemi yapılandırmıyor, yalnızca kimlik senkronizasyonu kuruluyor. Farklı bir üçüncü taraf federasyon çözümü kullanan ya da oturum açma yöntemini ayrıca yöneten ortamlar için var.

Enable single sign-on (Çoklu oturum açmayı etkinleştir): Bu kutu Seamless SSO özelliğini açıyor ve yalnızca Password Hash Synchronization ya da Pass-through authentication ile birlikte kullanılabiliyor. Etkinleştirildiğinde Active Directory’de AZUREADSSOACC adında bir bilgisayar hesabı oluşturuluyor ve kurumsal ağdaki domain’e bağlı bilgisayarlar Kerberos bileti ile Entra ID’ye parola girmeden oturum açabiliyor. Özelliğin çalışması için bir de grup ilkesi gerekiyor, onu serinin son bölümünde ele alacağız.

Bizim lab’ımızda Password Hash Synchronization seçimini koruyor ve Enable single sign-on kutusunu işaretleyerek devam ediyoruz. Böylece on-premises kesintilerden etkilenmeyen bulut kimlik doğrulamasını, domain’e bağlı bilgisayarlarda parolasız oturum açma deneyimiyle birleştirmiş oluyoruz.

Enable single sign-on kutusunu işaretlediğimizde sol menüye Configure adımının üstüne Single sign-on adımı ekleniyor. Sihirbazın sonunda bu adımda domain yönetici bilgilerini girerek AZUREADSSOACC bilgisayar hesabının oluşturulmasını sağlayacağız.

Adım 6: Connect to Microsoft Entra ID (Microsoft Entra ID’ye Bağlan)

Bu ekranda Entra Connect’in tenant’ımıza bağlanabilmesi için yetkili bir yönetici hesabıyla oturum açıyoruz. Ekranda dikkat çeken ilk şey yalnızca USERNAME (Kullanıcı adı) alanının bulunması. Eski Entra Connect sürümlerinde kullanıcı adı ve parola bu ekranda birlikte giriliyordu ve sihirbaz, oturum açma işlemini Internet Explorer tabanlı gömülü bir tarayıcı bileşeniyle yapıyordu. Bu bileşen güncel MFA ekranlarını görüntüleyemediği için MFA zorunlu olan tenant’larda Unsupported browser (Desteklenmeyen tarayıcı) hatasıyla karşılaşılıyor, yöneticiler çoğu zaman Security Defaults’u kapatmak ya da hesabı MFA’dan hariç tutmak gibi riskli geçici çözümlere başvuruyordu.

Güncel sürümde ise kullanıcı adını yazıp Next (İleri) dediğimizde WebView2 tabanlı bir Microsoft oturum açma penceresi açılıyor. Parola ve MFA doğrulaması bu pencerede, modern kimlik doğrulama akışıyla yapılıyor. Böylece MFA’yı devre dışı bırakmadan ya da hesabı Conditional Access ilkelerinden hariç tutmadan kurulumu tamamlayabiliyoruz. Bu yüzden kurulum paketini mutlaka Microsoft Entra admin center üzerinden indirilen güncel sürümle yapmak gerekiyor.

Oturum açacağımız hesap olarak onmicrosoft.com uzantılı, cloud-only (yalnızca bulutta tanımlı) bir hesap kullanıyoruz. Bu tercih önemli, çünkü on-premises Active Directory’den senkronize edilen bir hesapla bu adımı yapmak önerilmiyor. Senkronizasyonda ya da on-premises ortamda bir sorun yaşandığında, senkronize edilen hesap etkilenir ve Entra Connect’i yönetecek erişimi de kaybedebiliriz.

Ekran ilk açıldığında USERNAME alanında [email protected] örneği görünüyor ve alan doldurulana kadar Next butonu pasif kalıyor.

USERNAME alanına yönetici hesabımızı, lab’ımızda [email protected], yazıp Next ile devam ediyoruz.

Next dediğimizde sihirbazın üzerinde WebView2 tabanlı Microsoft oturum açma penceresi açılıyor. Bu Sign in ekranında, tarayıcıda Microsoft 365’e oturum açarken gördüğümüz sayfanın aynısı; dolayısıyla tenant’ta tanımlı tüm kimlik doğrulama yöntemleri ve Conditional Access politikaları burada da geçerli. Kullanıcı adı sihirbazdan otomatik olarak aktarılmış geliyor, Next ile ilerliyoruz.

Enter password (Parolayı girin) ekranında hesabın parolasını yazıp Sign in (Oturum aç) butonuna tıklıyoruz.

Parola doğrulandıktan sonra tenant’ımızda MFA zorunlu olduğu için Approve sign in request (Oturum açma isteğini onaylayın) ekranı geliyor. Ekranda gösterilen sayıyı Microsoft Authenticator uygulamasında açılan bildirime giriyor ve isteği onaylıyoruz. Microsoft’un MFA yorgunluğu (MFA fatigue) saldırılarına karşı varsayılan hale getirdiği number matching (sayı eşleştirme) özelliği sayesinde, kullanıcı ekranı görmeden bildirime yanlışlıkla ya da baskı altında onay veremiyor. Eski sürümlerde tam da bu adımda Unsupported browser hatası alınıyordu; güncel sürümde MFA akışı sorunsuz tamamlanıyor.

MFA onayından sonra Windows, Sign in to all apps and websites on this device? (Bu cihazdaki tüm uygulama ve web sitelerinde oturum açılsın mı?) sorusunu soruyor. Yes (Evet) seçeneği hesabı Windows’a iş veya okul hesabı olarak ekliyor ve cihazı kuruluşa kaydederek Microsoft Entra registered (Microsoft Entra’ya kayıtlı) cihaz olarak Entra ID’ye ekliyor. Bu, W25ENTRA üzerindeki diğer uygulama ve tarayıcı oturumlarının da bu Global Administrator hesabıyla otomatik açılması anlamına geliyor.

Entra Connect sunucusu gibi Tier 0 kabul ettiğimiz bir sunucuda yönetici hesabının oturum bilgilerinin işletim sistemi genelinde kalmasını istemiyoruz. Bu yüzden No, this app only (Hayır, yalnızca bu uygulama) seçeneğini seçiyoruz. Böylece oturum yalnızca Entra Connect sihirbazı için açılıyor ve sunucu Entra ID’ye kaydedilmiyor.

Adım 7: Connect Your Directories (Dizinlerinizi Bağlayın)

Bu ekranda senkronize edeceğimiz on-premises dizini tanımlıyoruz. DIRECTORY TYPE (Dizin türü) alanında Active Directory seçili geliyor, FOREST (Orman) alanında ise sihirbaz sunucunun bağlı olduğu forest’ı otomatik olarak buluyor. Birden fazla forest’ı tek bir Entra ID tenant’ına senkronize eden ortamlarda her forest bu ekrandan ayrı ayrı ekleniyor. Bizim lab’ımızda tek forest olduğu için bakicubuk.tech seçiliyken Add Directory (Dizin ekle) butonuna tıklıyoruz.

Açılan AD forest account (AD orman hesabı) penceresinde Entra Connect’in Active Directory’yi okumak ve gerektiğinde geri yazmak için kullanacağı hesabı belirliyoruz. Bu hesaba AD DS Connector account (AD DS bağlayıcı hesabı) deniyor ve iki seçenek var:

• Create new AD account (Yeni AD hesabı oluştur): Sihirbaz, bir kez girdiğimiz Enterprise Admin bilgileriyle MSOL_ önekli yeni bir hizmet hesabı oluşturuyor ve seçtiğimiz özelliklerin gerektirdiği izinleri bu hesaba otomatik olarak veriyor. Hesabın parolası sihirbaz tarafından uzun ve rastgele üretiliyor ve yalnızca Entra Connect’in kendi veritabanında şifreli olarak saklanıyor. Microsoft’un önerdiği ve bizim de tercih ettiğimiz seçenek bu.
• Use existing AD account (Mevcut AD hesabını kullan): Kurum politikası gereği hizmet hesaplarını önceden ve kontrollü şekilde oluşturan ortamlar için. Bu durumda gerekli izinlerin hesaba bizim tarafımızdan eksiksiz verilmesi gerekiyor; Entra Connect ile gelen ADSyncConfig PowerShell modülü bu izinleri vermek için hazır komutlar içeriyor.

ENTERPRISE ADMIN USERNAME alanına Enterprise Admins grubunun üyesi olan hesabı BAKICUBUK\administrator biçiminde, yani NetBIOS domain adıyla, PASSWORD alanına da parolasını girip OK ile onaylıyoruz. bakicubuk.tech\administrator biçimi de kabul ediliyor.

Sihirbaz hesabı oluşturup izinleri atadıktan sonra Connect Directories ekranına dönüyoruz. CONFIGURED DIRECTORIES (Yapılandırılmış dizinler) bölümünde bakicubuk.tech (Active Directory) satırı yeşil onay işaretiyle listeleniyor ve Next butonu etkin hale geliyor. Aynı forest ikinci kez eklenemeyeceği için FOREST alanı boşalıyor ve Add Directory butonu pasif görünüyor. Next ile devam ediyoruz.

Oluşturulan hesabı W25DC üzerinde görebiliyoruz. Hesap Users konteynerinde MSOL_ ile başlayan ve rastgele karakterlerle devam eden bir adla oluşturuluyor:

Get-ADUser -Filter "SamAccountName -like 'MSOL_*'" -Properties Description, PasswordLastSet, LastLogonDate |
  Select-Object SamAccountName, DistinguishedName, PasswordLastSet, LastLogonDate, Description

Enterprise Admin Hesabı Hakkında

Lab ortamında Enterprise Admin bilgisi olarak yerleşik Administrator hesabını kullandık. Burada iki soruyu netleştirmekte fayda var.

İlk soru, bu hesabın sonradan değiştirilmesinin senkronizasyonu etkileyip etkilemeyeceği. Etkilemiyor: sihirbaz Enterprise Admin bilgilerini yalnızca MSOL_ hesabını oluşturmak ve izinleri atamak için bir kez kullanıyor, hiçbir yerde saklamıyor. Senkronizasyon bundan sonra tamamen MSOL_ hesabıyla çalıştığı için Administrator hesabının parolasını değiştirmek, hesabı yeniden adlandırmak ya da devre dışı bırakmak senkronizasyonu kesintiye uğratmıyor. Enterprise Admin bilgileri yalnızca sihirbazı yeniden çalıştırıp yeni bir forest eklemek ya da password writeback gibi ek izin gerektiren bir özelliği açmak istediğimizde tekrar isteniyor.

İkinci soru güvenlikle ilgili. Yerleşik Administrator hesabı (RID 500) her domain’de bulunduğu ve varsayılan olarak hesap kilitleme politikasından muaf olduğu için saldırganların ilk hedeflerinden biri; bu hesabın günlük yönetim işlerinde kullanılmaması ve oturum açma etkinliğinin sıkı izlenmesi öneriliyor. Üretim ortamında bu adım için isimli ve yalnızca bu iş için kullanılan bir yönetici hesabı oluşturmak, Enterprise Admins üyeliğini yalnızca kurulum süresince vermek ve kurulumdan sonra geri almak daha doğru bir yaklaşım. Böylece kurulum dışında hiçbir zaman Enterprise Admin yetkisi taşıyan bir hesap açıkta kalmıyor ve yapılan her işlem isimli bir hesaba bağlanarak denetlenebiliyor.

Kurulum öncesi: isimli yönetici hesabı ve geçici Enterprise Admins üyeliği

New-ADUser -Name "adm-entraconnect" -SamAccountName "adm-entraconnect" `
  -UserPrincipalName "[email protected]" `
  -Path "OU=Tier0Admins,DC=bakicubuk,DC=tech" `
  -AccountPassword (Read-Host -AsSecureString "Parola") -Enabled $true `
  -Description "Entra Connect kurulum ve yapılandırma hesabı"
Add-ADGroupMember -Identity "Enterprise Admins" -Members "adm-entraconnect"

Kurulum sonrası: Enterprise Admins üyeliğini geri al ve hesabı devre dışı bırak

Remove-ADGroupMember -Identity "Enterprise Admins" -Members "adm-entraconnect" -Confirm:$false
Disable-ADAccount -Identity "adm-entraconnect"

Komutu kendi ortamınızda kullanmak için aşağıdaki değerleri değiştirmeniz gerekiyor. Tabloda yer almayan kısımlar (parametre adları, Read-Host ile parolanın güvenli şekilde sorulması, -Enabled $true ve grup adı olan Enterprise Admins) olduğu gibi kalmalı.

-Path ile belirttiğimiz OU (Organizational Unit)’nun önceden var olması gerekiyor, aksi halde komut Directory object not found hatası veriyor. Ortamınızda yönetici hesapları için ayrı bir OU (Organizational Unit) yoksa önce oluşturabilir ya da geçici olarak varsayılan Users konteynerini (CN=Users,DC=sirket,DC=com) kullanabilirsiniz. Mevcut OU (Organizational Unit)’ların distinguished name değerlerini şu komutla listeleyebilirsiniz:

Get-ADOrganizationalUnit -Filter * | Select-Object Name, DistinguishedName

Hesabın oluşturulduğunu ve Enterprise Admins grubuna eklendiğini doğrulamak için:

Get-ADUser adm-entraconnect -Properties MemberOf, Enabled | Select-Object SamAccountName, UserPrincipalName, Enabled, MemberOf
Get-ADGroupMember -Identity "Enterprise Admins" | Select-Object SamAccountName

Enterprise Admins grubu yalnızca forest root domain’de bulunuyor. Birden fazla domain içeren bir forest’ta komutları forest root domain’in bir domain controller’ında çalıştırmanız ya da -Server parametresiyle forest root domain’i göstermeniz gerekiyor. Sihirbazı ileride yeniden çalıştırmanız gerektiğinde hesabı Enable-ADAccount ile etkinleştirip üyeliği geçici olarak tekrar vermeniz yeterli.

Hibrit bir ortamda bu hesapların denetlenmesi en az yapılandırmaları kadar önemli. Domain controller’larda Advanced Audit Policy altında Audit Security Group Management, Audit Logon ve Audit Directory Service Access alt kategorilerinin etkin olduğunu kontrol ediyor ve SIEM tarafında şu olaylar için uyarı tanımlıyoruz:

Adım 8: Microsoft Entra Sign-in Configuration (Microsoft Entra Oturum Açma Yapılandırması)

Bu ekran, on-premises forest’taki UPN uzantılarını Entra ID’deki doğrulanmış alan adlarıyla karşılaştırıyor. Kullanıcıların buluta on-premises kimlik bilgileriyle oturum açabilmesi için UPN uzantılarının Entra ID’de doğrulanmış bir alan adıyla eşleşmesi gerekiyor. Forest’ımız bakicubuk.tech olduğu ve bu alan adını Bölüm 1’de tenant’ta doğruladığımız için tabloda tek satır görünüyor ve durumu Verified (Doğrulandı).

Tablonun sağ altındaki yenileme simgesi, Entra ID’deki alan adı durumunu yeniden sorguluyor. Sihirbaz açıkken tenant’a yeni bir alan adı ekleyip doğruladığımızda, sihirbazı kapatmadan bu simgeyle tabloyu güncelleyebiliyoruz.

Ekranın alt kısmındaki USER PRINCIPAL NAME alanı, kullanıcıların Entra ID’deki oturum açma adının (Entra ID tarafındaki userPrincipalName değerinin) hangi on-premises öznitelikten alınacağını belirliyor. Açılır listeye baktığımızda scriptPath, sn, title, unicodePwd, whenCreated gibi onlarca öznitelik görüyoruz. Bunun nedeni, sihirbazın Active Directory şemasındaki kullanıcı nesnesine ait tüm tek değerli öznitelikleri listelemesi; bu, hepsinin oturum açma adı olarak kullanılabileceği anlamına gelmiyor.

Bir özniteliğin oturum açma adı olarak kullanılabilmesi için üç şartı karşılaması gerekiyor: her kullanıcı için dolu ve benzersiz olması, kullanici@alanadi biçiminde bir değer taşıması ve @ işaretinden sonraki bölümün Entra ID’de doğrulanmış bir alan adı olması. Listedeki özniteliklerin büyük çoğunluğu (soyad, unvan, adres, telefon, oluşturulma tarihi gibi) bu şartları hiçbir zaman karşılamıyor.

Pratikte anlamlı olan seçenekler şunlar:

userPrincipalName dışında bir öznitelik seçtiğimiz senaryoya Alternate Login ID (alternatif oturum açma kimliği) deniyor. Bu durumda Entra ID’deki kullanıcı adı, on-premises UPN’den farklı oluyor. Microsoft bu yapıyı yalnızca UPN’lerin değiştirilemediği durumlar için öneriyor, çünkü on-premises ve bulut kimliklerinin farklı adlar taşıması bazı Office istemcilerinde tekrar tekrar kimlik bilgisi istenmesine, Microsoft Entra hybrid join ve Exchange hibrit gibi senaryolarda ek yapılandırma ihtiyacına ve destek süreçlerinde karışıklığa yol açabiliyor. Kullanıcıların e-posta adresleriyle oturum açması asıl hedefse, UPN’leri e-posta adresleriyle eşitlemek en temiz çözüm.

Lab’ımızda kullanıcıların UPN’leri doğrulanmış bakicubuk.tech alan adıyla bittiği için USER PRINCIPAL NAME alanında varsayılan userPrincipalName değerini seçili bırakıyoruz. Açılır listeyi incelemek için açtıysanız listeden yeniden userPrincipalName değerini seçtiğinizden emin olun. Tabloda bakicubuk.tech satırının Verified, USER PRINCIPAL NAME alanının userPrincipalName olduğunu kontrol ettikten sonra Next ile Domain and OU (Organizational Unit) filtering ekranına geçiyoruz.

Adım 9: Domain and OU Filtering (Domain ve OU Filtreleme)

Bu ekran, kurulumun belki de en önemli ekranı: burada çizdiğimiz sınır, buluta giden her şeyin sınırı oluyor. Ekranın üst kısmındaki Directory (Dizin) alanında, önceki adımda eklediğimiz bakicubuk.tech forest’ı seçili geliyor. Yanındaki Refresh Domains (Domain’leri yenile) butonu, sihirbaz açıkken forest’a yeni bir domain ya da OU (Organizational Unit) eklendiğinde ağacı yeniden okumak için kullanılıyor.

Ekran ilk açıldığında Sync all domains and OUs (Tüm domain ve OU (Organizational Unit)’ları senkronize et) seçeneği seçili ve ağaçtaki kök düğüm işaretli geliyor. Bu varsayılan, forest’taki tüm kullanıcı, grup ve kişi nesnelerinin Entra ID’ye gitmesi anlamına geliyor. Buna yerleşik Administrator hesabı, Users konteynerindeki hizmet hesapları, yönetici hesapları ve test ya da devre dışı hesaplar da dahil.

Sync selected domains and OUs (Seçili domain ve OU (Organizational Unit)’ları senkronize et) seçeneğini işaretliyoruz. Ağaç açılıyor ve domain’deki tüm OU ve konteynerler listeleniyor. Önce kök düğümün bakicubuk.tech işaretini kaldırıyoruz; bu işlem altındaki tüm OU (Organizational Unit) ve konteynerlerin işaretini de kaldırıyor. Ardından yalnızca LabUsers OU (Organizational Unit)’sunu işaretliyoruz. Kök düğümün onay kutusu artık dolu değil gri görünüyor; bu, altındaki OU (Organizational Unit)’ların yalnızca bir kısmının seçili olduğunu gösteriyor. Next ile devam ediyoruz.

Ağaçta gördüğümüz konteynerlerin hiçbirini kapsama almıyoruz. Builtin, Domain Controllers, ForeignSecurityPrincipals, LostAndFound, Managed Service Accounts, Program Data ve System, Active Directory’nin kendi işleyişi için kullandığı konteynerler; buradaki nesnelerin bulutta bir karşılığı olmamalı. Users konteyneri ise yerleşik Administrator, Guest ve krbtgt hesaplarını, Domain Admins ve Enterprise Admins gibi yetkili grupları ve Entra Connect’in oluşturduğu MSOL_ hesabını barındırıyor. Bu nesnelerin Entra ID’ye senkronize edilmesi hem gereksiz hem de on-premises yönetici hesaplarının bulutta da bir saldırı yüzeyi oluşturması anlamına geliyor.

Kök düğümün işaretini kaldırıp tek tek OU (Organizational Unit) seçmenin bir faydası daha var: kök düğüm işaretliyken ileride oluşturulan her yeni OU (Organizational Unit) otomatik olarak senkronizasyon kapsamına giriyor. Yalnızca seçili OU (Organizational Unit)’larla çalışmak, yeni oluşturulan OU (Organizational Unit)’ların bilinçli bir kararla kapsama alınmasını sağlıyor.

Adım 10: Uniquely Identifying Your Users (Kullanıcılarınızı Benzersiz Tanımlama)

Bu ekranda iki ayrı soruya cevap veriyoruz. Üst bölüm, aynı kişinin on-premises tarafta birden fazla hesapla temsil edilip edilmediğini; alt bölüm ise on-premises bir kullanıcının Entra ID’deki karşılığıyla hangi öznitelik üzerinden ömür boyu eşleştirileceğini belirliyor. İki bölümde de kurulumdan sonra geri dönmesi zor kararlar veriliyor, bu yüzden seçenekleri tek tek ele alalım.

On-premises Dizinlerde Kullanıcıların Tanımlanması

Select how users should be identified in your on-premises directories (Kullanıcıların on-premises dizinlerinizde nasıl tanımlanacağını seçin) bölümünde iki ana seçenek var.

• Users are represented only once across all directories (Kullanıcılar tüm dizinlerde yalnızca bir kez temsil edilir): Her kişinin tüm forest’lar genelinde tek bir kullanıcı hesabı olduğu anlamına geliyor. Tek forest’lı ortamların neredeyse tamamı ve kullanıcıların forest’lar arasında tekrarlanmadığı çok forest’lı ortamlar için doğru seçenek bu. Entra Connect her on-premises kullanıcı için Entra ID’de ayrı bir kullanıcı oluşturuyor.
• User identities exist across multiple directories. Match using (Kullanıcı kimlikleri birden fazla dizinde bulunuyor, eşleştirme yöntemi): Aynı kişinin birden fazla forest’ta hesabı bulunduğu ortamlar için. Örneğin bir şirket birleşmesinde çalışanın hem eski hem yeni forest’ta hesabı varsa ya da Exchange ayrı bir kaynak forest’ta tutuluyorsa, Entra Connect bu hesapları seçilen öznitelik üzerinden tek bir Entra ID kullanıcısında birleştiriyor.

Bu seçenek işaretlendiğinde dört eşleştirme yöntemi etkin hale geliyor:

Tek forest’lı bir ortamda alt seçeneklerden birini seçmenin hiçbir faydası yok; tersine, yanlış yapılandırılmış bir eşleştirme farklı kişilerin hesaplarını tek bir Entra ID kullanıcısında birleştirebiliyor. Bu seçenekler ekranda gri görünüyor ve yalnızca üstteki ikinci seçenek işaretlendiğinde etkinleşiyor.

Entra ID’de Kullanıcıların Tanımlanması: Source Anchor

Select how users should be identified with Microsoft Entra ID (Kullanıcıların Microsoft Entra ID’de nasıl tanımlanacağını seçin) bölümü source anchor (kaynak bağlantı noktası) seçimini yapıyor. Source anchor, on-premises bir nesneyi Entra ID’deki karşılığına ömür boyu bağlayan öznitelik. Entra ID tarafında bu değer kullanıcının ImmutableId özniteliğinde tutuluyor ve adından da anlaşılacağı gibi nesne oluşturulduktan sonra değiştirilmemesi gerekiyor. Bir kullanıcının adı, UPN’i, e-posta adresi ya da OU (Organizational Unit)’su değişse bile source anchor aynı kaldığı sürece Entra Connect bu kullanıcının buluttaki karşılığını bulabiliyor.

• Let Azure manage the source anchor (Kaynak bağlantı noktasını Azure yönetsin): Entra Connect, source anchor olarak mS-DS-ConsistencyGuid özniteliğini kullanıyor. Bir kullanıcı ilk kez senkronize edildiğinde bu öznitelik boşsa, Entra Connect nesnenin objectGUID değerini mS-DS-ConsistencyGuid özniteliğine yazıyor ve bundan sonra oradan okuyor. Ekranın altındaki bilgi kutusunda belirtilen “Azure will write back unique source anchors to your on-premises directory if mS-DS-ConsistencyGuid is currently unused by your organization” (mS-DS-ConsistencyGuid kuruluşunuzda kullanılmıyorsa Azure benzersiz source anchor değerlerini on-premises dizininize geri yazar) ifadesi tam olarak bu davranışı anlatıyor. Microsoft’un önerdiği seçenek bu.
• Choose a specific attribute (Belirli bir öznitelik seçin): Source anchor olarak kurumun seçtiği bir özniteliğin kullanılmasını sağlıyor. Bu öznitelik her kullanıcıda dolu, benzersiz ve kullanıcının ömrü boyunca değişmeyen bir değer taşımalı. E-posta adresi ya da UPN gibi zamanla değişebilen değerler bu nedenle source anchor olarak kesinlikle kullanılmamalı. Bu seçenek genellikle kurumun daha önce farklı bir source anchor ile senkronizasyon yaptığı ve aynı değeri korumak zorunda olduğu ya da kimlik yönetim sisteminden gelen benzersiz bir kimlik numarasını kullanmak istediği durumlar için var.

Neden objectGUID yerine mS-DS-ConsistencyGuid? Eski Azure AD Connect sürümlerinin varsayılanı olan objectGUID salt okunur bir öznitelik ve Active Directory her yeni nesne için rastgele bir değer atıyor. Bir kullanıcıyı başka bir forest’a taşıdığımızda ya da silip yeniden oluşturduğumuzda objectGUID değişiyor ve Entra Connect bu kullanıcıyı buluttaki karşılığıyla eşleştiremiyor; sonuçta yeni ve boş bir bulut hesabı oluşuyor, kullanıcı posta kutusuna ve OneDrive verisine erişimini kaybediyor. mS-DS-ConsistencyGuid ise yazılabilir bir öznitelik olduğu için forest geçişlerinde değeri eski hesaptan yeni hesaba kopyalanabiliyor ve kullanıcının bulut kimliği korunuyor.

Özniteliğin kurulumdan sonra doldurulduğunu W25DC üzerinde kontrol edebiliyoruz. İlk senkronizasyonun ardından LabUsers OU (Organizational Unit)’sundaki kullanıcıların mS-DS-ConsistencyGuid değerinin objectGUID ile aynı olması gerekiyor:

Get-ADUser -SearchBase "OU=LabUsers,DC=bakicubuk,DC=tech" -Filter * -Properties mS-DS-ConsistencyGuid |
  Select-Object SamAccountName, ObjectGUID, @{n='ConsistencyGuid';e={if ($_.'mS-DS-ConsistencyGuid') {[guid]$_.'mS-DS-ConsistencyGuid'}}}

Lab’ımız tek forest’lı olduğu ve her kullanıcı yalnızca bir kez temsil edildiği için üst bölümde Users are represented only once across all directories, alt bölümde Let Azure manage the source anchor seçeneğini işaretliyor ve Next ile devam ediyoruz. Her iki seçenek de sihirbazın varsayılan değerleri olduğu için ekranda herhangi bir değişiklik yapmamız gerekmiyor.

Adım 11: Filter Users and Devices (Kullanıcıları ve Cihazları Filtrele)

Bu ekranda OU (Organizational Unit) filtrelemesine ek olarak grup tabanlı filtreleme yapabiliyoruz. Ekranın üst kısmındaki açıklama bu özelliğin amacını açıkça belirtiyor: For a pilot deployment (Pilot dağıtım için). İki seçenek var:

• Synchronize all users and devices (Tüm kullanıcıları ve cihazları senkronize et): Varsayılan seçenek. Grup filtresi uygulanmıyor ve önceki ekranda seçtiğimiz OU (Organizational Unit)’ların içindeki tüm kullanıcı, grup, kişi ve cihaz nesneleri senkronize ediliyor. Yani buradaki “tümü”, forest’ın tamamı değil, OU (Organizational Unit) filtrelemesiyle çizdiğimiz kapsamın tamamı anlamına geliyor.
• Synchronize selected (Seçileni senkronize et): Yalnızca belirli bir grubun doğrudan üyeleri senkronize ediliyor. Bu seçenek işaretlendiğinde FOREST sütununda bakicubuk.tech, GROUP alanında ise grup adı ya da distinguished name girilecek bir kutu etkinleşiyor; Resolve (Çözümle) butonu girilen grubun Active Directory’de bulunduğunu doğruluyor. Ekranda da belirtildiği gibi iç içe gruplar (nested groups) desteklenmiyor ve yok sayılıyor: gruba üye olarak eklenen başka bir grubun kullanıcıları senkronize edilmiyor. Ayrıca bir kullanıcı gruptan çıkarıldığında kapsam dışında kaldığı için Entra ID’den siliniyor. Bu nedenlerle Microsoft bu yöntemi yalnızca pilot çalışmalar için öneriyor ve üretim ortamında desteklemiyor.

Pilot bir geçişte, Örneğin tüm kullanıcıları senkronize etmeden önce BT ekibinden birkaç kişiyle deneme yapmak için bu seçenek kullanışlı. Pilot tamamlandığında sihirbaz yeniden çalıştırılıp Synchronize all users and devices seçeneğine geçilmesi gerekiyor.

OU (Organizational Unit) filtrelemesiyle kapsamı zaten net şekilde çizdiğimiz için bu ekranda herhangi bir değişiklik yapmıyor, varsayılan Synchronize all users and devices seçeneğiyle Next diyerek devam ediyoruz.

Adım 12: Optional Features (İsteğe Bağlı Özellikler)

Bu ekranda senkronizasyona eklenebilecek ek özellikler listeleniyor. Ekrana ilk baktığımızda bazı kutuların gri ve tıklanamaz olduğunu görüyoruz; bu bir hata değil, her birinin ortamımızla ilgili bir nedeni var.

• Password hash synchronization kutusu işaretli ve gri geliyor. User sign-in ekranında oturum açma yöntemi olarak Password Hash Synchronization’ı seçtiğimiz için sihirbaz bu özelliği zorunlu olarak açıyor ve burada kapatılmasına izin vermiyor.
• Exchange hybrid deployment ve Exchange Mail Public Folders kutuları gri. Bu iki özellik yalnızca Active Directory şeması Exchange Server özniteliklerini içeriyorsa, yani forest’ta daha önce Exchange kurulmuş ya da şema Exchange için genişletilmişse etkinleşiyor. Lab forest’ımızda Exchange olmadığı için sihirbaz bu seçenekleri sunmuyor.
• Device writeback kutusu da gri. Bu özellik ilk kurulum sırasında değil, kurulum tamamlandıktan sonra sihirbazın Configure device options (Cihaz seçeneklerini yapılandır) görevi üzerinden ve forest’ın hazırlanmasıyla birlikte etkinleştirilebiliyor.
• Group writeback satırının yanında bilgi simgesi yerine sarı bir uyarı simgesi bulunuyor. Simgenin üzerine gelindiğinde özellikle ilgili güncel kısıtlamalar gösteriliyor; Microsoft, bulut gruplarının on-premises AD’ye yazılması senaryosunda yeni kurulumlar için Microsoft Entra Cloud Sync’in grup sağlama (group provisioning to AD) özelliğini öneriyor.

Serinin kapsamında yalnızca Password hash synchronization açık kalıyor. Kullanıcılarınızın Self-Service Password Reset (SSPR) ile bulut üzerinden parola sıfırlamasını istiyorsanız Password writeback özelliğini de açabilirsiniz; bu durumda MSOL_ hesabına kullanıcı nesneleri üzerinde parola sıfırlama izinleri de verilir ve bu değişiklik için Enterprise Admin bilgileri yeniden istenmez, çünkü hesap aynı sihirbaz akışında oluşturuluyor. Bu ekrandaki özelliklerin tamamı kurulumdan sonra sihirbaz yeniden çalıştırılarak açılıp kapatılabiliyor.

Hiçbir kutuya dokunmadan Next ile devam ediyoruz.

Adım 13: Single Sign-on (Çoklu Oturum Açma)

User sign-in ekranında Enable single sign-on kutusunu işaretlediğimiz için sihirbaz Configure adımından hemen önce bu ekranı gösteriyor. Ekranın üstündeki açıklama, on-premises forest’ı Seamless SSO için yapılandırmak üzere bir domain yöneticisi hesabı istendiğini belirtiyor. Forest listesinde bakicubuk.tech satırının yanında kırmızı bir çarpı işareti görüyoruz; bu, forest için henüz kimlik bilgisi girilmediğini gösteriyor ve kimlik bilgileri doğrulanana kadar Next butonu pasif kalıyor. Enter credentials (Kimlik bilgilerini gir) butonuna tıklıyoruz.

Açılan Windows Security penceresinde Forest Credentials (Orman kimlik bilgileri) isteniyor. User name alanına bakicubuk\administrator biçiminde domain yöneticisi hesabını, Password alanına parolasını giriyoruz. Pencerenin alt kısmındaki Domain: bakicubuk satırı, girdiğimiz NetBIOS adının doğru domain’e çözümlendiğini gösteriyor. OK ile onaylıyoruz.

Sihirbaz kimlik bilgilerini domain controller’a karşı doğruladığında bakicubuk.tech satırındaki kırmızı çarpı yeşil onay işaretine dönüşüyor ve Next butonu etkin hale geliyor.

Next ile Ready to configure ekranına geçiyoruz.

Bu ekranda girdiğimiz bilgiler henüz hiçbir değişiklik yapmıyor, yalnızca doğrulanıyor. Asıl işlem Configure adımında gerçekleşiyor: sihirbaz bu bilgilerle Computers konteynerinde AZUREADSSOACC adında bir bilgisayar hesabı oluşturuyor, Entra ID oturum açma sürecinde kullanılacak Kerberos SPN’lerini (HTTP/autologon.microsoftazuread-sso.com>) bu hesaba tanımlıyor ve hesabın Kerberos şifre çözme anahtarını güvenli şekilde Entra ID ile paylaşıyor. Bilgiler yalnızca bu işlem için kullanılıyor ve saklanmıyor.

Adım 14: Ready to Configure (Yapılandırmaya Hazır)

Sihirbazın son ekranı, önceki adımlarda verdiğimiz kararların bir özeti. Once you click Install, we will do the following (Install’a tıkladığınızda şunları yapacağız) başlığı altında sihirbazın yapacağı işlemler listeleniyor. Install‘a basmadan önce bu listeyi dikkatle okumak, yanlış bir seçimi geri dönüp düzeltmek için son fırsat.

Listede Entra ID bağlayıcısının hala AAD Connector olarak adlandırıldığını görüyoruz. Ürün adı değişse de bağlayıcının iç adı eski Azure AD adlandırmasını koruyor; Synchronization Service Manager ve PowerShell çıktılarında da bu adla karşılaşacağız.

Export Deletion Threshold, tek bir senkronizasyon döngüsünde 500’den fazla nesnenin silinmesi gerektiğinde dışa aktarımı durdurarak yanlışlıkla yapılan toplu silmelere karşı bir emniyet kemeri görevi görüyor. Örneğin senkronize edilen bir OU yanlışlıkla filtreden çıkarılırsa, bu ayar tüm kullanıcıların Entra ID’den silinmesini engelliyor. Eşik aşıldığında senkronizasyon hata veriyor ve yöneticinin silmenin kasıtlı olup olmadığını kontrol etmesi gerekiyor. Mevcut değeri kurulumdan sonra Get-ADSyncExportDeletionThreshold komutuyla görebiliyoruz.

Listenin altında iki seçenek var:

• Start the synchronization process when configuration completes (Yapılandırma tamamlandığında senkronizasyonu başlat): İşaretli olduğunda kurulum biter bitmez ilk tam senkronizasyon (initial sync) başlıyor ve zamanlayıcı 30 dakikalık döngüyle çalışmaya başlıyor. İşaretsiz bırakılırsa zamanlayıcı devre dışı kalıyor ve senkronizasyonun elle başlatılması gerekiyor. Bu seçenek, kurulumdan sonra senkronizasyon kurallarında ek özelleştirme yapılacaksa işe yarıyor. Lab’ımızda işaretli bırakıyoruz.
• Enable staging mode (Hazırlama modunu etkinleştir): Sunucunun Active Directory ve Entra ID’den veri okuyup senkronizasyon motorunda işlemesini, ancak hiçbir tarafa değişiklik yazmamasını sağlıyor. Password Hash Synchronization ve password writeback da bu modda devre dışı kalıyor. Staging mode, yüksek erişilebilirlik için yedek bir Entra Connect sunucusu tutmak, mevcut sunucudan yeni bir sunucuya geçmek (swing migration) ya da yapılandırma değişikliklerini canlıya almadan önce sonuçlarını görmek için kullanılıyor. Tek sunuculu lab’ımızda işaretlemiyoruz.

Install ile yapılandırmayı başlatıyoruz. Bu aşamada sihirbaz, yeni kurulumlarda varsayılan olan application-based authentication yapılandırmasını da tamamlıyor: Entra ID’de sunucuya özel bir uygulama kaydı oluşturuluyor, sertifika üretilip TPM içinde saklanıyor ve Entra bağlayıcısı bu uygulama kimliğiyle kimlik doğruluyor. Yapılandırma, ortamın büyüklüğüne bağlı olarak birkaç dakika sürüyor.

Adım 15: Configuration Complete (Yapılandırma Tamamlandı)

Yapılandırma birkaç dakika içinde tamamlanıyor ve sihirbaz Microsoft Entra Connect Sync configuration succeeded. The synchronization process has been initiated. (Microsoft Entra Connect Sync yapılandırması başarılı oldu, senkronizasyon süreci başlatıldı) mesajını gösteriyor. Ready to configure ekranında Start the synchronization process kutusunu işaretli bıraktığımız için ilk tam senkronizasyon arka planda başlamış durumda.

Ekranda üç bilgilendirme kutusu var:

• Yeşil kutu, sonraki adımlar: Yapılandırmanın tamamlandığını ve artık Azure ya da Office 365 portalında on-premises kullanıcıların oluşturulduğunu doğrulayabileceğimizi, ardından bir test oturumu açmamızı öneriyor. Bu doğrulamaları bir sonraki adımda yapacağız.
• Mavi kutu, source anchor: Microsoft Entra ID’nin source anchor olarak mS-DS-ConsistencyGuid özniteliğini kullanacak şekilde yapılandırıldığını teyit ediyor. Uniquely identifying your users adımında Let Azure manage the source anchor seçeneğini seçmemizin sonucu bu.
• Mavi kutu, Seamless SSO: Kullanıcılara tek oturum açma deneyimi sunmak için Seamless SSO’nun grup ilkesiyle yapılandırılması gerektiğini hatırlatıyor. Sihirbaz AZUREADSSOACC hesabını oluşturup Entra ID tarafını hazırladı, ancak istemci bilgisayarların Kerberos biletini Entra ID’ye gönderebilmesi için gereken tarayıcı bölge ayarını grup ilkesiyle dağıtmamız gerekiyor. Bu adımı Bölüm 4’te ele alacağız.

Ekranda Active Directory Recycle Bin ile ilgili bir uyarı görünmüyor, çünkü Bölüm 1’de Recycle Bin’in etkin olduğunu kontrol etmiştik. Recycle Bin kapalı bir ortamda bu ekranda etkinleştirilmesini öneren sarı bir uyarı kutusu da yer alıyor. Exit ile sihirbazı kapatıyoruz.

Adım 16: Kurulumu Doğrulama

Sihirbazı Exit ile kapattıktan sonra kurulumu birkaç açıdan doğruluyoruz. Önce W25ENTRA üzerinde yönetici PowerShell’de senkronizasyon zamanlayıcısının durumuna bakıyoruz:

Get-ADSyncScheduler | Select-Object SyncCycleEnabled, AllowedSyncCycleInterval, NextSyncCycleStartTimeInUTC, StagingModeEnabled

Çıktıda dört değeri kontrol ediyoruz. SyncCycleEnabled değerinin True olması, zamanlayıcının çalıştığını; AllowedSyncCycleInterval değerinin 00:30:00 olması, senkronizasyonun varsayılan olarak 30 dakikada bir tekrarlandığını gösteriyor. NextSyncCycleStartTimeInUTC bir sonraki döngünün zamanını UTC olarak veriyor; Türkiye saatine çevirmek için 3 saat eklemek gerekiyor. StagingModeEnabled değerinin False olması ise sunucunun Entra ID’ye aktif olarak yazdığını, yani staging mode’da olmadığını doğruluyor.

Active Directory’de yaptığımız bir değişikliğin Entra ID’ye yansıması için 30 dakika beklemek istemiyorsak senkronizasyonu elle başlatabiliyoruz. -PolicyType Delta parametresi yalnızca son senkronizasyondan bu yana değişen nesneleri işliyor ve birkaç saniye içinde tamamlanıyor. -PolicyType Initial ise tüm nesneleri baştan okuyan tam senkronizasyonu başlatıyor; bu yalnızca OU (Organizational Unit) filtrelemesi ya da senkronizasyon kuralları değiştirildiğinde gerekiyor.

Start-ADSyncSyncCycle -PolicyType Delta

Komutun Success döndürmesi, senkronizasyon döngüsünün başarıyla kuyruğa alındığını gösteriyor. Döngü zaten çalışıyorsa komut Busy durumuyla dönüyor; bu durumda birkaç dakika bekleyip tekrar denemek yeterli.

Aynı bilgiyi Entra admin center’da da görebiliriz: Entra ID > App registrations > All applications altında ConnectSyncProvisioning_W25ENTRA_... adıyla sunucumuza özel bir uygulama kaydı oluşmuş olmalı.

Senkronizasyonu Elle Tetikleme Seçenekleri

Günlük operasyonda en sık karşılaşılan ihtiyaç, Active Directory’de yeni açılan bir kullanıcının ya da yapılan bir değişikliğin 30 dakikalık döngüyü beklemeden Entra ID’ye yansıması. Start-ADSyncSyncCycle -PolicyType Delta dışında bu iş için kullanabileceğimiz başka yöntemler de var.

Tek bir nesneyi senkronize etmek: Entra Connect 2.0.89.0 ve sonraki sürümlerde gelen

Invoke-ADSyncSingleObjectSync

komutu, yalnızca belirttiğimiz nesneyi Active Directory’den okuyup Entra ID’ye gönderiyor. Komut ayrıca nesnenin hangi senkronizasyon kurallarından geçtiğini ve Entra ID’ye hangi özniteliklerin yazıldığını JSON biçiminde raporladığı için, bir kullanıcının neden senkronize olmadığını anlamak için de kullanışlı:

Invoke-ADSyncSingleObjectSync -DistinguishedName "CN=Nihat Cubuk,OU=LabUsers,DC=bakicubuk,DC=tech" |
  Out-File "$env:TEMP\SingleObjectSync.json"

Komuta -StagingMode parametresi eklendiğinde Entra ID’ye hiçbir değişiklik yazılmıyor, yalnızca senkronizasyon sonucunun ne olacağı raporlanıyor. Bu da bir değişikliği canlıya göndermeden önce etkisini görmek için güvenli bir yöntem.

Uzaktan tetiklemek: Kullanıcılar genellikle domain controller ya da bir yönetim sunucusundan açıldığı için, W25ENTRA‘ya oturum açmadan delta döngüsünü uzaktan başlatabiliyoruz. Komutu çalıştıran hesabın W25ENTRA üzerinde ADSyncOperators ya da ADSyncAdmins grubunda olması gerekiyor:

Invoke-Command -ComputerName W25ENTRA -ScriptBlock { Start-ADSyncSyncCycle -PolicyType Delta }

Kullanıcı açıp hemen senkronize etmek: Aşağıdaki örnek, yeni bir kullanıcıyı LabUsers OU (Organizational Unit)’sunda oluşturuyor, Active Directory replikasyonunun tamamlanması için kısa bir süre bekliyor, delta döngüsünü uzaktan başlatıyor ve döngü bitene kadar bekliyor:

New-ADUser -Name "Mustafa Kemal Atatürk" -GivenName "Mustafa Kemal" -Surname "Atatürk" `
  -SamAccountName "mustafakemal.ataturk" -UserPrincipalName "[email protected]" `
  -Path "OU=LabUsers,DC=bakicubuk,DC=tech" `
  -AccountPassword (Read-Host -AsSecureString "Parola") -Enabled $true

Start-Sleep -Seconds 30

Invoke-Command -ComputerName W25ENTRA -ScriptBlock {
  Start-ADSyncSyncCycle -PolicyType Delta
  do { Start-Sleep -Seconds 10 } while ((Get-ADSyncScheduler).SyncCycleInProgress)
  "Senkronizasyon tamamlandı"
}

Birkaç noktaya dikkat etmek gerekiyor. Birden fazla domain controller bulunan ortamlarda kullanıcı bir DC’de açılıp Entra Connect başka bir DC’den okuyorsa, senkronizasyonun kullanıcıyı görmesi için önce Active Directory replikasyonunun tamamlanması gerekiyor. Döngü zaten çalışıyorsa Start-ADSyncSyncCycle Busy sonucu döndürüyor; Get-ADSyncScheduler çıktısındaki SyncCycleInProgress değeri döngünün devam edip etmediğini gösteriyor. Döngü aralığı Set-ADSyncScheduler -CustomizedSyncCycleInterval ile uzatılabiliyor, ancak Microsoft’un izin verdiği en kısa aralık olan 30 dakikanın altına indirilemiyor.

Ardından Entra Connect’in Entra ID’ye hangi yöntemle kimlik doğruladığını kontrol ediyoruz. Eski sürümlerde bu bağlantı, Entra ID’de Sync_SUNUCUADI_... adıyla oluşturulan ve parolası sunucuda saklanan bir kullanıcı hesabıyla yapılıyordu. Güncel sürümde ise beklediğimiz değer Application:

Get-ADSyncEntraConnectorCredential

Çıktıda üç sütun görüyoruz. ConnectorIdentityType değerinin Application olması, Entra bağlayıcısının bir kullanıcı hesabı ve parola yerine uygulama kimliği ve sertifikayla kimlik doğruladığını kanıtlıyor. Username sütununda bir kullanıcı adı değil, süslü parantez içinde bir GUID ve tenant’ın onmicrosoft.com alan adı görünüyor; bu GUID, Entra ID’de oluşturulan uygulama kaydının Application (client) ID değeri. CertificateCredential sütunu ise kimlik doğrulamada kullanılan sertifika nesnesini gösteriyor.

Değer ServiceAccount görünüyorsa kurulum eski hesap tabanlı yönteme düşmüş demektir; bu durumda sihirbazı yeniden açıp Additional tasks altındaki Configure application-based authentication to Microsoft Entra ID görevini çalıştırmak gerekiyor.

Aynı bilgiyi Entra admin center‘da da görebiliyoruz. Entra ID > App registrations > All applications sekmesinde ConnectSyncProvisioning_W25ENTRA_ ile başlayan bir uygulama kaydı oluşmuş durumda. Kaydın adı üç parçadan oluşuyor: sabit ConnectSyncProvisioning öneki, Entra Connect sunucusunun adı ve sunucuya özgü bir tanımlayıcı. Bu adlandırma sayesinde birden fazla Entra Connect sunucusu bulunan ortamlarda (örneğin aktif ve staging sunucu) her sunucunun kendi uygulama kaydı ve sertifikası oluyor ve hangi kaydın hangi sunucuya ait olduğu adından anlaşılıyor.

Listede üç sütunu kontrol ediyoruz. Application (client) ID değeri, Get-ADSyncEntraConnectorCredential çıktısındaki Username alanında gördüğümüz GUID ile birebir aynı; bu, Entra Connect’in gerçekten bu uygulama kaydıyla kimlik doğruladığını kanıtlıyor. Created on sütunu kaydın kurulum günü oluşturulduğunu, Certificates & secrets sütunundaki Current (Güncel) durumu da kayda bağlı sertifikanın geçerli olduğunu gösteriyor. Sertifikanın süresi dolmaya yaklaştığında Entra Connect onu otomatik olarak yeniliyor; bu sütun ileride sertifika sorunlarını hızlıca fark etmek için de kullanışlı.

Son olarak kullanıcıların Entra ID’ye doğru şekilde geldiğini kontrol ediyoruz. Entra ID > Users > All users sayfasında Add filter (Filtre ekle) ile On-premises sync enabled (On-premises eşitleme etkin) filtresini ekleyip değerini Yes olarak seçiyoruz. Böylece listede yalnızca on-premises Active Directory’den senkronize edilen kullanıcılar görünüyor; cloud-only yönetici ve break-glass hesapları filtre dışında kalıyor.

Listede yalnızca LabUsers OU (Organizational Unit)’sundaki kullanıcıların bulunması, OU (Organizational Unit) filtrelemesinin beklendiği gibi çalıştığını gösteriyor: Administrator gibi yerleşik hesaplar ve Users konteynerindeki hesaplar Entra ID’ye gelmemiş. User principal name sütununda kullanıcıların @bakicubuk.tech uzantısıyla, yani on-premises UPN’leriyle oluşturulduğunu görüyoruz; onmicrosoft.com uzantısıyla gelen bir kullanıcı olsaydı bu, UPN uzantısının doğrulanmamış olduğuna işaret ederdi. On-premises sync enabled sütunundaki Yes değeri de bu kullanıcıların kaynağının Active Directory olduğunu ve öznitelik değişikliklerinin artık bulutta değil on-premises tarafta yapılması gerektiğini gösteriyor.

Seamless SSO hesabının oluştuğunu da W25DC üzerinden doğrulayabiliriz:

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

Bu hesabın şifreleme türlerini ve anahtar yenileme sürecini Bölüm 4’te ayrıntılı olarak ele alacağız.

Özet ve Sonraki Bölüm

Bu bölümde Microsoft Entra Connect Sync’i Windows Server 2025 üzerinde kurduk. Express yerine Customize ile ilerleyerek senkronizasyon kapsamını tek bir OU ile sınırladık, Password Hash Synchronization ve Seamless SSO’yu etkinleştirdik, source anchor olarak mS-DS-ConsistencyGuid kullandık ve Entra Connect’in Entra ID’ye parolalı bir hesap yerine sertifikalı bir uygulama kimliğiyle bağlandığını doğruladık.

Bölüm 3’te tenant’ımızın güvenlik tarafına geçiyoruz: Security Defaults’u kapatıp yerine break-glass hesapları ve Conditional Access politikalarıyla daha esnek ve denetlenebilir bir yapı kuracağız.

burada

burada

burada

burada

burada

burada

burada

burada

burada

burada

burada

burada