Назад | Перейти на главную страницу

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

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

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

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

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

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

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

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

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

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

Что сработало для меня, так это сбросить пароль учетной записи компьютера вручную, выполнив Reset-ComputerMachinePassword в повышенной (!) PowerShell:

PS> Reset-ComputerMachinePassword -Credential MYDOMAIN\SomeDomainAdminAccount

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

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

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

netsh int ipv4 сбросить reset.log

netsh int ipv6 сбросить reset.log

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

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

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

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

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

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

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

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

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

  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 был настроен для «VLAN Tag ID» равным «0». Это вызвало проблему. Интерфейс LAN маршрутизатора находится в конфигурации подинтерфейса (один для голосовой VLAN 40 и один для данных / собственной VLAN 1), мне удалось решить эту проблему, присвоив идентификатору тега VLAN значение «1» (данные / собственный) и вопрос решен сразу.

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

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

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

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