Подключение к домену отображается как «не прошедший проверку подлинности»

Я видел различные разные вопросы по этой проблеме, но либо обстоятельства не совпадают, либо решение не работает, поэтому я решил опубликовать его, чтобы посмотреть, есть ли у кого-нибудь какие-либо предложения.

Различные доменные ПК и ноутбуки, по-видимому, случайным образом задают имя соединения «lewis.local 2 (Не аутентифицировано)» - lewis.local, являющийся нашим доменом, - и содержат восклицательный знак, где обычно отображается логотип типа сети.

Это также происходит каждый раз при подключении через vpn.

Наша установка:

• 2 сервера, оба работают под управлением Windows Server 2003 R2 (x32)
• на главном сервере установлены AD, DNS и DHCP
• IPv4 примерно на 30 клиентских компьютерах (некоторые проводные, некоторые беспроводные)

Если у кого-то есть мысли по поводу решений, я был бы признателен. Я попытался удалить все, кроме ролей сервера AD, сбросить все системы и ничего.

Это не мешает ничему работать так же, как подключение к домену, в большинстве случаев, однако, это становится ужасно!

Также не знаю, может ли это быть как-то связано с этим, но DHCP-сервер, похоже, довольно долго задерживает выдачу IP-адреса клиенту.

Одной из возможных причин этой проблемы является то, что пароль учетной записи компьютера не синхронизируется с контроллером домена.

Это может произойти, например, если учетная запись компьютера в Active Directory удалена и повторно добавлена ​​вручную, или если клиентский компьютер был восстановлен в более ранний момент времени (пароли учетных записей компьютера автоматически меняются каждые 30 дней).

Для меня сработало сбросить пароль учетной записи компьютера вручную, выполнив Reset-ComputerMachinePasswordPowerShell с повышенными правами:

PS> Reset-ComputerMachinePassword -Credential MYDOMAIN\SomeDomainAdminAccount

После перезагрузки (или отключения и повторного включения сетевой карты, если вы не хотите перезагружаться), примечание (не прошедшее проверку подлинности) должно исчезнуть.

Запустите эти команды на каждом компьютере с проблемой:

netsh winsock сбросить каталог

netsh int ipv4 reset reset.log

netsh int ipv6 reset reset.log 

Перезагрузите компьютер, затем снова подключите компьютер к домену.

Просто удалите TLD из доменного имени и перезагрузите компьютер, он добавит его обратно после перезагрузки, и все должно быть хорошо. Без суеты, без суеты

Например: company.local удалить локальный и перезагрузиться, он будет добавлен обратно после перезагрузки

У меня была та же проблема, и оказалось, что межсетевой экран между ПК и DC блокировал 135 389 и т. Д. Обратно на ПК.

Чтобы найти эту проблему, я запустил Wireshark на компьютере и сделал gpupdate /force. В wireshark я видел кучу пакетов syn, выходящих на DC без ответа.

Как только брандмауэр был исправлен, мы перезагрузили компьютер, и он смог правильно связаться с DC, и проблема была решена.

Похоже, что-то испортило доверие между компьютером и доменом. Вы должны попытаться удалить компьютер из домена и прочитать его.

Трудно сказать, почему это произошло. Есть ли какие-либо сообщения об ошибках в журналах событий на контроллере домена сейчас или примерно в то время, когда это начало происходить? Были ли внесены какие-либо изменения в сеть?

Пара потенциальных решений:

1. Проверьте аренду DHCP и бронирование на вашем DC. Если у вас есть несколько записей для компьютеров-нарушителей, уменьшите их до одной записи. Тогда беги ipconfig /release && ipconfig /renewна этих машинах.
2. Удалите сетевые адаптеры из диспетчера устройств, затем найдите новое оборудование для переустановки сетевых адаптеров.
3. Восстановите ваши профили брандмауэра Windows по умолчанию: Запустите wf.mscи нажмите «Восстановить политику по умолчанию»
4. Отключите все брандмауэры полностью. Для брандмауэра Windows запустите, wf.mscзатем нажмите «Свойства брандмауэра Windows» и установите для состояния брандмауэра значение «Выкл.» Для каждой вкладки профиля («Домен», «Частный», «Общий»).

Последний вариант на самом деле не является исправлением, но он может помочь устранить проблему.

Может быть, это поможет кому-то по пути. У меня была эта проблема, и причина была в несоответствии VLAN на устройстве Riverbed Steelhead. Интерфейс In-Path на Riverbed подключен к порту LAN маршрутизатора, а интерфейс In-Path настроен для «ID тега VLAN», равного «0». Это вызвало проблему. Интерфейс локальной сети маршрутизатора находится в конфигурации подынтерфейса (один для голосовой VLAN 40 и один для данных / собственной VLAN 1), я смог решить эту проблему, назначив для идентификатора тега VLAN значение «1» (data / native) и проблема решена сразу.

У меня ничего не получалось.

Ноутбук мог подключаться к любой другой WiFi-станции, но не к компании. Таким образом, после проверки того, что аренды DHCP не были продублированы, при повторном подключении ноутбука, выполнении большого количества команд, следующая проблема была устранена.

Потом я зашел в настройки WiFi на роутере и поменял с AUTOна LONG GUARD. Это решило проблему сразу.