Bilgisayarı ve Sunucuyu Domain'e Ekleme: Ön Koşul ve Hatalar

Bilgisayarı domain’e eklemek (Windows’un Türkçe arayüzündeki adıyla etki alanına eklemek), o makinenin kimlik kaynağını kendi yerel hesap veritabanından Active Directory’ye devretmesi demektir. Aynı işlem sahada “bilgisayarı domaine alma” ya da “domaine dahil etme” diye de anılır; üçü de aynı şeyi anlatır. Katılım tamamlandığında bilgisayar domain’de bir nesne olarak var olur, kullanıcılar kurumsal hesaplarıyla oturum açar ve makineye uygulanan ayarlar tek merkezden yönetilir. İşlemin kendisi üç tıktır. Katılımın başarısız olduğu, ya da başarılı görünüp hiçbir işe yaramadığı yerler ise katılımdan önce ve sonra yaptıklarınızda saklıdır.

Bunu bir kuruma işe giriş gibi düşünün. Yeni bir çalışan işe başladığında yapılan asıl iş sözleşmeyi imzalatmak değildir: sicil dosyası açılır, kimlik kartı basılır, kişi bir departmana yazılır ve o departmanın yönetmeliği artık onu da bağlar. İmza beş saniye sürer, kaydın doğru açılıp açılmadığı aylarca hissedilir. Domain katılımı da tam olarak böyle çalışır; rehber boyunca aynı İK masasına geri döneceğiz.

Makale BT Sistem Yönetimi hizmetimizin kimlik altyapısı koluna odaklanır ve Active Directory Rehberi makalesindeki “Bilgisayarları Domain’e Ekleme” bölümünün devamıdır. Orada katılımın nasıl yapıldığı özetleniyor; burada katılımın neden kırıldığı, nesnenin nereye düştüğü ve elli makinede aynı işin nasıl yapıldığı var.

Ön koşulları zaten doğruladıysanız doğrudan katılım adımına geçebilirsiniz. Katılım hata veriyorsa Sık Karşılaşılan Katılım Hataları bölümü belirtiden kaynağa giden listeyi veriyor.

Domain’e Katılmadan Önce: Beş Ön Koşul

Domain katılımının başarısız olduğu vakaların neredeyse tamamı, katılım ekranında değil o ekrana gelmeden önce kaybedilir. Aşağıdaki beşini sırayla doğrulayın; katılım komutunu yazdığınızda geriye sadece onay kalsın.

Dört koşuldan önce bir de sürüm şartı var ve en çok zaman kaybettiren bu oluyor: Windows Home sürümleri domain’e katılamaz. Bu bir yapılandırma eksiği değil, sürümde bulunmayan bir yetenektir; kayıt defterinde açılacak bir anahtar da yoktur. Katılacak makinenin Pro, Enterprise veya Education sürümü olması gerekir. Bir cihaz mağazadan yeni geldiyse katılımı denemeden önce winver ile sürümünü doğrulayın.

DNS Domain Controller’ı Göstermeli

Bilgisayar, katılacağı domain’i DNS üzerinden bulur. Bu yüzden makinenin birincil DNS sunucusu bir Domain Controller olmak zorundadır; ISS’nizin DNS’i veya 8.8.8.8 yazılıysa katılım daha ilk adımda durur.

Sebebi şudur: domain adı DNS’te sıradan bir A kaydı değildir. Domain Controller’lar kendilerini SRV kayıtlarıyla duyurur; istemci “bu domain’in kimlik doğrulama sunucusu kim?” sorusunu bu kayıtlara sorar. Kurumun santraline telefon açıp “İK hangi dahiliye bakıyor?” diye sormak gibidir; dışarıdan bir rehberde o dahili numara yoktur, çünkü o numara sadece kurumun kendi defterinde yazılıdır. Kayıt türlerinin hangisinin ne taşıdığını ve bir sorgunun hangi sunucuya gittiğini DNS nedir rehberimizde ayrıntılı olarak anlatıyoruz.

İstemcide tek komutla doğrulayın:

nslookup -type=srv _ldap._tcp.dc._msdcs.ad.sercebilisim.com

Çıktıda en az bir Domain Controller adı ve IP adresi görmelisiniz. “Non-existent domain” veya boş yanıt geliyorsa katılımı denemeyin, önce DNS’i düzeltin. İç DNS’in nasıl kurulduğu ve forwarder yapılandırması Active Directory DNS yapılandırması rehberinde anlatılıyor.

Saat Sapması 5 Dakikayı Geçmemeli

Kerberos, kimlik doğrulama biletlerine zaman damgası basar ve varsayılan olarak 5 dakikadan fazla saat sapmasını reddeder. Bilet geçerli olsa bile saat uyuşmuyorsa doğrulama başarısız olur.

Turnikeden geçerken kartınızı okutmak gibidir: kart doğrudur, kişi doğrudur, ama sistem “bu giriş 40 dakika önce yapılmış görünüyor” derse kaydı kabul etmez. Saldırganın eski bir kaydı tekrar oynatmasını engelleyen mekanizma budur; yan etkisi, saati bozuk makinenin de kapıda kalmasıdır.

w32tm /query /status
w32tm /resync

Sanal sunucularda bu sorun daha sıktır: makine bir snapshot’tan geri döndüğünde saati de geriye gider. Kurumsal saat zincirinin doğru kurulması (PDC Emulator dışarıdaki bir kaynağa, diğer herkes PDC Emulator’a bakar) ayrı bir konudur; sunucu tarafındaki temel ayar Windows Server kurulumu rehberinin NTP bölümünde duruyor.

Hostname Katılımdan ÖNCE Belirlenmeli

Makinenin adını katılımdan sonra değiştirmek mümkündür, ama gereksiz yere pahalıdır. Katılım anında Active Directory’de o adla bir bilgisayar nesnesi oluşur; ad değişince bu nesnenin, ona bağlı DNS kaydının ve makinenin güvenli kanal parolasının birlikte güncellenmesi gerekir. Kimlik kartını bastırdıktan sonra ismin yanlış yazıldığını fark etmek gibidir: kart yeniden basılır, sicil defteri düzeltilir, kapı sistemi yeniden tanımlanır.

Katılımdan önce adı verin ve bir yeniden başlatmayla bitirin:

Rename-Computer -NewName "DHCP01" -Restart

İki kural: ad 15 karakteri geçmesin (NetBIOS sınırı) ve Türkçe karakter içermesin. DC01, DHCP01, FS-IST-01 gibi kısa ve konumu belli isimler, üç yıl sonra log okurken en çok işinize yarayan detaydır.

Çalışan Bir Yerel Yönetici Hesabı Olmalı

Katılımdan önce makinede, parolasını bildiğiniz ve çalıştığını doğruladığınız bir yerel yönetici hesabı bulunsun. Atlanması en kolay, bedeli en ağır ön koşul budur.

Sebebi şu: katılımdan sonra herkes domain hesabıyla oturum açar ve yerel hesap unutulur. Ama domain tarafında bir şey kırıldığında, mesela aşağıda anlatılan güven ilişkisi koptuğunda, makineye domain hesabıyla giremezsiniz. Elinizde çalışan bir yerel yönetici yoksa geriye makineyi baştan kurmak kalır.

Windows istemcilerde yerleşik Administrator hesabı varsayılan olarak devre dışıdır. Etkinleştirmek için Çalıştır kutusuna lusrmgr.msc yazın; Users altında Administrator’a sağ tıklayıp Properties’i açın ve “Account is disabled” kutusunun işaretini kaldırın. Parolayı aynı listede sağ tık → Set Password ile belirleyin. PowerShell tarafında iki satır:

Enable-LocalUser -Name "Administrator"
Set-LocalUser -Name "Administrator" -Password (Read-Host -AsSecureString -Prompt "Yeni parola")

Parolayı belirledikten sonra o hesapla bir kez oturum açıp gerçekten çalıştığını görün. İşe yaramayan bir kurtarma hesabı, hiç olmayandan daha tehlikelidir; çünkü size olmayan bir güven verir.

Birkaç makineden fazlasında bu parolaları elle yönetmek sürdürülemez hale gelir. LAPS her makinenin yerel yönetici parolasını birbirinden bağımsız tutar ve otomatik döndürür.

Katılım Yetkisi ve Ağ Erişimi

Katılımı yapan hesabın Domain Admin olması gerekmez. Active Directory’de sıradan bir domain kullanıcısı varsayılan olarak en fazla 10 bilgisayarı domain’e katabilir; bu sınırı ms-DS-MachineAccountQuota özniteliği belirler. Onbirinci makinede katılım, sebebi hiç anlaşılmayan bir yetki hatasıyla durur.

Doğru çözüm kotayı yükseltmek değil, yetkiyi devretmektir: ADUC’ta hedef OU’ya sağ tıklayıp Delegate Control ile teknisyen hesabına yalnızca o OU altında bilgisayar nesnesi oluşturma izni verilir. Böylece hem kota sorunu biter hem Domain Admin parolası sahaya inmez. Ayrıcalıklı hesapların neden sıradan makinelerde kullanılmaması gerektiğini Active Directory güvenlik sıkılaştırması rehberinde Tier modeli üzerinden ele alıyoruz.

Ağ tarafında istemciden Domain Controller’a şu portların açık olması gerekir: DNS için 53, Kerberos için 88, LDAP için 389, SMB için 445, RPC için 135 ve 49152-65535 dinamik aralığı. Şube ile merkez arasında firewall varsa katılım denemesinden önce bu listeyi kontrol edin.

Bilgisayarı Domain’e Ekleme

Ön koşullar tamamsa katılımın kendisi tek adımdır ve bir yeniden başlatmayla biter. İki yol vardır; sonuç aynıdır.

Arayüzden Katılım

Katılım penceresine giden en kısa yol Çalıştır kutusudur: Win+R tuşlarına basın, sysdm.cpl yazıp Enter’a basın. Klasik System Properties penceresi açılır.

Bu yolu önermemizin sebebi hız değil, dayanıklılık. Ayarlar uygulamasının menü ağacı neredeyse her Windows sürümünde yeniden düzenleniyor; bugün ezberlediğiniz tıklama zinciri iki sürüm sonra başka bir yere taşınmış oluyor. sysdm.cpl ise yirmi yılı aşkın süredir aynı komut ve Windows Server 2025 dahil her sürümde aynı pencereyi açıyor. Doğrudan Computer Name sekmesiyle açmak isterseniz SystemPropertiesComputerName.exe de aynı şekilde sabittir. Sunucularda Server Manager’ın Local Server sayfasındaki WORKGROUP bağlantısı da arkada aynı pencereyi çağırır.

Açılan pencerede Change düğmesine basın, “Member of” bölümünde Domain seçeneğini işaretleyin ve domain adını tam haliyle yazın: ad.sercebilisim.com. Aynı diyalogdaki Computer name alanı makinenin adını da alır. Kimlik bilgisi istendiğinde katılım yetkisi devredilmiş hesabı girin. “Welcome to the ad.sercebilisim.com domain” mesajını gördükten sonra makineyi yeniden başlatın.

Sunucularda aynı işi Server Manager’ın Local Server sayfasındaki WORKGROUP bağlantısı da açar; arkasında aynı pencere vardır.

PowerShell ile Katılım

Tek makinede arayüz yeterlidir. Birden fazla makinede, kurulum belgelenecekse veya işlem bir betiğin parçasıysa PowerShell tercih edilir:

Add-Computer -DomainName "ad.sercebilisim.com" -Credential (Get-Credential) -Restart

Adı da aynı anda değiştirmek isterseniz katılım ve yeniden adlandırma tek yeniden başlatmaya sığar:

Add-Computer -NewName "DHCP01" -DomainName "ad.sercebilisim.com" -Credential (Get-Credential) -Restart

Nesnenin doğrudan hedef departmana yazılması için -OUPath parametresini kullanın; bir sonraki bölümün konusu tam olarak budur:

Add-Computer -DomainName "ad.sercebilisim.com" `
  -OUPath "OU=Sunucular,DC=ad,DC=sercebilisim,DC=com" `
  -Credential (Get-Credential) `
  -Restart

Doğrulama: Katılım Gerçekten Oldu mu?

Yeniden başlattığınızda oturum açma ekranında domain adını görmek iyi bir işarettir, kanıt değildir. O ekran makinenin kendini domain üyesi saydığını gösterir; üç şeyi göstermez. Windows son oturumları önbelleğe aldığı için hiçbir Domain Controller’a ulaşılamasa da giriş yapılabilir. Nesnenin AD’de nereye düştüğü görünmez. Güvenli kanal bozulmuş olsa bile önbellekten giriş çalışmaya devam eder.

İşe giriş benzetmesiyle: kart okutulmadan kapıdan geçebiliyorsanız, kartın gerçekten çalıştığını bilmiyorsunuz demektir. Katılımı iki taraftan da doğrulayın.

İstemci tarafında komut istemini yönetici olarak açın:

systeminfo | findstr /B /C:"Domain"
nltest /dsgetdc:ad.sercebilisim.com
klist

Çıktılarda tek tek şu satırlara bakın:

• Domain: satırı katıldığınız domain adını göstermeli. Hâlâ WORKGROUP yazıyorsa katılım tamamlanmamış, makine yalnızca yeniden başlamıştır.
• nltest çıktısındaki DC: satırı bir Domain Controller adı vermeli. Hata dönüyorsa makine DC’yi bulamıyor; sorun katılımda değil DNS’tedir.
• klist çıktısında krbtgt/AD.SERCEBILISIM.COM bileti görünmeli. Bu bilet, makinenin Kerberos ile gerçekten kimlik doğruladığının kanıtıdır. Liste boşsa saat sapmasına bakın. Çıktıdaki alanların tek tek ne anlama geldiğini ve biletin hangi bayrakları taşıması gerektiğini Kerberos nedir rehberimizde gerçek klist çıktısı üzerinden gösteriyoruz.

Güvenli kanalın sağlığını PowerShell tek satırda söyler; beklenen çıktı True değeridir:

Test-ComputerSecureChannel -Verbose

Sunucu tarafında ADUC’u (dsa.msc) açın ve bilgisayar nesnesinin göründüğünü doğrulayın. Nesne, katılımda bir OU belirtmediyseniz Computers konteynerinde olacaktır. Yeri bir sonraki bölümün konusu; şimdilik önemli olan nesnenin var olması.

Nesnenin varlığını komutla da sorabilirsiniz (RSAT kurulu bir yönetim makinesinde veya doğrudan DC üzerinde):

Get-ADComputer DHCP01 -Properties DistinguishedName, LastLogonDate |
  Select-Object Name, DistinguishedName, LastLogonDate

DistinguishedName alanı nesnenin tam olarak nereye düştüğünü gösterir. Bu satırı not edin; birazdan lazım olacak.

Üç kontrolden biri bile beklediğiniz sonucu vermiyorsa Sık Karşılaşılan Katılım Hataları bölümüne geçin; belirtiden kaynağa giden liste orada.

Nesne Nereye Düştü? Computers Konteyneri ve OU Yerleşimi

Katılım sırasında bir hedef belirtmezseniz bilgisayar nesnesi domain’in kökündeki Computers konteynerine düşer. Buradaki tuzak şudur: Computers bir OU değil, bir konteynerdir ve konteynere GPO linklenemez.

İşe giriş benzetmesiyle: personel kaydı açılmış, kimlik kartı basılmış, ama kişi hiçbir departmana yazılmamıştır. Lobide oturuyordur. Kurumun tüm çalışanlarını bağlayan genel yönetmelik ona da işler, ama hiçbir departman yönetmeliği ulaşmaz; çünkü departman yönetmelikleri departmanlara asılır, lobiye değil.

Teknik karşılığı birebir aynıdır. Domain seviyesine linklenmiş GPO’lar (Default Domain Policy gibi) Computers konteynerindeki makinelere de uygulanır. Ama hedeflenmiş her politika bir OU’ya linklenir, dolayısıyla oradaki makine onların hiçbirini almaz. Bu yüzden “katılım başarılı ama GPO uygulanmıyor” şikayetinin en sık sebebi, GPO’nun kendisi değil nesnenin yeridir.

Bunun en net kanıtını iki konsolu yan yana açtığınızda görürsünüz. ADUC’ta Computers konteyneri vardır ve makineniz içindedir. GPMC’de ise Computers diye bir düğüm hiç yoktur. Group Policy Management konsolu ağacında yalnızca OU’ları listeler, çünkü GPO linklenebilecek yerler sadece onlardır. Yani nesneniz, politika yönetiminin göremediği bir yerde duruyordur.

Varsayılan Hedefi Bir OU’ya Çevirmek: redircmp

Buradaki asıl soru dosyalamayı kolaylaştırmak değil, şu: katılan makine, doğru OU’ya taşınana kadar hangi politikaları alacak?

Çünkü o makine taşınmayı beklerken boş boş durmuyor; ağa bağlı, açık ve kullanılabilir durumda. Kullanıcı başına oturuyor, USB takıyor, tarayıcı açıyor. Computers konteynerine düştüğünde ona ulaşan tek şey domain seviyesine linklenmiş politikalardır: parola kuralı gibi genel şeyler gelir, ama USB depolama kısıtı, kurumsal masaüstü arka planı, güvenlik taban ayarları, ekran kilidi süresi gibi OU’ya linklenen ne varsa gelmez. Bu boşluk birkaç saat de sürebilir, kimse fark etmezse haftalar da.

redircmp bu boşluğu kapatır. Komut, domain’de yol belirtilmeden oluşturulan tüm yeni bilgisayar nesnelerinin hangi OU’ya düşeceğini kalıcı olarak tanımlar. Hedef bir OU olduğu için oraya artık GPO linkleyebilirsiniz; makine daha ilk açılışında taban politikasını alır, dosyalanmayı beklerken korumasız kalmaz.

İşe giriş benzetmesiyle: yeni personelin departmanı henüz belli değilken bile eline verilen kart boş bir kart değildir. Ana kapıyı açar, kasa katına çıkmaz. Departmanı belli olunca kart yetkilendirilir.

Domain Admin yetkisiyle bir Domain Controller üzerinde bir kez çalıştırılır:

redircmp "OU=Yeni_Bilgisayarlar,DC=ad,DC=sercebilisim,DC=com"

İki noktayı bilerek uygulayın. Komut yalnızca bundan sonra oluşacak nesneleri etkiler; Computers konteynerinde bekleyen mevcut nesneler kendiliğinden taşınmaz, onları elle taşımanız gerekir. Ve hedef gerçekten bir OU olmalıdır, bir konteyner değil; zaten amaç tam olarak bu.

Bu OU Nereye Konur ve Neden Tek Tanedir?

Hedef OU’yu seçerken sık sorulan bir soru şudur: her lokasyon için ayrı bir varsayılan tanımlanabilir mi? Tanımlanamaz. redircmp domain seviyesinde çalışır ve domain başına tek bir varsayılan kabul eder. Lokasyon başına OU açsanız bile komut yalnızca birini işaret edebilir.

Bu bir kısıt gibi görünür, ama aslında OU’nun rolünü doğru anlamayı zorlar. Yeni_Bilgisayarlar makinenin yaşayacağı yer değil, indiği yerdir. Kalıcı adresi lokasyonunun altındaki Bilgisayarlar OU’sudur; buradaki duraklama geçicidir.

Bu yüzden OU’yu lokasyon ağacının dışına, Sunucular ve Servis_Kullanicilari ile aynı seviyeye koyun. Makine oraya düştüğünde hangi lokasyona ait olduğu henüz belli değildir; lokasyon ağacının içine yerleştirmek bu yüzden anlamsız olur.

Buraya linkleyeceğiniz taban GPO’yu tasarlarken ölçüt şu olmalı: makine bu politikayla ağda güvenle bekleyebilir mi? Kullanıcının işini yapmasını sağlamak zorunda değilsiniz, zaten geçici bir duraktır; amaç korumasız bir pencere bırakmamaktır. Sonradan doğru OU’ya taşındığında kalıcı politikalarını alacak.

Tek olmanın ikinci kazancı operasyonel: bu OU’da duran her nesne dosyalanmamış iş demektir. Boşsa her şey yerli yerindedir, doluysa birinin taşıması gerekiyordur. Disiplinli bir ortamda burası çoğu zaman boş durur, ve boş durması iyi haberdir.

Bu komutun kullanıcı tarafındaki eşi redirusr’dır ve varsayılan kullanıcı hedefini aynı şekilde değiştirir. OU ağacının nasıl kurgulanacağı ve yetkilerin nasıl devredileceği Active Directory kullanıcı, grup ve OU yönetimi rehberinde ayrıntılı işleniyor.

Nesneyi Katılımdan Önce Açmak

Bazı ortamlarda daha temiz bir yol vardır: nesneyi makine gelmeden önce doğru OU’da oluşturmak. Personel işe başlamadan sicil dosyasını açıp departmanına yazmak gibidir; kişi geldiğinde yerleşecek yer hazırdır.

New-ADComputer -Name "DHCP01" -Path "OU=Sunucular,DC=ad,DC=sercebilisim,DC=com"

Somut faydası şu: makine ilk açılışından itibaren kalıcı OU’sunun politikalarını alır. İniş pistine hiç uğramaz; ne Computers konteynerine, ne de redircmp ile yönlendirdiyseniz Yeni_Bilgisayarlar OU’suna. Bir önceki bölümdeki taban politikayla bekleme adımı tamamen ortadan kalkar, çünkü beklenecek bir şey yoktur.

Ama burada 2022’den beri geçerli olan bir kural var ve çoğu rehber hâlâ eski haliyle anlatıyor.

Katılımın çalışması için üç koşuldan biri gerekir: katılımı yapan kişi nesnenin oluşturanı olmalı, nesne Domain Admins üyesi biri tarafından açılmış olmalı, ya da nesnenin sahibi Domain controller: Allow computer account re-use during domain join grup ilkesindeki güvenilir sahipler listesinde bulunmalı. Üçüncüsü tüm üye makinelerde ve Domain Controller’larda Mart 2023 ve sonrası güncelleme ister.

İşe giriş benzetmesiyle: sicil dosyasını açan memur ile kimlik kartını basan memur farklıysa sistem işlemi kabul etmiyor. Kartı basacak kişinin ya dosyayı kendisinin açmış olması, ya da yetkili listesinde adının bulunması gerekiyor.

Bu kuralın bedelini bir müşteri ortamında ödedim. Kurumun güvenlik politikası gereği lokasyon teknisyenlerinin RSAT ve Active Directory erişimi yoktu, tüm AD operasyonu genel müdürlükten yürüyordu; her lokasyon için bir delegasyon grubu kurmuştuk. Buca lokasyonunda elli bilgisayar nesnesini önceden ben açtım, katılımı teknisyen yapacaktı. Yapamadı.

Ekrandaki mesaj tam olarak şuydu: “An account with the same name exists in Active Directory. Re-using the account was blocked by security policy.” O cümlenin ne anlama geldiğini o zaman bilmiyorduk. Elli makinenin hiçbiri katılmıyordu ve belirti Active Directory’nin kendisini işaret ediyor gibiydi; bozuk bir kayıt mı, replikasyon sorunu mu diye günlerce aradık. Çözüm nesnelerin sahipliğini teknisyenin delegasyon grubuna çevirmek oldu; o anda elli makine de katıldı.

Bir not: dokümantasyona göre Domain Admin’in açtığı nesnenin bu kontrolden muaf olması gerekiyordu, bizim ortamımızda olmadı. Sahada güvendiğim kural bu yüzden şu: muafiyete bel bağlamayın, sahipliği katılımı yapacak kimliğe hizalayın. Kontrolün okuduğu nitelik zaten o.

Pratikte iki temiz yol var. Küçük ortamlarda nesneyi açan hesapla katılımı da yapın, mesele kapanır. Ölçek büyüdüğünde ise farklı kimliklere yedi ayrı ACE dağıtmak yerine bir sonraki bölümdeki offline domain join yöntemine geçin; Microsoft o yöntemi tam da bu yüzden öneriyor. İzin kümesinin tam listesi Active Directory domain join permissions sayfasında duruyor.

Bu kısıtı geri almanın bir yolu da yok: eskiden kullanılan NetJoinLegacyAccountReuse kayıt defteri anahtarı 13 Ağustos 2024 güncellemeleriyle tamamen kaldırıldı, sıkılaştırma artık koşulsuz yürürlükte.

Nesne Yanlış Yerdeyse

Taşımak serbesttir ve nesne kimliğini bozmaz: ADUC’ta sürükleyip bırakın ya da Move-ADObject kullanın. Ama tek başına yeterli değildir. Makine yeni OU’nun politikalarını hemen almaz; yeniden başlatın. gpupdate /force çoğu zaman işi görür, ancak grup üyeliğine bağlı ayarlar için yeniden başlatma tek güvenilir yoldur.

Yerini düzelttiniz, yeniden başlattınız, GPO hâlâ gelmiyor ya da dakikalarca gecikiyorsa sorun artık nesnenin yerinde değildir.

Devraldığım bir WORKGROUP’tan AD’ye geçiş projesinde bunun uç bir örneğini gördüm. Site ve subnet tanımları özensizdi; RODC’ler, DC’ler ve birbiriyle ilgisi olmayan sunucular karşılıklı replike oluyordu. Üstüne kalabalık bir şubeye 4 GB bellek ve iki çekirdekli bir Domain Controller bakıyordu. Sonuç öngörülemezlikti: politika bazen anında geliyor, bazen parola sıfırlama gibi sıradan bir işlem on beş dakika sürüyordu. Aynı ortam, aynı GPO, her seferinde başka süre. O sunucuyu emekliye ayırıp replikasyon topolojisini düzelttiğimizde şikayet kendiliğinden bitti.

Buradan çıkan ayrım işinize yarar: politikanın hangi makineye uygulanacağını nesnenin OU’su belirler, ne kadar sürede uygulanacağını ise istemcinin bağlandığı Domain Controller’ın sağlığı ve Sites/Subnets tanımlarının doğruluğu belirler. gpresult /r çıktısındaki “Group Policy was applied from” satırı politikanın hangi DC’den geldiğini söyler; orada beklemediğiniz bir sunucu adı görüyorsanız aramanız gereken yer OU değil, site topolojisidir.

Sık Karşılaşılan Katılım Hataları

Domain katılım hatalarının ortak özelliği, tek bir mesajın çok sayıda farklı sebebi gizlemesidir. Ekranda “domain bulunamadı” yazar; sebep DNS, saat, port veya kapalı bir servis olabilir. Aşağıdaki tablo sahada en sık gördüğüm belirtileri kaynaklarıyla eşleştiriyor.

Tablodaki dört satır ayrıca açıklama hak ediyor.

IPv6 DNS Sunucusu Araya Giriyor

Bu, teşhisi en zor katılım arızasıdır, çünkü DNS ayarınıza baktığınızda her şey doğru görünür. ipconfig çıktısında DNS sunucusu olarak Domain Controller’ınız yazar, yine de sorgu oraya gitmez.

Bu rehberin ekran görüntülerini hazırlarken kendi lab ortamımda tam olarak bunu yaşadım ve itiraf edeyim, teşhis beklediğimden çok uzun sürdü. Katılım DNS_INFO_NO_RECORDS ile düştüğü için doğal refleks sunucu tarafına bakmaktı. Sırayla şunları doğruladım: domain adı doğruydu, ad.sercebilisim.com ve _msdcs zone’ları AD entegre olarak yerindeydi, Domain Controller kendi DNS’i olarak kendini gösteriyordu, SRV kayıtları zone’un içinde duruyordu ve DC kendi kendine sorulduğunda doğru cevabı veriyordu. Sunucu tarafında yanlış olan hiçbir şey yoktu.

Arada iki yanlış ipucunun da peşinden gittim. Biri sanal makinelerin ağ modu farkıydı, diğeri DNS’te duran ve ölü sandığım ikinci bir Domain Controller kaydı; ikincisi meğer tamamen meşru bir sunucuymuş. Arıza teşhisinde asıl zaman kaybı yanlış cevaplarda değil, doğru görünen cevaplarda yaşanıyor.

Dönüp bakınca ipucu ilk nslookup çıktısında baştan beri duruyordu ve ben okumamıştım. Sorgu cevapsız kalmıyordu; bir cevap geliyordu, ama cevabın içindeki SOA kaydında ns1.vercel-dns.com yazıyordu. Yani cevap iç DNS’ten değil, sitenin public DNS’inden, internetten gelmişti. Sorgu hiçbir zaman Domain Controller’a ulaşmamıştı.

Buradan çıkardığım kural şu: bir DNS sorgusu “başarısız” olmadığında da yanlış olabilir. Cevabın içeriğine değil, nereden geldiğine bakın.

IPv6’nın ne olduğunu, adresinin nasıl okunduğunu ve kimse açmadığı halde neden çoğu ağda hazır bulunduğunu IP adresi ve IPv6 makalemizde anlatıyoruz.

Sebep şudur: Windows çift yığın (dual stack) çalışır ve ortamda bir IPv6 DNS sunucusu varsa (genellikle router’ın IPv6 duyurusundan veya DHCPv6’dan gelir), ad çözümleme o tarafa kayabilir. O sunucu sizin iç domain’inizi bilmez, soruyu internete iletir ve size dış dünyanın cevabını getirir. Ekranda gördüğünüz hata DNS_INFO_NO_RECORDS (0x0000251D) olur: soru gitti, cevap boş geldi.

Ayırt edici işaret, cevabın nereden geldiğidir. nslookup çıktısında iç DNS’inizin adı yerine internetteki bir isim sunucusunun SOA kaydını görüyorsanız, sorgu hiçbir zaman DC’nize ulaşmamıştır.

İki adres ailesini birden listeleyin:

Get-DnsClientServerAddress | Select-Object InterfaceAlias, AddressFamily, ServerAddresses

IPv6 satırında sizin DC’niz olmayan bir adres varsa şüpheli bulunmuş demektir.

Teşhis için IPv6’yı geçici olarak kapatıp katılımı tekrar deneyebilirsiniz. Sorun kayboluyorsa kaynağı doğrulamış olursunuz. Ama burada durmayın: bu bir test, çözüm değil.

Kalıcı çözüm üç kademelidir, sırayla deneyin.

1. Kök sebebi düzeltin. Doğru çözüm budur: sorun IPv6’da değil, yanlış bir DNS sunucusunun ortamda olmasındadır. Adaptörden IPv6 DNS adresini kaldırın, ya da DC’nizin IPv6 adresine çevirin. Lab ortamındaysanız router’ın o segmentteki IPv6 duyurusunu kapatmak da işi görür.

2. Yetmiyorsa IPv4’ü tercih ettirin. Microsoft’un adını vererek önerdiği yöntem budur. IPv6 çalışır kalır, yalnızca öncelik sırası değişir:

reg add "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" /v DisabledComponents /t REG_DWORD /d 32 /f

Değer 32 (onaltılık 0x20), “Prefer IPv4 over IPv6” anlamına gelir. Değişiklik yeniden başlatma ister. Sonrasında doğrulayın:

netsh interface ipv6 show prefixpolicies

Çıktıda ::ffff:0:0/96 satırının önceliği ::/0 satırından yüksek olmalı.

3. Tam kapatma son çaredir ve Domain Controller’da hiç yapılmaz. Aynı registry değerinin 255 (0xFF) hali IPv6’yı kapatır. İki uyarı: 0 ve 32 dışındaki her değer Routing and Remote Access servisini bozar, yani VPN veya NAT rolü çalıştıran bir sunucuda sessiz bir arıza üretirsiniz. Ve internette sık görülen 0xffffffff değeri yanlıştır, açılışa beş saniye gecikme ekler; doğrusu 0xff’tir.

Son bir ayrıntı, çünkü sık yanılgı üretiyor: registry değeri, adaptör özelliklerindeki IPv6 kutusunun görüntüsünü değiştirmez. Kutu işaretli görünmeye devam eder. “Kutu işaretli, demek ki IPv6 açık” çıkarımı bu yüzden güvenilir değildir; durumu yukarıdaki prefixpolicies komutuyla doğrulayın.

Sanal Makineler Farklı Ağ Modunda

Lab ortamına özgü ama pratikte en çok zaman kaybettiren arıza budur. Domain Controller’ı bridged modda çalıştırıp yeni sunucuyu NAT modunda bırakırsanız iki makine farklı ağ segmentlerine düşer. Buradaki tuzak, bağlantının tamamen kopmaması: NAT’taki makine dışarı çıkabildiği için bridged sunucuya erişebilir, ama ters yön çalışmaz. Bridged sunucu, NAT’ın arkasında kalan adrese kendiliğinden ulaşamaz.

Tek yönlü çalışan bir bağlantı, hiç çalışmayandan daha zor teşhis edilir. Katılım ilk temasta başarılı bile olabilir; ardından makine DNS’e NAT ağındaki adresini kaydeder ve domain’deki hiç kimse ona o adresten erişemez. Belirti DNS veya Active Directory sorunu gibi okunur, oysa katman çok daha aşağıdadır.

Katılım denemesinden önce iki makinenin de aynı ağ modunda olduğunu doğrulayın ve ping testini iki yönde de yapın. Tek yönlü test bu arızada yanıltır: NAT’tan bridged’a atılan ping döner, siz de ağın sağlam olduğuna hükmedersiniz. Sanallaştırma platformlarında ağ modu seçimi ve segment tasarımı için hypervisor ve sanallaştırma rehberimize bakabilirsiniz.

AD’de Kalmış Eski Bilgisayar Nesnesi

Bir makine formatlanıp aynı adla yeniden kurulduğunda, AD’deki eski nesne yerinde durmaya devam eder. Yeni makine katılmaya çalıştığında bugün göreceğiniz hata büyük ihtimalle şudur:

An account with the same name exists in Active Directory.
Re-using the account was blocked by security policy.
0xaac (2732) NERR_AccountReuseBlockedByPolicy

Bu, bir önceki bölümde anlatılan katılım sıkılaştırmasının aynısıdır: nesne var, ama onu açan kimlikle katılımı yapan kimlik uyuşmuyor. İşe giriş benzetmesiyle aynı isimde kapatılmamış eski bir sicil dosyası vardır ve yeni kimlik kartı o dosyayla eşleşmez. Daha ayrıntılı gerekçe C:\Windows\debug\netsetup.log dosyasında bulunur.

Microsoft’un çözüm sırası nettir. Nesne hâlâ kullanılıyorsa onu oluşturan hesapla katılın. Nesne ölüyse silin ve yeniden deneyin, sahada en sık karşılaşılan durum budur. Alternatif olarak makineyi yeniden adlandırıp AD’de karşılığı olmayan bir adla katabilirsiniz.

Silmeyi bir alışkanlığa çevirin: makine hurdaya çıktığında veya yeniden kurulacağında nesneyi de kapatın. Yıllar içinde birikmiş ölü nesneler yalnızca kirlilik değil, saldırı yüzeyidir.

Bozulan Güven İlişkisi

Makine hesabı da bir hesaptır ve parolası vardır; Windows bu parolayı varsayılan olarak 30 günde bir kendiliğinden değiştirir. Makine uzun süre kapalı kaldıysa veya eski bir snapshot’tan geri döndürüldüyse elindeki parola AD’dekinden geride kalır ve güven ilişkisi kopar. Klasik refleks domain’den çıkıp yeniden katmaktır; gerek yoktur, çünkü bu iki yeniden başlatma ve bir kullanıcı profili riski demektir.

Onarım için önce makineye yerel yönetici hesabıyla oturum açın: güven ilişkisi kopmuşken domain hesabıyla giremezsiniz, oturum açma ekranında kullanıcı adını .\Administrator biçiminde yazmanız gerekir. İçeri girdikten sonra domain tarafında makine hesabını sıfırlama yetkisi olan bir hesapla tazeleyin:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

Komut True dönerse ilişki tazelenmiştir, yeniden başlatmaya bile gerek kalmadan makine domain’e yeniden konuşur.

Ölçek: Elli Makineyi Tek Tek Katmamak

Beş makinede arayüzden katılım en hızlı yoldur. Elli makinede aynı yöntem, elli kez tekrarlanan bir ritüele ve kaçınılmaz olarak birkaç yanlış OU’ya dönüşür. İK masası büyüdükçe işe giriş de elle değil, önceden hazırlanmış paketlerle yapılır.

Uzaktan katılım. Add-Computer bir makine listesi alabilir; makinelerin ağda açık ve erişilebilir olması yeterlidir:

$makineler = "PC-IST-011", "PC-IST-012", "PC-IST-013"
Add-Computer -ComputerName $makineler `
  -DomainName "ad.sercebilisim.com" `
  -OUPath "OU=Bilgisayarlar,OU=Genel_Mudurluk,OU=Lokasyonlar,DC=ad,DC=sercebilisim,DC=com" `
  -Credential (Get-Credential) `
  -LocalCredential (Get-Credential) `
  -Restart

İki ayrı kimlik bilgisi istenmesi kafa karıştırır: -Credential domain’e katma yetkisine sahip hesaptır, -LocalCredential ise hedef makinede yönetici olan yerel hesaptır.

Toplu katılımda bir noktaya dikkat edin: listedeki makinelerden herhangi biri için AD’de aynı adla bir nesne zaten duruyorsa, o makine yukarıda anlatılan hesap yeniden kullanım kısıtına takılır ve 0xaac ile düşer. Elli makinelik bir listede bu, sessizce atlanan üç makine demektir; komut çıktısını sonuna kadar okuyun.

Offline domain join (djoin). Merkezde bir katılım paketi üretilir, makineye taşınır, orada uygulanır. Kart merkezde basılıp şubeye gönderilir; personel işe başladığı gün kartı zaten cebindedir.

Bu yöntem genelde “VPN’i olmayan şube” çözümü diye anlatılır ve öyle de çalışır: makinenin katılım anında Domain Controller’a hiç ulaşması gerekmez, kurulum sırasında ağa çıkmayan bir imaj veya kapalı bir üretim hattı için biçilmiş kaftandır. Ama asıl gerekçesi başkadır. djoin /requestODJ komutu hedef makinede Active Directory üzerinde hiçbir izin gerektirmez; Microsoft yöntemi tam da bu yüzden öneriyor, çünkü katılım için sahaya dağıtılması gereken yetkiyi sıfıra indirir. Bir önceki bölümdeki izin ve sahiplik karmaşasının en temiz cevabı budur.

Domain’e üye ve yetkili bir makinede paketi üretin:

djoin /provision /domain ad.sercebilisim.com /machine DHCP01 /machineou "OU=Sunucular,DC=ad,DC=sercebilisim,DC=com" /savefile C:\dhcp01-odj.txt

Hedef makinede yönetici komut isteminde uygulayın ve yeniden başlatın:

djoin /requestODJ /loadfile C:\dhcp01-odj.txt /windowspath %SystemRoot% /localos

İmaj ve otomasyon. Kurulum imajıyla dağıtım yapıyorsanız katılımı unattend.xml dosyasındaki Microsoft-Windows-UnattendedJoin bileşenine taşıyabilir, ya da imajın içine bir djoin paketi gömebilirsiniz. MDT, WDS ve Intune ile Autopilot da bu adımı kendi süreçlerinin içinde halleder. Ölçek büyüdükçe soru “bilgisayarı domain’e nasıl eklerim” olmaktan çıkar, “yeni bir makine kutusundan çıktığında hangi departmana, hangi politikalarla ve kimin onayıyla düşer” haline gelir. Cevabı katılım komutunda değil, OU tasarımınızda ve yetki devrinizde saklıdır.

Bu ölçeğin gerçekte neye benzediğini merak ediyorsanız: cihazlarının yüzde 99’u WORKGROUP’ta olan bir eğitim kurumunda 1.500 cihazı bir ay içinde domain’e taşıdığımız Active Directory modernizasyon vaka çalışmasında bu rehberdeki her adımın saha karşılığını bulabilirsiniz.

Sonraki Adımlar

Bilgisayar ve sunucularınız domain üyesi olduğunda kimlik altyapısı asıl işini yapmaya başlar: ayarlar tek merkezden dağıtılır, yetkiler gruplarla yönetilir, oturum kayıtları tek yerde toplanır. Sıradaki adım bu makineleri gerçekten yönetmektir. Active Directory GPO yönetimi ile politika dağıtımını kurabilir, Active Directory kurulum rehberindeki domain adı ve OU kararlarını gözden geçirebilir, domain üyesi bir sunucuya DHCP rolü kurarak IP dağıtımını da merkeze alabilirsiniz.

Yazan

İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştüren bir ağ ve sistem mühendisidir. Şirketlere özel teknoloji rehberleri burada.