802.1x автоматически проверяет сертификат в клиентах Windows

Вам необходимо распространить сертификат вашего сервера RADIUS (если он был самоподписанный) или сертификат центра сертификации, который подписал его, вашим клиентам.

Прямо сейчас вы говорите своим клиентам (или соискателям в 802.1X-ese) проверить путь доверия сертификата вашего RADIUS-сервера. Я не знаю, как вы сгенерировали свою пару открытого и закрытого ключей для своего сервера RADIUS, но, вообще говоря, он будет либо самоподписанным, либо подписанным центром сертификации. В свою очередь, открытый ключ подписывающего центра сертификации будет распространяться среди клиентов либо через объекты групповой политики, службы сертификации Active Directory, либо он был включен Microsoft в репозиторий доверенного корневого центра сертификации.

Кто-нибудь знает, как этого избежать? Мы полностью готовы купить сертификат Verisign, Thwarte и т. Д., Если это поможет, но мы попробовали наш SSL-сертификат Comodo wildcard, который не исправил его.

Не рекомендуется использовать внешний корневой центр сертификации, подписывающий сертификат вашего сервера RADIUS.

Это из документации FreeRADIUS, но я ожидаю, что это справедливо и для реализации Microsoft:

В общем, вы должны использовать самозаверяющие сертификаты для 802.1x (EAP)
аутентификация. Когда вы перечисляете корневые центры сертификации других организаций в
"CA_file", вы разрешаете им маскироваться под вас для аутентификации
ваших пользователей, а также для выпуска клиентских сертификатов для EAP-TLS.

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

Ну вот и твоя проблема! Распространять сертификаты с помощью объектов групповой политики достаточно просто. Почему это не вариант в вашем случае? Если это не так, у вашего собственного звездообразного сертификата (который подписан корневым центром сертификации) вы могли бы подписать сертификат вашего сервера RADIUS?

РЕДАКТИРОВАТЬ: К сожалению, BYOD и WPA2-Enterprise на самом деле не предназначены для совместной работы. У вас есть три варианта:

1. Настройте своих клиентов так, чтобы они не проверяли доверительный путь сертификата вашего сервера RADIUS (т. Е. Снимите флажок с надписи «Подтвердить сертификаты сервера»).
2. Получите сертификат вашего сервера RADIUS, подписанный «внешним» центром сертификации, сертификат подписи которого распространяется в репозитории доверенного корневого центра сертификации (например, Verisign, Comodo и т. Д.).
3. Настройте своего рода перехватывающий портал, который действует как проситель от имени ваших клиентов.

Недостатками первых двух вариантов является то, что он открывает вашу схему 802.1X для атак MiTM. Я мог бы создать свой собственный сервер RADIUS и перехватить учетные данные вашего пользователя AD. Не идеальная установка, но ваш отдел должен будет провести анализ рисков. Если вы все-таки пойдете по этому пути, убедитесь, что вы документально оформляете CYA.

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

Эдуроам - еще один популярный выбор для образовательных организаций.

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

Во-первых, я использовал несколько SSID для обеспечения основной сети на WPA2-Enterprise и открытой сети для регистрации пользователей. Открытая сеть перенаправляет на настраиваемый портал авторизации (с использованием HTTPS и обычного сертификата, выданного центром сертификации), где пользователи зарегистрировались и предоставили платежную информацию. После завершения оплаты пользователи включаются в базу данных RADIUS, а затем могут повторно подключиться к SSID WPA2-Enterprise, чтобы выйти в Интернет.

Поскольку у меня был жесткий крайний срок, чтобы его запустить и запустить, он был протестирован только с Android и iOS, и ни один из них не имел реальных проблем. В процессе производства я довольно быстро понял, что Windows это совсем не нравится.

• Windows XP нуждался в SP3 для использования защищенной сети, поэтому я сохранил локальную копию для прямой загрузки на адаптивном портале. Один пользователь действительно появился с XP SP2, и его нужно было обновить.
• Windows XP, Vista и 7 отказались подключаться с указанием имени пользователя и пароля, но никогда не жаловались конкретно на сертификат сервера. Я обнаружил, что это было причиной методом проб и ошибок с первым зарегистрировавшимся пользователем Windows. На самом деле вручную настроить сетевой профиль было довольно просто, как только проблема была обнаружена.
• Windows 8, iOS и версия NetworkManager для GNOME / Ubuntu запрашивали сертификат сервера RADIUS, но позволяли пользователям принять сертификат и подключиться.
• Версия NetworkManager для KDE никогда не пыталась подключиться без ручной настройки, и выбранные ею значения по умолчанию были неправильными. К счастью, только один пользователь обнаружился с этой конкретной конфигурацией.
• Никто не запрашивал поддержку Mac OS X. Позже я узнал, что клиенты Mac OS X подключаются без проблем.

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

Я знаю, что этот пост действительно старый, однако он похож на мою проблему, за исключением того, что на прошлой неделе любой клиент мог подключиться к моей беспроводной сети, а на этой неделе - нет. У меня Aruba EOL 3200 с 8 точками доступа. Клиенты windows / android / iphone могли подключаться с помощью 802.1x с проверкой по локальной базе данных Aruba с одним именем пользователя. На этой неделе, войдя в систему, я заметил, что мой телефон не может подключиться к беспроводной сети. Тогда мой ноутбук с Windows 10 не смог подключиться (оба подключились раньше). Только клиенты, которые не отключились от сети, по-прежнему могли получить к ней доступ. Это происходит только с ssid 802.1x (штатный), а не с ssid PSK (для гостей). Затем я подтвердил, что единственный способ для компьютера с Windows подключиться к нему - это снять флажок «проверить идентичность сервера путем проверки сертификата» при добавлении профиля вручную. Устройства Android по-прежнему не могут подключиться.