Client'lar Hybrid Join Sürecinde Entra ID'ye SCP ile Nasıl Kaydolur

Bir makineyi On-Premises Active Directory Domain'ine katmak hepimizin yıllardır yaptığı bir iş. System Properties'ten Domain adını yazarsınız, yetkili bir hesap girersiniz, makine yeniden başlar ve olur biter. Arka planda neler olduğunu da az çok biliriz; makine DNS'e SRV kaydı sorar, kendine bir Domain Controller bulur, Active Directory'de bir Computer Account oluşur ve o andan itibaren Kerberos ile kimlik doğrulamaya başlar. Buraya kadar sürpriz yok.

Şimdi aynı makinenin bir de Microsoft Entra ID Tenant'ına kaydolması gerekiyor. İşte tam bu noktada, üzerinde biraz düşününce insanı rahatsız eden bir soru çıkıyor ortaya. Bu makine hangi Tenant'a ait olduğunu nereden biliyor? Düşünün, dünyada milyonlarca Tenant var. Makineye Tenant ID'yi elle yazan yok, ona "sen şu Tenant'a kaydol" diyen bir Group Policy de yok. Kullanıcı sabah gelip oturum açıyor, kahvesini içerken bir süre sonra Entra Admin Center'da o makine "Microsoft Entra hybrid joined" olarak beliriyor. Peki nasıl?

Bu sorunun cevabı, Active Directory'nin Configuration Partition'ında duran tek bir nesnede saklıdır. Bu nesnenin adı Service Connection Point olup, kısaca SCP olarak kullanılmaktadır. Entra Connect bu nesneyi Forest'a bir kez yazar ve işi biter. Sonrasında Domain'e üye her Windows makinesi, her oturum açmada aynı sabit adrese bakar, orada bir SCP bulursa içindeki Tenant bilgisini okur ve kaydını kendisi başlatır. Yani Hybrid Join dediğimiz şey, sunucu tarafında bir yazma ve Client tarafında sürekli tekrarlanan bir okuma işleminden ibarettir.

Bu makalede işin bu perde arkasını adım adım açıyorum. Önce SCP'nin ne olduğuna, Entra Connect Sync ile nasıl oluşturulduğuna ve nasıl doğrulandığına bakacağız. Ardından Client tarafına geçip SCP'nin Windows'un içine gömülü olan Scheduled Task ile nasıl okuduğunu, Device Registration Service'e nasıl ulaştığını ve cihazın kendini Entra ID'ye hangi kimlik kanıtıyla yazdırdığını inceleyeceğiz. Son bölümde de kaydın tamamlandığını hem Client üzerinde hem de Entra Admin Center'da nasıl teyit edeceğimizi göstereceğim.

Ortam olarak abc.local Forest'ı, Managed kimlik modeli PTA (Pass-through Authentication) ve M365x00439391.onmicrosoft.com Tenant'ı üzerinde çalışıyorum. Hybrid Join açısından Pass-through Authentication ile Password Hash Sync arasında fark yoktur; ikisi de Managed modeldir ve aynı akışı izler. Federated ortamlarda da SCP mantığı aynıdır, farklılaşan yalnızca kayıt anındaki kimlik kanıtı adımıdır ve o noktaya geldiğimizde iki modeli ayrı ayrı ele alacağım.

SCP, Active Directory'de bir servisin bağlantı bilgisini tutmak için kullanılan standart bir nesne türüdür ve objectClass değeri serviceConnectionPoint'tir. Hybrid Join için oluşturulan SCP, Forest'ın hangi Entra Tenant'ına bağlı olduğunu söyler. Nesnenin CN değeri ve bulunduğu Container sabittir ve Windows içinde Hard-Codded olarak gömülüdür; değişen tek kısım sondaki DC bileşenleridir, o da her Forest'ın kendi Configuration Partition'ını gösterir. Bu ortamda nesnenin tam yolu aşağıdaki gibidir.

Nesnenin keywords Attribute'unda iki değer bulunur. azureADName, Tenant'ın doğrulanmış Domain adını taşır; bu ortamda M365x00439391.onmicrosoft.com. azureADId ise Tenant'ın GUID değerini taşır.

SCP'nin Configuration Partition'da olması tesadüf değil. Configuration Partition Forest'taki her Domain Controller'a replike olur ve her Domain'den okunabilir. Okumak için özel bir izin de gerekmez; Authenticated Users'ın varsayılan Read hakkı yeterlidir. Böylece Forest'a katılan her makine, hangi Domain'de veya hangi OU'da olursa olsun, ek bir ayar yapılmadan aynı Tenant bilgisine ulaşır. Bu tasarımın doğal sonucu olarak Forest başına tek SCP vardır; tek bir Forest yalnızca tek bir Tenant'a bağlanabilir.

SCP'yi yazmadan önce yerine getirilmesi gereken bir ön koşul var. Entra Connect Sync kurulu olmalı ve Hybrid Join olacak Computer Object'lerin bulunduğu OU'lar Sync Scope içinde bulunmalıdır. Managed ortamda hangi makinelerin gerçekten Hybrid Join olacağını belirleyen asıl yer burasıdır. Sync Scope dışındaki bir makine SCP'yi okur ve kayıt dener, ancak Entra ID'de ona ait bir Device Object olmadığı için Device Registration Service isteği reddeder. Bu deneme her oturum açmada tekrarlanır ve her seferinde başarısız olur. Bu yüzden bir OU'yu Hybrid Join dışında tutmanın en temiz yolu onu Sync Scope'a hiç almamaktır.

Aşağıdaki Domain and OU filtering ekranında yapının tamamı görünüyor. Domain Controllers ve Computers Container'ları işaretsiz; Ist-All-Departments altındaki OU'lar ise kısmi seçili durumda. Microsoft, Domain Controller rolündeki sunucularda ve Server Core kurulumlarda Hybrid Join'i desteklemez; Domain Controllers OU'sunun Scope dışında kalması bu yüzden bilinçli bir tercihtir.



Aynı ekranı aşağı kaydırdığımda yalnızca HR ve IT altındaki Hybrid Computers OU'larının işaretli olduğu görülüyor. LPT Computers ve WKS Computers OU'ları Scope dışında. Bu ortamda Hybrid Join olacak makineler yalnızca bu iki OU'daki makinelerdir; diğerleri Domain'e üye olsa bile Entra ID'ye kaydolamaz.



SCP'nin oluşturulması Entra Connect Sync Wizard'ı üzerinden yapılır. Wizard'ı açıp Configure dediğimde Additional tasks listesi geliyor; buradan Configure device options seçeneğini seçiyorum.



Device options ekranında üç seçenek var. Configure Hybrid Microsoft Entra ID join, SCP'yi yazacak olan seçenektir. Diğer iki seçenek Device Writeback ile ilgilidir ve Entra ID'deki cihaz nesnelerinin On-Premises Active Directory'ye geri yazılmasını yönetir; bu makalenin konusu değil.



Device operating systems ekranında Windows 10 or later domain-joined devices seçeneğini işaretliyorum. Supported Windows downlevel domain-joined devices seçeneği Windows 8.1 ve Windows Server 2012 R2 gibi eski istemciler içindir; bu işletim sistemlerinde otomatik kayıt yoktur ve ayrı bir Workplace Join paketi gerekir. Bu senaryo artık desteklenmediği için işaretsiz bırakıyorum.



SCP configuration ekranı bu işin kalbidir. Burada SCP'nin yazılacağı Forest seçilir, Authentication Service olarak Managed ortam için Microsoft Entra ID veya Federated ortam için AD FS belirlenir ve Enterprise Admin kimlik bilgisi girilir. Wizard SCP'yi Configuration Partition'a yazdığı için bu yetki zorunludur. Enterprise Admin kimlik bilgisi elde yoksa aynı ekrandaki Download ConfigureSCP.ps1 düğmesiyle indirilen betik, Forest'ta yetkili biri tarafından ayrıca çalıştırılarak SCP oluşturulabilir.

Ekranın altındaki mavi bilgi kutusuna dikkat edin. Forest'ta zaten bir SCP varsa Wizard bunu tespit eder ve "detected that a forest has an existing SCP" bilgisini gösterir. Bu bir hata değildir; Wizard mevcut SCP ile devam eder ve aynı Tenant için aynı değerleri yazdığından nesne değişmez.



Wizard tamamlandığında iki şey yapmış olur. Birincisi, yukarıda verdiğim sabit adrese SCP nesnesini yazar ve keywords Attribute'unu azureADName ile azureADId değerleriyle doldurur. İkincisi, Domain Federated ise AD FS'e cihaz kaydı için gereken Claim kurallarını ekler; Managed ortamda bu ikinci adım yoktur. Bu işlem bir kez yapılır ve Client'lara hiçbir şey gönderilmez. Client'ların SCP'den haberdar olması bir sonraki bölümün konusu.

SCP'nin gerçekten yazıldığını iki yoldan doğrulayabiliriz. İlki PowerShell. Domain Controller'da veya RSAT Active Directory modülü yüklü bir makinede aşağıdaki komut, Configuration Partition'daki SCP nesnesini ve keywords değerlerini getirir.

Get-ADObject -SearchBase "CN=Configuration,DC=abc,DC=local" -Filter 'objectClass -eq "serviceConnectionPoint"' -Properties keywords | Where-Object { $_.DistinguishedName -like "*Device Registration Configuration*" } | Format-List DistinguishedName, keywords

Çıktıda DistinguishedName satırı sabit adresi, keywords satırı ise azureADName ve azureADId değerlerini gösteriyor. Buradaki azureADId, birazdan Client tarafında dsregcmd çıktısında göreceğimiz TenantId ile birebir aynı olmak zorunda.



İkinci yol ADSI Edit. adsiedit.msc'yi açıp Configuration Naming Context'ine bağlandığımda CN=Services altında CN=Device Registration Configuration Container'ını ve içinde GUID adlı SCP nesnesini görüyorum. Nesnenin Properties penceresinde Attribute Editor sekmesinden keywords satırını Edit ile açtığımda iki değer Multi-valued String Editor içinde listeleniyor. Orta panelde nesnenin Class sütununda serviceConnectionPoint yazması, bunun sıradan bir Container değil gerçek bir SCP olduğunu gösteriyor.



Sunucu tarafı burada bitiyor. Şimdi Client'a geçiyorum ve makinenin bu SCP'yi nasıl bulduğuna bakıyorum. Makine Domain'e katıldıktan sonra kullanıcı oturum açtığında, Windows'un kendi içinde gelen bir Scheduled Task SYSTEM hesabıyla çalışır. Bu görev, Task Scheduler Library altında Microsoft, Windows, Workplace Join yolundaki Automatic-Device-Join görevidir. Entra Connect tarafından eklenmez; Windows 10 ve üzeri her makinede kurulumdan itibaren vardır. Görevin açıklaması da amacını tek cümleyle özetler ve "Register this computer if the computer is already joined to an Active Directory domain" der.



Görevin Actions sekmesine baktığımda çalıştırdığı programın %SystemRoot%\System32\dsregcmd.exe olduğunu ve $(Arg0) $(Arg1) $(Arg2) parametrelerini aldığını görüyorum. Bu parametreler Event tabanlı tetiklemede Event'ten gelen değerlerdir; normal oturum açma tetiklemesinde boş gelir ve dsregcmd varsayılan otomatik kayıt kontrolünü yapar.



dsregcmd her çalıştığında sırayla üç soru sorar ve bir soruda elenen makine sonrakine geçmez. İlk soru "Domain'e üye miyim?" sorusudur; üye değilse Hybrid Join söz konusu olamaz ve dsregcmd hiçbir işlem yapmadan sonlanır. İkinci soru "Zaten kayıtlı mıyım?" sorusudur; kayıtlıysa yeniden kayıt gerekmez, dsregcmd durumu tazeler ve sonlanır. Üçüncü soru "SCP var mı?" sorusudur; yoksa dsregcmd sonlanır ve bir sonraki oturum açmada yine bakar, varsa Tenant bilgisini okur ve kaydı başlatır.

Bu akışın en önemli sonucu, Client'ın kaydolması gerektiğini bir yerden öğrenmemesidir. Her oturum açmada aynı soruyu sorar ve SCP'nin var olması cevabın kendisidir. Yönetici bir nesne yazar, Forest'taki bin makine onu okur.

Görevin son çalışma sonucunu Client'ta aşağıdaki komutla kontrol edebiliriz. LastTaskResult değerinin 0 olması görevin hatasız tamamlandığını gösterir.

Get-ScheduledTaskInfo -TaskPath "\Microsoft\Windows\Workplace Join\" -TaskName "Automatic-Device-Join"

dsregcmd Tenant bilgisini iki kaynaktan, belirli bir öncelik sırasıyla arar. İlk baktığı yer makinenin kendi Registry'sidir; HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD altındaki TenantId ve TenantName değerleri. Buna Client-side SCP denir ve varsa AD'deki SCP'yi ezer. Bu yöntem belirli OU'ları hedeflemek veya tek Forest'ı birden fazla Tenant'a bağlamak için kullanılır; standart kurulumda kullanılmaz. Registry anahtarı makinenin kendisinde olduğu için aşağıdaki komut Client'ta yönetici PowerShell ile çalıştırılır.

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD" -ErrorAction SilentlyContinue

SCP'nin Entra Connect ile AD'ye yazıldığı bir ortamda bu komutun boş dönmesi beklenen durumdur. Aşağıdaki çıktı da tam olarak bunu gösteriyor; makine Tenant bilgisini yalnızca AD'deki SCP'den okuyor.



Registry'de değer yoksa dsregcmd ikinci kaynağa geçer. Domain üyesi olduğu için zaten erişebildiği Domain Controller'a LDAP ile bağlanır ve sabit DN'deki SCP nesnesini okur; keywords Attribute'undan azureADId ve azureADName değerlerini alır. İki kaynak da boşsa kayıt hiç başlamaz ve dsregcmd /status çıktısındaki Tenant Details bölümünde TenantId dahil tüm alanlar boş kalır.

Tenant bilgisi elde edildikten sonra makine, azureADName değerini kullanarak Device Registration Service keşfi yapar. Gittiği adres https://enterpriseregistration.windows.net/ biçimindedir. DRS, Entra ID'nin cihaz kayıt servisidir; cihazın "ben buyum, beni kaydet" dediği karşı taraftır.

Keşif sonucunda dönen Metadata'da kayıt için JoinSrvUrl, anahtar işlemleri için KeySrvUrl ve Token işlemleri için AuthCodeUrl ile AccessTokenUrl uç noktaları bulunur. Keşif, SYSTEM Context'inde yapıldığı için ortamda Proxy varsa WinHTTP Proxy tanımlı olmalı ve SSL Inspection bu adresler için kapalı olmalıdır.

Keşfin sonucu Client'ta dsregcmd /status çıktısının Tenant Details bölümünde görülür. TenantId, SCP'deki azureADId ile aynı olmalıdır; farklıysa Registry'deki Client-side SCP devrededir. JoinSrvUrl, KeySrvUrl, AuthCodeUrl ve AccessTokenUrl doğrudan DRS keşfinin sonucudur. TenantName, MdmUrl, MdmTouUrl ve MdmComplianceUrl ise cihaz kaydına ait alanlar değildir; bunlar oturum açan kullanıcı PRT (Primary Refresh Token) aldıktan sonra dolar. Entra ID'ye senkronlanmamış bir hesapla, örneğin Domain Administrator ile bakıldığında bu alanlar boş görünür ve bu bir hata değildir. SettingsUrl ise her durumda boştur.


Tenant ve DRS bilindiğine göre sıra cihazın kendini kanıtlamasına geldi. Makine, DRS'e kimliğini ispat etmek için bir Key Pair ve Self-Signed sertifika üretir. Private Key, TPM varsa TPM içinde tutulur. Bu sertifika kayıt sürecinde geçici kimlik görevi görür; kayıt tamamlanınca DRS bunun yerine kendi imzaladığı cihaz sertifikasını verir.

Managed ortamda bu Self-Signed sertifikanın Public kısmı, Computer Object'in userCertificate Attribute'una yazılır ve Entra Connect tarafından Entra ID'ye senkronlanır. Federated ortamda bu yazma yapılmaz. Active Directory Users and Computers'ta PC01 nesnesinin Attribute Editor sekmesine baktığımda userCertificate Attribute içeriğinin dolu olduğunu görüyorum.

Edit ile açıldığında Octet String Attribute Editor içinde sertifikanın Hexadecimal içeriği listeleniyor.

Bu noktada kayıt akışı Domain tipine göre ikiye ayrılır ve hangi akışın izleneceğini azureADName'deki Domain'in Entra ID'de Managed mi yoksa Federated mı olduğu belirler. Managed ortamda userCertificate'e yazılan sertifika, Entra Connect'in bir sonraki Sync döngüsünde Computer Object ile birlikte Entra ID'ye taşınır ve orada Device Object oluşur.

Makine sonraki denemesinde DRS'e sertifikayla imzalı bir istek gönderir; Entra ID objectGUID ve SID eşleşmesini yapar ve kaydı tamamlar. Sync beklendiği için ilk kayıt genellikle bir sonraki oturum açmada tamamlanır. Bu arada cihaz Entra Admin Center'da görünür ama Registered sütununda "Pending" yazar; kayıt tamamlanınca bu ibare kalkar.

Federated ortamda ise makine AD FS'in WS-Trust windowstransport uç noktasından Kerberos ile Token alır, bu Token'ı DRS'e sunar ve Sync beklemeden anında kaydolur. AD FS'in objectGUID, primarySID, accountType ve issuerid Claim'lerini üretmesi gerekir; bu kurallar Wizard'ın SCP configuration adımında Entra Connect tarafından eklenir.

Kayıt tamamlandığında DRS'in verdiği cihaz sertifikası Client'ta Local Computer sertifika deposuna düşer. certlm.msc ile Personal > Certificates altına baktığımda Issued By sütununda MS-Organization-Access yazan sertifikayı görüyorum. Issued To değeri cihazın Entra ID Device ID bilgisidir ve geçerlilik süresi kayıt tarihinden itibaren on yıldır. Aynı depoda MS-Organization-P2P-Access sertifikası da bulunur; bu cihazlar arası kimlik doğrulama için kullanılan bir yıllık bir sertifikadır. Cihaz Intune'a kayıtlıysa Intune sertifikaları da burada listelenir, ancak bunların hiçbiri Hybrid Join sertifikası değildir.


Aynı sertifikayı PowerShell ile de çekebiliriz. Aşağıdaki komut Local Machine deposunda Issuer'ı MS-Organization-Access olan sertifikayı Subject, Issuer, NotAfter ve Thumbprint alanlarıyla listeler.

Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.Issuer -like "*MS-Organization-Access*" } | Format-List Subject, Issuer, NotAfter, Thumbprint

Bu sertifikanın dsregcmd tarafındaki karşılığı Device Details bölümüdür. DeviceId, sertifikanın Subject değeriyle; Thumbprint, PowerShell çıktısındaki Thumbprint ile birebir aynıdır. KeyProvider satırında Microsoft Platform Crypto Provider ve TpmProtected satırında YES görünmesi, Private Key'in TPM içinde tutulduğunu gösterir. DeviceAuthStatus değerinin SUCCESS olması ise cihazın bu sertifikayla Entra ID'ye kimlik doğrulayabildiğinin kanıtıdır.



Kaydın tamamlandığını görmek için dsregcmd /status çıktısının en üstündeki Device State bölümüne bakıyorum. AzureAdJoined ve DomainJoined satırlarının ikisi de YES ise makine Hybrid Join olmuştur. EnterpriseJoined satırının NO olması normaldir; bu alan Entra ID ile ilgisi olmayan On-Premises Device Registration Service senaryolarına aittir. Tenant Details bölümündeki TenantId değerinin de SCP'deki azureADId ile eşleştiğini bir kez daha teyit etmek, kaydın doğru Tenant'a yapıldığını garanti eder.


Son doğrulama Entra Admin Center'da. Devices altında All devices listesine baktığımda PC01 ve PC02 için Join type sütununda "Microsoft Entra hybrid joined", PC03 için ise "Microsoft Entra joined" yazıyor. Aynı Tenant'ta iki farklı kayıt türünün yan yana durması, SCP'nin yalnızca Domain'e üye makineleri ilgilendirdiğini de gösteriyor; PC03 hiçbir zaman SCP'ye bakmadı, çünkü Domain'e üye değil.



Cihaz kaydı burada tamamlanır. Kullanıcının Primary Refresh Token alması, Conditional Access ve Intune Enrollment cihaz kaydından ayrı süreçlerdir ve her biri kendi ön koşullarıyla ayrı bir yazının konusudur.

Bir sorunla karşılaştığınızda bakılacak yerler bellidir. dsregcmd /status çıktısının Device State, Device Details, Tenant Details ve Diagnostic Data bölümleri ilk adrestir. Event Viewer'da Applications and Services Logs altındaki Microsoft, Windows, User Device Registration, Admin günlüğü kayıt sürecindeki her adımı ve hatayı yazar. Görevi oturum kapatmadan yeniden tetiklemek isterseniz aşağıdaki komut aynı işi yapar.

Start-ScheduledTask -TaskPath "\Microsoft\Windows\Workplace Join\" -TaskName "Automatic-Device-Join"

Bütün bu akışı tek cümleye indirmek gerekirse, SCP Forest'ın hangi Tenant'a bağlı olduğunu söyleyen sabit adresli tek bir nesnedir; sunucu tarafında bir kez yazılır, Client tarafında her oturum açmada okunur ve makinenin kaydolma kararı yalnızca bu nesnenin var olup olmamasına bağlıdır. Kimin kaydolacağını belirleyen asıl filtre Group Policy değil, Entra Connect Sync Scope'udur. Bir Hybrid Join sorununu çözerken de bu sıra değişmez. Önce SCP var mı ve doğru Tenant'a mı işaret ediyor, sonra Computer Object Sync Scope'ta mı, en son da Client, SYSTEM Context'inden DRS'e ulaşabiliyor mu.

Faydalı olması dileğiyle...