Windows Client ve Sunucularda oturum açılırken alınan “The trust relationship between this workstation and the primary domain failed” hatanın giderilmesi

Kurumsal bilgi teknolojileri altyapısında Active Directory (AD) kimlik doğrulama ve kaynak yönetiminin bel kemiğidir. Client makineler ile domain arasında kurulan “güven ilişkisi” (trust relationship) bu sistemin sorunsuz çalışması için kritik önemdedir.

Ancak zaman zaman özellikle sistem geri yüklemeleri, snapshot geri dönüşleri veya şifre senkronizasyon bozulmaları sonrasında client makinelerde şu hata mesajıyla karşılaşabilirsiniz.

"The trust relationship between this workstation and the primary domain failed."

Bu hata genellikle panik yaratır çünkü kullanıcı domaine giriş yapamaz ve sistemle olan tüm bağlar kopmuş gibi görünür. Ancak bu sorun çözümsüz değildir. Hatta çoğu zaman doğru adımlar izlendiğinde birkaç dakika içinde çözülebilir.

Bu makalede yalnızca çözüm yollarını değil aynı zamanda her bir yöntemin ardındaki mantığı hangi durumlarda tercih edilmesi gerektiğini ve kendi deneyimlerime dayanarak önerilerimi de bulacaksınız.

Güven İlişkisi Neden Bozulur?

Öncelikle sorunun temelini anlamak gerekir. Active Directory’de her bilgisayarın domain içinde bir “bilgisayar hesabı” vardır ve bu hesap tıpkı kullanıcı hesapları gibi şifrelerle korunur. Bu şifre arka planda otomatik olarak belirli aralıklarla güncellenir.

Ancak bazı durumlarda:

• Bilgisayar yedeği eski bir tarihe geri yüklenirse,
• Domain Controller şifresiyle bilgisayarın lokalinde kayıtlı şifre eşleşmezse,
• Snapshot’tan dönülmüşse,
• Hyper-V / VMware ortamlarında klonlama sonrası domain’e katılım yapılmamışsa,
• Sistem saati farkı aşırı büyükse … bu güven ilişkisi bozulur ve yukarıdaki hata alınır.

1. Domaine Ayrılma ve Yeniden Katılma (Temiz Yöntem)

Bu en doğrudan ve “temiz” çözüm yoludur. Ancak aynı zamanda kullanıcı profillerinde bozulma, GPO (Group Policy) senkronizasyon sorunları veya yeniden yapılandırma gerektirebilir.

Ne zaman tercih edilmeli?

• Bilgisayar nesnesi bozulmuşsa
• Diğer yöntemler başarısızsa
• Bilgisayar profili yedeklenmiş ve yeniden oluşturulabilecek durumdaysa

djoin /leave

yada

djoin /domain kadirkozan.local /user administrator /password:*

Bu komut çalıştırıldıktan sonra bilgisayarınızı yeniden başlatınız.

Domain’den çıkmadan önce kullanıcı verilerini ve profilleri yedeklemek önerilir.

2. PowerShell ile Güven Kanalını Onarmak (Hızlı ve Temiz Yaklaşım)

Bu komut ile bilgisayar domain’den çıkarılmadan arka plandaki güven kanalını yeniden kurar.

Ne zaman tercih edilmeli?

• Domain hesabı hâlâ geçerliyse
• Bilgisayar nesnesi AD’de mevcutsa
• Kullanıcı profili korunmak isteniyorsa

Test-ComputerSecureChannel -Repair -Credential <DomainAdı>\Administrator

Komut çalıştırıldıktan sonra işletim sistemini yeniden başlatın.

Bu yöntem sistem yöneticilerinin en sevdiği çözümlerden biridir. Hem hızlıdır, hem de kullanıcı profillerine dokunmaz. Ancak bazı durumlarda yetersiz kalabilir (örneğin, bilgisayar hesabı silinmişse).

3. Bilgisayar Hesabı Şifresini Sıfırlamak (Gelişmiş PowerShell Yöntemi)

Burada yapılan işlem, istemcinin domain içindeki bilgisayar hesabının şifresini sıfırlamaktır.

Reset-ComputerMachinePassword -Server <DomainController> -Credential <DomainAdı>\Administrator

Bu komut çalıştırıldıktan sonrasında işletim sistemini yeniden başlatma gerekir.

Domain yapısını bozmadan güven ilişkisini düzeltir. Özellikle “Read-Only Domain Controller” kullanılan ortamlarda dikkatli olunmalıdır. İzinli bir DC üzerinde çalıştığınızdan emin olun.

4. Netdom ile Şifre Sıfırlama (Klasik Yaklaşım)

Netdom aracı Windows Server yönetiminde sıkça kullanılan bir komut satırı aracıdır. Bilgisayar hesabının şifresini sıfırlar.

netdom resetpwd /Server:<DomainController> /UserD:<DomainYönetici> /PasswordD:*

Bu komut çalıştırıldıktan sonrasında işletim sistemini yeniden başlatma gerekir. CLI seven sistem yöneticileri için idealdir. Ayrıca script’lerle otomasyona da uygundur.

5. Bilgisayar Nesnesini Silip Yeniden Oluşturmak (Radikal Çözüm)

Eğer bilgisayar nesnesi AD’den silinmişse ya da bozulmuşsa, bu yöntem tercih edilir.

1. ADUC (Active Directory Users and Computers) üzerinden nesneyi silin.
2. Client sistem üzerinden;

Remove-Computer -UnjoinDomainCredential <DomainAdı>\Administrator

3. işletim sistemini yeniden başlatınız.

4. Domaine tekrar katılmak için;

Add-Computer -DomainName "<DomainAdı>" -Credential <DomainAdı>\Administrator -Restart

Bu yöntem son çare olarak değerlendirilmelidir. Kullanıcı profilleri, GPO uygulamaları ve sistem ayarları yeniden yapılandırma gerektirebilir.

6. Sistem Saati Senkronizasyonu (Sık Görülmeyen Ama Etkili Bir Sebep)

Domain güvenliği açısından istemci ve domain controller arasındaki saat farkı en fazla 5 dakika olabilir. Bu sınır aşıldığında kimlik doğrulama başarısız olur.

w32tm /resync

Gerekirse manuel zaman sunucusu ayarlayın:

w32tm /config /manualpeerlist:"<NTPServer>" /syncfromflags:manual /update

Özellikle sanallaştırma ortamlarında host saat ayarları ile uyumsuzluk sık karşılaşılan bir durumdur.

Active Directory ile istemci arasındaki güven ilişkisi hataları ilk bakışta karmaşık ve kritik gibi görünse de aslında çoğu zaman sistematik bir şekilde çözülebilir. Bu rehberde sunduğum yöntemleri kullanarak, hem hızlı hem de güvenli bir şekilde sorunu giderebilirsiniz. Eğer IT altyapınızda merkezi izleme/loglama sistemi varsa (örneğin: Event Viewer, SIEM), bu hatanın hangi tarihte başladığını izlemek, sorunun kaynağını analiz etmek açısından büyük kolaylık sağlayacaktır.

7. SPN Kayıtlarını Kontrol Etmek ve Gerekirse Yeniden Oluşturmak

Service Principal Name (SPN) bir servis hesabını benzersiz şekilde tanımlayan Kerberos kimlik doğrulama sürecinin temel parçalarından biridir. Bilgisayar hesaplarına ait “HOST/COMPUTERNAME” veya “HOST/FQDN” SPN’leri eksikse güven ilişkisi bozulabilir veya Kerberos üzerinden kimlik doğrulama başarısız olur.

SPN’lerin mevcut olup olmadığını kontrol edin:

setspn -L <BilgisayarAdı>

Aşağıdaki gibi olması gereken SPN kayıtlarını kontrol edin:

HOST/COMPUTERNAME
HOST/FQDN.of.COMPUTERNAME

Eksikse şu şekilde yeniden ekleyiniz.

setspn -A HOST/COMPUTERNAME <BilgisayarAdı>
setspn -A HOST/FQDN.of.COMPUTERNAME <BilgisayarAdı>

SPN eksikliği çoğu zaman gözden kaçar çünkü güven ilişkisi hatasının doğrudan belirtisi olmaz. Ancak özellikle uygulama sunucuları veya servis hesaplarıyla ilişkili makinelerde SPN eksikliği Kerberos bileşenlerinde kritik problemlere neden olabilir.

8. SPN Çakışmalarını (Duplicate) Kontrol Etmek

Eğer bir SPN aynı anda birden fazla nesneye atanmışsa (örneğin iki farklı bilgisayar ya da kullanıcı hesabı) bu da Kerberos kimlik doğrulamasında çakışmaya ve dolayısıyla güven ilişkisi hatalarına yol açabilir.

setspn -x -f

Bu komut, domain genelinde SPN çakışmalarını listeler.

Gerekirse düzeltin:

• Çakışan SPN’leri hangi nesnelere ait olduğunu görmek için setspn -L <NesneAdı> komutunu kullanın.
• Hatalı olanlardan SPN’leri silin:

setspn -D HOST/COMPUTERNAME <HatalıNesne>

SPN çakışmaları özellikle migration (taşıma) süreçlerinde ya da aynı isimle yeniden oluşturulan makinelerde sıkça yaşanır. Bu tip durumlarda domain denetleyicisi, doğru SPN’ye yönlendirme yapamayacağı için güven ilişkisi kopmuş gibi davranabilir.

9. Bilgisayarın LSA Cache’inden Parola Hash’ini Çekip AD’ye Enjekte Etmek (İleri Seviye)

Bu yöntem sistem yöneticileri için “son çare” olarak kabul edilir ve ileri düzey bilgi gerektirir. Bilgisayar kendi şifresini LSA (Local Security Authority) cache’inde tutar. Bu hash güven ilişkisi onarımında kullanılabilir.

Ne zaman kullanılır?

• Test-ComputerSecureChannel -Repair, Reset-ComputerMachinePassword, netdom ve nltest gibi tüm standart yöntemler başarısız olduğunda.
• Bilgisayar domain’de görünüyordur ama giriş yapılamıyordur.
• Fiziksel erişim var ama domain bağlantısı kurulamıyordur.

Özet Adımlar:

1. Offline erişim ile sistemin LSA kaydından bilgisayar şifresinin NT hash’ini çekin.
2. Bu hash’i AD üzerindeki ilgili bilgisayar nesnesine enjekte edin (örneğin impacket-secretsdump, lsass dump ve rpcclient gibi araçlarla).
3. Yeniden başlatma ile ilişki kurulmuş olur.

Bu işlem düşük seviyeli sistem müdahalesi içerir ve yanlış uygulandığında daha büyük sistem sorunlarına yol açabilir. Etik ve güvenlik açısından sadece kurumsal ortamlarda, yetkili kişilerce uygulanmalıdır. Bu yöntem genellikle güvenlik testlerinde veya AD restore senaryolarında kullanılır. Aynı zamanda forensik müdahalelerde ya da air-gapped (izole) sistemlerin domain entegrasyonunda da oldukça etkilidir. Ancak üretim ortamında dikkatli olunmalıdır.