Kısa cevap: Etki alanına bağlı bir Windows VDS, NLA sırasında etki alanı denetleyicisine ulaşamıyorsa yalnız RDP portuna odaklanmayın. Kurum içi DNS, ağ yolu, hesap kapsamı ve güven ilişkisi incelenmelidir. Bu yazı kendi Active Directory ortamını yöneten veya yetkili yöneticiyle çalışan kullanıcı içindir; bütün VDS’lerde domain bulunduğunu varsaymaz.
Önce hesabın türünü doğrulayın
Kullanılan hesap yerel mi, etki alanı hesabı mı? Aynı kısa kullanıcı adı farklı makinelerde başka bir kimliğe ait olabilir. Hesap biçimini ve doğru etki alanını yöneticiyle doğrulayın; sürekli farklı parola denemek hesabı kilitleyebilir. oturum açma hatası rehberi bu ayrımı anlamanıza yardımcı olur. Parola sıfırlaması, yanlış hesap kapsamını düzelten bir işlem değildir.
Dış internet ile kurum erişimini ayırın
Tarayıcıdan bir haber sitesi açılması, iç DNS’nin etki alanı kayıtlarını çözebildiğini göstermez. Yetkili yönetici sunucunun tanımlı DNS adreslerini, kurum ağına giden yolunu ve hedef etki alanı denetleyicisini incelemelidir. Genel DNS sunucusunu rastgele yazmak sorunu ağırlaştırabilir. DNS kavramları rehberindeki genel açıklamaları kullanın fakat kurum içi dizin hizmetini herkese açık web DNS’siyle aynı yapı sanmayın.
Hata mesajını kendi ortamınıza uyarlayın
Microsoft RDP doğrulama belgesi, etki alanı denetleyicisine erişim veya güvenli kanal sorunlarının NLA erişimini etkileyebileceğini açıklar. Azure’daki kurtarma ekranının kendi sağlayıcınızda aynı adla bulunduğunu kabul etmeyin. Sunucu konsolu sağlanıyorsa bu yol, işletim sistemini incelemek içindir; sorunu NLA’yı kalıcı kapatarak saklamak için değil.
Son ağ değişikliklerini kontrol edin
VPN kesintisi, DNS değişikliği, sunucu geri yüklemesi veya domain tarafında bakım yapıldı mı? Bir zaman çizelgesi oluşturun. saat senkronizasyonu rehberini de göz önünde tutun; kimlik doğrulama incelemesinde cihazların zamanları anlamlı karşılaştırılmalıdır. Tüm ayarları bir anda değiştirmek yerine en son değişen bağımlılığı bulun. Eski yedekten dönülen bir makinenin durumu kurum yöneticisine özellikle belirtilmelidir.
Onarımın ardından kullanıcı senaryosunu test edin
Yetkili düzeltme tamamlanınca sorun yaşayan etki alanı hesabıyla oturum açmayı deneyin. Ardından uygulama ve paylaşımlara yalnız gerekli yetkilerle erişildiğini doğrulayın. Windows olay kaydı toplama rehberindeki yöntemle önceki ve sonraki hata zamanlarını karşılaştırın. Bir yerel yönetici oturumunun çalışması domain sorununun çözüldüğüne tek başına kanıt değildir. Sonuç kaydında hangi hesap türünün ve hangi bağlantı yolunun test edildiğini açık yazın.
Bu konunun diğer kontrolleri
- RDP’de NLA, MFA ve Port Değiştirme Aynı Güvenliği mi Sağlar?
- RDP Erişimi Kaybolursa: NLA’yı Kapatmadan Konsol Kurtarma Planı
Sıkça Sorulan Sorular
İnternet açılıyorsa domain doğrulaması da çalışır mı?
Hayır. İnternet erişimi ile kurumun DNS ve etki alanı denetleyicisine erişim aynı test değildir. İç ağ yolunu ve ilgili sunucu adlarını yetkili yönetici doğrulamalıdır.
Yerel hesapla açılması domain hesabının parolasının yanlış olduğunu mu gösterir?
Hayır. Farklı doğrulama yolları kullanılıyor olabilir. Etki alanı erişimi, hesap biçimi, güven ilişkisi ve haklar ayrıca incelenmelidir.
Sunucuyu domainden çıkarıp tekrar ekleyeyim mi?
Bunu ilk kontrol olarak uygulamayın. Uygulama ve erişim bağımlılıklarını etkileyebilir. Önce kayıtları toplayın; gerekiyorsa kurum yöneticisi bakım ve geri dönüş planıyla işlem yapmalıdır.
DNS değişikliğinden sonra domain erişimini nasıl test etmeliyim?
Önce hangi DNS adresinin değiştiğini ve bu adresin kurum içi adları çözmek için kullanılıp kullanılmadığını yöneticiye bildirin. Rastgele genel DNS eklemeyin. Testte etki alanı hesabıyla giriş sonucunu, hedef denetleyiciye erişim durumunu ve hata zamanını ayrı kaydedin. Bir web sitesinin açılmasını başarılı domain testi saymayın. Kurum ağına VPN üzerinden erişiliyorsa tünelin kurulduğunu görmekle ilgili adların çözümlendiğini doğrulamak da farklı kontrollerdir; sonuçlarını birbirine karıştırmayın.