Active Directory Domain Join Süreci ve Sistem Bileşenleriyle İlişkisi

Active Directory ortamına Domain Join işlemi başlatıldığında, işletim sistemi çekirdek servisleri üzerinden DNS tabanlı bir çözümleme akışı tetiklenir. Girilen Domain adı, Client tarafından yorumlanır ve bu bilgiye karşılık gelen DNS SRV (Service Record) sorguları otomatik olarak oluşturulur. Sürecin ilerleyebilmesi için DNS Query, SRV ve Host (A) kayıtları üzerinden yapılır ve bağlantı kurulacak uygun Domain Controller belirlenir. Bu aşamadan itibaren, Client tarafında sırasıyla Service Discovery, Authentication, Secure Channel Negotiation ve Group Policy Processing işlemleri devreye girer.

İşletim sistemi bu süreci belirli koşullara göre yönlendirir. Hangi API’nin çağrılacağı, hangi DLL’in devreye gireceği ve hangi bağlantı noktasının kullanılacağı, ortamdan alınan yanıtlara göre belirlenir. Her adım, işlem sırasını bir öncekinden aldığı bilgiler doğrultusunda şekillendirir. Domain Join süreci, işletim sistemi servislerinin birbirine bağlı ve eş zamanlı çalışmasıyla ilerleyen bir yapı ortaya çıkarır. İşlem tamamlandığında, Client bilgisayarın Domain üyeliği tanımlanır ve makine hesabı üzerinden sürdürülebilir bir ilişki başlatılır. Bu yapı, Kerberos Ticket işlemleri, Group Policy aktarımı ve Secure Channel devamlılığı için işletim sistemi tarafından temel güven bağı olarak kullanılır.

Bu makalemde, Domain Join sürecinin işletim sistemi tarafından hangi adımlarla yürütüldüğü, hangi bileşenlerin ne zaman devreye girdiği ve DNS tabanlı çözümleme akışının sistem içi servislerle nasıl ilişkilendiği adım adım incelenmektedir.

1. Domain Bilgisinin Girilmesi

Kullanıcı, bilgisayar adını değiştirmek veya bir Domain'e katılmak için System Properties penceresindeki Change... butonuna tıkladıktan sonra Computer Name/Domain Changes ekranına ulaşır. Bu ekranda Domain seçeneği işaretlenir ve hedef Domain adı, .local gibi bir Suffix ile birlikte girilir. Benim Active Directory Domain'im abc.local şeklindedir.



Bu alan, sistem tarafından bir Fully Qualified Domain Name (FQDN) olarak değerlendirilir. Windows işletim sistemi, bu bilgiyi temel alarak DNS üzerinden Domain Controller'ları tespit etmek amacıyla bir çözümleme süreci başlatır. Bu süreçte Netlogon servisi devreye girer ve DNS üzerinde _ldap._tcp.dc._msdcs.abc.local şeklindeki SRV kaydına yönelik bir DNS sorgusu üretir.

Mevcut bilgisayar Hostname bilgisi DESKTOP-OMCA19O iken, yeni Hostname olarak DMISTPC01 atanmakta ve WORKGROUP yapısından çıkılarak abc.local Domain’ine geçiş hazırlığı yapılmaktadır. Bu adım, tüm Domain Join sürecinin tetiklendiği ilk noktadır.

2. DNS Üzerinden SRV Kaydı Sorgusunun Başlatılması

DNS üzerinden yapılan SRV kayıt sorgusunu Client tarafında teknik olarak başlatan bileşen, Netlogon servisidir. Bu servis, Client Domain'e üye olduğunda Authentication (kimlik doğrulama) ve DC keşfi gibi işlemler için aktif hale gelir ve sistemin temel servisleriyle senkronize şekilde çalışır.

Ancak Domain'e henüz Join edilmemiş yani Workgroup durumunda çalışan makinelerde Netlogon servisi, varsayılan olarak pasif durumdadır. Services.msc üzerinden manuel olarak başlatılmak istendiğinde servis, bir anlığına çalışır gibi görünse de hemen ardından durur. Çünkü bu durumda servis, kullanıma gerek olmadığı sonucuna vararak otomatik olarak kapanır. Bu davranış bir hata değil, doğrudan tasarımsal bir tercih olarak işletim sistemine gömülüdür.




Domain Join işlemi başlatıldığında, Join işlemini başlatmak için kullanılan User Account’un Credential bilgisi, yani User Name (kullanıcı adı) ve Password (parola) bilgisi doğrulanır. Bu kimlik doğrulama sürecini yönetmek için işletim sistemi önce Security Support Provider Interface (SSPI) altyapısını devreye alır. SSPI, ortam koşullarına bağlı olarak Kerberos ya da NTLM protokolünü kullanır ve kullanıcı hesabının yetkilerini kontrol eder.

Kullanıcı hesabının kimlik doğrulaması başarıyla tamamlandığında Netlogon servisi otomatik olarak aktif hale gelir. Bu noktadan sonra herhangi bir manuel müdahale gerekmez. Süreç kendi içinde ilerleyerek Client’ın hangi Domain Controller ile iletişim kuracağını belirler. Bunun için Netlogon servisi içerisinden DsGetDcName() API’si çağrılır ve uygun Domain Controller seçimi için gerekli teknik süreç akışı başlar.





Sürecin ilk aşamasında Client, katılmak istediği Domain’e ait DNS SRV kaydını arar. Bu arama, uygun bir Domain Controller bulunabilmesi için başlatılır ve çözümleme işi, Client tarafında çalışan DNS Resolver modülü dnsapi.dll üzerinden yapılır. SRV sorgusu, DNS sunucusuna gönderildikten sonra alınan yanıt ile birlikte Domain Controller keşfi devam eder.

Normalde bu noktada işlem, arka planda sessiz şekilde yürür ve kullanıcı herhangi bir şey fark etmez. İstenirse bu akış daha yakından izlenebilir. Bunun için Domain Controller üzerinde Netlogon servisine ait Debug Log özelliği, CMD üzerinden nltest /dbflag:0x2080ffff komutu ile tetikleterek açmamız gereklidir.

Böylece hangi SRV kayıtlarının sorgulandığı DsGetDcName API çağrısının nasıl işlendiği ve sürecin hangi adımlardan geçtiği doğrudan kaydedilmiş olur. İzleme çıktıları, C:\Windows\debug\netlogon.log dosyasında tutulur ve burada SRV sorguları da dahil olmak üzere Domain Controller keşfi ile ilgili tüm detaylar görülebilir.

Bu Log kaydında, DNS üzerinden hangi SRV kaydının sorgulandığı, kaç Domain Controller bulunduğu ve hangi DC'nin seçildiği gibi detaylar yer alır. Yani bu API, DC keşif sürecinin merkezinde yer alan ve diğer alt sistemleri ihtiyaca göre zincirleme biçimde devreye sokan bir yönlendirici görevi üstlenir.

netlogon.log dosyasındaki bu satır, DMISTPC01 bilgisayarının Netlogon servisi tarafından, ABC NetBIOS isimli Domain için DC Locator sürecini tetiklemek üzere DsGetDcName() API fonksiyonunun çağrıldığını açıkça göstermektedir.

07/23 03:52:39 [MISC] [5348] ABC: DsGetDcName function called: Client PID=5920, Dom:ABC Acct:(null) Flags: DS RET_DNS

Fonksiyon çalıştırıldıktan sonra Log kayıtlarında yer alan ilgili satırlar, yapılan sorgu sonucunda hangi Domain Controller'ın seçildiğini ve bu DC'ye ait temel parametrelerin ne olduğunu açıkça gösterir. Bu veriler, DsGetDcName() API'sinin başarılı biçimde bir hedef DC belirlediğini ve bağlantı kurulabilecek adres, site bilgisi, IP adres türü gibi detayları sağladığını teknik olarak doğrular.

07/23 03:52:39 [MISC] [5348] DsGetDcName: results as follows: DCName:\\DMISTDCSRV01.abc.local DCAddress:\\10.10.10.100 DCAddrType:0x1 DomainName:abc.local DnsForestName:abc.local Flags:0xe003f3fd DcSiteName:Default-First-Site-Name ClientSiteName:Default-First-Site-Name



Buraya kadar aktarılan kısım, Domain Join işleminin kullanıcı tarafında nasıl göründüğünü ve arka planda hangi temel bileşenlerin devreye girdiğini özetleyen bir akış niteliğindedir. Görseller ve açıklamalar, sürecin adım adım nasıl ilerlediğini göstermek için kullanıldı. Ancak bu noktaya kadar olan bölüm, yalnızca sürecin normal işleyişini kavratmaya odaklanıyor. Bundan sonra ise işin daha derin teknik kısmına geçiyoruz.

Artık odak noktamız, DsGetDcName() API olacak. Bu API, Netlogon servisi aracılığıyla çağrılarak hangi Domain Controller’a bağlanılacağını belirleyen mekanizmanın merkezinde yer alıyor. Parametrelerin nasıl işlendiği, geri dönen yapıların ne anlama geldiği ve bellek yönetiminin nasıl yapılması gerektiği gibi ayrıntıları inceleyerek süreci en düşük seviyede anlamaya başlayacağım.

DsGetDcName() API Prototipi

DsGetDcName() fonksiyonu, Netlogon servisi üzerinden çağrılır ve Client’ın hangi Domain Controller’a bağlanacağını bulmak için kullanılır. Active Directory ortamında Domain Controller keşfi, bu API aracılığıyla yönetilir ve DNS tabanlı sorgularla desteklenir.

Fonksiyon çalıştırıldığında bazı parametreler alır. Bunlar ComputerName, DomainName, DomainGuid, SiteName, DomainGuid değeri ve Flags gibi girdilerdir. Bu parametreler, yapılacak DNS sorgusunun türünü ve kapsamını belirler. Yani fonksiyonun nasıl davranacağını ve hangi bilgileri talep edeceğini bu parametreler yönlendirir.

Fonksiyon başarıyla sonuçlandığında, uygun bir Domain Controller hakkında bilgi içeren Domain_CONTROLLER_INFO yapısını döndürür. Bu yapı içinde DC’nin adı, adresi, rolü ve sahip olduğu yetenekler yer alır.

DsGetDcName() fonksiyonu çalıştırıldığında, geri dönen Domain_CONTROLLER_INFO yapısı, dinamik olarak ayrılmış bir bellek alanında tutulur. Bu yapı, DC bilgilerini okuma işlemleri tamamlandıktan sonra artık kullanılmaz hale gelir. Ancak bu bellek alanı işletim sistemi tarafından otomatik olarak boşaltılmaz. Bu nedenle geliştiricinin mutlaka NetApiBufferFree() fonksiyonunu çağırarak ilgili alanı serbest bırakması gerekir. Bu adım atlanırsa bellek sızıntısı meydana gelir ve sistemin uzun vadeli kararlılığı olumsuz etkilenir.

Sonuç olarak DsGetDcName(), Domain Controller seçimi sürecinde kritik rol oynayan bir API’dir ve aldığı parametrelere göre farklı davranışlar gösterebilir.

DsGetDcName() Fonksiyon Çağrıları ve DLL Etkileşimi

DsGetDcName() tek başına tüm işi yapmaz; sadece Domain Controller keşfi sürecinin ana API’sidir. Çalışırken ihtiyaç duyduğu işlemleri, sistemdeki farklı DLL’lere devreder ve bu DLL’lerdeki hazır fonksiyonları çağırarak süreci tamamlar.

Burada kritik nokta, DLL’lerin işi yapan eller, parametrelerin ise bu ellere “ne yapacağını” söyleyen talimatlar olduğudur. Yani hangi Domain için sorgu yapılacağı, hangi Site'ın öncelikli olacağı veya hangi tür DC’nin aranacağı gibi kararlar, API’ye verilen parametrelerle belirlenir. DLL’ler ise bu talimatlara göre devreye girer.

Örneğin DNS sorgusu gerektiğinde Netlogon, kendi içinde bu işlemi çözmez. Bunun yerine, LPCWSTR DomainName parametresinde verilen bilgiye dayanarak dnsapi.dll içindeki DnsQuery() fonksiyonunu çağırır. Bu sayede DNS üzerinden doğru kayıtlar sorgulanır ve elde edilen sonuçlar Netlogon’un akışına geri aktarılır ki zaten makalemizin ana odak noktası da aslında tam olarak bu parametre ve bu DLL'in arasındaki etkileşim sürecinde yürütülen işlemlerdir.

Bu yapı, yazılım mimarisinde bir modülün başka bir modül içindeki hazır işlevleri dışarıdan çağırarak kullanması şeklinde tanımlanır ve Function Call olarak adlandırılır.

Aşağıdaki tablo, DsGetDcName() çağrısı sırasında devreye giren başlıca DLL bileşenlerini ve bu bileşenlerin işlevsel rollerine ilişkin detayları açıkmaktadır.

Süreç sırasında tüm DLL bileşenleri aynı anda ya da sabit bir sırayla devreye girmez. netlogon.dll, genel kontrol akışını yöneten çekirdek bileşendir. Ancak ihtiyaç doğduğunda diğer DLL’ler devreye alınır. Örneğin, DNS çözümlemesi gerektiğinde dnsapi.dll çağrılır, Secure Channel kurulumu yapılacaksa secur32.dll devreye girer. Ortam Kerberos tabanlı ise kimlik doğrulama görevleri kerberos.dll üzerinden yürütülür, eğer NTLM tercih edilirse bu görevler msv1_0.dll tarafından üstlenilir.

Her DLL yalnızca kendi işlevsel kapsamına giren durumlarda ve bağlam koşullarına göre aktif hale gelir. Bu modelin merkezinde bulunan DsGetDcName() API’si, sistemi doğrudan yöneten bir bileşen değildir; hangi işlevin, hangi koşulda devreye girmesi gerektiğini belirleyen bir denetim mekanizması gibi çalışır.

secur32.dll ve kerberos.dll ilişkisi

Bir kullanıcı oturum açmak istediğinde ya da bir bilgisayar Domain’e katılma sürecini başlattığında, kimlik doğrulama isteği doğrudan Kerberos veya NTLM protokolüne gönderilmez. Bu istek önce secur32.dll tarafından karşılanır. Bu bileşen, ortamın hangi kimlik doğrulama mekanizmasına uygun olduğunu belirleyen bir yönlendirici gibi çalışır.

İşletim sistemi, hangi protokolün kullanılacağını baştan bilmek zorunda değildir. secur32.dll, ortam yapılandırmasını ve mevcut koşulları kontrol eder; ardından en uygun mekanizmayı seçer. Eğer Kerberos tercih edilirse süreç kerberos.dll üzerinden bilet alışveriş adımlarıyla devam eder. NTLM tercih edilirse bu kez doğrulama akışı msv1_0.dll üzerinden yürütülür.

Bu yapı sayesinde karar verme süreci merkezi bir noktadan yönetilir ve yalnızca ihtiyaç duyulan servisler devreye girer. Karar aşaması tamamlandıktan sonra kontrol secur32.dll’den çıkar, seçilen protokolün ilgili DLL’i süreci devralır ve doğrulama işlemleri arka planda protokole uygun şekilde ilerler.

Bu teknik akış biraz soyut görünebilir. Şimdi, mantığı daha anlaşılır kılmak için bunu günlük hayatta geçen bir diyalog benzetmesiyle açıklayayım:

➔ Windows, ilk olarak gişe görevlisi gibi çalışan secur32.dll’e gider ve der ki:

“Beni Domain’e bağla. Hangi protokol uygunsa onu kullan.”

➔ secur32.dll bakar:

“Hmm… Bu ortamda Kerberos çalışıyor, seni oraya yönlendiriyorum.”

veya

“Kerberos uygun değil, NTLM ile devam edeceksin.”

➔ Eğer Kerberos uygunsa, kerberos.dll’i çağırır ve der ki:

“Şuna bir TGT bileti hazırla, AS-REQ (Authentication Service Request) sürecini başlat.”

➔ Eğer NTLM seçilmişse, kontrol msv1_0.dll’e geçer ve challenge/response akışı başlatılır.

Bu noktaya kadar aktarılan süreç, secur32.dll’in bir yönlendirici gibi davranarak hangi kimlik doğrulama mekanizmasının devreye gireceğini belirlediğini ortaya koymaktadır. Kerberos ya da NTLM, secur32.dll’in kararına göre çağrılır ve kendi özel DLL’leri üzerinden akışı sürdürür.

Bu yapı sayesinde sistem, gereksiz bileşenleri devreye almadan yalnızca ihtiyaç duyulan protokolleri çalıştırır. Böylece Windows kimlik doğrulama mimarisi hem performans hem de güvenlik açısından dengeli bir işleyiş sağlar.

DNS Query-1: SRV Kaydı Sorgulama

Client, Active Directory ortamında hangi Domain Controller’ların hizmet verdiğini tespit edebilmek için DNS sunucusuna bir SRV kaydı sorgusu gönderir. Bu sorgu, _ldap._tcp.dc._msdcs.abc.local hedefine yöneltilir ve UDP 53 Port'u üzerinden iletilir. Amaç, Domain'e hizmet veren DC'lerin kim olduğunu öğrenmektir. Bu SRV kaydı, yalnızca DC Locator amacıyla kullanılan _msdcs.abc.local DNS Zone'u altında yer alır. Domain Join gibi işlemlerde, hangi sunucuların Domain Controller olarak hizmet verdiğini belirlemek için referans noktasıdır.



DNS sunucusu bu isteğe karşılık olarak, Domain'e ait olan tüm DC’lerin FQDN bilgilerini, LDAP Port 389 numarası, Priority (öncelik) ve Weight (ağırlık) değerlerini içeren SRV kayıtlarıyla yanıt verir. Elde edilen bu veriler, Client tarafında değerlendirilerek hangi DC’ye bağlantı kurulacağına karar verilmesinde kullanılır.

Örnek SRV Kaydı Yanıtı

Bir Client, Domain Controller bilgilerini öğrenmek üzere DNS sunucusuna SRV kaydı sorgusu gönderdiğinde, sunucudan gelen yanıtta birden fazla kayıt yer alabilir. Her SRV kaydı, farklı bir DC'nin bilgilerini taşır ve sistem bu kayıtları değerlendirerek bağlantı kurulacak DC'yi seçer.

Yanıt içinde her kayıt; öncelik değeri Priority, ağırlık oranı Weight, LDAP Port 389 numarası ve hedef FQDN bilgisini içerir. Priority değeri en düşük olan kayda öncelik verilirken, aynı Priority seviyesindeki kayıtlar arasında Weight oranına göre dağılım yapılır. Bu yapı, ortamda birden fazla Domain Controller bulunduğunda yük dengelemesi ve yüksek erişilebilirlik sağlamak amacıyla kullanılır.

Aşağıda bu sorguya ait örnek bir yanıt yer alıyor.

SRV kaydı yanıtları, sistem tarafından belirli kurallara göre yorumlanır. Client, hangi DC’ye bağlanacağına karar verirken bu kuralları dikkate alır. Aşağıda örnekte yer alan kayıtların nasıl değerlendirildiğine birlikte bakalım.

✅ dc01 ve dc02 kayıtlarında Priority değeri aynı olup, 0 değeri taşırlar. Bu nedenle aralarında Load Balancing (yük dengeleme) yapılır. Weight değeri daha yüksek olan hedef, bağlanma açısından daha avantajlıdır.

✅ dc03 kaydı ise Priority değeri 10 olduğundan, sistem tarafından yedek bir hedef olarak değerlendirilir. Diğer kayıtlar başarısız olursa devreye alınır.

✅ Windows Client, SRV yanıtlarını aldıktan sonra önce Priority değerine göre, ardından aynı Priority değerine sahip kayıtlar arasında Weight değerine göre sıralama yapar. Bağlantı kurulacak DC bu sıralamaya göre seçilir.

Her ortamda burada verilen örnekteki gibi Priority (öncelik) ve Weight (ağırlık) değerlerinin farklı yapılandırılması zorunlu değildir. Birçok yapıda varsayılan olarak tüm Domain Controller'lar aynı Priority ve Weight değerleriyle tanımlanır ve yük dengeleme Client tarafından rastgele yapılır. Ancak özel bir gereksinimle, belirli DC'lere öncelik verilmesi ya da ağırlık farklarıyla trafik yönlendirmesi amaçlanıyorsa, bu değerler bilinçli olarak farklılaştırılabilir.

DNS Query-2: Host (A) Kaydı Sorgulama

SRV kayıtları üzerinden alınan FQDN’ler, sistemin hangi Domain Controller’a yönleneceğini belirlemesini sağlar. Ancak bir FQDN yalnızca isim bilgisidir; bağlantının gerçekten kurulabilmesi için bu ismin hangi IP adresine karşılık geldiğinin bilinmesi gerekir. Bu amaçla DNS sunucusuna doğrudan bir A kaydı sorgusu gönderilir.

SRV kaydı sorgusu sonucunda istemci sistem, Domain Controller'ın FQDN bilgisine örneğin dc01.abc.local şeklinde ulaşır. Ancak bu bilgi, bağlantı kurulabilmesi için yeterli değildir çünkü LDAP gibi dizin servisleri doğrudan IP adresi üzerinden iletişim kurar. Bu nedenle Client, dc01.abc.local adresinin hangi IP’ye karşılık geldiğini belirlemek amacıyla DNS sunucusuna bir Host (A) kaydı sorgusu gönderir. Bu sorgu, Client'ın DNS çözümleme bileşeni tarafından başlatılır ve verilen FQDN'e ait IPv4 ya da varsa IPv6 adresi geri döndürülür.

Geri dönen IP adresi, istemcinin fiziksel olarak bağlantı kuracağı Domain Controller hedefini belirler. Bu adrese TCP 389 üzerinden LDAP oturumu açılarak dizin servislerine erişim sağlanır. Bu bağlantı üzerinden bilgisayar nesnesi oluşturma, kimlik doğrulama oturumu açma, Group Policy verilerinin alınması gibi işlemler gerçekleştirilir. A kaydının çözülmesi, Domain Join sürecinin başarıyla tamamlanabilmesi için zorunlu bir adımdır.

Bu noktada dikkat edilmesi gereken kritik bir detay vardır:

✅ Sistem, Forward Lookup Zone altında yer alan tüm Host (A) kayıtlarını taramaz.

✅ Sadece _ldap._tcp.dc._msdcs.abc.local SRV sorgusuna karşılık dönen DC FQDN’leri için Host (A) kaydı sorgusu yapar.

Bu yapı sayesinde işlem, gereksiz sorgulardan arındırılmış şekilde yalnızca hedef Domain Controller’lara odaklanarak ilerler.

Bu süreci daha somut görmek açısından örnek bir DNS çözümleme akışı şu şekilde ilerler: Client, _ldap._tcp.dc._msdcs.abc.local adresine bir SRV sorgusu gönderir. Bu sorguya DNS sunucusundan gelen yanıtta, Domain Controller’lara ait FQDN bilgileri yer alır.

Bu yanıtı aldıktan sonra sistem, yalnızca belirli DC'ler için A kaydı sorgusu başlatır. Örneğin:

dc03 için sorgu yapılmazsa, bu FQDN daha düşük öncelikli olarak değerlendirilmiş ya da bağlantı tercihi dışında kalmış olabilir. Bu seçicilik, gereksiz DNS sorgularının önüne geçilmesi ve bilgi sızıntısı riskinin azaltılması açısından önemlidir. Tüm A kayıtlarını sorgulamak yerine yalnızca SRV yanıtı içindeki hedefler çözülür ve bu da süreci hem verimli hem güvenli hale getirir.

Client, SRV ve A DNS kayıtlarını çözüp Domain Controller’ın IP adresini öğrendikten sonra artık gerçek bağlantı aşamasına geçer. Bu noktada isim çözümleme tamamlanmış kabul edilir ve iletişim, ilgili protokoller ve Port'lar üzerinden sürdürülür. İşletim sistemi, Domain Join sürecinde gerekli servisleri sırasıyla devreye alır; bu sıra, ortamdan gelen yanıtlar ve o anki gereksinimlere göre şekillenir.

Bu makalede, bir Client'ın Active Directory ortamına Domain Join sürecinde izlediği teknik adımlar tüm bileşenleriyle birlikte ele alındı. İşlem başlatıldığında arka planda devreye giren NetLogon servisi, DsGetDcName API çağrısı üzerinden DNS yapılarına ulaşarak _ldap._tcp.dc._msdcs.DomainName formatındaki SRV kayıtlarını sorguluyor. Bu kayıtlar sayesinde hangi Domain Controller ile haberleşileceği belirleniyor ve Client, kendi Site bilgisine en yakın DC üzerinden süreci sürdürüyor. DNS katmanındaki bu çözümleme tamamlandığında, LSASS üzerinden Secure Channel kurulumuna zemin hazırlayan makine hesabı oluşturuluyor.

Client, hedef Domain Controller ile LDAP kanalından iletişime geçerek kendini tanıtıyor ve makine hesabı için gerekli metadata ile birlikte DNSHostname ve ServicePrincipalName gibi değerleri yazdırıyor. Bu sırada hem Kerberos hem de NTLM protokollerinin uygun olduğu senaryolarda kimlik doğrulama tamamlanıyor ve net bir güven ilişkisi kuruluyor. Sürecin sonunda, Client artık Domain içindeki kaynaklarla konuşabilecek, Group Policy nesnelerini işleyebilecek ve DC ile sürekli bağlantıda kalacak şekilde yapılandırılmış hale geliyor.

Her adımda rol alan servisler, kullanılan API'ler, DNS kayıt türleri ve protokol seviyesindeki geçişler düşünüldüğünde, Domain Join işleminin basit bir üyelik eyleminden çok daha fazlası olduğu net biçimde ortaya çıkıyor. Arka plandaki bu teknik kurgu anlaşılmadan, adım adım ilerleyen sürecin neden zaman zaman başarısız olabileceğini ya da hangi detayların Log'lar üzerinden izlenebileceğini doğru yorumlamak mümkün olmuyor. Yapının bütünlüğü ancak bu derinliğe inilerek gerçekten kavranabiliyor.

Faydalı olması dileğiyle...