Domain'e Bilgisayar Ekleme: Adımlar, Ön Koşullar ve Hatalar

Bilgisayarı domain’e eklemek (Windows’un Türkçe arayüzündeki adıyla etki alanına eklemek), makinenin kimlik kaynağını kendi yerel hesap veritabanından Active Directory’ye devretmesidir. Sahada “bilgisayarı domaine alma” ya da “domaine dahil etme” de denir, üçü aynı iştir.

Katılım tamamlandığında bilgisayar domain’de bir nesne olarak var olur, kullanıcılar kurumsal hesaplarıyla oturum açar ve makinenin ayarları tek merkezden yönetilir. İşlemin kendisi bir pencere ve bir yeniden başlatmadır. Katılımın düştüğü ya da başarılı görünüp işe yaramadığı yerler, o pencereden önce ve sonra yapılanlardadır.

Bu yazıdaki ekranları ve çıktıları lab domain’imiz ad.sistemkusu.com’a yeni bir Windows 11 bilgisayarı katarken aldım: Ankara muhasebedeki ilk bilgisayar, ankmuh01. Katılımı Domain Admin değil, Ankara helpdesk’inin standart hesabı ayse.demir yaptı. İlk deneme düştü ve sebebi ekranda hiç görünmüyordu. Ne olduğunu IPv6 bölümünde anlattım.

Serinin benzetmesiyle Active Directory bir otelin kart sistemidir. Bilgisayarı domain’e eklemek, yeni bir odanın kapısına kart okuyucu takıp onu ön büronun sistemine kaydetmektir. Okuyucu takıldığı an değil, sisteme doğru kaydedildiği an işe yarar: odanın hangi katta olduğu, hangi kartları kabul edeceği ve ön büroyla hangi şifreyle konuşacağı o kayıtta yazılıdır.

Yazı BT Sistem Yönetimi hizmetimizin kimlik altyapısı koluna odaklanır ve Active Directory rehberimizin “Bilgisayarları Domain’e Ekleme” bölümünün devamıdır. Ö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 düştüğü vakaların çoğu katılım penceresinde değil, o pencereye gelmeden önce kaybedilir. Aşağıdaki beş koşulu sırayla doğrulayın, katılım komutunu yazdığınızda geriye yalnız onay kalsın.

Beşinden ö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 ve kayıt defterinde açılacak bir anahtar da yoktur. Katılacak makine Pro, Enterprise ya da Education olmalıdır. Lab’daki ankmuh01 Windows 11 Pro, sürüm 26H2. Sürümü Settings → System → About ekranındaki Edition satırı ya da winver gösterir.

DNS Domain Controller’ı Göstermeli

Bilgisayar, katılacağı domain’i DNS üzerinden bulur. Bu yüzden makinenin DNS sunucusu bir domain controller olmak zorundadır. Modemin, internet sağlayıcısının ya da 8.8.8.8’in adresi yazılıysa katılım 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 ve istemci “bu domain’de kimlik doğrulamayı kim yapıyor?” sorusunu bu kayıtlara sorar. Örnekteki otelde bu, dahili telefon rehberidir: “kart kodlama hangi masada?” sorusunun cevabı yalnız otelin kendi rehberinde yazar, şehrin telefon rehberinde yoktur. Kayıt türlerini ve bir sorgunun hangi sunucuya gittiğini DNS nedir yazımızda anlattık.

DNS adresini klasik Network Connections penceresinden verin. Settings uygulaması sürümden sürüme yer değiştirir. Çalıştır kutusuna (Win+R) yazılan ncpa.cpl ise Windows Server dahil yıllardır aynı penceredir ve Settings’in göstermediği ayarları da taşır: DNS suffix listesi ve Register this connection’s addresses in DNS yalnız buradaki Advanced → DNS sekmesinde var.

Menü yolu: Win+R → ncpa.cpl → Ethernet0’a sağ tık → Properties → Internet Protocol Version 4 (TCP/IPv4) → Properties.

1. Use the following DNS server addresses: seçilir. IP adresi DHCP’den gelmeye devam edebilir, yalnız DNS elle verilir.
2. Preferred DNS server: 192.168.1.10 (dc01).
3. Alternate DNS server: ikinci domain controller, lab’da dc02 (192.168.1.11). dc02 lab’da çoğu zaman kapalı durduğu için katılımda boş bıraktım.

İki pencere aynı ayarı yazıyor, birbirine karşı çalışmıyor. Lab’da ncpa.cpl’den yazdığım ikinci adres Settings’te göründü, Settings’ten sildiğimde ncpa.cpl’den de kalktı. İkisi de kayıt defterinde adaptörün aynı NameServer değerini değiştiriyor. Aynı ayar Settings’te Network & internet → Ethernet → DNS server assignment → Edit yolundadır.

Komut karşılığı, yükseltilmiş PowerShell’de:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses 192.168.1.10

Ayarın işe yarayıp yaramadığını SRV kaydını sorarak doğrulayın:

nslookup -type=SRV _ldap._tcp.dc._msdcs.ad.sistemkusu.com 192.168.1.10

Lab’da DC’ye doğrudan sorulan bu sorgu iki kayıt döndürdü: dc01 ve dc02, port 389. Sorguyu sunucu belirtmeden çalıştırdığımda ise cevap başka bir yerden geldi. Bu farkı IPv6 bölümünde ayrıca anlattım, çünkü katılımın ilk denemesi tam burada düştü. İç DNS’in kurulması ve forwarder yapılandırması Active Directory DNS yapılandırması yazımızda duruyor.

Saat: Kerberos’un 5 Dakikası ve Windows’un Telafisi

Saati katılımdan önce her makinede elle karşılaştırmak gerekmiyor. Kerberos’un fabrika ayarındaki sınırı 5 dakikadır ve bu sınır domain’in Maximum tolerance for computer clock synchronization ayarında durur. Ama lab’da saati 10 dakika, sonra 2 saat ileri alınmış bir sunucu da domain’e katıldı.

Ölçümü srv01’de yaptım. Saat eşitlemesini kapattım ve saati önce 10 dakika, sonra 2 saat ileri aldım:

1. +10 dakika: Add-Computer hatasız bitti, yeniden başlatmadan sonra nltest /sc_verify NERR_Success döndü.
2. +2 saat: katılım yine hatasız bitti. Yeniden başlatmadan sonra SISTEMKUSU\ilker.pehlivan ile domain oturumu açıldı, klist tgt Kerberos biletini gösterdi.
3. dc01’in günlüğü: iki denemede de bilet verme (4768) ve servis bileti (4769) olayları düştü, ön kimlik doğrulama hatası (4771) düşmedi.

Microsoft’un Kerberos uzantı belgesi MS-KILE bunun bir yolunu tarif eder: saat farkı hatası, karşı tarafın saatini de taşır ve istemci bu saate göre yeniden dener. Belge bunu servis tarafı için açıkça yazıyor. Domain controller’ın bilet verirken de farkı telafi ettiğini belgede değil, lab’daki 4768 olaylarında gördüm.

Örnekteki otelde kart okuyucunun saati geride kalınca geçerli kart da reddedilir. Windows’ta okuyucu reddederken kendi saatini de söyler ve misafir kartını o saate göre yeniden gösterir.

Saat yine de eşit tutulur, çünkü telafi her sistemde yok ve farklı saatli makinelerin günlükleri olayları yanlış sırayla gösterir. Domain’de saatin nasıl aktığını (üyeler bir DC’den, DC’ler PDC Emulator’den, o da dış kaynaktan) Active Directory kurulumu yazımızda anlattık. Lab’da srv01’in saat servisi yeniden açılınca saat iki saat geriye, dc01’in saatine döndü. Katılım saat şüphesiyle düşerse teşhisi aşağıda.

Bilgisayarın Adı Katılımdan ÖNCE Verilmeli

Makinenin adını katılımdan sonra değiştirmek mümkündür, ama gereksiz bir iştir. Katılım sırasında Windows, Active Directory’de o adla bir bilgisayar nesnesini arka planda kendisi açar. Ad sonradan değişince Windows bu nesnenin adını, ona bağlı DNS kaydını ve servis adlarını da güncellemek zorundadır: iş domain’de yazma yetkisi ve bir yeniden başlatma daha ister.

Kurulumdan çıkan Windows 11 makineye WIN-7MG655VTVO2 gibi rastgele bir ad verir. Adı klasik System Properties penceresinden verin. Bu pencere ad ile domain üyeliğini aynı yerde gösterir.

Menü yolu: Win+R → sysdm.cpl → Computer Name sekmesi → Change…

1. Computer name: yeni ad, lab’da ankmuh01.
2. Member of: katılımdan önce Workgroup seçili durur, şimdilik dokunmayın.
3. OK: pencere yeniden başlatmayı ister, ad açılıştan sonra geçerli olur.

Aynı pencere Settings’te System → About → Rename this PC olarak da var, ama orada domain alanı yok. Komut karşılığı:

Rename-Computer -NewName "ankmuh01" -Restart

İki kural var: ad 15 karakteri geçmez (NetBIOS sınırı) ve Türkçe karakter taşımaz. ankmuh01 Ankara’nın (ank), muhasebenin (muh) ve envanter numarasının (01) birleşimidir. Böyle bir ad, üç yıl sonra log okurken makinenin nerede olduğunu söyler.

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

Katılımdan önce makinede, parolasını bildiğiniz ve çalıştığını gördüğü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 bozulduğunda, örneğin 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 11’de yerleşik Administrator hesabı fabrika ayarında kapalı gelir. ankmuh01’de de kapalıydı ve kurulumda açılan yerel hesap ilkerpehlivan çalışan tek yöneticiydi. Hesabın gerçekten çalıştığını bir kez oturum açarak görün, çünkü işe yaramayan bir kurtarma hesabı size olmayan bir güven verir.

Birkaç makineden fazlasında bu parolaları elle yönetmek sürdürülemez. LAPS her makinenin yerel yönetici parolasını ayrı tutar ve kendiliğinden döndürür. ankmuh01 katıldıktan altı dakika sonra LAPS makinede yerelyonetici hesabını açtı ve parolasını AD’ye yazdı.

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ı fabrika ayarında en fazla 10 bilgisayarı domain’e katabilir. Sınırı ms-DS-MachineAccountQuota özniteliği belirler ve on birinci makinede katılım, sebebi ilk bakışta anlaşılmayan bir yetki hatasıyla durur.

Doğru çözüm kotayı yükseltmek değil, yetkiyi bilinçli vermektir. İki yol var:

1. OU’ya yetki devri: ADUC’ta hedef OU’ya sağ tıklayıp Delegate Control ile bir gruba yalnız o OU altında bilgisayar nesnesi oluşturma izni verilir.
2. Nesneyi önceden açmak: nesneyi Domain Admin açar ve katılım yetkisini tek bir makine için bir gruba verir. Lab’da bu yolu kullandım, nesneyi katılımdan önce açmak bölümünde anlatıyorum.

İkisinde de 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ı yazımızda Tier modeli üzerinden anlattık.

Ağ tarafında istemciden domain controller’a şu portlar açık olmalıdır: 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. Arayüzden ya da PowerShell’den yapılı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 ile açıp sysdm.cpl yazın. Windows 11’de aynı pencereye Settings → System → About → Domain or workgroup bağlantısı da gider. Komutu önermemin sebebi dayanıklılık: Ayarlar uygulamasının menüleri sürümden sürüme yer değiştiriyor, sysdm.cpl ise yıllardır aynı pencereyi açıyor. Sunucularda Server Manager’ın Local Server sayfasındaki WORKGROUP bağlantısı da arkada bu pencereyi çağırır.

System Properties penceresinde Change düğmesine basın ve açılan Computer Name/Domain Changes penceresini doldurun:

1. Computer name: ankmuh01. Ad önceden verildiyse burada yalnız kontrol edilir.
2. Member of: Domain seçilir ve domain adı tam hâliyle yazılır: ad.sistemkusu.com.

OK’e basınca Windows katılım yetkisi olan bir hesabın credential’ını (kimlik bilgisi) sorar. Kullanıcı adını UPN biçiminde yazdım: ayse.demir@ad.sistemkusu.com.

İlk denemem burada düştü. Windows şu hatayı verdi:

Sebebini IPv6 bölümünde anlattım. DNS düzeltildikten sonra aynı pencere 17:12:50’de “Welcome to the ad.sistemkusu.com domain.” dedi ve yeniden başlatma istedi. Pencerenin altında artık Full computer name: ankmuh01.ad.sistemkusu.com yazıyordu.

PowerShell ile Katılım

Tek makinede arayüz yeterlidir. Birden fazla makinede, kurulum belgelenecekse ya da işlem bir betiğin parçasıysa PowerShell daha uygundur. Yükseltilmiş PowerShell’de:

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

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

Add-Computer -NewName "ankmuh01" -DomainName "ad.sistemkusu.com" -Credential (Get-Credential) -Restart

Nesnenin doğrudan hedef OU’ya yazılması için -OUPath verilir. Bir sonraki bölümün konusu tam olarak budur:

Add-Computer -DomainName "ad.sistemkusu.com" `
  -OUPath "OU=Ankara,OU=Bilgisayarlar,OU=Tier 2,DC=ad,DC=sistemkusu,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 Sign in to: SISTEMKUSU yazısını görmek iyi bir işarettir, kanıt değildir. O ekran makinenin kendini domain üyesi saydığını gösterir. Üç şeyi göstermez:

1. DC’ye gerçekten ulaşılıyor mu? Windows son oturumları önbelleğe aldığı için hiçbir DC’ye ulaşılamasa da giriş yapılabilir.
2. Nesne AD’de nereye düştü? Oturum ekranı bunu bilmez.
3. Güvenli kanal sağlam mı? Güvenli kanal (secure channel), makinenin kendi hesabının parolasıyla domain controller’a kurduğu doğrulanmış bağlantıdır. Parola iki tarafta uyuşmazsa kanal kurulamaz, ama önbellekten giriş çalışmaya devam eder.

Örnekteki otelde kapıdaki okuyucunun yanması kartın çalıştığını kanıtlamaz, okuyucunun ön büroyla konuştuğunu ancak bir kart okutunca görürsünüz. Katılımı iki taraftan doğrulayın.

İstemci tarafında üç komut yeterli ve ikisi yükseltilmiş oturum ister. Lab’da önce standart kullanıcı ayse.demir olarak denedim:

1. nltest /sc_verify erişim reddi (ERROR_ACCESS_DENIED) döndürdü.
2. gpresult /r /scope:computer de Access Denied dedi.

Yerel yönetici ilkerpehlivan ile yükseltilmiş PowerShell’de güvenli kanalı yeniden sordum:

nltest /sc_verify:ad.sistemkusu.com

Flags: 800000b0 HAS_IP  HAS_TIMESERV  Authentication Service: Kerberos
Trusted DC Name \\dc01.ad.sistemkusu.com
Trusted DC Connection Status Status = 0 0x0 NERR_Success
Trust Verification Status = 0 0x0 NERR_Success
The command completed successfully

Çıktıdan üç şey okunur:

1. Trusted DC Name: makinenin konuştuğu DC, burada dc01.
2. Authentication Service: Kerberos: kimlik doğrulama Kerberos’la yapılıyor. Lab’da saati 2 saat ileri alınmış srv01’de de bu satır aynı geldi.
3. Trust Verification Status: güvenli kanal sağlam.

Aynı soruyu PowerShell yükseltme istemeden de sorar. Test-ComputerSecureChannel yükseltilmemiş oturumda da True döndü:

Test-ComputerSecureChannel -Verbose

Katılımın geçmişini System event log’u tutar. NetJoin olaylarında iki deneme yan yana görünüyordu:

17:06:00 4097 The machine ankmuh01 attempted to join the domain ad.sistemkusu.com but failed. The error code was 1355.
17:06:00 4097 The machine ankmuh01 attempted to join the domain ad.sistemkusu.com but failed. The error code was 1355.
17:12:50 4100 During domain join, the domain controller contacted found an existing computer account in Active Directory with the same name.
17:12:50 4096 The machine ankmuh01 successfully joined the domain ad.sistemkusu.com.

4100 olayı katılımın yeni bir nesne açmadığını, önceden açılmış nesneyi kullandığını söylüyor. Neden böyle olduğu bir sonraki bölümün konusu.

Sunucu tarafında nesnenin AD’de nerede durduğuna bakın. dc01’de:

Get-ADComputer ankmuh01 -Properties DNSHostName, whenCreated, whenChanged, OperatingSystem, OperatingSystemVersion, LastLogonDate |
  Format-List Name, DNSHostName, Enabled, whenCreated, whenChanged, OperatingSystem, OperatingSystemVersion, LastLogonDate, DistinguishedName

Name                   : ankmuh01
DNSHostName            : ankmuh01.ad.sistemkusu.com
Enabled                : True
whenCreated            : 8.10.2026 22:30:26
whenChanged            : 9.10.2026 17:12:50
OperatingSystem        : Windows 11 Pro
OperatingSystemVersion : 10.0 (26300)
LastLogonDate          : 9.10.2026 17:12:50
DistinguishedName      : CN=ankmuh01,OU=Ankara,OU=Bilgisayarlar,OU=Tier 2,DC=ad,DC=sistemkusu,DC=com

Nesne katılımdan bir gün önce açılmış, katılım anında güncellenmiş. Son satır nesnenin Ankara’nın OU’sunda durduğunu söylüyor. Aynı bilgi Active Directory Administrative Center’da (ADAC) Tier 2 → Bilgisayarlar → Ankara altında görünür. Operating system sütununu listeye sütun menüsünden ekledim:

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

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

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

Örnekteki otelde bu, kart okuyucusu sisteme kaydedilmiş ama hiçbir kata yazılmamış bir odadır. Otelin bütün odalarına giden genel ayarlar ona da gelir, ama kat şefinin kendi katına verdiği ayarlar gelmez, çünkü oda hiçbir katta değildir.

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

Farkın en net kanıtını iki konsolu yan yana açınca görürsünüz. ADUC’ta Computers konteyneri vardır, GPMC’de ise Computers diye bir düğüm hiç yoktur. Group Policy Management konsolu ağacında yalnız OU’ları listeler, çünkü GPO linklenebilecek yerler yalnız onlardır.

Nesnenin düşebileceği üç yer var ve her biri makineye farklı bir policy seti verir. Bu bölümün geri kalanı üçünü sırayla anlatıyor:

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

redircmp, hedef verilmeden katılan makinenin nesnesini Computers konteyneri yerine sizin seçtiğiniz bir OU’ya düşürür. Asıl kazancı dosyalama değildir: makine doğru OU’ya taşınana kadar geçen sürede de policy alır.

O makine taşınmayı beklerken boş durmaz: ağa bağlı, açık ve kullanılabilir durumdadır. Kullanıcı başına oturur, USB takar, tarayıcı açar. Computers konteynerine düşen makineye yalnız domain seviyesine linklenmiş policy’ler ulaşır. Parola kuralı gibi genel ayarlar gelir, ama USB kısıtı, güvenlik taban ayarları ve ekran kilidi süresi gibi OU’ya linklenen hiçbir şey gelmez. Bu boşluk birkaç saat de sürebilir, kimse fark etmezse haftalar da.

Komut bu boşluğu kapatır: yol belirtilmeden oluşturulan bütün yeni bilgisayar nesnelerinin hangi OU’ya düşeceğini kalıcı olarak tanımlar. Hedef bir OU olduğu için oraya GPO linkleyebilirsiniz ve makine daha ilk açılışında taban policy’yi alır.

Domain Admin yetkisiyle bir domain controller’da bir kez çalıştırılır:

redircmp "OU=Yeni Bilgisayarlar,OU=Tier 2,DC=ad,DC=sistemkusu,DC=com"

İki noktaya dikkat:

1. Komut yalnız bundan sonra oluşacak nesneleri etkiler. Computers konteynerinde bekleyen nesneler kendiliğinden taşınmaz.
2. Hedef bir OU olmalıdır, konteyner değil. Amaç zaten budur.

Bu OU Nereye Konur ve Neden Tek Tanedir?

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.

Bu kısıt 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 OU’dur (Tier 2\Bilgisayarlar\Ankara gibi), buradaki duraklama geçicidir. Bu yüzden OU’yu lokasyon ağacının dışına, Bilgisayarlar ile aynı seviyeye koyun: makine oraya düştüğünde hangi lokasyona ait olduğu henüz belli değildir.

Buraya linkleyeceğiniz taban GPO’yu tasarlarken ölçüt şu: makine bu policy’yle ağda güvenle bekleyebilir mi? Kullanıcının işini yapmasını sağlamak zorunda değilsiniz, amaç korumasız bir pencere bırakmamaktır.

Tek olmanın operasyonel bir kazancı da var: bu OU’da duran her nesne dosyalanmamış iş demektir. Boşsa her şey yerindedir, doluysa birinin taşıması gerekiyordur.

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 kurgusunu ve yetki devrini Active Directory kullanıcı, grup ve OU yönetimi yazımızda anlattık.

Nesneyi Katılımdan Önce Açmak

Daha temiz bir yol var: nesneyi makine gelmeden önce doğru OU’da açmak. Örnekteki otelde bu, kart okuyucu takılmadan önce odanın kaydını doğru katta açmaktır: okuyucu takıldığı an oda zaten yerindedir.

Faydası şu: makine ilk açılışından itibaren kalıcı OU’sunun policy’lerini alır, ne Computers konteynerine ne redircmp ile yönlendirilmiş bir iniş OU’suna uğrar. Nesne makinenin bütün ömrü boyunca da işe yarar: makine formatlandığında ya da yerine aynı kullanıcı için yeni bir cihaz geldiğinde nesne silinmez, sıfırlanır ve yeni kurulum aynı OU’ya, aynı GPO’lara düşer (eski nesneyi devralmak).

Lab’da ankmuh01’in nesnesini katılımdan bir gün önce dc01’de ADAC ile açtım: Tier 2 → Bilgisayarlar → Ankara → Tasks → New → Computer. Formun Computer bölümünde üç alan önemli:

1. Computer name: ankmuh01. Computer (NetBIOS) name alanı kendiliğinden ANKMUH01 olur.
2. Create in: seçili OU, burada OU=Ankara,OU=Bilgisayarlar,OU=Tier 2,....
3. User or Group: makineyi domain’e katabilecek kişi ya da grup. Fabrika ayarında Domain Admins yazar. Ankara helpdesk’inin grubunu seçtim, bugünkü adıyla GG_ANK_IT.

Komut karşılığının yarısı ADAC’ın Windows PowerShell History panelinde görünür:

New-ADComputer -Name "ankmuh01" -Path "OU=Ankara,OU=Bilgisayarlar,OU=Tier 2,DC=ad,DC=sistemkusu,DC=com"

Öbür yarısının, yani User or Group alanının bir parametresi yok. ADAC aynı panelde yalnız nesnenin güvenlik tanımının değiştiğini yazdı: alan, nesnenin izin listesine o grup için yeni girdiler ekliyor.

Bu yolun 2022’den beri bir kuralı var ve çoğu rehber hâlâ eski hâliyle anlatıyor. Windows, 11 Ekim 2022 ve sonraki güncellemelerle var olan bir bilgisayar hesabına katılımı fabrika ayarında engelledi (KB5020276). Katılım ancak şu üç durumdan birinde geçer:

1. Katılımı yapan kişi nesneyi açan kişidir.
2. Nesneyi Domain Admins üyesi biri açmıştır.
3. Nesnenin sahibi, Domain controller: Allow computer account re-use during domain join policy’sindeki güvenilir sahipler listesindedir. Bu yol bütün üye makinelerde ve DC’lerde Mart 2023 ve sonrası güncellemeyi ister.

Bunların dışında katılım 2732 hatasıyla durur (NERR_AccountReuseBlockedByPolicy) ve ekranda şu mesaj çıkar: “An account with the same name exists in Active Directory. Re-using the account was blocked by security policy.” Ayrıntı C:\Windows\debug\netsetup.log dosyasına yazılır. Lab’da sıra şöyleydi:

1. Nesneyi Domain Admins üyesi ilker.pehlivan açtı.
2. Katılımı standart kullanıcı ayse.demir yaptı.
3. netsetup.log kararı şöyle yazdı:

10/09/2026 17:12:50:200 NetpGetComputerObjectDn: Crack results:         (Account already exists) DN = CN=ankmuh01,OU=Ankara,OU=Bilgisayarlar,OU=Tier 2,DC=ad,DC=sistemkusu,DC=com
10/09/2026 17:12:50:207 NetpGetADObjectOwnerAttributes: Ms-Ds-CreatorSid is empty.
10/09/2026 17:12:50:226 NetpCheckIfAccountShouldBeReused: Active Directory Policy check with SAM_DOMAIN_JOIN_POLICY_LEVEL_V2 returned NetStatus:0x0.
10/09/2026 17:12:50:226 NetpCheckIfAccountShouldBeReused: Account re-use attempt was permitted by Active Directory Policy.

İkinci kural işledi: nesneyi açan Domain Admins üyesi olduğu için yeniden kullanım serbest kaldı. Logdaki Ms-Ds-CreatorSid is empty satırı da bununla tutarlı. Bu öznitelik yalnız sıradan bir kullanıcı nesneyi kendi 10 makinelik kotasıyla açtığında yazılır. Nesneyi Domain Admins üyesi ya da bilgisayar oluşturma yetkisi devredilmiş biri açtıysa boş kalır.

Sahada bu kuralın bedelini ödediğim bir vaka var ve sonucu lab’dakinden farklıydı. Kurumun security policy’si gereği lokasyon teknisyenlerinin RSAT ve Active Directory erişimi yoktu, bütün AD operasyonu genel müdürlükten yürüyordu ve 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 yukarıdakiydi. 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 ve o anda elli makine de katıldı.

O ortamda Domain Admin’in açtığı nesne muaf sayılmadı, lab’da sayıldı. İki ortamın farkını bugün ölçemem, o ortamın güncelleme düzeyi ve nesneleri açarken hesabımın üyelikleri elimde değil. Bu yüzden sahada güvendiğim kural değişmedi: 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 offline domain join yöntemine geçin. Microsoft o yöntemi tam da bu yüzden öneriyor. İzinlerin tam listesi Microsoft’un Active Directory domain join permissions sayfasında duruyor.

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

Nesne Yanlış Yerdeyse

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

Makinenin hangi GPO’ları aldığını tahmin etmeyin, sorun. Makinede yükseltilmiş oturumda gpresult /r /scope:computer uygulanan GPO’ları listeler. ankmuh01’de:

COMPUTER SETTINGS
------------------

    Last time Group Policy was applied: 9.10.2026 at 23:09:23
    Group Policy was applied from:      dc01.ad.sistemkusu.com
    Group Policy slow link threshold:   500 kbps
    Domain Name:                        SISTEMKUSU
    Domain Type:                        Windows 2008 or later

    Applied Group Policy Objects
    -----------------------------
        PC_ANK_LAPS
        Default Domain Policy

İki GPO geldi: domain seviyesindeki Default Domain Policy ve Ankara OU’suna linklenmiş PC_ANK_LAPS. İkincisi gelmeseydi nesnenin yeri yanlış demekti.

“Applied Group Policy Objects” bölümünde yalnız Default Domain Policy varsa, nesne büyük ihtimalle hâlâ Computers konteynerindedir. GPO’ların linklenme mantığını Active Directory GPO yönetimi yazımızda anlattık.

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

Buradan çıkan ayrım işinize yarar: policy’nin hangi makineye uygulanacağını nesnenin OU’su belirler, ne kadar sürede uygulanacağını ise istemcinin bağlandığı DC’nin sağlığı ve Sites ve Subnets tanımlarının doğruluğu belirler. gpresult /r çıktısındaki “Group Policy was applied from” satırı policy’nin hangi DC’den geldiğini söyler. Orada beklemediğiniz bir sunucu adı görüyorsanız aranacak 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 ya da kapalı bir servis olabilir. Aşağıdaki tablo sık görülen belirtileri kaynaklarıyla eşleştiriyor. İlk iki satırı, saat satırını ve son satırı bu yazının lab’ında ölçtüm.

Tablodaki beş satır ayrıca açıklama istiyor.

IPv6 DNS Sunucusu Araya Giriyor

IPv6 DNS arızası, teşhisi en zor katılım arızasıdır, çünkü DNS ayarına baktığınızda her şey doğru görünür. Ekranda DNS sunucusu olarak domain controller yazar, yine de sorgu oraya gitmez.

ankmuh01’in ilk katılım denemesi tam bu sebeple düştü. DNS’i o gün Settings’in Edit DNS settings ekranından vermiştim: IPv4 DNS dc01’i gösteriyordu, IPv6 anahtarı Off duruyordu. Off, makinenin IPv6 DNS kullanmayacağı anlamına gelmiyor: elle bir IPv6 DNS verilmediği anlamına geliyor. ncpa.cpl’de aynı durum IPv6 penceresinde Obtain DNS server address automatically olarak görünür. Modem IPv6 duyurusunda kendi DNS adresini vermeye devam ediyordu. İki adres ailesini birden listeleyince bu görünüyordu:

Get-DnsClientServerAddress -InterfaceAlias Ethernet* | Format-Table -AutoSize

InterfaceAlias InterfaceIndex AddressFamily ServerAddresses
-------------- -------------- ------------- ---------------
Ethernet0                   6 IPv4          {192.168.1.10}
Ethernet0                   6 IPv6          {<önek>::1, <önek>::1}

ipconfig /all çıktısındaki sıra daha da açıktı: DNS sunucuları listesinde modemin IPv6 adresi 192.168.1.10’dan önce geliyordu. SRV kaydını sunucu belirtmeden sorduğumda cevap şuydu:

DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  <önek>::1

sistemkusu.com
        primary name server = ns1.vercel-dns.com
        responsible mail addr = hostmaster.nsone.net
        serial  = 1791301714
        refresh = 43200 (12 hours)
        retry   = 7200 (2 hours)
        expire  = 1209600 (14 days)
        default TTL = 600 (10 mins)

Sorgu cevapsız kalmadı, bir cevap geldi. Ama cevabın içindeki SOA kaydında ns1.vercel-dns.com yazıyor: bu, sitemizin internetteki DNS’i. Sorgu modemin DNS’ine, oradan internete gitmiş ve hiçbir zaman DC’ye ulaşmamıştı. Aynı dakikada Resolve-DnsName dc01.ad.sistemkusu.com de dc01’in iç adresini değil, internetteki iki genel IP adresini döndürdü.

Katılım penceresi bunu 1355 hatası olarak gösterdi. netsetup.log’da ilgili satırlar:

10/09/2026 17:06:00:499 NetpJoinDomain
10/09/2026 17:06:00:499         HostName: ankmuh01
10/09/2026 17:06:00:499         NetbiosName: ANKMUH01
10/09/2026 17:06:00:499         Domain: ad.sistemkusu.com
10/09/2026 17:06:00:499         MachineAccountOU: (NULL)
10/09/2026 17:06:00:499         Account: ayse.demir@ad.sistemkusu.com
10/09/2026 17:06:00:516 NetpCheckDomainNameIsValid for ad.sistemkusu.com returned 0x54b, last error is 0x0
10/09/2026 17:06:00:516 NetpJoinDomainOnDs: Domain name is invalid, NetpValidateName returned: 0x54b
10/09/2026 17:06:00:516 NetpDoDomainJoin: status: 0x54b

0x54b onaltılık tabanda 1355’tir, ERROR_NO_SUCH_DOMAIN. Aynı log yarım dakika önce, 17:05:32’de aynı domain adı için 0x0 yazmıştı. Yani arıza sabit değildi: bazı sorgular DC’ye ulaşıyor, bazıları modeme gidiyordu. Aralıklı bir arıza, hiç çalışmayandan daha zor teşhis edilir.

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 ve kimse açmadığı hâlde neden çoğu ağda hazır bulunduğunu IP adresi ve IPv6 yazımızda anlattık.

Teşhis için IPv6’yı geçici olarak kapatıp katılımı yeniden 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. Sorun IPv6’da değil, ortamda yanlış bir DNS sunucusunun olmasındadır. IPv6 DNS adresini DC’nin IPv6 adresine çevirin. Yolu IPv4’ünkiyle aynıdır, yalnız protokol değişir: ncpa.cpl → Ethernet0 → Properties → Internet Protocol Version 6 (TCP/IPv6) → Properties → Use the following DNS server addresses, Preferred DNS server alanına dc01’in IPv6 adresi.

Lab’daki ilk düzeltmeyi Settings’te, IPv6 anahtarını On’a alıp yaptım. Bu anahtarı yeniden Off’a aldığımda adaptörün IPv6 kutusu işaretli kaldı, yalnız elle yazılan IPv6 DNS silindi ve ayar otomatiğe döndü. Settings’teki Off, IPv6’yı kapatmıyor.

Kaydettikten sonra üç şey değişti:

1. Get-DnsClientServerAddress iki adres ailesinde de yalnız dc01’i gösterdi.
2. Sunucu belirtmeden sorulan SRV sorgusu dc01 ve dc02 kayıtlarını döndürdü.
3. İkinci katılım denemesi geçti.

Komut karşılığı:

Set-DnsClientServerAddress -InterfaceAlias "Ethernet0" -ServerAddresses 192.168.1.10, "<önek>:6d13:e8f7:9bef:d021"

Lab ortamındaysanız modemin o segmentteki IPv6 DNS 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ız ö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 ve 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) hâli IPv6’yı kapatır. İki uyarı var:

1. 0 ve 32 dışındaki her değer Routing and Remote Access servisini bozar. VPN ya da NAT rolü çalıştıran bir sunucuda sessiz bir arıza üretirsiniz.
2. İnternette 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, durumu yukarıdaki prefixpolicies komutuyla doğrulayın.

Katılım Saat Yüzünden mi Düştü? Önce Ölçün

Katılım bir Kerberos hatasıyla düşerse ya da sebebi bulunamıyorsa saati tahminle değil ölçerek eleyin. Komut, makinenin saatini domain controller’ın saatiyle üç kez karşılaştırır:

w32tm /stripchart /computer:dc01.ad.sistemkusu.com /samples:3 /dataonly

ankmuh01’de fark yarım saniyenin altındaydı:

Tracking dc01.ad.sistemkusu.com [[<önek>:6d13:e8f7:9bef:d021]:123].
Collecting 3 samples.
The current time is 9.10.2026 17:01:35.
17:01:35, -00.4825851s
17:01:37, -00.4833308s
17:01:39, -00.4836135s

Lab hattının genel IPv6 öneki bu yazının çıktılarında ve ekranlarında <önek> diye maskelendi.

Satırdaki sayı, makinenin saatinin DC’ninkinden ne kadar ayrı olduğudur. Birkaç saniyelik fark katılımı açıklamaz, sebebi DNS’te ve portlarda aramaya devam edin. Dakikalarca fark varsa saat servisini çalıştırıp saati DC’den alın: w32tm /resync. Sanal makinede bu fark daha sık görülür, çünkü snapshot’a dönen makinenin saati de geriye gider. Saat düzelince ön koşul bölümüne dönüp katılımı yeniden deneyin.

Sanal Makineler Farklı Ağ Modunda

Lab ortamına özgü ama pratikte çok zaman kaybettiren bir arıza. Domain controller’ı bridged modda çalıştırıp yeni sunucuyu NAT modunda bırakırsanız iki makine farklı ağ segmentlerine düşer. 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.

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 ya da 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. Ağ modu seçimi ve segment tasarımı için hypervisor ve sanallaştırma yazımıza bakabilirsiniz.

AD’de Kalmış Eski Bilgisayar Nesnesi

Bir makine formatlanıp aynı adla yeniden kurulduğunda AD’deki eski nesne yerinde durur. Bu çoğu zaman bir sorun değil, kazançtır: nesne makinenin OU’sunu, GPO’larını ve grup üyeliklerini taşır. Sahada formatlanan makinenin nesnesini silmiyorum, Reset Account ile sıfırlayıp makineyi aynı adla yeniden katıyorum. Yeni kurulum ilk açılışından itibaren eskisinin OU’sunda, aynı GPO’larla ve aynı gruplarda başlar.

Aynı yol, eskisinin yerine aynı kullanıcıya verilen yeni bir bilgisayar için de geçerlidir: yeni cihaz eskisinin adını alır ve nesneyi bütün ayarlarıyla devralır. Adın envanter numarası olarak yeniden verilmesini isimlendirme standardı yazımızda anlattık.

Active Directory Users and Computers’ta nesneye sağ tık Reset Account. Microsoft’un Reset a Computer Account sayfasındaki komut karşılığı:

dsmod computer "CN=ankmuh01,OU=Ankara,OU=Bilgisayarlar,OU=Tier 2,DC=ad,DC=sistemkusu,DC=com" -reset

Lab’da srv01’i bu yolla yeniden kattım. ADUC Account SRV01 was successfully reset. dedi. Makine o sırada açıktı ve kısa süre sonra domain hesabıyla oturum açma The trust relationship between this workstation and the primary domain failed. hatası verdi. Reset Account çalışan bir makinenin güven ilişkisini koparır, bu yüzden yalnız yeniden kurulacak ya da yerine yenisi gelecek makinede kullanılır.

Ardından makineyi workgroup’a alıp aynı adla yeniden kattım. netsetup.log kararı Account re-use attempt was permitted by Active Directory Policy. satırıyla yazdı. Nesnenin kimliği değişmedi, yalnız makine hesabının parolası yenilendi:

Workgroup’a alınan makinenin nesnesi silinmedi, kapalı duruma geçti ve OU’sunda, gruplarında bekledi. Yeniden katılım onu açtı.

İşlem Account Operators, Domain Admins ya da bu iş için devredilmiş bir yetki ister. Katılımın geçip geçmeyeceğine ise yine nesneyi önceden açma bölümündeki KB5020276 kuralı karar verir: nesneyi açan kimlikle katılımı yapan kimlik uyuşmazsa yeni kurulum şu hatayı alır:

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

Gerekçe C:\Windows\debug\netsetup.log dosyasındadır. Eski nesneyle ne yapılacağı makinenin geleceğine bağlıdır:

1. Makine aynı işe dönüyorsa nesneyi devralın: Reset Account ile sıfırlayın, katılımı nesneyi açan hesapla ya da Domain Admins üyesi bir hesapla yapın.
2. Makine hurdaya çıktıysa ya da başka bir işe gidiyorsa nesneyi silin. Silinip aynı adla yeniden açılan nesne yeni bir SID alır ve eski üyelikleri taşımaz.
3. Makineyi yeniden adlandırıp AD’de karşılığı olmayan bir adla katın.

Hurdaya çıkan makinenin nesnesini silmeyi bir alışkanlığa çevirin. Yıllar içinde birikmiş ölü nesneler yalnız kirlilik değil, saldırı yüzeyidir.

Bozulan Güven İlişkisi

Oturum ekranındaki The trust relationship between this workstation and the primary domain failed. hatası, makinenin domain controller’la güvenli kanal kuramadığını söyler. Sebep neredeyse her zaman makine hesabının parolasıdır.

Makine hesabı da bir hesaptır ve parolası vardır. Windows bu parolayı fabrika ayarında 30 günde bir değiştirir ve değişimi makinenin kendisi başlatır. Bu yüzden aylarca kapalı kalan makine güvenini kaybetmez: AD’de makine parolasının süresi dolmaz, makine açıldığında parolasının eskidiğini görür ve kendisi yeniler (Microsoft Directory Services ekibi).

Güven, iki tarafın parolası ayrıştığında kopar: makine eski bir snapshot’a ya da yedeğe döndürüldüğünde, klonlandığında ya da hesabı AD’de sıfırlandığında. Örnekteki otelde bu, kapıdaki okuyucunun ön büroyla konuştuğu şifrenin değişmiş olmasıdır: okuyucu yerindedir ama hiçbir kartı doğrulayamaz.

Kaç değişimin yettiğini lab’da ölçtüm. srv01 kapalıyken snapshot aldım, makine parolasını Reset-ComputerMachinePassword ile bir kez değiştirdim ve snapshot’a döndüm. Tek değişim yetti. Açılışta nltest /sc_verify ERROR_ACCESS_DENIED verdi, srv01 Netlogon 3210 (the password for this computer account is not recognized), dc01 Netlogon 5722 olayını yazdı ve domain oturumu yukarıdaki hatayla durdu. Snapshot’taki makine DC’nin bir önceki parolasını sundu, DC onu kabul etmedi.

Bu ölçümden bir çıkarım doğar, çünkü Windows parolayı 30 günde bir değiştirir. 30 günden eski bir snapshot’a dönen makine büyük olasılıkla kopuk açılır. Daha yeni bir snapshot’ta sonuç, arada bir değişim olup olmadığına bağlıdır.

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 ekranında kullanıcı adını .\yerelyonetici biçiminde yazarsınız. İç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 ve makine yeniden başlatmaya bile gerek kalmadan domain’le konuşur. Onarım iki tarafa yeni bir parola yazar: snapshot ölçümünden sonra srv01’i bu komutla onardığımda dc01’deki pwdLastSet onarımın dakikasına geçti.

-Repair olmadan çalışan Test-ComputerSecureChannel teşhis için tek başına güvenilir değil. Lab’da srv01’in hesabını açıkken sıfırladım ve güveni bilerek kopardım. Aynı dakikada iki araç iki farklı şey söyledi:

1. Test-ComputerSecureChannel: True, The secure channel ... is in good condition.
2. nltest /sc_verify:ad.sistemkusu.com: Trust Verification Status = 86 0x56 ERROR_INVALID_PASSWORD.

Domain oturumu da açılmıyordu, yani doğruyu söyleyen nltest /sc_verify idi. Güvenden şüphe ediyorsanız ikisine birden bakın, /sc_verify’ın parola hatasını onarımın gerekçesi sayın. Snapshot ölçümünde iki araç da kopuk dedi (False ve ERROR_ACCESS_DENIED). Test-ComputerSecureChannel’ın yanıldığı durum, hesabın açık makinede sıfırlanmasıydı.

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

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

$makineler = "ankmuh02", "ankmuh03", "ankmuh04"
Add-Computer -ComputerName $makineler `
  -DomainName "ad.sistemkusu.com" `
  -OUPath "OU=Ankara,OU=Bilgisayarlar,OU=Tier 2,DC=ad,DC=sistemkusu,DC=com" `
  -Credential (Get-Credential) `
  -LocalCredential (Get-Credential) `
  -Restart

İki ayrı credential istenmesi kafa karıştırır: -Credential domain’e katma yetkisi olan hesaptır, -LocalCredential ise hedef makinelerde yönetici olan yerel hesaptır.

Toplu katılımda bir noktaya dikkat edin: listedeki makinelerden biri için AD’de aynı adla bir nesne duruyorsa o makine yukarıdaki yeniden kullanım kuralına takılır ve 0xaac hatası verir. 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 ve orada uygulanır. Örnekteki otelde bu, okuyucunun ön büroda kodlanıp kutusuyla odaya gönderilmesidir: oda kapısına takıldığı gün zaten tanınır.

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 DC’ye hiç ulaşması gerekmez. Ama asıl gerekçesi başkadır. djoin /requestODJ komutu hedef makinede Active Directory üzerinde hiçbir izin gerektirmez. Microsoft yöntemi bu yüzden öneriyor, çünkü katılım için sahaya dağıtılan 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.sistemkusu.com /machine ankmuh02 /machineou "OU=Ankara,OU=Bilgisayarlar,OU=Tier 2,DC=ad,DC=sistemkusu,DC=com" /savefile C:\ankmuh02-odj.txt

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

djoin /requestODJ /loadfile C:\ankmuh02-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çlerinde halleder. Ölçek büyüdükçe soru “bilgisayarı domain’e nasıl eklerim?” olmaktan çıkar, “yeni bir makine kutusundan çıktığında hangi OU’ya, hangi policy’lerle ve kimin onayıyla düşer?” hâline 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 kurumda uç noktaların tamamını bir ay içinde domain’e taşıdığımız Active Directory modernizasyon vaka çalışmasında bu yazıdaki her adımın saha karşılığını bulabilirsiniz.

Sonuç: Domain’e Ekleme Pencereden Önce Başlar

Domain’e eklemenin kendisi bir pencere ve bir yeniden başlatmadır. Lab’da beklenenden farklı çıkan şeyler:

1. IPv6 Off, IPv6 DNS kullanılmayacak demek değildi. Modemin IPv6 DNS’i araya girdi, sorgu internete gitti ve katılım 1355 ile düştü.
2. Arıza aralıklıydı. Aynı yarım dakikada aynı ad bir kez çözüldü, bir kez çözülemedi.
3. Katılımı Domain Admin yapmadı. Nesne önceden açıldı, Ankara helpdesk’inin standart hesabı makineyi kattı ve KB5020276 kontrolü yeniden kullanıma izin verdi.
4. “Can join” alanı geniş izin veriyor. Seçilen grup nesne üzerinde bütün extended right’ları alıyor.
5. Güvenli kanalı standart kullanıcı soramadı. nltest /sc_verify ve gpresult yükseltilmiş oturum istedi, Test-ComputerSecureChannel istemedi.

Girişteki benzetmeye dönersek: okuyucuyu kapıya takmak birkaç saniyelik iştir. Okuyucunun ön büroya ulaşabilmesi (DNS), saatinin doğru olması (Kerberos), odanın doğru kata yazılması (OU) ve ön büroyla konuştuğu şifrenin güncel kalması (güvenli kanal) ise o birkaç saniyeden önce ve sonra yapılan işlerdir.

Bilgisayarlarınız domain üyesi olduğunda sıradaki adım onları gerçekten yönetmektir. Rehberdeki ilk durak, domain controller’a oturum açmadan yönetmeyi sağlayan RSAT ve yönetim konsolları. Ardından Active Directory GPO yönetimi ile policy dağıtımını kurabilir, LAPS ile yerel yönetici parolalarını makine başına ayırabilir, 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ürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn