Найти в Дзене

Траблшутинг Wi-Fi аутентификации 802.1x в AD

Ночью подняли новый контроллер домена, после чего перестал работать корпоративный Wi-Fi. Контроллер не основной, дополнительный в офисе. Пользователи входят под своей доменной учётной записью, их не пускает. С утра паника в селе, нужно срочно чинить. 802.1x — не алё.

Точки Cisco управляются через виртуальный контроллер, который по RADIUS обращается к новому контроллеру домена. Что-то не так на DC, смотрю в логи и вижу ошибку:

Audit Failure. Event ID 6273
Network Policy Name: Secure Wireless Connections
Authentication Type: EAP

The client could not be authenticated because the Extensible Authentication Protocol (EAP) Type cannot be processed by the server.
-2

Есть от чего оттолкнуться. Становится понятно, что Wi-Fi контроллер обратился к AD с попыткой аутентификации пользователя по протоколу EAP, что описано в политике Secure Wireless Connections. А контроллер не смог выполнить аутентификацию.

Extensible Authentication Protocol (EAP, расширяемый протокол проверки подлинности) — это платформа проверки подлинности, которая позволяет использовать различные методы проверки подлинности для технологий безопасного доступа к сети. Примеры этих технологий включают беспроводной доступ с использованием IEEE 802.1X, проводной доступ с помощью IEEE 802.1X и подключения PPP, такие как виртуальная частная сеть (VPN). EAP не является конкретным методом проверки подлинности, как MS-CHAP версии 2, а платформой, которая позволяет поставщикам сетей разрабатывать и устанавливать новые методы проверки подлинности, известные как методы EAP, на клиенте доступа и сервере проверки подлинности. Платформа EAP изначально определена RFC 3748 и расширена различными другими RFC и стандартами.

-3

Запускаем оснастку Network Policy Server (NPC) и смотрим что у нас с политикой Secure Wireless Connections. Правой кнопкой — Свойства. Полазил по оснастке, сравнил с другими контроллерами домена, все настройки одинаковые. Копаем глубже.

-4

Вкладка Constraints → Authentication Methods → EAP Types → Microsoft: Protected EAP (PEAP). Вот здесь у нас находятся настройки EAP аутентификации, которая у нас не работает. Для данной аутентификации требуется сертификат, обычно он может протухнуть или быть недоверенным. Проверим, нажимаем Edit.

-5

Упс, ошибка:

A certificate could not be found that can be used with this Extensible Authentication Protocol.

Очень странно. Обычно для EAP используется сертификат самого контроллера домена. Открываю оснастку сертификатов локального компьютера DC.

-6

А здесь вообще нет сертификата контроллера домена. Понятно почему аутентификация не работает. Нам нужен сертификат нового контроллера домена. Непонятно почему его нет.

-7

Правой кнопкой → All Tasks → Request New Certificate...

-8

Меня устраивает Active Directory Enrollment Policy. Next.

-9

Выбираю галкой сертификат Domain Controller. Enroll.

-10

Ждём. Ошибка. RPC сервер недоступен, и ссылка на центр сертификации.

-11

Становится понятно почему контроллер домена не смог получить свой сертификат. Нет доступа к центру сертификации. Пробую открыть в браузере.

-12

Действительно, доступа не хватает. Делаю заявку на открытие доступа. Не помню какие порты уже просил открыть, 80-й, 135-й.. Это можно на Firewall отловить. Доступы предоставили.

Попытка номер два.

-13

Succeeded.

-14

У контроллера домена появился свой сертификат. Что не может не радовать.

Снова пробуем отредактировать Microsoft: Protected EAP (PEAP).

-15

Оснастка теперь открывается.

Мне кажется, проблема уже устранена. Посылаем гонца попробовать аутентифицироваться в сети Wi-Fi, аутентификация проходит успешно. Скорее всего, устранены и другие проблемы, о которых мы и не знали.

Что ещё могло бы быть

В нашем случае у нас вообще не было никакого сертификата, подходящего для EAP аутентификации. Но могут быть и другие проблемы, связанные со сроком действия сертификата, с отзывом сертификатов, с сертификатами промежуточных и корневых центров сертификации.

NPS сервер может и не быть контроллером домена. Там может использоваться какой-то другой сертификат, даже самоподписанный. Этому сертификату должны доверять клиенты.

Старенькая статья с требованиями к сертификату:

https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc731363(v=ws.10)?redirectedfrom=MSDN

Кто-то пишет что находил проблему в отключенной версии протокола TLS. У кого-то время на точках доступа было выставлено неверно.

Источник:

Траблшутинг Wi-Fi аутентификации 802.1x в AD | internet-lab.ru

💰 Поддержать проект

Если вам понравилась статья, то ставьте 👍🏻 каналу.
Пишите комментарии, задавайте вопросы, подписывайтесь.