Вопрос или проблема
Всем привет!
Я хотел бы переключиться с аутентификации пользователя/пароля PEAP-MSCHAPv2 на аутентификацию на основе сертификатов в своей сети. Текущая настройка работает уже много лет без проблем: два контроллера домена Windows 2016 с ролью NPS и клиенты Windows 10 + Windows 11. Аутентификация работает как для проводных, так и для беспроводных клиентов (разрешено использовать как учетные записи компьютеров, так и учетные записи пользователей).
Тестовая среда
Для целей тестирования я развернул отдельный коммутатор (Aruba 2530) и выбрал две физические машины: одну с Windows 10 и одну с Windows 11. Обе машины присоединены к домену и правильно загружают все настройки из объектов групповой политики. Настройки, которые нас интересуют:
- автозапуск службы Wired Autoconfig
- разрешить автоматическую регистрацию сертификатов
- настройка проводного сетевого профиля для аутентификации с помощью сертификата, только аутентификация машины
Коммутатор был добавлен в качестве клиента RADIUS на контроллере домена №2. Коммутатор указывает на контроллер домена №2 как единственный хост RADIUS.
Также я создал новую сетевую политику на контроллере домена №2, которая обрабатывает запросы только от указанного коммутатора (таким образом, я не нарушу подключение для других клиентов RADIUS во время своих экспериментов). Политика настроена на использование ‘Microsoft: смарт-карт или другого сертификата’, и я убедился, что правильный сертификат выбран из списка.
Что касается сертификатов, на серверах NPS уже были правильно зарегистрированы сертификаты от доменного удостоверяющего центра. Для целей тестирования я выдал новый шаблон сертификата для клиентов, который теперь они могут автоматически регистрировать для использования в сетевой аутентификации (все это было настроено в соответствии со статьей Microsoft).
Поведение клиентов
Теперь вот где все становится странным…
Windows 11 (ноутбук Lenovo), подключенный к конфигурируемому для аутентификации портам коммутатора, аутентифицируется почти мгновенно, при этом журналы событий на клиенте и сервере NPS показывают похожую информацию: аутентификация прошла успешно, доступ к сети предоставлен (также показывается, что используется правильная сетевая политика). Успех!
Однако Windows 10 (настольный компьютер Dell) не может аутентифицироваться! Журнал событий на клиенте сообщает “Сеть перестала отвечать на запросы аутентификации” с причиной 0x70004. Журнал событий на сервере NPS не показывает никаких признаков неудачной аутентификации, как будто запрос никогда не достиг сервера!
Это кажется очень странным, так как настройки, загружаемые из GPO, идентичны, и я подключаю оба ноутбука к одному и тому же коммутатору, так что это контролируемая среда. Оба компьютера имеют правильные сертификаты в своих хранилищах.
Перехват пакетов
Я также не увидел никаких связанных событий на коммутаторе, поэтому настроил зеркалирование портов и запустил захват пакетов.
Там я четко вижу, что процесс аутентификации машины с Windows 10 останавливается после того, как ПК отправляет ‘Client Hello’. Только через некоторое время коммутатор отправляет ‘Failure’ клиенту, завершая весь процесс.
На Windows 11, однако, я вижу, что сразу после ‘Client Hello’ сервер отвечает ‘Change Cipher Spec, Encrypted Handshake Message’, что приводит к ‘Success’ вскоре после этого.
Я посмотрел на пакеты ‘Client Hello’, и там есть некоторые различия, самое очевидное из которых – версия TLS в одной строке (выделено). Похоже, Windows 10 использует TLS 1.2, а Windows 11 использует TLS 1.0? Или я неправильно читаю? Кроме того, списки наборов шифров, которые предлагают клиенты, немного различаются.
Windows 10:
Windows 11:
И вот ответ от сервера NPS на машину с Windows 11, на случай, если это даст дополнительную информацию:
Я немного запутался, надеюсь, кто-то сможет прояснить ситуацию и указать мне верное направление – вероятно, как убедиться, что Windows 10 использует правильный шифр для этой цели. Я чувствую, что это может быть причиной сбоя аутентификации.
Обновление 24/04/2024: Смотрите отладку на коммутаторе.
0000:00:41:13.31 1X m8021xCtrl:Port 24: добавлен новый клиент f8b156-b83e62.
0000:00:41:13.34 1X m8021xCtrl:Port 24: получен EAPOL Start от f8b156-b83e62.
0000:00:41:13.34 1X m8021xCtrl:Port 24: клиент f8b156-b83e62 добавлен в VLAN 40.
0000:00:41:13.87 1X m8021xCtrl:Port 24: установлено соединение.
0000:00:41:13.87 1X m8021xCtrl:Port 24: отправлено ReqId #1 клиенту f8b156-b83e62.
0000:00:41:13.87 1X m8021xCtrl:Port 24: количество отправленных запросов EAP Id: 1 клиенту: f8b156-b83e62.
0000:00:41:13.87 1X m8021xCtrl:Port 24: получен RspId #1 от f8b156-b83e62.
0000:00:41:13.87 1X m8021xCtrl:Port 24: enterAuthState для клиента f8b156-b83e62, State SM_AUTHENTICATING для host/0pc-test.domain.local0000:00:41:13.87 1X m8021xCtrl:Port 24: начата сессия аутентификации для клиента f8b156-b83e62 пользователь: host/0pc-test.domain.local.
0000:00:41:13.87 RAD mRadiusCtrl:Получено RADIUS MSG: AUTH REQUEST, сессия: 10, метод доступа: PORT-ACCESS.
0000:00:41:13.87 1X m8021xCtrl:Port 24: получен запрос EAP идентичности для клиента f8b156-b83e62.
0000:00:41:13.87 1X m8021xCtrl:Port 24: отправлен EAP ответ от клиента f8b156-b83e62 на сервер аутентификации.
0000:00:41:13.87 RAD mRadiusCtrl:Получено RADIUS MSG: DATA, сессия: 10.
0000:00:41:13.87 RAD mRadiusCtrl:ACCESS REQUEST id: 22 к 10.10.5.11 сессия: 10, метод доступа: PORT-ACCESS, User-Name: host/0pc-test.domain.local, Calling-Station-Id: f8b156-b83e62, NAS-Port-Id: 24, NAS-IP-Address: 10.10.5.231.
0000:00:41:13.87 RAD mRadiusCtrl:ACCESS REQUEST id: 22 к 10.10.5.11 сессия: 10, метод доступа: PORT-ACCESS, NAS-identifier: HP-2530-24G.
0000:00:41:13.89 RAD tRadiusR:ACCESS CHALLENGE id: 22 от 10.10.5.11 получен.
0000:00:41:13.89 1X m8021xCtrl:Port 24: получен запрос EAP для клиента f8b156-b83e62.
0000:00:41:13.89 1X m8021xCtrl:Port 24: EAP запрос #2 для f8b156-b83e62 может пройти без обработки аутентификатором.
0000:00:41:13.89 1X m8021xCtrl:Port 24: отправлен EAP запрос #2 для f8b156-b83e62.
0000:00:41:13.89 1X m8021xCtrl:Port 24: установлен таймаут для клиента f8b156-b83e62 на 30 секунд.
0000:00:41:13.90 1X m8021xCtrl:Port 24: получен тип 13 EAP ответ #2 от f8b156-b83e62.
0000:00:41:13.90 1X m8021xCtrl:Port 24: EAP ответ #2 для f8b156-b83e62 может пройти без обработки аутентификатором.
0000:00:41:13.90 1X m8021xCtrl:Port 24: отправлен EAP ответ от клиента f8b156-b83e62 на сервер аутентификации.
0000:00:41:13.90 RAD mRadiusCtrl:Получено RADIUS MSG: DATA, сессия: 10.
0000:00:41:13.90 RAD mRadiusCtrl:ACCESS REQUEST id: 23 к 10.10.5.11 сессия: 10, метод доступа: PORT-ACCESS, User-Name: host/0pc-test.domain.local, Calling-Station-Id: f8b156-b83e62, NAS-Port-Id: 24, NAS-IP-Address: 10.10.5.231.
0000:00:41:13.90 RAD mRadiusCtrl:ACCESS REQUEST id: 23 к 10.10.5.11 сессия: 10, метод доступа: PORT-ACCESS, NAS-identifier: HP-2530-24G.
0000:00:41:13.90 RAD tRadiusR:ACCESS CHALLENGE id: 23 от 10.10.5.11 получен.
0000:00:41:13.90 1X m8021xCtrl:Port 24: получен запрос EAP для клиента f8b156-b83e62.
0000:00:41:13.90 1X m8021xCtrl:Port 24: EAP запрос #3 для f8b156-b83e62 может пройти без обработки аутентификатором.
0000:00:41:13.90 1X m8021xCtrl:Port 24: отправлен EAP запрос #3 для f8b156-b83e62.
0000:00:41:13.90 1X m8021xCtrl:Port 24: установлен таймаут для клиента f8b156-b83e62 на 30 секунд.
0000:00:41:32.61 1X m8021xCtrl:Port 24: соединение прервано.
0000:00:41:32.61 1X m8021xCtrl:Port 24: удален клиент f8b156-b83e62 Пользователь host/0pc-test.domain.local из списка клиентов
0000:00:41:32.61 1X m8021xCtrl:Прерывание сессии аутентификации для клиента f8b156-b83e62.
0000:00:41:32.61 RAD mRadiusCtrl:Получено RADIUS MSG: ABORT REQUEST, сессия: 10, ACCESS REQUEST id: 23 к 10.10.5.11, метод доступа: PORT-ACCESS.
0000:00:41:32.61 RAD mRadiusCtrl:Удаление RADIUS REQUEST id: 23 из очереди.
Обновление: При попытке получить аутентификацию принтеров в сети с использованием сертификата, я узнал, что MTU нужно изменить на серверах NPS, согласно этой статье: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc755205(v=ws.10)?redirectedfrom=MSDN
В настоящее время я тестирую это только на сетевой политике, посвященной принтерам, но вскоре я собираюсь протестировать это на рабочих станциях и дам знать о результатах.
Ответ или решение
Проблема, с которой вы столкнулись, может вызывать весьма сложные технические вопросы, особенно при переходе от аутентификации PEAP-MSCHAPv2 к аутентификации на основе сертификатов с использованием EAP-TLS. Рассмотрим ключевые аспекты вашего сценария, чтобы помочь выявить возможные причины проблемы с аутентификацией на Windows 10.
1. Обзор ситуации
Вы можете использовать систему Windows Server 2016 с ролью NPS (Network Policy Server) для аутентификации клиентов на основе сертификатов. Ваша тестовая установка включает в себя два клиентских устройства – одно с Windows 10 и другое с Windows 11. В то время как Windows 11 выполняет аутентификацию успешно, Windows 10 сталкивается с ошибкой: "Сеть перестала отвечать на запросы аутентификации" с кодом 0x70004.
2. Сравнение сетевых условий
Так как описанные вами условия в тестовой среде идентичны для двух устройств, стоит обратить внимание на следующие технические параметры:
a. Протоколы шифрования
Как вы заметили, существует различие в версиях TLS, используемых клиентами. Ваша диагностика показывает, что Windows 10 использует TLS 1.2, а Windows 11 возможно использует более старую версию TLS (например, 1.0). Это может быть причиной проблемы, так как некоторые старые устройства и настройки сети могут не поддерживать более новые протоколы и шифры.
b. Набор шифров
Также обратите внимание на различия в наборах шифров, которые предлагают оба устройства в процессе аутентификации. Windows 10 может предлагать шифры, которые не поддерживаются вашим сетевым оборудованием или NPS. Необходимо убедиться, что все клиенты и серверы на одной стороне поддерживают одинаковые наборы шифров.
3. Настройки сертификатов
Проверка сертификатов, используемых для EAP-TLS, играет важную роль:
- Убедитесь, что на каждом клиенте установлен правильный сертификат, а также что он доверен в цепочке сертификатов до корневого сертификата.
- Нужно проверить, что расширения сертификатов настроены правильно (например, расширения Key Usage и Enhanced Key Usage).
4. Настройки групповой политики
Поскольку вы используете группы политик, важно подтвердить, что настройки, касающиеся аутентификации и шифрования, одинаковые для обеих версий Windows:
- Убедитесь, что политики на самом деле применяются правильно и не игнорируются Windows 10.
- Проверьте функции автоматического получения сертификатов и других параметров, чтобы гарантировать, что они настроены в соответствии с вашими ожиданиями.
5. Настройка MTU
Вы упомянули о необходимости изменения MTU на серверах NPS. Установление правильного значения MTU может значительно повлиять на сетевые операции, особенно если в пакетах ненароком отсутствует что-либо важное из-за фрагментации. Неправильное значение MTU может приводить к сбоям в аутентификации, поэтому данный аспект также стоит проверить.
Рекомендации по устранению неполадок
- Проверьте настройки шифрования на обоих клиентах по сравнению с теми, что поддерживаются вашим переключателем и NPS.
- Сравните клиентские сертификаты на предмет корректности важной информации.
- Пересмотрите групповую политику для Windows 10 и убедитесь, что все настройки идентичны Windows 11.
- Измените настройки MTU на NPS, это может помочь в некоторых случаях.
- Изучите логи NPS и вспомогательных систем, чтобы найти дополнительные подсказки о том, почему запросы с Windows 10 не обрабатываются.
Заключение
Тщательное разбирательство всех аспектов — от сертификатов и настроек шифрования до политик групп — поможет вам выявить корень проблемы с аутентификацией устройств на Windows 10 в вашем окружении EAP-TLS. Важно принимать во внимание и общие сетевые настройки, которые могут оказывать влияние на успешное взаимодействие устройств и сетевой инфраструктуры.