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

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

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

PS> Reset-ComputerMachinePassword -Credential MYDOMAIN\SomeDomainAdminAccount

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

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

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

netsh int ipv4 reset reset.log

netsh int ipv6 reset reset.log

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

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

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

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

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

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

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

Оказывается, виноваты некоторые патчи от ноября 2022 года . Чтобы решить эту проблему, я сначала выполнил инструкции в этом блоге:https://dirteam.com/sander/2022/11/09/knowledgebase-you-experience-errors-with-event-id-42-and-source-kdcsvc-на-контроллерах домена/

т. е. я сделал следующие шаги:

Шаг 1. Если для функционального уровня домена Active Directory (DFL) установлено значение Windows Server 2003, обновите его до Windows Server 2008 или более поздней версии. При этом пароль учетной записи krbtgt сбрасывается, поэтому не сбрасывайте пароль учетной записи krbtgt на этапе 2 (в течение недели). Перейдите к шагу 3.

Шаг 2. Чтобы сбросить пароль для учетной записи krbtgt, используйте сценарий PowerShell Microsoft New-KrbtgtKeys.ps1 из Github и запустите его на контроллере домена, владеющем ролью Flexible Single Master Operations (FSMO) основного эмулятора контроллера домена (PDCE).

Шаг 3. Настройте затронутые объекты пользователя, чтобы они больше не использовали явно RC4_HMAC_MD5.

Когда люди выходят из системы и снова входят в систему после смены паролей, их ключи сеанса будут зашифрованы AES и больше не будут уязвимы в контексте CVE-2022-37966. Если для учетной записи необходим RC4, перейдите к шагу 3 приведенного ниже альтернативного метода.

Шаг 4. При необходимости, если новых ошибок с кодом события 42 не возникает, настройте параметр «Сетевая безопасность: настройка типов шифрования, разрешенных для Kerberos» в объекте групповой политики, предназначенном для домена, чтобы явно отключить типы шифрования DES_CBC_CRC, DES_CBC_MD5 и RC4_HMAC_MD5 и явно включить AES128_HMAC_SHA1, AES256_HMAC_SHA1 и будущие типы шифрования.

Затем я изменил пароль учетной записи компьютера на затронутых рядовых серверах/системах:

      Reset-ComputerMachinePassword -Credential MYDOMAIN\SomeDomainAdminAccount

Наконец, я установил на контроллеры домена одно из следующих обновлений, в зависимости от версии Windows Server:

• Windows Server 2022: KB5021656.
• Windows Server 2019: KB5021655.
• Windows Server 2016: KB5021654.
• Windows Server 2012 R2: KB5021653.
• Windows Server 2012: KB5021652.
• Windows Server 2008 R2 с пакетом обновления 1: KB5021651
• Windows Server 2008 с пакетом обновления 2: KB5021657.

Источник: https://learn.microsoft.com/en-us/windows/release-health/status-windows-server-2022#november-2022 .

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

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

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

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

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

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

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

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

Я знаю старую тему, но ничего выше не помогло. Проблема началась после того, как мы заменили коммутатор Cisco на коммутатор HP. Настройка статического IPv4 какое-то время работала, но вернуться к DHCP не удалось и т. д. Невозможно отсоединиться и присоединиться. «Выбранный сервер не смог выполнить запрошенную операцию». USB WIFI сработал хорошо, но не дал долгосрочного решения, но это дало мне подсказку, что это должно быть что-то с этой конкретной картой Intel Card на нескольких компьютерах в офисе. Что помогло, так это изменить настройки сетевой карты:Пакеты Jumbo: отключено (ранее было установлено значение 9024). Разгрузка большой отправки V2 (IPv4), а также (IPv6): отключено. Теперь соединение с общими сетевыми ресурсами и сервером Exchange работало отлично.

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

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

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

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

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