Підключення до домену відображається як "неаутентифікований"

Я бачив різноманітні різні питання щодо цієї проблеми, що плавають навколо, але або обставини не однакові, або рішення не працює, тому я подумав, що я опублікував би його, щоб побачити, чи є у когось якісь пропозиції.

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

Це, мабуть, трапляється кожного разу при підключенні через vpn.

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

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

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

Це не заважає нічого працювати так само, як і підключення домену більшу частину часу, однак воно стає фустирующим!

Крім того, не знаю, чи це може мати щось спільне з цим, але, здається, DHCP-сервер має досить тривалий час для видачі IP-адреси клієнту.

Однією з можливих причин цієї проблеми є те, коли пароль машинного облікового запису не синхронізується з контролером домену.

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

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

PS> Reset-ComputerMachinePassword -Credential MYDOMAIN\SomeDomainAdminAccount

Після перезавантаження (або відключення та повторного ввімкнення мережевої карти, якщо ви не хочете перезавантажуватись), (неаутентифікована) примітка повинна бути втрачена.

Запустіть ці команди на кожному комп’ютері із проблемою:

каталог скидання winsock

netsh int ipv4 reset reset.log

netsh int ipv6 reset reset.log 

Перезавантажте ПК, а потім знову приєднайте комп'ютер до домену.

Просто видаліть TLD з доменного імені та перезавантажте, він додасть його назад після перезавантаження, і все повинно бути добре. Ні суєти, ні мус

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

У мене була така ж проблема, і виявилося, що між собою брандмауер між ПК та постійним струмом блокував 135,389 тощо.

Щоб знайти цю проблему, я запустив Wireshark на ПК і зробив gpupdate /force. У провідній скарзі я побачив купу синхронних пакетів, що виходили до постійного струму без відповіді.

Після того, як брандмауер був виправлений, ми перезавантажили ПК, і він зміг правильно зв’язатися з постійним струмом, і проблема була вирішена.

Здається, що щось зіпсувало довіру між комп’ютером та доменом. Спробуйте видалити комп'ютер із домену та прочитати його.

Важко сказати, чому це сталося. Чи є повідомлення про помилки в журналах подій на постійному струмі зараз або приблизно в той час, коли це почалося? Чи були внесені якісь зміни в мережі?

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

1. Перевірте свою оренду DHCP та бронювання вашого постійного струму. Якщо у вас декілька записів для машин, які порушують правопорушення, зрівняйте їх до одного запису кожен. Потім запустіть ipconfig /release && ipconfig /renewна цих машинах.
2. Видаліть мережеві адаптери з Диспетчера пристроїв, а потім Скануйте нове обладнання для повторної інсталяції NIC.
3. Відновіть профілі брандмауера Windows до значень за замовчуванням: запустіть wf.mscі натисніть "Відновити політику за замовчуванням"
4. Вимкнути будь-який і всі брандмауери повністю. Для брандмауера Windows запустіть, wf.mscпотім натисніть "Властивості брандмауера Windows" та встановіть стан брандмауера "Вимкнено" для кожної вкладки профілю (Домен, приватний, загальнодоступний).

Останній варіант насправді не виправлений, але він може допомогти вирішити проблему.

Можливо, це допоможе комусь на цьому шляху. У мене виникла ця проблема, і причина в тому, що в пристрої Riverbed Steelhead було невідповідність VLAN. Інтерфейс In-Path на руслі ріки підключений до порту локальної мережі маршрутизатора, а інтерфейс In-Path був налаштований для "VLAN ID тегу" "0". Це спричинило проблему. Інтерфейс локальної мережі маршрутизатора знаходиться в конфігурації підінтерфейсу (один для голосової VLAN 40, а інший для даних / рідної VLAN 1), я зміг вирішити цю проблему, призначивши ідентифікатор тегу VLAN "1" (дані / рідне) та питання вирішено негайно.

Для мене нічого не вийшло.

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

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