Zaufanie domeny zerwane po miesiącu offline? Najpierw sprawdź

Laptop pozostaje poza VPN przez sześć tygodni, wraca, a użytkownik nie może zalogować się na konto domenowe. Błąd wspomina relację zaufania, więc ktoś resetuje konto komputera albo wymusza na użytkowniku pełny tunel, i problem zdaje się znikać. Żadne z tych działań nie dowiodło, co było zepsute. Członek Windows może pozostać offline znacznie dłużej niż zwykły interwał hasła komputera i nie utracić zaufania automatycznie, więc pierwszym zadaniem jest oddzielenie awarii osiągalności od rzeczywistej niezgodności sekretu.

Błąd wygląda jak zaufanie, ale trzy stany są podobne

Użytkownik może zalogować się przy użyciu buforowanych informacji domenowych, stacja robocza może nie znaleźć kontrolera domeny albo członek i domena mogą naprawdę nie zgadzać się co do konta komputera. Tylko trzeci przypadek jest zerwaną relacją zaufania w ścisłym sensie.

Stan replikacji AD to czwarta obserwacja i wcale nie dotyczy tej stacji roboczej. Opisuje zgodność między kontrolerami domeny, a zdrowy pulpit replikacji nie dowodzi, że lokalny sekret tego komputera pasuje do jego konta komputera.

Znane domyślne 30 dni to polityka zmiany, a nie termin wygaśnięcia offline. Wyjaśnienie Microsoftu dotyczące hasła konta komputera opisuje skoordynowany proces zmiany, a organizacja może skonfigurować inny interwał.

Ikona VPN nie dowodzi niczego o bezpiecznym kanale

Łączność musi być wystarczająco dobra, by dotrzeć do usług domeny, zanim jakikolwiek test coś znaczy. To znaczy zamierzony resolver DNS domeny, znajdowany kontroler, osiągalne usługi uwierzytelniania i zegar wystarczająco bliski dla Kerberos.

Pełny tunel może być tu całkowicie poprawnym rozwiązaniem. Przejście na tunel dzielony nie jest warunkiem zdrowej relacji z domeną, a traktowanie go jako warunku zamienia diagnozę w zmianę architektury. Sprawdź, który kontroler stacja robocza faktycznie wybiera, i zachowaj tę nazwę razem z błędem.

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

Zapisz serwer DNS, rozpoznany kontroler i dokładny tekst błędu. Klient VPN, który zgłasza połączenie, mówi, że tunel istnieje, a nie że ścieżka do domeny działa. Kontroler, który odpowiada na porcie Kerberos, ale nie na porcie katalogu, to ustalenie firewalla, a nie ustalenie zaufania.

Przetestuj członka, zanim go naprawisz

Na autoryzowanym członku domeny Windows Test-ComputerSecureChannel -Verbose to kontrola tylko do odczytu kanału między komputerem a domeną. Uruchom ją w kontekście badanego komputera, a nie z kontrolera domeny, który ma inną rolę i inne zasady odzyskiwania. Zapisz dane wyjściowe i kod zakończenia zamiast słowa zaliczono lub nie zaliczono. Jeśli w tej kompilacji brak polecenia cmdlet, moduł to osobny problem.

Wynik nadal wymaga kontekstu. Jeśli komputer nie może dotrzeć do wybranego kontrolera lub uwierzytelnić się na nim, nieudany test nie jest niezależnym dowodem, że hasło offline wygasło. Zachowaj rzeczywisty błąd i użyty kontroler, i powtórz test, gdy ścieżka będzie znana jako dobra.

Skoreluj zdarzenia Netlogon na członku i na odpowiednim kontrolerze wokół incydentu. Zachowaj nazwę komputera, adres źródłowy, czas i wszelkie dowody zmiany konta. Udane logowanie innego użytkownika albo zdrowy pulpit kontrolera nie mogą zastąpić wymiany tego komputera.

Napraw tylko tę relację, którą udowodniłeś

Gdy łączność jest stabilna i administrator potwierdził, że naprawa jest właściwa, tryb -Repair polecenia cmdlet z autoryzowanymi poświadczeniami jest jedną obsługiwaną operacją dla stacji roboczej członka. Zmienia relację i nie jest kolejnym testem tylko do odczytu.

Przed zmianą miej dostępne zatwierdzone lokalne konto odzyskiwania i ścieżkę zarządzania. Kontrolery domeny mają inną rolę odzyskiwania i ta procedura nie może traktować ich jak zwykłych stacji roboczych. Użyj przepływu odzyskiwania organizacji, zamiast uruchamiać po kolei kilka narzędzi resetujących i mieć nadzieję, że jedno z nich jest właściwe.

Po naprawie zweryfikuj nowy test bezpiecznego kanału i pierwotną operację domenową. Zachowaj profile użytkowników i stan aplikacji, i nie czyń usunięcia-i-ponownego-przyłączenia pierwszą niewyjaśnioną czynnością.

Co sprawdzić, gdy awaria powróci

Jeśli awaria powróci, przyjrzyj się wycofaniu, podwójnej tożsamości i momentowi zmian konta, zamiast ponownie resetować to samo konto. Przywrócony obraz, migawka, sklonowana tożsamość komputera lub reset konta komputera wykonany gdzie indziej — wszystkie zasługują na zbadanie.

Tymczasowo udany reset to przydatny dowód odzyskania, ale nie dowód, że przerywany VPN spowodował pierwotną niezgodność. Następne wystąpienie powie ci, czy przyczyna została kiedykolwiek usunięta.

Zapisz kontroler, serwer DNS i dane wyjściowe testu w zgłoszeniu. To ten zapis odróżnia prawdziwą awarię zaufania od laptopa, który po prostu nie odnalazł domeny.