Połączenie domeny jest wyświetlane jako „nieuwierzytelnione”

Widziałem różne pytania dotyczące tego problemu, ale albo okoliczności nie są takie same, albo rozwiązanie nie działa, więc pomyślałem, że opublikuję je, aby sprawdzić, czy ktoś ma jakieś sugestie.

Wygląda na to, że różne komputery PC i laptopy w domenie losowo nadają nazwę połączenia „lewis.local 2 (Unauthenticated)” - lewis.local jest naszą domeną - i wykrzyknik w miejscu, w którym zwykle wyświetlane jest logo typu sieci.

Wydaje się, że dzieje się tak również przy każdym połączeniu przez VPN.

Nasza konfiguracja to:

• 2 serwery, na których działa system Windows Server 2003 R2 (x32)
• na głównym serwerze są zainstalowane AD, DNS i DHCP
• IPv4 na około 30 komputerach klienckich (niektóre przewodowe, niektóre bezprzewodowe)

Jeśli ktoś ma jakieś przemyślenia na temat rozwiązań, doceniłbym to. Próbowałem usunąć wszystkie role serwera oprócz AD, zresetować wszystkie systemy i nic.

Nie przeszkadza to, aby cokolwiek działało jak połączenie z domeną przez większość czasu, ale robi się to frustrujące!

Nie wiem też, czy może to mieć z tym coś wspólnego, ale wydaje się, że serwer DHCP ma dość długi czas oczekiwania na wydanie adresu IP klientowi.

Jednym z możliwych powodów tego problemu jest zsynchronizowanie hasła konta komputera z kontrolerem domeny.

Może się to zdarzyć na przykład, jeśli konto komputera w usłudze Active Directory zostanie ręcznie usunięte i ponownie dodane, lub jeśli komputer kliencki został przywrócony do wcześniejszego momentu (hasła konta komputera są zmieniane automatycznie co 30 dni).

Dla mnie zadziałało ręczne zresetowanie hasła do konta komputera, wykonując Reset-ComputerMachinePasswordw podwyższonym (!) Programie PowerShell:

PS> Reset-ComputerMachinePassword -Credential MYDOMAIN\SomeDomainAdminAccount

Po ponownym uruchomieniu (lub wyłączeniu i ponownym włączeniu karty sieciowej, jeśli nie chcesz ponownie uruchamiać komputera), (nieuwierzytelniona) notatka powinna zniknąć.

Uruchom następujące polecenia na każdym komputerze z problemem:

netsh winsock zresetuj katalog

netsh int ipv4 reset reset.log

netsh int ipv6 reset reset.log 

Uruchom ponownie komputer, a następnie ponownie podłącz komputer do domeny.

Po prostu usuń TLD z nazwy domeny i uruchom ponownie, doda to z powrotem po ponownym uruchomieniu i wszystko powinno być w porządku.

np .: company.local usuń lokalny i zrestartuj komputer, zostanie on ponownie dodany po restarcie

Miałem ten sam problem i okazało się, że zapora ogniowa między komputerem a kontrolerem domeny blokuje 135 389 itd. Z powrotem na komputer.

Aby znaleźć ten problem, uruchomiłem Wireshark na komputerze i zrobiłem gpupdate /force. W wireshark widziałem kilka pakietów syn wychodzących do DC bez odpowiedzi.

Po naprawieniu zapory ponownie uruchomiliśmy komputer, który był w stanie prawidłowo skontaktować się z kontrolerem domeny i problem został rozwiązany.

Wygląda na to, że coś pomieszało zaufanie między komputerem a domeną. Powinieneś spróbować usunąć komputer z domeny i przeczytać go.

Trudno powiedzieć, dlaczego tak się stało. Czy są jakieś komunikaty o błędach w dziennikach zdarzeń na kontrolerze domeny teraz lub mniej więcej w czasie, gdy to się zaczęło? Czy wprowadzono jakieś zmiany w sieci?

Kilka potencjalnych rozwiązań:

1. Sprawdź dzierżawę i rezerwacje DHCP na swoim DC. Jeśli masz wiele wpisów dotyczących przestępczych maszyn, zmniejsz je do jednego. Następnie uruchom ipconfig /release && ipconfig /renewte maszyny.
2. Usuń karty sieciowe z Menedżera urządzeń, a następnie Wyszukaj nowy sprzęt, aby ponownie zainstalować karty sieciowe.
3. Przywróć domyślne ustawienia Zapory systemu Windows: Uruchom wf.msci kliknij „Przywróć domyślne zasady”
4. Wyłącz wszystkie zapory ogniowe całkowicie. W przypadku Zapory systemu Windows uruchom, wf.msca następnie kliknij opcję „Właściwości Zapory systemu Windows” i ustaw stan Zapory na „Wyłączony” dla każdej karty profilu (Domena, Prywatny, Publiczny).

Ostatnia opcja nie jest naprawą, ale może pomóc rozwiązać problem.

Może to pomoże komuś po drodze. Miałem ten problem, a przyczyną było niedopasowanie VLAN w urządzeniu Riverbed Steelhead. Interfejs In-Path na Riverbed podłączony do portu LAN routera, a interfejs In-Path został skonfigurowany dla „VLAN Tag ID” na „0”. To spowodowało problem. Interfejs LAN routera jest w konfiguracji podinterfejsu (jeden dla głosu VLAN 40, a drugi dla danych / natywnej VLAN 1), udało mi się rozwiązać ten problem, przypisując identyfikator znacznika VLAN do „1” (dane / natywny) oraz problem rozwiązany natychmiast.

Dla mnie nic nie działało.

Laptop może połączyć się z dowolną inną stacją WiFi, ale nie z firmą. Więc po sprawdzeniu, że dzierżawy DHCP nie zostały zduplikowane, ponownym dołączeniu do laptopa, uruchomieniu wielu poleceń, następujące problemy rozwiązały problem.

Następnie przeszedłem do ustawień WiFi na routerze i zmieniłem z AUTOna LONG GUARD. Naprawiono problem od razu.