Domen etimadı bir ay oflayndan sonra pozuldu? Əvvəlcə bunu yoxlayın
Üzv iş stansiyası maşın parolu intervalını keçdikdən sonra da etimadı itirmədən oflayn qala bilər. Hesabı sıfırlamazdan əvvəl təhlükəsiz kanalı sübut edin.
Noutbuk altı həftə VPN-dən kənarda qalır, sonra qayıdır və istifadəçi domen hesabı ilə daxil ola bilmir. Xəta etimad münasibətindən bəhs edir, ona görə kimsə kompüter hesabını sıfırlayır və ya istifadəçini tam tunelə keçməyə məcbur edir və problem guya yox olur. Heç bir addım nəyin pozulduğunu sübut etmədi. Windows üzvü adi maşın parolu intervalından xeyli kənarda onlayn olmadan qala bilər və etimadı avtomatik itirməz, ona görə ilk iş əlçatanlıq nasazlığını əsl sirr uyğunsuzluğundan ayırmaqdır.
Xəta etimada oxşayır, amma üç vəziyyət bir-birinə bənzəyir
İstifadəçi keşlənmiş domen məlumatı ilə daxil ola bilər, iş stansiyası domen nəzarətçisini tapa bilməyə də bilər, ya da üzv və domen maşın hesabı barədə həqiqətən fərqli fikirdə ola bilər. Yalnız üçüncü hal ciddi mənada pozulmuş etimad münasibətidir.
AD replikasiyasının sağlamlığı dördüncü müşahidədir və bu iş stansiyası ilə heç bağlı deyil. O, domen nəzarətçiləri arasındakı razılığı təsvir edir və sağlam replikasiya paneli bu maşının yerli sirrinin öz kompüter hesabına uyğun olduğunu sübut etmir.
Adi 30 günlük standart oflayn bitmə tarixi deyil, dəyişiklik siyasətidir. Microsoft-un maşın hesabı parolu izahı əlaqələndirilmiş dəyişiklik prosesini təsvir edir və təşkilat fərqli interval təyin edə bilər.
VPN nişanı təhlükəsiz kanal barədə heç nə sübut etmir
Hər hansı test məna kəsb etməzdən əvvəl bağlantı domen xidmətlərinə çatmaq üçün kifayət qədər yaxşı olmalıdır. Bu, nəzərdə tutulan domen DNS həlledicisi, tapıla bilən nəzarətçi, əlçatan autentifikasiya xidmətləri və Kerberos üçün kifayət qədər yaxın saat deməkdir.
Tam tunel burada tamamilə qəbuledilən dizayn ola bilər. Bölünmüş tunelə keçmək sağlam domen münasibəti üçün ilkin şərt deyil və onu belə qəbul etmək diaqnozu arxitektura dəyişikliyinə çevirir. İş stansiyasının əslində hansı nəzarətçini seçdiyini yoxlayın və o adı xəta ilə birlikdə saxlayın.
nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -VerboseDNS serverini, həll edilmiş nəzarətçini və dəqiq xəta mətnini qeyd edin. Bağlı olduğunu bildirən VPN müştərisi tunelin mövcud olduğunu deyir, domen yolunun işlədiyini deyil. Kerberos portunda cavab verən, amma kataloq portunda verməyən nəzarətçi etimad deyil, firewall tapıntısıdır.
Üzvü təmir etməzdən əvvəl onu test edin
Səlahiyyətli Windows domen üzvündə Test-ComputerSecureChannel -Verbose maşınla domen arasındakı kanalın yalnız oxuna bilən yoxlamasıdır. Onu araşdırdığınız maşın kontekstində işə salın, domen nəzarətçisindən yox, çünki onun rolu və bərpa qaydaları fərqlidir. Keçdi və ya kəsildi sözü əvəzinə çıxışı və çıxış statusunu qeyd edin. Əgər həmin buraxılışda cmdlet yoxdursa, modul ayrı problemdir.
Nəticə hələ də kontekst tələb edir. Əgər maşın seçilmiş nəzarətçiyə çata və ya onunla autentifikasiya edə bilmirsə, uğursuz test oflayn parolun bitdiyinə dair müstəqil sübut deyil. Həqiqi xətanı və istifadə olunan nəzarətçini saxlayın, yol etibarlı olduqda testi təkrarlayın.
Hadisə ətrafında üzvdə və aidiyyəti nəzarətçidə Netlogon hadisələrini əlaqələndirin. Maşın adını, mənbə ünvanını, vaxtı və hesab dəyişikliyinə dair hər hansı sübutu qoruyun. Başqa istifadəçinin uğurlu girişi və ya sağlam nəzarətçi paneli bu maşının mübadiləsini əvəz edə bilməz.
Yalnız sübut etdiyiniz münasibəti təmir edin
Bağlantı sabitləşdikdən və administrator təmirin məqsədəuyğun olduğunu təsdiqlədikdən sonra cmdlet-in səlahiyyətli etimadnamələrlə -Repair rejimi üzv iş stansiyası üçün dəstəklənən bir əməliyyatdır. O, münasibəti dəyişir və başqa bir yalnız oxuna bilən test deyil.
Dəyişiklikdən əvvəl təsdiqlənmiş yerli bərpa hesabı və idarəetmə yolu hazır saxlayın. Domen nəzarətçilərinin bərpa rolu fərqlidir və bu prosedurla adi iş stansiyaları kimi qəbul edilməməlidir. Bir neçə sıfırlama alətini ardıcıl işə salıb birinin düzgün olduğuna ümid etmək əvəzinə təşkilatın bərpa iş axınından istifadə edin.
Təmirdən sonra yeni təhlükəsiz kanal testini və ilkin domen əməliyyatını yoxlayın. İstifadəçi profillərini və tətbiq vəziyyətini qoruyun və silib yenidən qoşulmanı ilk izahsız addım etməyin.
Nasazlıq qayıdanda nəyi yoxlamaq lazımdır
Əgər nasazlıq qayıdırsa, eyni hesabı yenidən sıfırlamaq əvəzinə geri qaytarmaya, təkrarlanan kimliyə və hesab dəyişikliklərinin vaxtına baxın. Bərpa edilmiş obraz, snapshot, klonlaşdırılmış maşın kimliyi və ya başqa yerdə aparılmış kompüter hesabı sıfırlaması — hamısı araşdırmaya layiqdir.
Müvəqqəti uğurlu sıfırlama faydalı bərpa sübutudur, amma aralıq VPN-in ilkin uyğunsuzluğa səbəb olduğunu sübut etmir. Səbəbin heç vaxt aradan qaldırılıb-qaldırılmadığını sizə növbəti hadisə deyəcək.
Nəzarətçini, DNS serverini və test çıxışını bilete yazın. Məhz bu qeyd əsl etimad nasazlığını domeni sadəcə tapa bilməyən noutbukdan fərqləndirir.