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 üzerinden Domain adını yazar, yetkili bir hesap girersiniz, makine yeniden başlar ve işlem tamamlanır. 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 Authentication (kimlik doğrulama) süreci başlar. Buraya kadar sürpriz yok.

Şimdi aynı makinenin bir de Microsoft Entra ID Tenant'ına kaydolması gerekiyor. Buna Entra ID Hybrid Join diyoruz; makine hem On-Premises Domain'in üyesi olmaya devam ediyor hem de Entra ID'de bir cihaz kimliği kazanıyor. Bu kimlik sayesinde kullanıcı PRT (Primary Refresh Token) alabiliyor, Conditional Access "bu cihaz bizim mi" sorusunu sorabiliyor ve Intune gibi bulut yönetim araçları cihazı tanıyabiliyor. İş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 Configuration Partition içinde duran tek bir nesnede saklıdır. Bu nesnenin adı Service Connection Point olup, kısaca SCP olarak anılı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 Entra Connect Sync ile nasıl oluşturulduğuna, ne olduğuna ve nasıl doğrulandığına bakacağız. Ardından Client tarafına geçip Windows'un içine gömülü olan Scheduled Task'in SCP'yi 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'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; departman OU'larının bulunduğu üst OU ise kısmi seçili durumda, yani altındaki OU'ların yalnızca bir kısmı Scope'a alınmış. 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 sürüm Windows işletim sistemleri 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 butonu ile indirilen Script, 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, Configuration Partition'daki 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.

Peki Wizard'ın yazdığı bu nesne tam olarak ne? 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-Coded 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'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 komutu ile ADSI.Edit'i açıp, Configuration Naming Context'e bağlandığımda CN=Services altında CN=Device Registration Configuration Container ve içinde CN=62a0ff2e-97b9-4513-943f-0d221bd30080 GUID isimli 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 yazım, Task Scheduler'ın kendi mekanizmasıdır.

Bir Scheduled Task'in tetikleyicisi yalnızca oturum açma olmak zorunda değildir; Event Viewer'daki bir Event Log'a belirli bir Event ID düştüğünde de görev çalışabilir. Böyle bir Event tetiklemesinde Task Scheduler, o Event'in XML içeriğinden XPath ile seçilen alanları Arg0, Arg1, Arg2 değişkenlerine aktarır ve komut satırına parametre olarak geçirir.

Automatic-Device-Join görevinin Triggers sütununda "Multiple triggers defined" yazmasının sebebi de budur; görev hem oturum açmada hem de Device Registration ile ilgili belirli Event'ler oluştuğunda çalışır. Normal oturum açma tetiklemesinde ortada bir Event olmadığı için bu değişkenler boş kalır ve dsregcmd parametresiz çalışıp varsayılan otomatik kayıt kontrolünü yapar. Yani günlük akışta gördüğümüz Hybrid Join, aslında parametresiz bir dsregcmd çağrısından ibarettir.



dsregcmd, parametresiz çalıştığında bir dizi ön kontrol yapar ve bu kontroller sıralıdır; bir kontrolde takılan makine sonrakine geçmez.

1. Domain üyeliği kontrolü. dsregcmd bunu Domain Controller'a sormaz, Windows'un yerel olarak tuttuğu Domain bilgisinden okur. Makine bir Domain'in üyesi değilse Hybrid Join zaten anlamsızdır ve dsregcmd hiçbir işlem yapmadan sonlanır.
2. Mevcut kayıt durumu kontrolü. Makine daha önce Entra ID'ye kaydolmuşsa yeniden kayıt gerekmez; dsregcmd yalnızca durumu tazeler ve sonlanır.
3. SCP araması. Birazdan ayrıntısına gireceğim bu adımda dsregcmd Tenant bilgisini arar. SCP bulunamazsa yine sonlanır ve bir sonraki oturum açmada aynı kontrolleri baştan yapar; SCP bulunursa içindeki Tenant bilgisini okur ve kayıt sürecini başlatır.

Bu akışın en önemli sonucu, Client'ın kaydolması gerektiğini hiçbir yerden öğrenmemesidir. Ona bir bildirim gelmez, bir Group Policy "kaydol" demez, Entra Connect ona bir şey göndermez. Her oturum açmada aynı kontrolleri yapar ve SCP'nin var olması cevabın kendisidir. Yönetici Forest'a bir nesne yazar, o Forest'taki bin makine her oturum açmada gidip o nesneyi okur.

Bu akışın en önemli sonucu, Client'ın kaydolması gerektiğini hiçbir yerden öğrenmemesidir. Ona bir bildirim gelmez, bir Group Policy "kaydol" demez, Entra Connect ona bir şey göndermez. Her oturum açmada aynı kontrolleri yapar ve SCP'nin var olması cevabın kendisidir. Yönetici Forest'a bir nesne yazar, o Forest'taki bin makine her oturum açmada gidip o nesneyi okur.

Görevin gerçekten çalışıp çalışmadığını Client'ta aşağıdaki komutla kontrol edebiliriz. Çıktıdaki LastRunTime görevin en son ne zaman tetiklendiğini, LastTaskResult ise sonucunu gösterir. LastTaskResult değerinin 0 olması dsregcmd'nin hatasız tamamlandığı anlamına gelir; ancak bu, kaydın tamamlandığı anlamına gelmez. SCP bulunamadığı için hiçbir işlem yapmadan sonlanan bir dsregcmd de 0 döner. Kaydın gerçekten olup olmadığını dsregcmd /status çıktısından okuyacağız.

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

Peki dsregcmd o SCP'yi nerede arıyor? Aslında tek bir yerde değil, iki kaynağa belirli bir öncelik sırasıyla bakıyor. İlk durağı Active Directory değil, makinenin kendi Registry'si. Windows önce aşağıdaki anahtarın altında TenantId ve TenantName değerlerinin tanımlı olup olmadığını kontrol eder; bir değer bulursa Active Directory'ye hiç sormadan onu kullanır.

Buna Configure client-side registry setting for 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, PowerShell üzerinde Run as administrator 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/ altında azureADName ile oluşturulan yoldur. 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 ayar 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 dört sertifika görüyorum. Hybrid Join'i temsil eden, Issued By sütununda MS-Organization-Access yazan satırdır; diğer üçü aynı depoda duruyor ama farklı ilişkileri temsil ediyor. Her birinin ne olduğunu ayrı ayrı açıklamakta fayda var.

» MS-Organization-Access, cihazın Entra ID kimliğidir. Hybrid Join tamamlandığında DRS tarafından verilir. Issued To değeri cihazın Entra ID Device ID bilgisidir ve geçerlilik süresi kayıt tarihinden itibaren on yıldır. Cihaz Entra ID'ye kendini kanıtlarken, kullanıcı PRT alırken ve Conditional Access cihaz kontrolü yaparken bu sertifika kullanılır. Bu sertifika yoksa cihaz Entra ID'de kayıtlı değildir.

» MS-Organization-P2P-Access, cihazlar arası kimlik doğrulama sertifikasıdır. Aynı Tenant'a kayıtlı iki cihaz, örneğin Remote Desktop bağlantısında, birbirini bu sertifikayla doğrular. Hybrid Join'in bir yan ürünüdür, kaydın kendisi değildir. Bir yıl geçerlidir ve kendiliğinden yenilenir.

Microsoft Intune MDM Device CA, cihazın Intune kimliğidir. Cihaz Intune'a Enroll olduğunda verilir ve MDM Check-in sırasında cihaz kendini bu sertifikayla tanıtır. Hybrid Join ile ilgisi yoktur; cihaz Intune'a kayıtlı olmasaydı bu satır olmazdı.

» Microsoft Intune Device Management Device CA, Intune'un ikinci cihaz sertifikasıdır ve Intune'un cihaz yönetimi kanalı için kullanılır. Bu da MDM Enrollment'ın ürünüdür; Entra ID kaydıyla ilgisi yoktur.

Bu dört satır, tek bir makinenin üç farklı ilişkisini gösteriyor. Cihaz ile Entra ID arasındaki ilişki MS-Organization-Access ile, cihaz ile diğer cihazlar arasındaki ilişki P2P sertifikasıyla, cihaz ile Intune arasındaki ilişki ise iki Intune CA sertifikasıyla temsil edilir. Hybrid Join yalnızca birincisini oluşturur; Intune sertifikaları ancak Entra ID kaydı tamamlandıktan sonra, ayrı bir Enrollment süreciyle gelir.



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...