802.1x PEAP GPO, который доверяет самозаверяющему сертификату CA
Я работаю над инфраструктурой аутентификации 802.1.x, поддерживаемой Freeradius, для наших беспроводных клиентов. Я использую довольно общую конфигурацию Freeradius с EAP-PEAP. Нашими клиентами являются преимущественно машины с Windows XP SP3, но также существует несколько ноутбуков с 32- и 64-разрядной ОС Windows 7. Наш домен находится на функциональном уровне Windows Server 2003. Аутентификация 802.1x работает с вручную настроенными тестовыми клиентами.
Я хочу создать объект групповой политики, который автоматически настраивает наших клиентов путем 1) развертывания для них самозаверяющего сертификата CA в качестве доверенного корневого сертификата и 2) настройки нашего ESSID в качестве предпочтительной сети с соответствующей конфигурацией 802.1x.
У меня нет трудностей с развертыванием самозаверяющего сертификата CA для клиентов, использующих GPO. Однако я не могу понять, как настроить сертификат в качестве доверенного корневого сертификата в объекте групповой политики.
Это из настроек GPO, находящихся в Computer Configuration - Polices - Security Settings - Wireless Network (IEEE 802.11) Polices:
Мой самозаверяющий сертификат ЦС недоступен в разделе «Доверенные корневые центры сертификации». Попытка аутентифицировать клиента без доверия моему самозаверяющему сертификату в настройках 802.1x PEAP завершается неудачей из-за настройки «Проверить сертификат сервера». И, конечно, если я вручную настрою клиент доверять моему сертификату, сертификат сервера радиуса может быть правильно проверен, и тогда 802.1x будет работать.
Моя цель состоит в том, чтобы иметь возможность назначить машину для OU, где будет применяться этот GPO, и все полученные настройки 802.1.x и CA будут выполнены без необходимости прикасаться к клиентской машине.
Как я могу создать объект групповой политики для параметров 802.1x PEAP, который настроит клиентов на доверие моему самозаверяющему сертификату CA?
РЕДАКТИРОВАТЬ:
Сервер Microsoft NPS или NAP на данный момент не подходит для моей организации из-за проблем с расходами. Лучший способ описать нашу среду - это централизованное расположение, в котором работают наши основные службы, с двумя десятками удаленных сайтов, подключенных через WAN-каналы различной скорости и надежности. У нас есть разные возможности и успехи в осуществлении положительного физического или политического контроля над этими удаленными сайтами, поэтому они являются моим основным направлением как для беспроводной, так и для проводной аутентификации 802.1x. Если мы потеряем соединение WAN (что случается нередко), мне по-прежнему нужны клиенты на удаленных сайтах, чтобы иметь возможность получить доступ к сети, поэтому в большинстве из этих мест требуется сервер RADIUS. Запрос на еще дюжину оконных серверов будет отклонен.
Исторически все наши серверы Linux и сетевое оборудование обслуживались отдельно от нашей доменной инфраструктуры. Это означает такие вещи, как разделение области DNS с независимыми службами DNS, независимой инфраструктурой аутентификации и так далее. Хотя я понимаю, что они являются некоторыми преимуществами для инфраструктуры PKI, интегрированной в домен, мне нужен хороший пример того, почему я должен это делать или, альтернативно, почему я не должен использовать независимую инфраструктуру PKI.
ХОРОШО. По общему признанию, я ни в коем случае не эксперт Microsoft или GPO, но это кажется странным.
Этот вопрос казалось, есть половина ответа - сертификат должен быть доступен в доверенных корневых центрах сертификации на любом контроллере домена, к которому подключается gpmc. В этом есть смысл. Однако даже после установки сертификата на нашем контроллере домена он по-прежнему не был доступен для выбора, если я запустил gpmc на своей рабочей станции. В качестве забавы я вошел в соответствующий контроллер домена и запустил gpmc напрямую, И сертификат был доступен.
Затем я попытался установить сертификат в доверенные корневые центры сертификации моей рабочей станции, думая в том же духе, что и @Greg Askew. Никаких кубиков. По-прежнему недоступен в качестве опции в настройках PEAP.
Вам очевидно нужно а) чтобы установить сертификат в доверенных корневых центрах сертификации на любом контроллере домена, к которому gpmc подключается, и б) запускать GPMC напрямую на этом контроллере домена.
Для меня это не имеет смысла, поскольку RSAT - это RSAT - это RSAT, независимо от того, используете ли вы gpmc на контроллере домена или на рабочей станции. Подумайте ... пиво идет тому, кто может это объяснить!
С моей рабочей станции - без сертификата:
С контроллера домена - сертификат имеется!
Просто предположение. Я бы подумал, что машина, на которой запущен gpmc, должна иметь сертификат в папке доверенного корневого ЦС компьютера и / или иметь объект групповой политики, который развертывает сертификат в домене как сертификат доверенного корневого ЦС.
У вас должен быть самозаверяющий сертификат с установленным только открытым ключом в списке доверенных сертификатов (CTL) беспроводного клиента "локального компьютера", а не CTL "текущего пользователя". Используйте mmc.exe, добавьте оснастку сертификата и выберите локальный компьютер.
В нашей конфигурации нам нужно было настроить корпоративный ЦС, и мы обнаружили, что проще всего настроить NPS-сервер для аутентификации.