Microsoft Entra ID Connect Kurulumu – Bölüm 2: Gelişmiş Yapılandırma Adımları

On-Premises Active Directory'deki kullanıcıların, grupların ve parolaların Microsoft Entra ID ile senkronize edilmesi, Microsoft Entra Connect Sync kurulumunda Wizard'ın her ekranında yapılan seçimlere bağlıdır. Oturum açma yöntemi, Connector Account, Source Anchor ve OU kapsamı gibi kararların bir kısmı kurulumdan sonra değiştirilemediği için bu seçimlerin ne anlama geldiğini bilerek ilerlemek gerekiyor. Aracın ne olduğunu, sistem gereksinimlerini, UPN Suffix hazırlığını ve kurulum öncesi kontrolleri Microsoft Entra Connect Kurulumu – Bölüm 1: Temel Yükleme ve Hazırlık başlıklı makalemde anlatmıştım. Şimdi kurulumun kendisine geçiyorum ve her ekranda hangi seçimin neyi değiştirdiğini adım adım gösteriyorum.

Makaleyi üç aşamada kurguladım. Önce sürüm bilgisi, kontrol listesi ve karar tablosuyla hazırlığı tamamlıyorum. Ardından Wizard'ı ekran ekran geçiyorum. Son bölümde ise kurulum bittikten sonra yapılması gereken işleri tek bir listede topluyorum.

HAZIRLIK                      KURULUM                        KURULUM SONRASI
---------------------------   ----------------------------   ------------------------------
Sürüm ve tarihler             Wizard ekranları (1-17)        İlk senkronizasyon ve doğrulama
Kurulum öncesi kontrol        Her ekranda bir karar          Seamless SSO GPO ve Key Rollover
Karar tablosu                 Görsel ve kısa uyarı           Ek Agent'lar ve lisans kontrolleri

Ürünün resmi adı Microsoft Entra Connect Sync'tir, eski adı Azure AD Connect'tir. Kurulum dizinlerinde ve bazı Wizard ekranlarında eski adlar hala görünüyor; makalede bu adlarla karşılaştığım yerlerde ayrıca belirtiyorum.

Hangi Sürümle Kurulum Yapılmalı?

Makaleyi Ekim 2026 itibarıyla güncelledim. Bu tarihte Microsoft Entra admin center üzerinden indirilen en yeni sürüm, 23 Eylül 2026'da yayımlanan 2.6.92.0. Yeni kurulumda her zaman en güncel sürümün kullanılması gerekiyor. Sürümle ilgili bilinmesi gereken tarihleri aşağıdaki tabloda topladım.

Bu makaledeki ekran görüntülerinin bir kısmı, Tenant'ta Sync_ ile başlayan senkronizasyon hesabının oluşturulduğu daha eski bir Build'e ait. O Build ile bugün indirilen sürüm arasında davranış farkları olduğu için, değişen her noktada önce eski davranışı, ardından güncel davranışı yazdım.

Güncel Sürümde Neler Değişti?

Aşağıdaki tablo, bu makalede geçen konularda Microsoft'un sonradan değiştirdiği davranışları bir arada gösteriyor. Son sütun, her değişikliğin kurulumun hangi adımında karşıma çıktığını gösteriyor.

Kurulum Öncesi Kontrol Listesi

Wizard'ı başlatmadan önce aşağıdaki tabloyu baştan sona geçiyorum. Tablodaki her satır, kurulumun bir adımında ihtiyaç duyulan bir gereksinimi gösteriyor; eksik bir satır Wizard'ın ortasında durmama neden olur. Satırlar, gereksinimin ilk karşıma çıktığı adıma göre sıralı.

Kurulum Boyunca Vereceğim Kararlar

Wizard'daki ekranların bir kısmı yalnızca bilgi ister, bir kısmı ise kalıcı karar ister. Aşağıdaki tablo bu kararları, Microsoft'un önerisini, benim bu kurulumdaki seçimimi ve seçimin kurulumdan sonra değiştirilip değiştirilemeyeceğini bir arada gösteriyor. Her satırın ayrıntısı ilgili adımda yer alıyor.

1- Microsoft Entra Connect Sync Kurulum Dosyasını İndirme

Kurulum dosyasını indirmek için entra.microsoft.com adresinde oturum açıyorum. Ekran görüntüsünü aldığım tarihte menü yolu Hybrid management altındaki Microsoft Entra Connect ve onun içindeki Connect Sync sekmesiydi. Microsoft'un güncel dokümanında aynı sayfaya Entra ID altındaki Entra Connect üzerinden ulaşılıyor, indirme bağlantısı da Get started sayfasının Manage sekmesinde bulunuyor.



Açılan sayfada Download butonuna tıklayarak kurulum dosyasını indiriyorum.

2- Kurulumun Başlatılması

İndirdiğim kurulum dosyasını çalıştırıyorum. Kurulum, sunucuda .NET Framework 4.7.2 ve TLS 1.2 gereksinimlerinin karşılanmasını bekliyor; bu ikisi eksikse Wizard ilk ekranlarda uyarı verir. Lisans sözleşmesini kabul edip Continue butonuna tıklayarak devam ediyorum.

3- Express Settings

Express Settings ekranında iki yol var: Use express settings ve Customize. İlki kurulumu varsayılan ayarlarla tamamlar, ikincisi her adımı ayrı ayrı yapılandırmama izin verir.

Use Express Settings

Microsoft bu seçeneği, tek Forest'lı bir topolojide kimlik doğrulama için Password Hash Synchronization kullanılacak ortamlar için öneriyor. Express kurulumda Wizard benden iki kimlik bilgisi istiyor: Microsoft Entra ID tarafı için Hybrid Identity Administrator hesabı ve On-Premises Active Directory tarafı için Enterprise Admins grubuna üye bir hesap. Wizard'ın bu iki hesapla arka planda yaptığı işler aşağıdaki tabloda yer alıyor.

Customize

Express kurulumun karşılamadığı her topoloji ve ihtiyaç için Customize seçeneği kullanılır. Bu yolda kendim belirleyebildiğim ayarlar ve her birinin makalede ele alındığı adım aşağıdaki tabloda yer alıyor.

Ben bu kurulumda PTA, Seamless SSO, Exchange Hybrid ve Password Writeback kullanacağım için Customize ile ilerliyorum.

4- Install required components

Install required components ekranındaki kutuların hiçbiri işaretlenmezse Wizard, her şeyi varsayılan ayarlarla kurar. Bu durumda sunucunun kendi üzerinde bir LocalDB veritabanı kurulur, senkronizasyon servisi için bir Virtual Service Account (VSA) oluşturulur ve sunucu üzerinde dört yerel grup açılır. Ekrandaki her seçenek bu varsayılanlardan birini değiştirir.

✅ Specify a custom installation location

Bu seçenek işaretlenmezse kurulum iki ayrı dizine yapılır. Sync Engine dosyaları %ProgramFiles%\Microsoft Azure AD Sync dizinine, Wizard ve ADSyncConfig modülü ise %ProgramFiles%\Microsoft Azure Active Directory Connect dizinine kurulur. Ürünün adı değişti, ancak klasör adları değişmedi. Sunucuda Entra adını taşıyan bir klasör aramayın, klasörler hala Azure AD adıyla duruyor.

Varsayılan kurulumda LocalDB veritabanı dosyaları Sync Engine dizininin altında tutulduğu için, kurulum yolu başka bir sürücüye alınırsa veritabanı da o sürücüde oluşur. Sistem sürücüsünde yer kısıtı olan veya uygulamaları ayrı sürücüye kurmayı standart edinmiş ortamlarda bu seçenek bu yüzden işaretlenir.

✅ Use an existing SQL Server

Bu seçenek işaretlenmezse Wizard, veritabanı olarak SQL Server Express LocalDB kurar ve Microsoft Entra Connect Sync kendi veritabanını aynı sunucuda tutar. SQL Server Express'in 10 GB boyut sınırı vardır ve bu sınır yaklaşık 100.000 nesnenin yönetilmesine yeter. Veritabanı seçimini ve bu sınırın ne zaman aşıldığını Microsoft Entra Connect Kurulumu - Bölüm 1 makalemde ayrıntılı olarak anlattım.

Nesne sayısı bu sınırı aşan ortamlarda bu seçenek işaretlenir ve mevcut bir SQL Server Instance'ı gösterilir. Wizard sunucu adını, Instance adını (Instance'ta Browsing kapalıysa Instance adı, virgül ve Port numarası biçiminde) ve veritabanı adını ister. Veritabanını Wizard'ın mı oluşturacağı, yoksa SQL yöneticisinin önceden mi hazırlaması gerektiği kurulumu yapan hesabın SQL yetkilerine bağlıdır: SA yetkisi varsa veritabanı kurulumda oluşturulur, yalnızca DBO yetkisi varsa veritabanının önceden hazırlanmış olması gerekir. Mevcut SQL Server kullanılacaksa dikkat ettiğim kısıtlar aşağıdaki tabloda yer alıyor.

✅ Use an existing service account

Senkronizasyon servisini (ADSync) çalıştıran hesap varsayılan olarak bir Virtual Service Account'tur. VSA'nın parolası yoktur, Windows tarafından yönetilir ve Sync Engine ile SQL Server'ın aynı sunucuda olduğu senaryolar için tasarlanmıştır. Uzak bir SQL Server kullanılacaksa Microsoft Group Managed Service Account (gMSA) önerir. Kimlik doğrulama isteyen bir Proxy varsa Domain'de parola korumalı bir servis hesabı da kullanılabilir.

✅ Specify custom sync groups

Varsayılan kurulumda sunucu üzerinde dört yerel grup oluşturulur. Wizard'da bu seçenek işaretlendiğinde her grup için bir kutu açılır. Kutuların karşılığı olan gruplar ve amaçları aşağıdaki tabloda yer alıyor.

Seçenek yalnızca, grupları kurulumdan önce kendim oluşturup kendi verdiğim adlarla kullanmak istediğimde gerekir. Bu durumda kutulara kendi gruplarımı yazarım; kurulum dört grubu oluşturmaz, benim gösterdiklerimi kullanır. Gösterdiğim gruplar sunucu üzerinde Local grup olmak zorundadır, Domain'deki gruplar kullanılamaz.

✅ Import synchronization settings

Bu seçenek, çalışan bir Microsoft Entra Connect Sync sunucusunun ayarlarını yeni kurulan sunucuya aktarır. Aynı yapılandırmaya sahip ikinci bir sunucu kurarken veya mevcut sunucuyu yenisiyle değiştirirken kullanılır. İçe aktarılan dosya, kaynak sunucunun kendiliğinden ürettiği bir JSON dosyasıdır. Wizard, yapılandırma her değiştiğinde ayarları %ProgramData%\AADConnect klasörüne Applied-SynchronizationPolicy-*.JSON adıyla yazar; dosya adının sonundaki kısım tarih ve saat bilgisidir.

Bu seçenek her durumda kullanılamaz ve her ayarı aktarmaz. Kısıtlar aşağıdaki tabloda yer alıyor.

Uzak SQL Server, özel servis hesabı veya içe aktarılacak bir yapılandırma yoksa hiçbir kutuyu işaretlemeden devam etmek yeterlidir. Ben de hiçbir seçeneği işaretlemeden Install butonuna basıyorum.

5- User sign-in

User sign-in ekranında kullanıcıların Microsoft Entra ID'de nasıl oturum açacağını seçiyorum. Seçim, parolanın nerede doğrulanacağını belirler: bulutta mı, On-Premises Active Directory'de mi, yoksa bir Federation servisinde mi. Burada her seçeneğin kurulum açısından ne anlama geldiğine odaklanıyorum.

✅ Password Hash Synchronization (PHS)

Password Hash Synchronization, kullanıcıların On-Premises parolalarıyla bulutta oturum açabilmesini sağlar. Microsoft Entra Connect Sync, Active Directory'deki parola Hash'lerini Domain Controller'dan okur, her Hash'i yeniden Hash'leyerek bir türevini üretir ve bu türevi şifreli bağlantı üzerinden Microsoft Entra ID'ye gönderir. Parolanın açık hali ve Active Directory'deki özgün Hash hiçbir aşamada Entra ID'ye gönderilmez.

Kullanıcı oturum açarken yazdığı parola Entra ID tarafında aynı işlemden geçirilir ve saklanan türevle karşılaştırılır. İkisi eşleşirse oturum açılır. Bu yüzden doğrulama için Active Directory'ye sorulmasına gerek kalmaz.

PHS, Wizard'da iki ayrı ekranda karşıma çıkar ve her birinde farklı bir rol üstlenir. User sign-in ekranında PHS'i seçersem birincil oturum açma yöntemi PHS olur. Bu ekranda PTA veya Federation seçersem birincil yöntem o olur; PHS'i yine de Optional features ekranında ek özellik olarak açabilirim. PTA'nın böyle bir ikinci kullanımı yoktur; yalnızca birincil yöntem olabilir. İki kullanımın farkı aşağıdaki tabloda yer alıyor.

İki özellik, PHS hangi ekrandan açılırsa açılsın geçerlidir.

Senkronizasyon sıklığı sabittir. Parola Hash'leri iki dakikada bir senkronize edilir ve bu sıklık değiştirilemez.

Sızdırılmış kimlik bilgileri raporu PHS ister. Microsoft Entra ID Protection'ın Users with leaked credentials raporu PHS'in etkin olmasını gerektirir. Microsoft bu nedenle PTA veya Federation kullanılsa bile PHS'in de etkinleştirilmesini önerir.

✅ Pass-through Authentication (PTA)

Pass-through Authentication, kullanıcıların On-Premises parolalarıyla bulutta oturum açabilmesini sağlar, ancak parolayı bulutta doğrulamaz. Kullanıcı parolasını Entra ID'nin oturum açma sayfasına yazar. Entra ID parolayı şifreler ve doğrulama isteğini, On-Premises ortamda çalışan Authentication Agent'a iletir.

Authentication Agent isteği kendi kurduğu giden bağlantı üzerinden alır, parolanın şifresini çözer ve Active Directory'ye doğrulatır. Domain Controller'ın verdiği yanıt aynı yoldan Entra ID'ye döner. Yanıt olumluysa oturum açılır. Bu yüzden parola Hash'inin bulutta saklanmasına gerek kalmaz. PTA seçildiğinde kurulum açısından ortaya çıkan sonuçlar şunlar.

On-Premises kuralları anında uygulanır. Hesap devre dışıysa, kilitliyse, parolanın süresi dolmuşsa veya kullanıcı izin verilen Logon Hours dışında oturum açmaya çalışıyorsa erişim reddedilir.

Doğrulama On-Premises ortama bağımlıdır. Her istek Active Directory'ye sorulduğu için, On-Premises ortam veya Authentication Agent'lar erişilemez olduğunda kullanıcılar oturum açamaz.

Gelen bağlantı gerekmez. Agent yalnızca giden yönde 443 ve 80 numaralı Port'ları kullanır.

Birden fazla Agent gerekir. İlk Authentication Agent, Microsoft Entra Connect Sync sunucusunun kendisine kurulur. Microsoft, Production ortamlarında en az üç Authentication Agent çalıştırılmasını önerir.

Parola Hash'i buluta gönderilmez. Bu yalnızca PTA tek başına kullanıldığında geçerlidir. Ben Optional features ekranında PHS'i de açacağım için benim kurulumumda Hash türevi Entra ID'ye senkronize edilecek.

✅ Federation with AD FS

Bu seçenekte kimlik doğrulama Microsoft Entra ID'de değil, On-Premises ortamdaki Active Directory Federation Services (AD FS) altyapısında yapılır. Kullanıcı oturum açmak istediğinde Entra ID onu AD FS'e yönlendirir. Doğrulama AD FS'te gerçekleşir ve AD FS bir Token üretir. Entra ID bu Token'a güvenerek oturumu açar. AD FS seçildiğinde kurulum açısından ortaya çıkan sonuçlar şunlar.

Ek sunucu ve sertifika gerekir. Wizard ile AD FS yapılandırmak için Federation ve Web Application Proxy sunucusunda Windows Server 2012 R2 veya üzeri bir işletim sistemi, ayrıca Federation servis adı için bir TLS/SSL sertifikası gerekir.

Doğrulama On-Premises ortama bağımlıdır. AD FS erişilemez olduğunda kullanıcılar oturum açamaz.

PHS yedek olarak açılabilir. PHS, Optional features ekranında ek özellik olarak ayrıca etkinleştirilebilir. Böylece Federation servisinde kesinti olduğunda devreye alınabilecek bir yedek hazır olur.

Microsoft'un önerisi PHS'tir. Microsoft, kullanıcıların Microsoft 365 ve Entra ID tabanlı kaynaklarda oturum açmasını isteyen çoğu kuruluş için varsayılan PHS seçeneğini önerir.

Geçiş kademeli denenebilir. Federation'dan bulut kimlik doğrulamasına geçiş, Staged Rollout özelliğiyle önce seçili kullanıcı gruplarında denenebilir.

✅ Federation with PingFederate

Bu seçeneğin mantığı AD FS ile aynıdır. Kimlik doğrulama yine Microsoft Entra ID'de değil, On-Premises ortamdaki bir Federation sunucusunda yapılır. Tek fark, Federation sunucusu olarak AD FS yerine PingFederate kullanılmasıdır. PingFederate seçildiğinde kurulum açısından ortaya çıkan sonuçlar şunlar.

Sürüm ve sertifika gerekir. Wizard ile yapılandırma için PingFederate 8.4 veya üzeri bir sürüm ve Federation servis adı için bir TLS/SSL sertifikası gerekir.

Ayarlar PingFederate yöneticisine iletilir. Wizard, Federation ayarlarını dışa aktarır. Bu ayarları PingFederate sunucusuna PingFederate yöneticisi uygular.

Wizard sunucuyu doğrular. Wizard, PingFederate sunucusunun Metadata'sını doğrular.

✅ Do not configure

Bu seçenekte Wizard hiçbir oturum açma yöntemi kurmaz ve yapılandırmaz. Yalnızca dizin senkronizasyonu yapılır, yani kullanıcılar ve gruplar Entra ID'ye aktarılır ama kullanıcıların nasıl oturum açacağına Wizard karışmaz. Ortamda oturum açmayı zaten üstlenen üçüncü taraf bir Federation sunucusu veya başka bir çözüm varsa tercih edilir. Daha sonra bir yöntem eklemek istenirse Wizard yeniden çalıştırılır ve Change user sign-in görevi kullanılır.

✅ Enable single sign-on

Bu kutu Seamless SSO özelliğini açar. Seamless SSO, kurumsal ağdaki Domain-Joined bir cihazda Windows oturumu açmış kullanıcının, Entra ID tabanlı servislere parolasını yeniden yazmadan girmesini sağlar. Bu seçenekle ilgili bilinmesi gerekenler şunlar.

PHS veya PTA ile birlikte çalışır. Tek başına bir oturum açma yöntemi değildir, birincil yöntemin yanında açılır. AD FS için geçerli değildir, çünkü AD FS aynı deneyimi zaten sunar.

Active Directory'de bir hesap oluşturur. Entra ID'ye senkronize edilen her AD Forest'ta AZUREADSSOACC adında bir Computer Account oluşturulur ve bu hesabın Kerberos Decryption Key bilgisi Entra ID ile paylaşılır. Birden fazla Forest varsa her hesabın kendi Key'i olur.

Entra Joined ve Hybrid Joined cihazlarda kullanılmaz. Seamless SSO cihazın Domain-Joined olmasını ister, ancak Microsoft Entra Joined ve Microsoft Entra Hybrid Joined cihazlarda SSO, Primary Refresh Token (PRT) üzerinden çalışır. Hybrid Join kaydının arka planda nasıl ilerlediğini Hybrid Join ve SCP kayıt süreci makalemde anlattım.

Önerilen yöntem işletim sistemine göre değişir. Microsoft, Windows 10, Windows Server 2016 ve sonrası için PRT tabanlı SSO'yu, Windows 7 ve Windows 8.1 için Seamless SSO'yu önerir. İkisi birlikte açıksa PRT tabanlı SSO önceliklidir.

İstemci tarafı ayrıca yapılandırılır. Wizard yalnızca sunucu tarafını kurar. Tarayıcıların Kerberos Ticket'ı Entra ID'ye göndermesi için Group Policy ile dağıtılan bir Intranet Zone ayarı gerekir. Bu işi 19 numaralı adımdaki kurulum sonrası listesinde anlatıyorum.

Ben bu kurulumda kimlik doğrulamanın Active Directory'de yapılmasını istediğim için Pass-through Authentication ile Enable single sign-on seçeneklerini işaretliyorum. PHS'i 13 numaralı adımdaki Optional features ekranında ek özellik olarak açacağım; böylece yöntemi elle PHS'e çevirmem gerektiğinde Hash'ler bulutta hazır olur ve sızdırılmış kimlik bilgileri raporu çalışır.

6- Connect to Microsoft Entra ID

Connect to Microsoft Entra ID adımında Wizard, Tenant'a bağlanmak için yetkili bir hesapla oturum açmamı istiyor.

Hangi Hesap Kullanılmalı?

Hesabın Tenant'ta Global Administrator veya Hybrid Identity Administrator rolüne sahip olması gerekir. Hesabı seçerken dikkat ettiğim koşullar aşağıdaki tabloda yer alıyor. Bu koşullara uyan hesap olarak Tenant'ın onmicrosoft.com Domain'indeki Cloud-Only bir yönetici hesabıyla oturum açıyorum.

7- Connect your directories

Connect your directories adımında On-Premises dizini ekliyorum. Directory Type olarak Active Directory seçili, Forest alanında firatboyan.local yazıyor. Birden fazla Forest senkronize edilecekse her biri bu ekrandan ayrı ayrı eklenir. Add Directory butonuna basıyorum.



Bu adımda hata alınırsa önce Forest adının doğru çözümlendiğini ve sunucunun Domain Controller'lara Network üzerinden erişebildiğini kontrol etmek gerekir.

8- AD forest account

Add Directory sonrasında açılan AD forest account penceresinde, senkronizasyon sırasında Active Directory'ye bağlanacak hesabı belirliyorum. Microsoft bu hesaba AD DS Connector Account diyor. İki seçenek var: Create new AD account ve Use existing AD account.

1️⃣ Create new AD account

Bu seçenekte bir Enterprise Admin hesabının kullanıcı adını ve parolasını giriyorum; Wizard bu hesabı kullanarak Active Directory'de MSOL_ ile başlayan bir hesap oluşturur ve senkronizasyon için gereken izinleri bu hesaba kendisi atar. Enterprise Admin hesabı yalnızca hesabı oluşturmak için kullanılır, senkronizasyonu oluşturulan Connector Account yürütür. Bu seçenekte izinleri elle vermeye gerek kalmaz.

2️⃣ Use existing AD account

Bu seçenekte önceden hazırladığım bir hesabı gösteriyorum. Hesap normal bir kullanıcı hesabı olabilir, çünkü temel senkronizasyon için varsayılan okuma izinleri yeterlidir. Ancak açılacak her özellik ek izin ister ve bu seçenekte izinleri hazırlamak benim sorumluluğumdadır.

İki kısıt var. Birincisi yetki seviyesi: 1.4.18.0 sürümünden itibaren Wizard, Enterprise Admin veya Domain Admin hesabını Connector Account olarak reddediyor ve hesabı kendisinin oluşturmasını ya da doğru izinlere sahip bir senkronizasyon hesabı belirtilmesini istiyor. İkincisi hesap türü: Connector Account kurulumdan önce Active Directory'de normal bir User nesnesi olarak oluşturulmuş olmalıdır; VSA, MSA ve gMSA desteklenmez.

Ben bu seçenekle ilerliyorum. Hazırlık beş alt adımdan oluşuyor: hesabı oluşturmak, okuma ve PHS izinlerini vermek, yazma izinlerini vermek, izinleri doğrulamak ve hesabı Wizard'a girmek.

8.1- Connector Account'un Oluşturulması

Ortamımda hazır bir Connector Account olmadığı için Entra ID Sync Admin adında bir kullanıcı hesabı oluşturuyorum.

8.2- Okuma ve Password Hash Synchronization İzinleri

Domain seviyesindeki Properties penceresinin Security sekmesinde bu hesaba Read, Replicating Directory Changes ve Replicating Directory Changes All izinlerini veriyorum.

Aynı üç izin, GUI yerine 8.3 numaralı adımda tanıtacağım ADSyncConfig modülündeki iki komutla da verilebilir. Set-ADSyncBasicReadPermissions temel okuma için gereken Read ve Replicating Directory Changes izinlerini, Set-ADSyncPasswordHashSyncPermissions ise Replicating Directory Changes ve Replicating Directory Changes All izinlerini verir. Replicating Directory Changes izni iki komutta da ortaktır, çünkü her komut kendi özelliği için gereken izinlerin tamamını tek başına verecek şekilde tasarlanmıştır. GUI'den elle vermeyi tercih etmeyen, modülü yükledikten sonra aşağıdaki iki komutu çalıştırabilir.

Set-ADSyncBasicReadPermissions -ADConnectorAccountName "HESAP_ADI" -ADConnectorAccountDomain "firatboyan.local"

Set-ADSyncPasswordHashSyncPermissions -ADConnectorAccountName "HESAP_ADI" -ADConnectorAccountDomain "firatboyan.local"

8.3- ADSyncConfig Modülü ile Yazma İzinleri

Buraya kadar verdiğim izinler hesabın Active Directory'yi okumasına ve parola Hash'lerini almasına yeter; ancak hiçbiri User, Group ve Contact nesnelerinin Attribute değerlerini değiştirme yetkisi vermez. Oysa kurulumun ilerleyen adımlarında yapacağım üç seçim yazma izni ister. Hangi seçimin neden yazma izni istediği aşağıdaki tabloda yer alıyor.

Bu izinleri tek tek elle vermek yerine Microsoft'un ADSyncConfig PowerShell modülünü kullanıyorum. Modül Build 1.1.880.0 ile geldi ve kurulum dizinindeki AdSyncConfig.psm1 dosyasında bulunuyor. Modül bir araç kutusu gibidir: Import-Module kutuyu açar, izni ise kutunun içindeki Set-ADSync komutları verir. Modül Active Directory PowerShell araçlarını gerektirdiği için önce RSAT-AD-Tools özelliğini kuruyorum. Aşağıdaki blok hesaba izin atamaz; bu adımın devamındaki komutların ön koşuludur.

Install-WindowsFeature RSAT-AD-Tools

Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\AdSyncConfig\AdSyncConfig.psm1"

Get-Command -Module AdSyncConfig

Modüldeki beş izin komutunun hangi nesnede hangi izni atadığı aşağıdaki tabloda yer alıyor.

Tablodaki ilk iki komutu 8.2 numaralı adımda GUI ile karşıladığım için kalan üç komutu çalıştırıyorum. Komutlardaki HESAP_ADI ifadesinin yerine Connector Account adını yazıyorum; firatboyan.local ise hesabın bulunduğu AD Domain'dir. Cmdlet'ler varsayılan olarak Domain kökünden aşağıya izin atar; kapsamı belirli bir OU ile sınırlamak için -ADConnectorAccountDN ve -ADobjectDN parametreli biçim kullanılır.

Set-ADSyncMsDsConsistencyGuidPermissions -ADConnectorAccountName "HESAP_ADI" -ADConnectorAccountDomain "firatboyan.local"

Set-ADSyncPasswordWritebackPermissions -ADConnectorAccountName "HESAP_ADI" -ADConnectorAccountDomain "firatboyan.local"

Set-ADSyncExchangeHybridPermissions -ADConnectorAccountName "HESAP_ADI" -ADConnectorAccountDomain "firatboyan.local"

8.4- İzinlerin Doğrulanması

Aynı modülde izinleri kontrol etmek için iki komut daha var. Get-ADSyncADConnectorAccount, hangi hesabın Connector Account olarak kullanıldığını gösterir; Show-ADSyncADObjectPermissions ise Domain üzerinde tanımlı izinlerin tamamını bütün hesaplar için listeler. İki komut birbirinden bağımsız çalışır. İlk komutla öğrendiğim hesap adını, ikinci komutun çıktısında Connector Account'a ait satırları bulmak için kullanıyorum.

Get-ADSyncADConnectorAccount

Show-ADSyncADObjectPermissions -ADobjectDN "DC=firatboyan,DC=local"

8.5- Hesabın Wizard'a Girilmesi

İzinler hazır olduğuna göre Use existing AD account seçeneğini işaretleyip oluşturduğum hesabın bilgilerini giriyor ve dizin ekleme işlemini tamamlıyorum.

9- Microsoft Entra sign-in configuration

Microsoft Entra sign-in configuration adımında Wizard, Active Directory'deki UPN Suffix'lerini listeliyor ve bunların Entra ID'de doğrulanmış bir Domain ile eşleşip eşleşmediğini gösteriyor. Aynı ekranda, bulutta oturum açma adı olarak kullanılacak Attribute'u seçiyorum. UPN Suffix kimlik doğrulama yöntemini belirlemez; belirlediği şey kullanıcının oturum açarken yazacağı addır.

Ortamımda iki UPN Suffix var: firatboyan.local ve firatboyan.com. Entra ID'de yalnızca firatboyan.com doğrulanmış durumda. firatboyan.local gibi yönlendirilemeyen bir Domain'in Entra ID'de doğrulanması mümkün değildir.

Continue without matching all UPN suffixes to verified domains

Listede Not Added veya Not Verified durumunda bir Suffix varsa Wizard devam etmek için bu kutunun işaretlenmesini ister. Kutu, doğrulanmamış Suffix'li kullanıcıların kendi UPN'leriyle oturum açabilmesini sağlamaz; kurulumun ilerlemesine izin verir.

Kutudan bağımsız olan davranış şudur: bir kullanıcının UPN Suffix'i Entra ID'de doğrulanmış bir Domain ile eşleşmiyorsa, Entra ID bu Suffix'i Tenant'ın varsayılan onmicrosoft.com Domain'i ile değiştirir. Yani nesne bulutta oluşur, ancak oturum açma adı kullanıcının beklediği adres olmaz. Seçili yöntem PTA ise ek bir koşul daha var: kuruluma devam edebilmek için en az bir doğrulanmış Domain bulunmalıdır.



Kalıcı çözüm, @firatboyan.local Suffix'li kullanıcıların UPN değerini doğrulanmış @firatboyan.com Suffix'i ile güncellemektir. Yeni Suffix'in önce Active Directory Domains and Trusts konsolundan UPN Suffix olarak tanımlanmış olması gerekir. Toplu değişiklik için PowerShell ile Active Directory kullanıcılarının UPN bilgilerini değiştirme makalemdeki yöntemi kullanıyorum.

userPrincipalName Yerine mail Seçmek: Alternate ID

Ekrandaki User Principal Name listesinde varsayılan Attribute userPrincipalName'dir ve Microsoft bu varsayılanın korunmasını önerir. userPrincipalName yönlendirilemeyen bir Suffix taşıyorsa ve doğrulanamıyorsa mail gibi başka bir Attribute seçilebilir. userPrincipalName dışında bir Attribute kullanmanın adı Alternate ID'dir. Bu seçim senkronizasyonun çalışma biçimini değiştirmez; kullanıcının buluttaki oturum açma adının hangi Attribute'tan alınacağını belirler. Alternate ID kullanmadan önce bilinmesi gereken kısıtlar aşağıdaki tabloda yer alıyor.

mail Attribute'u boş olan kullanıcıları görmek için aşağıdaki PowerShell komutunu kullanıyorum.

Get-ADUser -Filter * -Properties mail | Where-Object { -not $_.mail } | Select-Object SamAccountName, UserPrincipalName

Production'da: UPN'ler düzeltilir ve varsayılan userPrincipalName ile ilerlenir.

Bu Lab'da: Alternate ID davranışını göstermek için mail Attribute'unu seçerek devam ediyorum.

10- Domain and OU filtering

Domain and OU filtering adımında hangi Domain'lerin ve OU'ların senkronize edileceğini belirliyorum.

10.1- Varsayılan seçenek Sync all domains and OUs'tur. Bu durumda tüm Domain'ler ve OU'lar senkronizasyon kapsamına girer.



10.2- Sync selected domains and OUs seçeneğinde yalnızca işaretlediğim OU'lar senkronize edilir. Servis hesaplarının veya senkronize edilmesi istenmeyen nesnelerin bulunduğu OU'ları kapsam dışında tutmak için bu seçeneği kullanıyorum.



10.3- Önce firatboyan.local seviyesindeki işareti kaldırarak tüm seçimleri temizliyor, ardından yalnızca senkronize etmek istediğim OU'ları işaretliyorum.

OU seçerken dikkat ettiğim noktalar şunlar.

Bazı OU'lar işlevsellik için gereklidir. Örneğin Hybrid Join kullanılacaksa Computer nesnelerinin bulunduğu OU'lar da kapsamda olmalıdır.

Filtre grubunun OU'su kapsamda olmalıdır. Group-Based Filtering kullanılacaksa filtre grubunun bulunduğu OU seçili olmalıdır, çünkü OU Filtering, Group-Based Filtering'den önce değerlendirilir.

Erişilemeyen Domain'ler işaretsiz görünür. Firewall nedeniyle erişilemeyen Domain'ler listede işaretsiz ve uyarıyla görünür.

Yeni OU'ların davranışı bu ekranda belirlenir. 1.1.524.0 ve sonrasında yeni oluşturulan OU'ların senkronize edilip edilmeyeceğini kendim seçebiliyorum. Daha eski sürümlerde yeni OU'lar varsayılan olarak senkronize ediliyordu.

11- Uniquely identifying your users

Uniquely identifying your users adımında iki ayrı karar veriyorum: kullanıcıların On-Premises dizinlerde nasıl tanımlanacağı ve Entra ID ile hangi Attribute üzerinden eşleneceği (Source Anchor). Kullanıcı eşleştirme ayarı kurulumdan sonra değiştirilemez. Source Anchor için de aynı kural geçerlidir; tek istisnayı bölümün sonunda anlatıyorum.

✅ Users are represented only once across all directories

Bu seçenekte her kullanıcı Entra ID'de ayrı bir nesne olarak oluşturulur ve nesneler Metaverse'te birleştirilmez. Tek Forest'lı ortamlar ve her kullanıcının tüm Forest'larda yalnızca bir kez bulunduğu yapılar için doğru seçenek budur.

✅ User identities exist across multiple directories. Match Using:

Aynı kişi birden fazla Forest'ta temsil ediliyorsa, bu nesnelerin hangi Attribute üzerinden birleştirileceği burada seçilir. Seçenekler aşağıdaki tabloda yer alıyor.

Production'da: Tek Forest'lı ortamda doğru seçenek Users are represented only once across all directories olur.

Bu Lab'da: Ekran görüntüsünü aldığım eski kurulumda bu bölümde Mail attribute seçeneğiyle devam etmiştim.

Hard Match ve Soft Match

Tenant'ta önceden oluşturulmuş Cloud-Only hesaplar varsa, senkronizasyon başladığında Entra ID gelen nesneleri mevcut nesnelerle eşleştirmeye çalışır. Bu işlemde üç Attribute kullanılır: userPrincipalName, proxyAddresses ve sourceAnchor/immutableID. userPrincipalName veya proxyAddresses üzerinden yapılan eşleşme Soft Match, sourceAnchor üzerinden yapılan eşleşme Hard Match olarak adlandırılır. proxyAddresses için yalnızca SMTP: önekli değer, yani birincil e-posta adresi dikkate alınır.

Eşleşme bulunduğunda buluttaki nesne On-Premises tarafından yönetilen bir nesneye dönüşür ve On-Premises'ta değeri olan Attribute'lar buluttaki değerlerin üzerine yazılır. Güvenlik gereği Entra ID, yönetici rolüne sahip bulut kullanıcılarını On-Premises kullanıcılarla eşleştirmez.

✅ Select how users should be identified with Microsoft Entra ID

Ekranın alt bölümünde Source Anchor seçilir. Source Anchor, bir nesnenin yaşam süresi boyunca değişmeyen ve On-Premises nesneyi Entra ID'deki karşılığına bağlayan birincil anahtardır. Federation senaryolarında ve bazı Entra ID arayüzlerinde immutableID adıyla da geçer.

✔ Let Azure manage the source anchor

Bu seçenekte Attribute'u Wizard belirler. Mantık şöyle çalışır: Tenant'ta önceki bir kurulumdan kalan bir Source Anchor bilgisi varsa o kullanılır. Yoksa Wizard dizindeki nesnelerde mS-DS-ConsistencyGuid Attribute'unun dolu olup olmadığına bakar. Hiçbir nesnede dolu değilse Source Anchor olarak mS-DS-ConsistencyGuid seçilir. Bir veya daha fazla nesnede doluysa Wizard bu Attribute'un başka uygulamalarca kullanıldığı sonucuna varır ve objectGUID'e döner.

mS-DS-ConsistencyGuid seçildiğinde User nesneleri için Source Anchor olarak bu Attribute kullanılır. Bir User nesnesinde Attribute boşsa, Microsoft Entra Connect Sync nesnenin objectGUID değerini On-Premises Active Directory'deki mS-DS-ConsistencyGuid Attribute'una yazar ve nesneyi ondan sonra Entra ID'ye gönderir. Connector Account'a 8.3 numaralı adımda bu Attribute için yazma izni vermemin nedeni budur. Group nesnelerinde ise 1.5.18.0 sürümünden itibaren mS-DS-ConsistencyGuid doluysa immutableID olarak bu değer kullanılıyor; ancak Microsoft Entra Connect Sync bu değeri Group nesneleri için Active Directory'ye kendisi yazmıyor.

Bu yaklaşımın faydası Forest'lar arası taşımalarda ortaya çıkar. objectGUID, nesne başka bir Forest'a veya Domain'e taşındığında değişir. mS-DS-ConsistencyGuid ise yazılabilir bir Attribute olduğu için kaynak nesnedeki değer hedef nesneye aktarılabilir ve buluttaki nesneyle bağ korunur.

✔ Choose a specific Attribute

Bu seçenekte Source Anchor olarak mevcut bir Active Directory Attribute'unu kendim belirlerim. Seçilen Attribute nesnenin yaşam süresi boyunca değişmemelidir; kişi evlendiğinde veya görev değiştirdiğinde değişebilen Attribute'lar uygun değildir. Attribute değeri @ işareti içeremez, bu nedenle e-posta adresi ve userPrincipalName kullanılamaz. Değer büyük küçük harfe duyarlıdır.

Ben Let Azure manage the source anchor seçeneğiyle devam ediyorum.

Bu istisnanın koşulları şunlar: sürüm 1.1.552.0 veya üzeri olmalı, dizinde mS-DS-ConsistencyGuid değeri dolu hiçbir nesne bulunmamalı ve Connector Account'ta bu Attribute için yazma izni olmalı. Dizinde değeri dolu nesne varsa Wizard, Attribute'un başka bir uygulama tarafından kullanıldığı sonucuna varıp hata verir; Attribute'un gerçekten boşta olduğundan eminsem Wizard'ı /SkipLdapSearch parametresiyle başlatarak bu denetimi atlayabilirim. AD FS, Microsoft Entra Connect dışında yönetiliyorsa veya üçüncü taraf bir Federation sunucusu varsa ImmutableID Claim kuralları geçişten sonra elle güncellenir.

12- Filter users and devices

Filter users and devices adımında senkronizasyon kapsamını tek bir gruba göre daraltma imkanı sunuluyor.

✅ Synchronize all users and devices

Önceki adımda seçtiğim Domain ve OU kapsamındaki tüm nesneler senkronize edilir, grup bazlı ek bir filtre uygulanmaz. Pilot bir geçiş yapılmıyorsa kullanılacak seçenek budur.

✅ Synchronize selected

Bu seçenekte yalnızca belirttiğim grubun doğrudan üyeleri senkronize edilir. Kullanıcılar, gruplar, Contact'lar ve bilgisayarlar grubun doğrudan üyesi olmalıdır; iç içe grup üyeliği çözümlenmez. Gruba üye olarak başka bir grup eklendiğinde yalnızca o grubun kendisi kapsama girer, üyeleri girmez. Group alanına grup adını yazıp Resolve butonuna bastığımda Wizard grubu doğrular ve Distinguished Name (DN) biçimine çevirir.

13- Optional features

Optional features ekranındaki her seçenek, senkronizasyona yeni bir veri akışı ekler. Bazıları yalnızca buluta doğru, bazıları buluttan On-Premises'a doğru çalışır. Yazma yönünde çalışan her özellik Connector Account'ta ek izin gerektirdiği için yalnızca ihtiyacım olanları açıyorum.

✅ Exchange Hybrid Deployment

On-Premises Exchange ile Exchange Online'daki Mailbox'ların bir arada çalışmasını sağlayan seçenektir. Etkinleştirildiğinde Microsoft Entra Connect Sync, belirli bir Attribute setini Entra ID'den On-Premises Active Directory'ye geri yazar.

Microsoft'un dokümanındaki Exchange Hybrid Writeback listesi dokuz Attribute'tan oluşur: msDS-ExternalDirectoryObjectID, msExchArchiveStatus, msExchBlockedSendersHash, msExchSafeRecipientsHash, msExchSafeSendersHash, msExchUCVoiceMailSettings, msExchUserHoldPolicies, proxyAddresses ve publicDelegates. proxyAddresses için yalnızca Exchange Online'daki x500 adresi eklenir. Exchange sürümüne bağlı olarak daha az Attribute senkronize edilebilir.

✅ Exchange Mail Public Folders

Mail-Enabled Public Folder nesnelerinin On-Premises Active Directory'den Entra ID'ye senkronize edilmesini sağlar. Üyeleri arasında Public Folder bulunan grupların senkronize edilmesi desteklenmez; denendiğinde senkronizasyon hatası oluşur.

✅ Microsoft Entra ID App and Attribute Filtering

Entra ID'ye senkronize edilen Attribute setini daraltmaya yarar ve Wizard'a iki sayfa ekler. İlk sayfada kullanılan servisler seçilir, ikinci sayfada bu servislere göre senkronize edilecek Attribute'lar listelenir ve istenmeyenlerin işareti kaldırılabilir. Attribute kaldırmak ilgili servisin işlevini etkileyebileceği için bu seçeneği açmadan önce servislerin Attribute gereksinimlerini kontrol etmek gerekir.

✅ Password Hash Synchronization

Oturum açma yöntemi olarak PTA veya Federation seçildiyse PHS bu ekrandan ek olarak etkinleştirilebilir. PTA seçiliyken PHS'i açmak iki işe yarar: eski istemciler için destek ve yedek sağlar, Entra ID Protection'ın sızdırılmış kimlik bilgileri raporunu çalıştırır. PHS tek yönlüdür; bulutta yapılan parola değişikliğinin Active Directory'ye yansıması için Password Writeback gerekir.

✅ Password Writeback

Entra ID'de yapılan parola değişikliklerinin On-Premises Active Directory'ye yazılmasını sağlar. İletişim kanalı olarak Azure Service Bus Relay kullanılır; tüm iletişim 443 numaralı Port üzerinden giden yöndedir ve gelen yönde Firewall kuralı gerekmez.

Geri yazılan işlemler şunlardır: kullanıcının Self-Service Password Reset portalından yaptığı sıfırlama, kullanıcının kendi isteğiyle veya zorunlu olarak yaptığı parola değişikliği ve yöneticinin Microsoft Entra admin center üzerinden yaptığı sıfırlama. Yeni parola Active Directory'ye yazılmadan önce On-Premises AD DS politikasına göre denetlenir; geçmiş, karmaşıklık, yaş, Password Filter'lar ve AD DS'te tanımlı diğer parola kısıtlamaları (örneğin Fine-Grained Password Policy) bu denetime dahildir. Özelliğin çalışması için gereken üç koşul aşağıdaki tabloda yer alıyor.

✅ Group Writeback

Bu seçenek Microsoft 365 Group'larının On-Premises Active Directory'de temsil edilmesini sağlar ve yalnızca On-Premises Active Directory'de Exchange varsa kullanılabilir. Kaynak bulut olduğu için akış Entra ID'den Active Directory'ye doğrudur.

✅ Device Writeback

Entra ID'deki cihaz nesnelerinin On-Premises Active Directory'ye yazılmasını sağlar. Microsoft iki senaryo için gerektiğini belirtir: Windows Hello for Business'ın Hybrid Certificate Trust modeliyle dağıtımı ve AD FS (2012 R2 veya üzeri) ile korunan uygulamalara cihaz bazlı Conditional Access uygulanması. Microsoft Entra ID P1 veya P2 aboneliği gerekir ve cihazlar kullanıcılarla aynı Forest'ta bulunmalıdır. Bu iki senaryo yoksa seçeneği açmaya gerek yoktur.

✅ Directory Extension Attribute Sync

Varsayılan senkronizasyon setinde olmayan Attribute'ların Entra ID'ye taşınmasını sağlar. Seçenek işaretlendiğinde Wizard'a Directory Extensions sayfası eklenir ve senkronize edilecek Attribute'lar burada seçilir. Available Attributes alanı büyük küçük harfe duyarlıdır.

Ben Exchange hybrid deployment, Password hash synchronization ve Password writeback seçeneklerini işaretleyerek devam ediyorum. Ortamımda On-Premises Exchange ile Exchange Online birlikte çalışacak, PTA'nın yanında PHS'in hazır olmasını istiyorum ve bulutta yapılan parola sıfırlamalarının Active Directory'ye yazılması gerekiyor.

14- Enable single sign-on

User sign-in adımında Enable single sign-on kutusunu işaretlediğim için Wizard şimdi Seamless SSO yapılandırmasını istiyor. Ekranda senkronize edilen Forest'lar listeleniyor; benim ortamımda yalnızca firatboyan.local var. AZUREADSSOACC Computer Account'unun oluşturulabilmesi için her Forest'a ait Domain Administrator bilgisi bu sayfada girilir; Seamless SSO istenmeyen Forest'lar atlanabilir. Bu bilgiler yalnızca özelliği etkinleştirmek için kullanılır; Microsoft Entra Connect'te veya Entra ID'de saklanmaz.



Enter credentials butonuna tıklıyor ve FIRATBOYAN\Administrator hesabının bilgilerini girip OK butonuna basıyorum.



Doğrulama tamamlandığında butonun yanında yeşil onay işareti beliriyor ve Next butonu etkinleşiyor.

15- Ready to configure

Ready to configure ekranı, Wizard'ın Install butonuna basıldığında yapacağı işlemleri listeliyor.



Benim seçimlerime göre listede şu işlemler var:

✔ Synchronization Services'in bu bilgisayara kurulması ve yapılandırılması.

✔ Pass-through Authentication için Authentication Agent'ın kurulması.

✔ Pass-through Authentication'ın Tenant'ta etkinleştirilmesi.

✔ Seamless SSO'nun etkinleştirilmesi.

✔ Source Anchor'ın mS-DS-ConsistencyGuid olarak yapılandırılması.

✔ Microsoft Entra ID Connector'ının yapılandırılması.

✔ firatboyan.local Connector'ının yapılandırılması.

✔ Password Hash Synchronization'ın etkinleştirilmesi.

✔ Password Writeback'in etkinleştirilmesi.

✔ Microsoft Entra ID Export Deletion Threshold'un (500) etkinleştirilmesi.

Son maddedeki Prevent accidental deletes özelliği kurulumda varsayılan olarak etkin gelir ve 500'den fazla silme içeren bir Export'a izin vermez. Yanlışlıkla bir OU'nun kapsam dışına çıkarılması gibi hatalarda Tenant'ı toplu silmeden koruyan mekanizma budur. Eşiğin görüntülenmesini ve değiştirilmesini 19 numaralı adımda anlatıyorum.

Start the synchronization process ve Enable staging mode

Listenin altında iki kutu var.

Start the synchronization process when configuration completes. İşaretli bırakılırsa kurulum biter bitmez ilk tam senkronizasyon başlar. İşaret kaldırılırsa Wizard senkronizasyonu yapılandırır, ancak Scheduler'ı devre dışı bırakır.

Enable staging mode. Staging Mode'daki sunucu Import ve Synchronization işlemlerini normal şekilde yürütür, ancak hiçbir Export çalıştırmaz. Kurulumda seçilmiş olsalar bile Password Sync ve Password Writeback bu modda çalışmaz. Staging Mode, etkin sunucunun yanında hazır bekleyen ikinci bir sunucu kurmak veya yapılandırmayı dışarıya yazmadan önce incelemek için kullanılır. Tenant'a aynı anda yalnızca bir sunucu etkin olarak yazabilir; yapı Active-Passive olmak zorundadır.

Staging sunucusu veriyi içeri almaya ve işlemeye devam ettiği için, devraldığında hızlıca etkin hale gelir. Geçiş için Wizard'da Configure staging mode görevi açılır, Staging Mode kutusunun işareti kaldırılır ve senkronizasyonun başlatılması onaylanır. Mod kapatıldığında sunucu Export yapmaya başlar, Password Sync ve Password Writeback etkinleşir.

İlk kutuyu işaretli, ikinciyi boş bırakıp Install butonuna tıklıyorum.

16- Configuring

Configuring aşamasında Wizard, listelediği işlemleri sırayla uyguluyor. Aşağıdaki ekranlar benim kurulumumda gördüğüm sırayı gösteriyor.

Verifying Synchronization Service Connectivity to Microsoft Entra ID

Senkronizasyon servisinin Microsoft Entra ID'ye erişimi doğrulanıyor. Bağlantı kurulamazsa Retry butonu ile yeniden denenebilir.

Creating the Microsoft Entra ID Synchronization Account

Bu adım, sunucunun Entra ID'ye hangi kimlikle bağlanacağını belirliyor. Makaledeki en büyük davranış değişikliği burada. Aşağıdaki iki görsel, kurulumumu yaptığım eski sürümde Tenant'ta Sync_ ile başlayan bir kullanıcı hesabının oluşturulduğu anı gösteriyor.

2.5.76.0 sürümüyle Application-Based Authentication genel kullanıma açıldı ve varsayılan oldu. İki yöntem arasındaki fark aşağıdaki tabloda yer alıyor.

2.6.84.0 sürümünden itibaren eski Sync_ hesabıyla ilgili geçerli olan kurallar aşağıdaki tabloda yer alıyor.

Enabling Single Sign-On

14 numaralı adımda girdiğim Domain Administrator bilgisiyle firatboyan.local Forest'ında AZUREADSSOACC Computer Account'u oluşturuluyor ve hesabın Kerberos Decryption Key'i Entra ID ile paylaşılıyor.

Installing ve Configuring Authentication Agent for Pass-Through Authentication

PTA için ilk Authentication Agent, Microsoft Entra Connect Sync sunucusunun kendisine kuruluyor ve Tenant'a kaydediliyor. Bu tek Agent Production için yeterli değildir; kurulumdan sonra farklı sunuculara ek Agent'lar kurarak toplam sayıyı en az üçe çıkarmak gerekir.

Checking for Installed Components

Wizard, kurulu bileşenleri yeniden denetliyor.

Configuring Microsoft Entra Connect Sync

Senkronizasyon servisi (ADSync) seçtiğim ayarlarla yapılandırılıyor. Yapılandırmayı Wizard yapar, senkronizasyonu ADSync servisi yürütür. Synchronization Service Manager ise kurulumdan sonra senkronizasyonu izlemek için kullandığım yönetim arayüzüdür.

Configuring (M365x03533948.onmicrosoft.com - AAD)

Tenant tarafındaki Connector yapılandırılıyor. Ekranda Connector adının sonunda eski adlandırmadan kalan AAD kısaltması görünüyor.

Updating Synchronization Rules (M365x03533948.onmicrosoft.com - AAD)

Seçtiğim özelliklere karşılık gelen varsayılan Sync Rule'lar oluşturuluyor ve güncelleniyor. Bu işi Wizard yapar. Synchronization Rules Editor ise kurulumdan sonra bu kuralları incelemek ve özel kural eklemek için kullandığım ayrı bir araçtır.

Configuring (firatboyan.local)

On-Premises tarafındaki Connector yapılandırılıyor: 8 numaralı adımda belirlediğim Connector Account, 10 numaralı adımdaki Domain ve OU seçimi ve 11 numaralı adımdaki Source Anchor ayarı bu Connector'a uygulanıyor.

17- Configuration complete

Kurulum tamamlandı. Özet ekranı, yapılandırmanın sonucunu ve dikkat edilmesi gereken noktaları listeliyor: Source Anchor olarak mS-DS-ConsistencyGuid kullanılıyor, PTA ve Seamless SSO etkin, PHS ile Password Writeback açık ve ilk senkronizasyon başlatıldı.



Wizard'dan çıktıktan sonra Windows oturumunu kapatıp yeniden açıyorum. Microsoft, Synchronization Service Manager ve Synchronization Rules Editor kullanılmadan önce bunun yapılmasını istiyor.

18- İlk Synchronization ve Doğrulama

İlk senkronizasyonun sonucunu önce Synchronization Service Manager'da kontrol ediyorum. Operations sekmesinde Import, Synchronization ve Export adımlarının başarıyla tamamlandığını, toplam 264 nesnenin Entra ID'ye aktarıldığını görüyorum. Users OU'su altındaki Ayşe Yıldız, Mehmet Aksoy, Zeynep Kaya, Ali Demir ve Fatma Şahin gibi hesaplar listede yer alıyor.

Senkronize edilen kullanıcıların kaynağı On-Premises Active Directory'dir: kullanıcı bilgileri ve parolalar Active Directory'de değiştirilir, değişiklikler Entra ID'ye yansır. Bulutta yapılan parola sıfırlamaları da Password Writeback sayesinde Active Directory'ye yazılır.

Bulut tarafında iki yerden doğrulama yapıyorum. Microsoft Entra admin center'da Entra Connect altındaki Connect Sync sayfası son senkronizasyon zamanını gösteriyor; bir kullanıcının özelliklerinde On-premises sync enabled değerinin Yes olması o nesnenin On-Premises'tan senkronize edildiğini doğruluyor. Microsoft 365 admin center'daki Active users listesinde ise Sync status sütunu, kullanıcının Cloud-Only mi yoksa On-Premises'tan senkronize edilmiş mi olduğunu simgeyle gösteriyor.

Bundan sonrası Scheduler'ın işi. Nesne ve Attribute senkronizasyonu varsayılan olarak 30 dakikada bir çalışır; parola senkronizasyonu ayrı bir süreçtir ve iki dakikada bir çalışır. Scheduler'ın durumunu görmek ve beklemeden bir Delta senkronizasyonu başlatmak için aşağıdaki komutları kullanıyorum. Delta yalnızca değişiklikleri işler; Initial ise tüm Connector'larda Full Import ve Full Synchronization çalıştırır.

Get-ADSyncScheduler

Start-ADSyncSyncCycle -PolicyType Delta

19- Kurulum Sonrası Kontrol Listesi

Wizard bitti, ancak Seamless SSO ve PTA'nın Production'da güvenli ve kesintisiz çalışması için yapılacak işler var. Aşağıdaki tablo bu işleri, nedenlerini ve nasıl doğrulanacağını bir arada gösteriyor. Her satırın ayrıntısı tablonun altındaki bölümlerde yer alıyor.

Seamless SSO için Group Policy Yapılandırması

Wizard'ın yaptığı iş sunucu tarafıyla sınırlıdır: AZUREADSSOACC hesabını oluşturur ve Key'i Entra ID ile paylaşır. İstemci tarafına dokunmaz. Oysa tarayıcı, Kerberos Ticket'ı yalnızca Intranet Zone'daki adreslere kendiliğinden gönderir ve Entra ID'nin Seamless SSO adresleri varsayılan olarak Internet Zone'da kalır. Bu adresler Intranet Zone'a alınmadıkça Wizard'da özellik açık görünse de kullanıcıdan parola istenmeye devam eder.

Ayar User Configuration altında olduğu için Group Policy nesnesini kullanıcı hesaplarının bulunduğu OU'ya bağlıyorum. Yapılacak iki ayar var.

Site to Zone Assignment List. User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page altındadır. Microsoft'un özel kurulum dokümanına göre iki adres Value name olarak girilir ve her ikisine de 1 değeri verilir: https://autologon.microsoftazuread-sso.com ve https://aadg.windows.net.nsatc.net.

Allow updates to status bar via script. Aynı yolun altındaki Intranet Zone düğümünde bulunur ve etkinleştirilmesi gerekir.

Site to Zone Assignment List yerine bir Registry Item Group Policy Preference de kullanılabilir; ancak Microsoft'un bu alternatif için verdiği Registry yolu yalnızca autologon adresini kapsar. İki yöntem arasındaki fark, kullanıcıların kendi Intranet Zone ayarlarını değiştirip değiştiremeyeceğidir: Group Policy ayarı kilitler, Preference ise değiştirilebilir bırakır. Bu adımlar Internet Explorer, Microsoft Edge ve güvenilir site listesini Internet Explorer ile paylaşan Google Chrome için geçerlidir.

Yöntemlerin her birini, Group Policy ekranlarıyla birlikte adım adım Microsoft Entra ID Seamless SSO, PHS, PTA Farkı ve Kerberos başlıklı makalemin Domain-Joined Cihazlar İçin Zorunlu GPO Yapılandırması bölümünde anlattım. Yapılandırmayı oradan takip edebilirsin.

AZUREADSSOACC Hesabının Korunması

AZUREADSSOACC Computer Account'u güçlü biçimde korunmalıdır. Hesabı yalnızca Domain Administrator hesapları yönetebilmeli, hesapta Kerberos Delegation kapalı olmalı ve başka hiçbir hesabın bu hesap üzerinde Delegation izni bulunmamalıdır. Hesabı kazara silinmeye karşı korunan bir OU'da tutmak da önerilir. Ortamda Pass-the-Hash ve Credential Theft önlemleri varsa hesabın Quarantine Container'ına düşmediği ayrıca kontrol edilmelidir.

Kerberos Decryption Key Rollover

Kerberos Decryption Key sızarsa senkronize edilen herhangi bir kullanıcı için Kerberos Ticket üretilebilir. Microsoft bu yüzden Key'in en az 30 günde bir yenilenmesini önerir. İşlem otomatik değildir; Microsoft Entra Connect Sync sunucusunda, yönetici olarak açılmış bir PowerShell oturumunda, Domain Administrator ve Hybrid Identity Administrator bilgileriyle aşağıdaki adımlarla yapılır. Son adımdaki Update-AzureADSSOForest komutu, AZUREADSSOACC hesabının Key'ini Active Directory'de yeniler ve yeni Key'i Entra ID'ye bildirir. 2.6.91.0 sürümünden itibaren ADSync.psd1 modülünün AzureADSSO.psd1 modülünden önce yüklenmesi gerekiyor.

cd "$env:ProgramFiles\Microsoft Azure Active Directory Connect"

Import-Module "$env:ProgramFiles\Microsoft Azure AD Sync\Bin\ADSync\ADSync.psd1"

Import-Module .\AzureADSSO.psd1

New-AzureADSSOAuthenticationContext

Get-AzureADSSOStatus | ConvertFrom-Json

$creds = Get-Credential

Update-AzureADSSOForest -OnPremCredentials $creds

Bu komutlar Domain Controller'da değil, Microsoft Entra Connect Sync'in kurulu olduğu sunucuda çalıştırılır. Çalıştırırken dikkat ettiğim noktalar aşağıdaki tabloda yer alıyor.

Kerberos Şifreleme Türü: RC4 Yerine AES

Seamless SSO'da Domain Controller, kullanıcıya AZUREADSSOACC hesabı için bir Kerberos Ticket verir ve bu Ticket'ı o hesabın Key'i ile şifreler. Şifrelemede hangi algoritmanın kullanılacağını hesabın Active Directory'deki msDS-SupportedEncryptionTypes Attribute'u belirler. Seamless SSO üç türü destekler: AES256_HMAC_SHA1, AES128_HMAC_SHA1 ve RC4_HMAC_MD5.

Bu konu, Temmuz 2026 Windows Server güncellemesiyle önem kazandı. Eskiden AD DS'te varsayılan Kerberos şifreleme türü RC4'tü. Bu güncellemeyle varsayılan AES-256 oldu ve Microsoft, RC4 kullanmaya devam eden ortamlarda Seamless SSO sorunları yaşanabileceğini belirtiyor. Önerisi, AZUREADSSOACC hesabının AES256_HMAC_SHA1 veya başka bir AES tabanlı türle çalışacak şekilde yapılandırılması.

Geçişte sıra önemli: Önce yukarıdaki komutlarla Kerberos Decryption Key yenilenir, sonra hesabın şifreleme türü AES'e çevrilir. Key yenilenmeden şifreleme türü değiştirilirse Seamless SSO çalışmayabilir. Şifreleme türünü Domain Controller'da aşağıdaki komutla değiştiriyorum.

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

Set-ADComputer AZUREADSSOACC -KerberosEncryptionType AES256

Ek Authentication Agent'lar

Kurulumda yalnızca bir Authentication Agent kuruldu ve bu Agent Microsoft Entra Connect Sync sunucusunun üzerinde. Bu sunucu bakıma alındığında veya erişilemez olduğunda PTA doğrulaması durur. Microsoft Production için en az üç Agent önerir. Ek Agent'ların kurulum dosyası admin center'da Entra Connect altındaki Pass-through authentication sayfasından indirilir ve farklı sunuculara kurulur. Agent'ların durumu aynı sayfada görünür.

Password Writeback Kontrolleri

Wizard'da seçeneği açmak tek başına yeterli değildir. Kullanıcıların lisanslı olduğunu, Domain'deki Minimum password age değerinin 0 olduğunu ve Microsoft Entra admin center'da Password reset altındaki On-premises integration sayfasında Writeback ayarının etkin olduğunu doğruluyorum. Son kontrol olarak bir test kullanıcısıyla Self-Service Password Reset yapıp yeni parolanın Active Directory'de çalıştığını deniyorum.

Application-Based Authentication Doğrulaması

Sunucunun Entra ID'ye hangi kimlikle bağlandığını iki yoldan görebiliyorum. Wizard'daki View or export current configuration görevinde, uygulama kimliği kullanılıyorsa uygulamanın Client ID'si, eski yöntem kullanılıyorsa hesap adı görünür. Aynı bilgiyi aşağıdaki PowerShell komutu da verir. Çıktıdaki ConnectorIdentityType alanı ServiceAccount değerini gösteriyorsa sunucu hala eski hesapla çalışıyordur ve Wizard'da Additional tasks altındaki Configure application-based authentication to Microsoft Entra ID görevi çalıştırılır.

Get-ADSyncEntraConnectorCredential

Export Deletion Threshold

Eşik aşıldığında Export hiçbir nesneyi silmeden durur, yöneticiye e-posta gönderilir ve Synchronization Service Manager'da Export adımının durumu stopped-deletion-threshold-exceeded olarak görünür. Eşik, Global Administrator veya Hybrid Identity Administrator hesabıyla aşağıdaki cmdlet'lerle görüntülenir ve değiştirilir. Komutlardaki admin@tenant.onmicrosoft.com ifadesinin yerine yönetici hesabının UPN değeri yazılır.

Get-ADSyncExportDeletionThreshold -AADUserName "admin@tenant.onmicrosoft.com"

Enable-ADSyncExportDeletionThreshold -DeletionThreshold 500 -AADUserName "admin@tenant.onmicrosoft.com"

Seamless SSO Testi

Group Policy dağıtıldıktan sonra özelliği iki yerden doğruluyorum. İlki Tenant tarafı: Microsoft Entra admin center'da Entra ID altındaki Entra Connect ve Connect sync sayfasında Seamless single sign-on değerinin Enabled göründüğünü kontrol ediyorum.

[EKRAN GÖRÜNTÜSÜ: Microsoft Entra admin center, Connect sync sayfasında Seamless single sign-on satırının Enabled göründüğü bölüm]

İkincisi istemci tarafı. Test için kullanıcının Domain-Joined bir cihazda Windows oturumu açmış olması, cihazın Domain Controller'a kablolu, kablosuz veya VPN üzerinden doğrudan erişebilmesi ve Group Policy'nin bu kullanıcıya uygulanmış olması gerekir. Tarayıcıda yeni bir gizli oturum açıp https://myapps.microsoft.com/M365x03533948.onmicrosoft.com adresine gidiyorum. Seamless SSO çalışıyorsa kullanıcı adı ve parola sorulmadan oturum açılır. Son olarak test hesaplarıyla Microsoft 365 servislerinde oturum açıp PTA üzerinden doğrulamanın çalıştığını deniyorum.

Faydalı olması dileğiyle...