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 etki alanı olan abc.local ifadesi girilir.



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 makine bir Domain'e üye olduğunda 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 kendini kullanıma gerek olmadığına kanaat getirerek 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.

Netlogon servisi aktif olmadığında, DNS üzerinden SRV sorgusunun başlatılması mümkün değildir. Çünkü bu sorguyu tetikleyen işlem zinciri, ancak Domain Join süreci başlatılıp kimlik doğrulama bilgileri sisteme ulaştığında devreye girer. Workgroup modundaki makinelerde böyle bir tetikleyici unsur bulunmadığından, DNS tarafında SRV kaydı sorgulaması da gerçekleşmez.





Domain Join işlemi, kullanıcıdan alınan Credential (kullanıcı adı ve parola) bilgisi ile başlatıldığında, bu bilgilerin sistem tarafından işlenebilmesi için belirli servislerin aktif hale gelmesi gerekir. Bu noktada Netlogon servisi, süreci devam ettirecek olan ilk bileşen olarak devreye girer. İşletim sistemi bu servisi, doğrulanmış kimlik bilgileri alındığında otomatik şekilde çalıştırır. Netlogon servisinin aktifleşmesi, sistemin DNS üzerinden Domain Controller arayışına geçebilmesi ve çözümleme sürecini başlatabilmesi için zorunlu bir adımdır. Bu aşama tamamlandığında, iç servisler bir sonraki işleme geçmek üzere hazır hale gelir.

Administrator yetkisine sahip bir kullanıcı adı ve parola girilerek kimlik doğrulaması başarıyla tamamlandığında, Workgroup durumundaki bilgisayarda Netlogon servisi, kullanıcı müdahalesi olmaksızın işletim sistemi tarafından otomatik olarak başlatılır ve servis durumu Running konumuna getirilir. Bu servis, Control Panel (denetim masası) üzerinden veya Services.msc arayüzünden manuel olarak başlatılamaz; kontrol doğrudan Service Control Manager (SCM) tarafından gerçekleştirilir.

Administrator yetkisine sahip bir Credential (kullanıcı adı ve parola) bilgisi girilerek Authentication (kimlik doğrulaması) işlemi başarıyla tamamlanıp, Netlogon servisi aktif hale geldiğinde, servis içindeki DsGetDcName() API bileşeni programatik olarak çağrılır. Bu API (Application Programming Interface), istemcinin ait olduğu Domain ortamında hangi Domain Controller’ların hizmet verdiğini bulmak amacıyla DC Locator sürecini tetikler.



Netlogon servisinin devreye girmesiyle birlikte sistem, DNS temelli Domain Controller keşif sürecine geçer. Aynı zamanda, ilerleyen adımlarda kullanılacak olan Secure Channel (güvenli kanal) kurulumunun altyapısı da bu servis aracılığıyla hazırlanır. Netlogon servisi, Domain Join işlemindeki DNS SRV sorgularının başlatılmasını, DsGetDcName() gibi API (Application Programming Interface) çağrılarının yönlendirilmesini ve sonraki doğrulama işlemleri için gerekli sistem bileşenlerinin aktifleşmesini sağlar. Bu nedenle Domain üyeliği sürecinde Netlogon’un zamanında ve otomatik olarak aktif hale gelmesi hayati önem taşır.



Sürecin ilk adımı olarak, ilgili Domain adına karşılık gelen SRV DNS sorgusu üretilir ve bu sorgu, çözümleme için sistemin DNS istemcisi bileşeni olan dnsapi.dll aracılığıyla DNS sunucusuna iletilir. Bu işlem, sistem düzeyinde sessizce gerçekleşir ancak istenirse Netlogon servisinin Debug Log mekanizması aktif hale getirilerek, C:\Windows\debug\netlogon.log dosyası üzerinden DsGetDcName() fonksiyon çağrısı ve üretilen SRV kayıtları doğrudan gözlemlenebilir.



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

Sonrasında gelen satırlarda bu da fonksiyonun sonucu olarak hangi Domain Controller bulunduğunu verir.

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

DsGetDcName() API Prototipi

DsGetDcName() fonksiyonu, Netlogon servisi aracılığıyla çağrılır ve istemcinin hangi Domain Controller'a bağlanması gerektiğini belirlemek için kullanılır. Bu API, Active Directory ortamında DC bulma işlemini yönetir ve DNS tabanlı sorgularla desteklenir.

Fonksiyon, çağrıldığı anda belirli parametreler alır. Bu parametreler; ComputerName, DomainName, DomainGuid, SiteName, DomainGuid değeri ve Flags (davranış bayrakları) gibi girdilerden oluşur. Her parametre, DNS sorgusunun türünü, kapsamını ve yanıt beklentisini etkileyerek DsGetDcName() fonksiyonunun nasıl çalışacağını belirler.

Fonksiyon başarılı bir şekilde çalıştığında, uygun bir Domain Controller hakkında bilgileri içeren DOMAIN_CONTROLLER_INFO yapısına işaret eden bir Pointer döner. Bu yapı; DC'nin adı, adresi, rolü ve yetenekleri gibi detayları barındırır.

Elde edilen Pointer, heap üzerinde ayrılmış belleğe karşılık gelir ve işlem tamamlandıktan sonra NetApiBufferFree() fonksiyonu kullanılarak serbest bırakılmalıdır. Bu, kaynak sızıntısını önlemek ve sistem kararlılığını korumak açısından kritik bir adımdır.

Aşağıda, DsGetDcName() API'sinin aldığı parametrelerin işlevsel açıklamaları yer almaktadır. Her bir parametre, Domain Controller seçimi sürecinde fonksiyonun davranışını doğrudan etkileyen kritik girdilerdir.

Çağrı (Function Call) zincirinde devreye giren DLL’ler

Buradaki çağrı ifadesi, Netlogon servisinin sistem içinde yer alan farklı DLL dosyalarında tanımlı fonksiyonları programatik olarak tetiklemesi anlamına gelir. Netlogon servisi, bu işlemleri kendi içinde doğrudan yürütmez. İhtiyaç duyulan görevler, ilgili DLL içindeki özel işlevlere belirli parametrelerle iletilir ve ilgili fonksiyonlar çalıştırılır. Bu yapı, bir modülün başka bir modüle ait işlevleri dışarıdan çağırarak kullanması esasına dayanır ve yazılım geliştirmede Function Call olarak tanımlanır.

Örneğin, bir DNS Query işlemi gerektiğinde Netlogon servisi, bu işlemi kendi içinde gerçekleştirmez. Bunun yerine, API içindeki dnsapi.dll içerisinde yer alan DnsQuery() gibi bir fonksiyonu çağırarak çözümleme işlemini ilgili DLL aracılığıyla başlatır.



dnsapi.dll içinde DnsQuery_A, DnsQuery_W ve DnsQuery_UTF8 olmak üzere aynı işlevi gerçekleştiren fakat farklı karakter setleriyle çalışan üç ayrı DnsQuery() fonksiyonu yer alır. Bu fonksiyonlardan yalnızca biri çağrılır; hangisinin kullanılacağı, çağıran uygulamanın karakter setine bağlıdır.

Modern Windows sistemlerde Unicode uyumlu DnsQuery_W daha yaygın biçimde kullanılırken, Unicode-aware applications (Unicode'u tanıyan ve doğru işleyebilen uygulamalar) için DnsQuery_UTF8 tercih edilir. ANSI karakter setiyle çalışan eski uygulamalarda ise DnsQuery_A devreye girer.

Netlogon gibi servisler, DNS çözümleme işlemlerini doğrudan gerçekleştirmez. Bunun yerine, ilgili ihtiyaca göre dnsapi.dll içindeki uygun DnsQuery() fonksiyonunu çağırarak çözümleme sürecini başlatır. DLL, bu işlevleri dışa açık hale getirerek, sistemdeki farklı bileşenlerin ortak ve yeniden kullanılabilir bir DNS Query altyapısı üzerinden işlem yapmasına imkan tanır.

DsGetDcName() API Çağrısı

DsGetDcName() fonksiyonu çağrıldığında, sistem bu işlevi yerine getirebilmek için çeşitli dinamik bileşenleri işlem sırasına bağlı olarak devreye alır. Her bileşen belirli bir görevi yürütmek üzere çağrılır ve bu görevler sistemin o anki ihtiyaçlarına göre şekillenir. Fonksiyon, Domain Controller arama sürecini başlatmakla kalmaz, DNS çözümlemesi, kimlik doğrulama ve bağlantı kurulumu gibi süreçleri yönlendirecek servis çağrılarını da tetikler.

DsGetDcName() API'si çağrıldığında aşağıdaki sistem bileşenleri, koşullu biçimde sırasıyla devreye girer. Bu bileşenler sabit bir sırayla çalışmaz. Hangi DLL'in çağrılacağı, işlem bağlamında ortaya çıkan gereksinimlere göre belirlenir. Her DLL yalnızca kendi görev alanına giren işlev gerçekleştiğinde aktif hale gelir. Bu yapı, fonksiyonun tek bir işlem yürütmediğini, farklı sistem katmanlarında eşzamanlı etkileşim başlattığını gösterir. 

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

secur32.dll ve kerberos.dll ilişkisi

Bir kullanıcı sisteme giriş yapmak istediğinde ya da bir bilgisayar Domain'e katılma sürecini başlattığında, kimlik doğrulama işlemleri doğrudan protokole yönlendirilmez. Bunun yerine, sistem bu isteği önce secur32.dll üzerinden karşılar. Bu bileşen, ortamın hangi kimlik doğrulama mekanizmasına uygun olduğunu belirlemekle sorumludur.

İşletim sistemi, tercih edilecek protokolü doğrudan bilmek zorunda değildir. secur32.dll, ortam yapılandırmasını kontrol eder ve Kerberos, NTLM gibi hangi protokol uygun görünüyorsa işlemi oraya yönlendirir. Her şey, merkezi bir karar yapısı üzerinden yürütülür ve ihtiyaç duyulan servisler yalnızca gereksinim ortaya çıktığında devreye alınır.

Bu karar süreci tamamlandığında, artık kontrol secur32.dll'den çıkar ve belirlenen doğrulama protokolüne geçiş yapılır. Bundan sonra gerçekleşen adımlar, sistemin belirlediği protokole uygun şekilde arka planda ilerlemeye başlar.

➜ Windows, ilk olarak gişe görevlisi olan secur32.dll'ye 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.”

➜ Arkaya döner, kerberos.dll’yi çağırır ve der ki:

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

Süreç sırasında tüm DLL’ler, eş zamanlı veya sabit bir sırayla devreye girmez. netlogon.dll, genel kontrol akışını yönetir. Eğer DNS çözümlemesi gerekiyorsa dnsapi.dll çağrılır, Secure Channel kurulumu söz konusuysa secur32.dll devreye girer, ortam Kerberos yapılandırmasına sahipse kerberos.dll kullanılır.

Her DLL, yalnızca kendi işlevsel kapsamına giren durumlarda ve bağlam koşullarına göre aktif hale gelir. Bu işlem modeli içinde DsGetDcName() API bileşeni, sistemi doğrudan yöneten bir bileşen değil, koşula bağlı olarak kaynakları devreye alan bir denetim mekanizması gibi çalışır.

Bu DLL dosyalarının tamamı C:\Windows\System32 dizini altında yer alır.

DNS Query 1 – _ldap._tcp.dc._msdcs.abc.local

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’ye 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: – DC FQDN'i için 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.

Örneğin sistem, SRV yanıtı sonucu dc01.abc.local bilgisini aldıysa, bu FQDN’e ait IP adresini öğrenmek için DNS sunucusuna bir A kaydı sorgusu gönderir. Yani dc01.abc.local → hangi IP? sorusu, aslında bağlantı öncesinde zorunlu olarak yanıtlanması gereken bir adımdır. DNS sunucusunun verdiği IP adresi, LDAP oturumunun kurulacağı fiziksel hedefi belirler.

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

4. IP Bilgisi Alındıktan Sonra Bağlantılar Başlatılır

Client, SRV ve A sorgularından sonra Domain Controller’ın IP bilgisini elde ettiğinde artık gerçek bağlantı aşamasına geçer. Bu noktada isim çözümleme tamamlanmış kabul edilir ve iletişim protokolleri Port düzeyinde açılmaya başlar. İşletim sistemi, Domain Join akışında ihtiyaç duyulan servisleri sırasıyla devreye alır; sıralama ortamın yanıtlarına ve gereksinimlere göre şekillenir.

Kimlik doğrulama için Kerberos trafiği Port 88 üzerinden başlatılabilir. Directory erişimi ve bilgisayar nesnesi işlemleri için LDAP bağlantısı TCP 389 üzerinde kurulurken, makine hesabı ilişkisi ve Group Policy içeriği gibi veri aktarımı gerektiren adımlar Netlogon işlevleriyle birlikte SMB üzerinden TCP 445 kanalını kullanır. Bazı yapılandırmalarda ek yapılandırma ve kayıt işlemleri için RPC uç noktaları TCP 135 üzerinden devreye girer. Aşağıdaki tabloda bu bağlantıların temel işlevleri özetlenmiştir.

5. Domain Join İşlemi Sonrası Gerçekleşen Adımlar

Domain Join işleminden sonra sistemde belirli servisler ve yapılandırmalar otomatik olarak çalışmaya başlar. Group Policy verileri çekilir, bilgisayar hesabı Active Directory üzerinde oluşturulur ve bu hesaba ait parola sistemin Registry yapısında güvenli biçimde saklanır. Secure Channel, bu parola üzerinden tanımlanır ve servisler aracılığıyla belirli aralıklarla otomatik olarak güncellenir. Tüm bu işlemler, bilgisayarın etki alanına entegre şekilde çalışabilmesi ve yönetilebilir durumda kalabilmesi için zorunlu adımlardır.

Bu noktadan itibaren Client, artık Active Directory yapısının bir parçası haline gelir. İşletim sistemi, kimlik doğrulama mekanizmalarını, politika uygulamalarını ve güvenli iletişim kanallarını bu yapıya göre yönlendirir. Domain üyeliğiyle birlikte işletim sistemi, güvenlik bileşenleriyle senkron çalışmaya başlar; dizin hizmetleriyle kurduğu iletişim aktif hale gelir ve sistem davranışları bu bütünleşik yapıya göre şekillenir. Devamında, bu etkileşimlerin teknik arka planını ben adım adım ortaya koyacağım.

⚡ 5.1- AD’de Computer Object Oluşturulması

Domain Join işlemi sırasında Client, TCP 389 Port'u üzerinden Active Directory Domain Services (AD DS) ile bir LDAP (Lightweight Directory Access Protocol) bağlantısı kurar. Bu bağlantı, Client bilgisayarının kendini dizine kaydedebilmesi için gerekli olan nesne oluşturma işlemini başlatır.

Client sistem, bu süreçte bir LDAP AddRequest işlemi gerçekleştirir. Bu istek, objectClass=computer özelliğine sahip bir nesnenin dizine eklenmesini talep eder. Oluşturulan bu Computer Object, varsayılan olarak CN=Computers,DC=abc,DC=local konumuna yazılır; ancak Client, Prestaging ile önceden belirlenmiş farklı bir OU’ya da yönlendirilebilir.



Active Directory altyapısında Domain'e katılan her yeni Client bilgisayar, eğer özel bir yönlendirme yapılmamışsa varsayılan olarak CN=Computers adlı Container altında oluşturulur. Ancak bu yapı, sistem yönetimi açısından ciddi sınırlamalara sahiptir çünkü Container nesneleri üzerinde doğrudan Group Policy Object (GPO) uygulanamaz. GPO bağlantıları yalnızca Organizational Unit (OU) yapıları üzerinden gerçekleştirilir. Bu nedenle, varsayılan Container'da kalan bilgisayar nesneleri, organizasyonun tanımladığı politika kurallarından tamamen yoksun kalır.

Bu durum; güvenlik ayarlarının uygulanmaması, istemcilerin denetim dışı kalması, yazılım dağıtımı ve otomasyonların çalışmaması gibi sonuçlara yol açar. Dolayısıyla, CN=Computers yapısında bulunan tüm bilgisayar nesneleri, ilk fırsatta uygun OU hiyerarşisine taşınmalı ve sistemsel denetim altına alınmalıdır. Taşıma işlemi, manuel olarak yapılabileceği gibi PowerShell komutları veya otomatikleştirilmiş kurumsal süreçlerle de gerçekleştirilebilir. Amaç, her istemci bilgisayarın ilgili GPO kapsamına alınarak merkezi olarak yönetilebilir hale getirilmesidir. Bu, hem güvenlik hem de yapılandırma bütünlüğü açısından zorunlu bir uygulamadır.



Bu nesne, Active Directory üzerinde benzersiz bir sAMAccountName, distinguishedName, objectGUID ve bir dizi kimlik doğrulama ve yetkilendirme için gerekli Attribute’larla birlikte oluşturulur. İşlem sırasında dNSHostName, servicePrincipalName, userAccountControl, operatingSystem gibi öznitelikler de atanır.

Nesne oluşturma tamamlandığında, bu makine hesabı Domain içinde NTLM veya Kerberos Authentication (kimlik doğrulama) işlemlerinde kullanılacak şekilde bir Machine Password (makine parolası) ile ilişkilendirilir ve Secure Channel (güvenli bir kanal) kurmak üzere yapılandırılır. Bu ilişkilendirme, ileride yapılacak GPO uygulamaları, replikasyon talepleri ve kimlik doğrulama trafiği açısından kritik bir temel oluşturur.

⚡ 5.2- Makine Hesabı Parolasının Yerel Olarak Saklanması

Domain Join işlemi başarıyla tamamlandığında, Client bilgisayar için Active Directory üzerinde bir Computer Account (makine hesabı) oluşturulur. Bu hesaba, sistem tarafından otomatik olarak bir Machine Password (makine parolası) atanır. Güvenli kimlik doğrulama ve replication işlemlerinde kullanılacak bu parola, Client tarafında şifrelenmiş biçimde saklanmak üzere aşağıdaki Registry konumuna kaydedilir:

Bu kayıt alanı, aslında C:\Windows\System32\config\SECURITY dosyasının bir parçasıdır ve yalnızca Local Security Authority Subsystem Service (LSASS) tarafından erişilebilir durumdadır. SECURITY Hive'i, sistem Boot sürecinde LSASS tarafından belleğe yüklenir ve erişim yetkisi LocalSystem güvenlik bağlamıyla sınırlıdır.

Bu nedenle, normal kullanıcılar, hatta Local Administrator yetkisine sahip oturumlar bile bu Hive içeriğine erişemez. regedit.exe veya benzeri kullanıcı modundaki araçlar bu alandaki Policy\Secrets anahtarını görüntüleyemez. Erişim yalnızca SYSTEM seviyesindeki servisler, Kernel-Mode bileşenleri veya özel yetkilerle çalışan Forensic araçlar üzerinden mümkündür.

Client bilgisayarın sahip olduğu makine hesabı parolası, varsayılan olarak her 30 günde bir otomatik şekilde güncellenir. Bu işlem, hem Active Directory üzerindeki Computer Object hem de Client tarafındaki HKLM\SECURITY\Policy\Secrets altında eş zamanlı olarak senkronize edilir.

⚡ 5.3- Bilgisayarın Yeniden Başlatılması

Domain Join işlemi tamamlandığında, sistem tarafından bir yeniden başlatma gerçekleştirilir. Bu adım, yapılan dizin kayıtlarının ve güvenlik yapılandırmalarının geçerli olması için zorunludur.

Yeniden başlatma sonrasında bilgisayar açılışta artık bir Domain üyesi olarak çalışır; makine hesabı ile kimlik doğrulaması yapılır, GPO'lar işlenir ve güvenli kanal bağlantıları kurularak dizin servisleriyle iletişim başlatılır.

⚡ 5.4- GPO'ların alınması (LDAP + SYSVOL) 

Domain'e başarıyla katılan bir bilgisayar, Group Policy (GPO) mekanizması üzerinden uygulanan sistem yapılandırmalarını almaya başlar. Bu süreç, istemci tarafında tetiklenen bir dizi sistem bileşeniyle gerçekleştirilir ve hem kimlik doğrulama sonrası yapılandırmaları hem de güvenlik politikalarını içerir. GPO alınması, Domain ortamına entegre edilen her sistem için temel bir davranış modelidir ve işletim sisteminin, organizasyonel kurallar çerçevesinde çalışmasını sağlar.

• LDAP ile GPO'ların listelenmesi

Domain'e başarıyla katılmış bir Client, oturum açma veya sistem başlatma sırasında Group Policy uygulama sürecini başlatır. Bu sürecin ilk adımında, TCP 389 Port'u üzerinden LDAP protokolünü kullanarak hedef Domain Controller’a bağlanır.

Client, kendi bilgisayar nesnesinin yer aldığı Organizational Unit (OU) için, Distinguished Name (DN) değerini temel alarak LDAP üzerinden dizin sorgusu gerçekleştirir. Bu sorgu sırasında, hem doğrudan bulunduğu OU hem de ona ait parent OU’lar ve en üst düzeydeki Domain nesnesi boyunca sıralı şekilde yukarı doğru ilerlenir. Her bir nesne üzerindeki gPLink ve gPOptions Attribute’ları okunur. 

Bu Attribute’lar sayesinde Client:

👉 Hangi GPO’ların bu OU’ya bağlı olduğunu,
👉 GPO’ların uygulanma sırasını,
👉 Enforced ya da Disable edilmiş GPO olup olmadığını,

analiz eder ve buna göre bir uygulanacak GPO listesi oluşturur.

Elde edilen bu mantıksal liste, sonraki aşamada SYSVOL üzerinden GPO verilerinin fiziksel olarak indirilmesi süreci için kullanılır. LDAP, bu noktada yalnızca hangi GPO’ların geçerli olduğunu belirlemeye yarar; yapılandırma dosyalarının alınmasında doğrudan rol oynamaz.

Aşağıdaki PowerShell komutundan, ilgili OU’nun Distinguished Name (DN) bilgisini girerek her bir GPO bağlantısına ait gPLink ve gPOptions Attribute’larının nasıl tanımlandığını görebilir, böylece Client’ın Group Policy uygulama sürecinde bu değerleri nasıl okuduğunu ve yorumladığını anlayabilirsiniz:

Bu sayede, Client’ın bulunduğu OU’ya doğrudan bağlı GPO’ları (gPLink) ve Inheritance davranışını kontrol eden gPOptions değerini nasıl değerlendirdiği gözlemlenebilir.



İlgili PowerShell komutu çalıştırıldığında, belirtilen OU’ya doğrudan Link’lenmiş Group Policy Object (GPO) tanımları gPLink Attribute’u üzerinden elde edilir. Bu Attribute, her GPO bağlantısını Distinguished Name (DN) formatında içerir ve her bağlantının sonuna eklenen ;flag yapısı ile bağlantı davranışını tanımlar.

Buradaki ;flag ifadesinde yer alan değer, GPO’nun bu OU üzerinde nasıl uygulanacağını belirtir. Noktalı virgül (;) karakteri ise LDAP yolu ile Flag bilgisini birbirinden ayırmak amacıyla kullanılır.

Bu yapı sayesinde, aynı OU’ya birden fazla GPO bağlanması durumunda her bir bağlantının hem kimliği hem de uygulama davranışı ayrıştırılabilir şekilde tanımlanmış olur. Özellikle Enforced ve Link Disabled gibi davranışların istemci tarafında nasıl uygulanacağını anlamak için bu flag değerleri kritik öneme sahiptir.

gPOptions Attribute’u yalnızca bir OU üzerinde Block Inheritance özelliği etkinleştirildiğinde yazılır ve bu durumda aşağıdaki değerlerden birini alır:

Bu Attribute’un GPO bağlantılarını kontrol eden gPLink ile ilgisi yoktur; yalnızca inheritance davranışı üzerinde etkilidir.

• SYSVOL içeriğinin alınması

Group Policy Object (GPO), Active Directory üzerinde GUID gibi bir tanımlayıcı ve buna ait metadata bilgisini barındırır. GPO’ya ait gerçek yapılandırma dosyaları ise Domain Controller'ın yerel dosya sisteminde, SYSVOL paylaşımı altında saklanır. Bu dosyalar, Client’lar tarafından Server Message Block (SMB) protokolü üzerinden, yani TCP 445 Port'u aracılığıyla alınır.

Client, Group Policy işlem sürecinde her bir GPO için GroupPolicyContainer (GPC) nesnesini LDAP ile sorgular, ardından ilgili GroupPolicyTemplate (GPT) içeriğini almak üzere aşağıdaki SYSVOL yolu üzerinden dosya seviyesinde erişim kurar.



Bu klasörde yer alan gpt.ini, Registry.pol, Scripts, Adm, Machine ve User gibi alt dizinler, uygulanan GPO'nun yapılandırma yükünü oluşturur. Group Policy Client Service (gpsvc), bu içeriği yorumlayarak gerekli yapılandırma değişikliklerini işletim sistemi düzeyinde uygular.

• İlk GPO çekme süreci

Bilgisayar yeniden başlatıldığında ya da bir kullanıcı oturum açtığında, Windows işletim sistemi, Userenv.dll ve gpsvc.dll bileşenleri üzerinden Group Policy Client Service (gpsvc) aracılığıyla Group Policy Refresh sürecini tetikler. Bu işlem, kullanıcı ve bilgisayar tabanlı Group Policy nesnelerinin (GPO) uygulanmasını sağlar.

Userenv.dll, kullanıcı profil ayarlarının işlenmesinden ve ortam değişkenlerinin yüklenmesinden sorumluyken, gpsvc.dll ise doğrudan Group Policy uygulama sürecini yürüten çekirdek işlemleri yürütür. Her iki bileşen de C:\Windows\System32 dizininde yer alır ve işletim sisteminin Protected System Files arasında bulunur.

gpsvc.dll, svchost.exe altında çalışan Group Policy Client servisi tarafından yüklenir ve bu servisin Policy uygulama döngüsünü başlatmasında merkezi bir rol üstlenir. Sistem açıldığında, GPO'lara ait konfigürasyonlar işlenir, Registry tabanlı ayarlar uygulanır, login script’ler tetiklenir ve arka planda periyodik Policy Refresh Timer devreye girer. Tüm bu süreç, GPSVC servisiyle senkronize olarak ilerler.

• Uygulanan ilk GPO'lar

Group Policy işleme süreci, istemci sistemin başlatılmasıyla birlikte Computer Configuration kapsamındaki ilkelerin uygulanmasıyla başlar. Bu aşama, bilgisayar oturumu açılmadan önce işletim sisteminin çekirdek servisleri tarafından tetiklenir. Windows mimarisi gereği, GPO işlemesi, Computer Policy ve User Policy olmak üzere iki ayrı fazda gerçekleştirilir. Bu fazlar zamanlama, güvenlik bağlamı ve uygulama bağlamı açısından birbirinden ayrılmıştır.

Bilgisayar açıldığında, sistem seviyesinde çalışan Group Policy Client servisi (gpsvc) devreye girer ve Computer Configuration kapsamındaki politikaları işler. Bu aşamada uygulanan GPO’lar arasında güvenlik ayarları, servis konfigürasyonları, Registry anahtarları, Startup Script’ler ve cihaz düzeyindeki kısıtlamalar yer alabilir. Bu işlem, kullanıcı kimlik doğrulaması gerçekleşmeden tamamlanmalıdır; çünkü bu ayarlar, sistemin güvenli başlangıç davranışını belirler.

Kullanıcı oturumu açıldığında, sistem yeniden Group Policy Refresh sürecini başlatır ve bu defa User Configuration kapsamındaki GPO’lar uygulanır. Bu kısımda kullanıcı profiline özel ayarlar devreye girer. Masaüstü kısıtlamaları, Explorer davranışları, User-Level Registry anahtarları, Logon Script’ler ve kişisel ortam yapılandırmaları bu kapsamda değerlendirilir. User Configuration, kullanıcının kimlik bilgilerine dayalı bir güvenlik bağlamında çalıştığı için, Security Identifier (SID) tabanlı hedeflemeye izin verir.

Bu çift aşamalı işleme modeli sayesinde, aynı istemci sistem üzerinde hem bilgisayara yönelik hem de kullanıcıya yönelik yapılandırmalar, farklı güvenlik bağlamlarında ve farklı zamanlama döngülerinde senkronize şekilde uygulanabilir. İlk kez domain'e katılmış bir istemci sistemde, bilgisayar açıldığında yalnızca bilgisayar yapılandırması kapsamındaki ilkeler devreye girer. Kullanıcı oturumu açılana kadar kullanıcı yapılandırmasına ait kurallar işlenmez. Bu durum, Domain'e yeni alınan makinelerde gözlemlenen doğal ve öngörülebilir bir davranıştır.

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