Błąd 691 VPN w Windows: która kontrola naprawdę zawiodła?

Windows odrzuca hasło, które minutę wcześniej zaakceptował gdzie indziej, więc konto wygląda na zepsute, choć próba nigdy nie została oceniona. Błąd 691 oznacza, że połączenie zostało odrzucone podczas uwierzytelniania, a klient wyświetla ten sam tekst niezależnie od tego, czy hasło było błędne, czy nazwa konta została rozwiązana na nieoczekiwaną tożsamość, czy polityka po stronie serwera odrzuciła połączenie. Trzy różne naprawy dzielą jeden komunikat, dlatego reset czasami pomaga, a czasami nie zmienia zupełnie nic. Zacznij od części, którą możesz sprawdzić sam: dokładnego ciągu wysłanego przez klienta i magazynu poświadczeń, z którego go pobrał. Następnie zapytaj serwer, jaką decyzję zapisał, ponieważ okno dialogowe jest odmową, a nie diagnozą.

Trzy sposoby na odmowę, jedno okno dialogowe

Błędne hasło to tylko pierwsza droga do tego okna. Nazwa konta może zostać rozwiązana na tożsamość, której nie zamierzałeś, konto może nie mieć uprawnienia do połączeń przychodzących albo warunek serwera może odrzucić połączenie po zaakceptowaniu hasła. Każdy z tych przypadków daje ten sam tekst klienta, a każdy ma własną naprawę.

Dlatego reset wygląda na działający w poniedziałek, a we wtorek nie robi nic. Czytaj okno dialogowe jako odmowę, a nie diagnozę, i przed dotknięciem konta zanotuj nazwę profilu oraz lokalny czas awarii.

Te trzy kategorie zawodzą także na różnych warstwach. Błędne hasło zawodzi w dowodzie tożsamości, błędna forma konta zawodzi w wyszukiwaniu, a warunek polityki zawodzi w autoryzacji po udowodnieniu tożsamości. Tylko pierwszą naprawia się zmianą hasła. Pozostałe dwie wymagają kogoś z dostępem do rejestru decyzji serwera, dlatego następnym krokiem jest prośba o informacje, a nie kolejny reset.

Co klient faktycznie wysłał

Potwierdź akceptowany format konta z osobą zarządzającą bramą, ponieważ samo nazwisko użytkownika, nazwa kwalifikowana domeną i główna nazwa użytkownika mogą prowadzić do różnych kontekstów konta. Tylko jedna z nich może być tożsamością mającą uprawnienie. Zapytaj, jakiej formy oczekuje brama, przed pierwszą próbą, a nie po piątej, i sprawdź, czy klient nie używa zapisanego poświadczenia zamiast tego, które wpisałeś.

Dwa zapytania tylko do odczytu na maszynie Windows pokazują profil i wszelkie buforowane poświadczenia, które mogłyby przebić okno dialogowe. Żadne z nich nie łączy się z serwerem:

Get-VpnConnection -Name 'Corp VPN' | Format-List Name, ServerAddress, TunnelType, AuthenticationMethod
cmdkey /list | Select-String -Pattern 'corp' -SimpleMatch

Traktuj hasło jako dane, a nie jako tekst skopiowany z dokumentu. Wartość, która przeszła przez skrypt, może zawierać znaki ucieczki, które nigdy nie były częścią hasła, a eksport konfiguracji mógł ją ująć w cudzysłowy. Usunięcie wszystkich znaków specjalnych, aby pasowała, to inna zmiana niż znalezienie rzeczywistej wartości, więc najpierw ustal rzeczywistą wartość.

Uzyskaj decyzję polityki, a nie reset

We wdrożeniu dostępu zdalnego z serwerem zasad sieciowych dwie decyzje są wykonywane po kolei. Uwierzytelnianie ustala, które konto pyta, a autoryzacja decyduje, czy to konto w ogóle może się połączyć. Warunki i ograniczenia polityki są oceniane według własnych kryteriów, więc prawidłowe hasło rozstrzyga tylko pierwszą połowę pytania. Nazwa polityki w zdarzeniu serwera wskazuje, która decyzja została faktycznie wykonana.

Wyślij administratorowi nazwę profilu, próbowane konto i znacznik czasu. Poproś o pasujący zapis decyzji i jego powód zamiast kolejnego resetu hasła oraz o nazwę polityki, którą niesie zdarzenie. dokumentacja kodów błędów dostępu zdalnego firmy Microsoft wymienia 691 wśród błędów poświadczeń i uwierzytelniania, i właśnie dlatego okno dialogowe nie potrafi rozdzielić trzech przypadków.

Przekształcenie konta w bezwarunkowe zezwolenie czyni decyzję autoryzacyjną trwałym wyjątkiem. Usuwa też warunek, który wykonywał pożyteczną pracę, a następna osoba przeglądająca politykę nie będzie wiedzieć, dlaczego się zmieniła. Poproś raczej właściciela o potwierdzenie zamierzonej polityki, aby akceptacja pozostała świadoma.

Spróbuj jeszcze raz, a potem porównaj

Powtórz ten sam profil po jedynej poprawce, którą zidentyfikowałeś. Jeśli dostęp zostanie zaakceptowany i zasób wewnętrzny nadal zawodzi, awaria przeniosła się na inną warstwę i nie mówi już nic o haśle. To niezmieniony profil czyni to porównanie sensownym.

Oprzyj się pokusie wyłączenia rodziny adresów lub włączenia szczegółowego śledzenia, zanim odmowa zostanie wyjaśniona. Śledzenie tworzy ilość, a nie decyzję, a pierwszym użytecznym wynikiem pozostaje komponent, który odrzucił próbę, i powód, który zapisał. Gdy to wiadomo, ponowna próba albo potwierdza naprawę, albo daje nowy i węższy objaw.