დომენის ნდობა ერთი თვის ოფლაინის შემდეგ გატყდა? ჯერ შეამოწმეთ

ლეპტოპი ექვსი კვირა VPN-ის გარეთ რჩება, ბრუნდება და მომხმარებელი დომენის ანგარიშით ვერ შედის. შეცდომა ნდობის ურთიერთობას ახსენებს, ამიტომ ვიღაც კომპიუტერის ანგარიშს აბრუნებს ან მომხმარებელს სრულ გვირაბზე აიძულებს და პრობლემა თითქოს ქრება. არც ერთმა ქმედებამ არ დაამტკიცა, რა იყო გატეხილი. Windows-ის წევრი შეიძლება ოფლაინში დარჩეს ჩვეულებრივი მანქანის პაროლის ინტერვალზე გაცილებით მეტ ხანს და ნდობა ავტომატურად არ დაკარგოს, ამიტომ პირველი ამოცანაა წვდომადობის ჩავარდნის გამოყოფა საიდუმლოს ნამდვილი შეუთანხმებლობისგან.

შეცდომა ნდობას ჰგავს, მაგრამ სამი მდგომარეობა მსგავსია

მომხმარებელს შეუძლია ქეშირებული დომენის ინფორმაციით შევიდეს, სამუშაო სადგურმა შეიძლება დომენის კონტროლერი ვერ იპოვოს, ან წევრი და დომენი ნამდვილად არ ეთანხმებოდნენ მანქანის ანგარიშს. მხოლოდ მესამეა გატეხილი ნდობის ურთიერთობა მკაცრი გაგებით.

AD რეპლიკაციის ჯანმრთელობა მეოთხე დაკვირვებაა და საერთოდ არ ეხება ამ სამუშაო სადგურს. ის აღწერს შეთანხმებას დომენის კონტროლერებს შორის და ჯანსაღი რეპლიკაციის დაფა არ ამტკიცებს, რომ ამ მანქანის ლოკალური საიდუმლო მის კომპიუტერის ანგარიშს ემთხვევა.

ნაცნობი 30-დღიანი ნაგულისხმევი ცვლილების პოლიტიკაა და არა ოფლაინ ვადის გასვლის ბოლო ვადა. Microsoft-ის განმარტება მანქანის ანგარიშის პაროლის შესახებ აღწერს კოორდინირებულ ცვლილების პროცესს და ორგანიზაციას შეუძლია სხვა ინტერვალის კონფიგურირება.

VPN-ის ხატულა არაფერს ამტკიცებს უსაფრთხო არხზე

კავშირი უნდა იყოს საკმარისად კარგი დომენის სერვისებამდე მისასვლელად, სანამ რომელიმე ტესტი რამეს ნიშნავს. ეს ნიშნავს განკუთვნილ დომენის DNS გამხსნელს, მოსაძებნ კონტროლერს, ხელმისაწვდომ ავთენტიფიკაციის სერვისებს და Kerberos-ისთვის საკმარისად ახლო საათს.

სრული გვირაბი აქ შეიძლება სრულიად ვალიდური დიზაინი იყოს. გაყოფილ გვირაბზე გადასვლა ჯანსაღი დომენური ურთიერთობის წინაპირობა არ არის და მისი ასე განხილვა დიაგნოზს არქიტექტურის ცვლილებად აქცევს. შეამოწმეთ, რომელ კონტროლერს ირჩევს სამუშაო სადგური რეალურად და შეინახეთ ეს სახელი შეცდომასთან ერთად.

nltest /dsgetdc:corp.example.com
Test-ComputerSecureChannel -Verbose

ჩაწერეთ DNS სერვერი, ამოხსნილი კონტროლერი და შეცდომის ზუსტი ტექსტი. VPN კლიენტი, რომელიც აცხადებს კავშირს, გეუბნებათ, რომ გვირაბი არსებობს და არა რომ დომენის გზა მუშაობს. კონტროლერი, რომელიც პასუხობს Kerberos პორტზე, მაგრამ არა კატალოგის პორტზე, ფაიერვოლის აღმოჩენაა და არა ნდობის.

შეამოწმეთ წევრი სანამ შეაკეთებთ

ავტორიზებულ Windows დომენის წევრზე Test-ComputerSecureChannel -Verbose მანქანასა და დომენს შორის არხის მხოლოდ-წაკითხვის შემოწმებაა. გაუშვით ის თქვენ მიერ გამოძიებული მანქანის კონტექსტში და არა დომენის კონტროლერიდან, რომელსაც სხვა როლი და სხვა აღდგენის წესები აქვს. ჩაწერეთ გამოსავალი და გასვლის სტატუსი და არა სიტყვა გავიდა ან ჩავარდა. თუ cmdlet ამ ბილდში არ არის, მოდული ცალკე პრობლემაა.

შედეგს მაინც კონტექსტი სჭირდება. თუ მანქანა ვერ აღწევს ან ვერ ავთენტიფიცირდება არჩეულ კონტროლერთან, ჩავარდნილი ტესტი დამოუკიდებელი მტკიცებულება არ არის, რომ ოფლაინ პაროლს ვადა გაუვიდა. შეინახეთ ფაქტობრივი შეცდომა და გამოყენებული კონტროლერი და გაიმეორეთ ტესტი, როცა გზა ცნობილი კარგი იქნება.

დააკავშირეთ Netlogon მოვლენები წევრზე და შესაბამის კონტროლერზე ინციდენტის გარშემო. შეინახეთ მანქანის სახელი, წყაროს მისამართი, დრო და ანგარიშის ცვლილების ნებისმიერი მტკიცებულება. სხვა მომხმარებლის წარმატებული შესვლა ან ჯანსაღი კონტროლერის დაფა ვერ შეცვლის ამ მანქანის გაცვლას.

შეაკეთეთ მხოლოდ ის ურთიერთობა, რომელიც დაამტკიცეთ

როცა კავშირი სტაბილურია და ადმინისტრატორმა დაადასტურა, რომ შეკეთება მიზანშეწონილია, cmdlet-ის -Repair რეჟიმი ავტორიზებული სერთიფიკატებით წევრი სამუშაო სადგურისთვის ერთი მხარდაჭერილი ოპერაციაა. ის ცვლის ურთიერთობას და ის არ არის კიდევ ერთი მხოლოდ-წაკითხვის ტესტი.

ცვლილებამდე ხელმისაწვდომად გქონდეთ დამტკიცებული ლოკალური აღდგენის ანგარიში და მართვის გზა. დომენის კონტროლერებს სხვა აღდგენის როლი აქვთ და ეს პროცედურა მათ ჩვეულებრივ სამუშაო სადგურებად არ უნდა განიხილავდეს. გამოიყენეთ ორგანიზაციის აღდგენის სამუშაო ნაკადი და არა რამდენიმე განულების ხელსაწყოს თანმიმდევრული გაშვება იმ იმედით, რომ ერთ-ერთი სწორია.

შეკეთების შემდეგ შეამოწმეთ ახალი უსაფრთხო არხის ტესტი და საწყისი დომენური ოპერაცია. შეინახეთ მომხმარებლის პროფილები და აპლიკაციების მდგომარეობა და მოცილება-ხელახლა შეერთება არ გახადოთ პირველი აუხსნელი ქმედება.

რა უნდა შემოწმდეს, როცა ჩავარდნა ბრუნდება

თუ ჩავარდნა ბრუნდება, შეხედეთ უკან დაბრუნებას, ორმაგ იდენტობას და ანგარიშის ცვლილებების დროს და არა იმავე ანგარიშის ხელახლა განულებას. აღდგენილი იმიჯი, სნეფშოტი, კლონირებული მანქანის იდენტობა ან სხვაგან შესრულებული კომპიუტერის ანგარიშის განულება ყველა გამოძიების ღირსია.

დროებით წარმატებული განულება სასარგებლო აღდგენის მტკიცებულებაა, მაგრამ არ არის მტკიცებულება, რომ წყვეტილი VPN-მა გამოიწვია საწყისი შეუთანხმებლობა. შემდეგი შემთხვევა გეტყვით, საერთოდ თუ იქნა მიზეზი აღმოფხვრილი.

ჩაწერეთ კონტროლერი, DNS სერვერი და ტესტის გამოსავალი ბილეთში. სწორედ ეს ჩანაწერი განასხვავებს ნამდვილ ნდობის ჩავარდნას ლეპტოპისგან, რომელმაც უბრალოდ ვერ იპოვა დომენი.