• 1. «Быстрая» установка сертификатов
• 1.1 Установка корневого сертификата CA напрямую
• 1.2 Установка клиентского сертификата напрямую
• 2. Установка сертификатов через интерфейс управления сертификатами Internet Explorer
• 2.1 Установка пользовательских сертификатов через интерфейс управления сертификатами
• 2.2 Установка корневого сертификата через интерфейс управления сертификатами
• 3. Настройка точки доступа
• 4. Настройка беспроводной сети на клиенте
• 5. Процесс подключения со стороны RADIUS-сервера
• 6. Добавление FreeRadius в автостарт
• Заключение

В предыдущей статье рассматривался вопрос настройки RADIUS-сервера и генерации сертификатов для работы беспроводной сети с применением WPA шифрования и аутентификации клиентов по протоколу EAP-TLS (с использованием клиентских сертификатов).

В этой части мы коснемся настроек клиентской части. Напомню, что операционная система Microsoft Windows XP, начиная с Service Pack 1 (а лучше сразу поставить Service Pack2), при работе с беспроводными сетями позволяет использовать аутентификацию по логину/паролю (то есть PEAP) и аутентификацию по цифровому сертификату (EAP-TLS). Механизм PEAP уже рассматривался нами ранее, сегодня будет рассмотрен EAP-TLS.

Для работы нам потребуется не более того, что упоминалось в предыдущей части статьи. А именно:

• беспроводной клиент — в данном случае это USB беспроводной адаптер ASUS WL-167g, подключенный к компьютеру с операционной системой Windows XP pro + SP2
• точка доступа с поддержкой WPA — ей являлась TRENDnet TEW-410APB+
• RADIUS-сервер — был использован FreeRadius сервер версии 1.0.5, работающий под операционной системой Gentoo Linux.
• OpenSSL (был использован пакет openssl-0.9.7g)

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

«Быстрая» установка сертификатов.

Сертификаты можно устанавливать как напрямую, щелчком из проводника (windows explorer), так и через отдельную интерфейс-закладку Internet Explorer (еще это можно делать через mmc-консоль).

Рассмотрим первый способ установки, как самый быстрый и простой.

1.1 Установка корневого сертификата CA напрямую.

Для начала, необходимо установить корневой сертификат CA (сертификационного центра). Просто открываем в Windows Explorer-е директорию, где у нас лежат файлы сертификатов, и два раза щелкаем на созданном ранее файле tmp_org-ca.crt

В ответ получаем окошко, где нам предлагается установить сертификат в систему. Можно сразу щелкнуть по кнопке "Установить сертификат", а можно предварительно побегать по закладкам:

Закладка "Состав" показывает все параметры сертификата. Особенно интересны пункты "Действителен с" и "Действителен по" — сертификат будет действителен только в этом промежутке времени. Если им воспользоваться раньше или позже указанного времени, он будет отвергнутым (это касается сертификатов любых типов — как серверных, так и клиентских).

"Путь сертификации" показывает, что сертификат является корневым (самоподписанным).

После нажатия кнопки "Установить сертификат" в закладке "Общие", мы попадем в мастер импорта сертификатов.

Операционная система сама разберется, куда помещать сертификат, поэтому можно оставить галку на "Автоматически выбрать хранилище".

… осталось нажать кнопку "готово".

Выскакивает последнее предупреждение об установке нового центра сертификации "tmp_org root CA".

После нажатия на кнопку "да" в предыдущем меню, система сообщит нам, что импорт выполнен. Тем не менее, даже после нажатия на "ОК", основное окошко с сертификатом продолжает сообщать, что сертификат неизвестен. Это всего лишь "фича" операционной системы. Достаточно закрыть то окно и открыть его заново (два раза щелкнуть на файл с сертификатом):

В этом случае нам уже сообщают, что сертификат известен и ему доверяют.

1.2 Установка клиентского сертификата напрямую.

Клиентский сертификат устанавливается не сложнее, чем серверный. Выбираем в браузере нужный файл, в данном случае это — test_user2.p12,

И щелкаем на нем два раза левой кнопкой мыши.

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

Вводим пароль, которым был закрыт файл персонального сертификата (при конвертации его в формат PKCS#12).

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

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

Далее опять предоставляем Windows самой разобраться, куда кидать персональный сертификат.

Последнее подтверждение….

… и персональный сертификат установлен.

2. Установка сертификатов через интерфейс управления сертификатами Internet Explorer.

2.1 Установка пользовательских сертификатов через интерфейс управления сертификатами.

Все вышеописанные действия (а также посмотреть, какие сертификаты у нас установлены и, при необходимости, удалить их) можно и следующим образом:

В Internet Explorer жмем на "Сервис -> Свойства обозревателя"

В появившемся окне идем на закладку "Содержание" и жмем кнопку "Сертификаты".

В появившемся меню нас интересует закладка "Личные".

Тут хранятся персональные сертификаты пользователя. Как видно, один из них — test_user2 — уже установлен. Щелкнув по нему, можно посмотреть его содержимое.

Персональный сертификат действителен на период с 13.12.2005 по 13.12.2007. Он выдан test_user2 и подписан центром "tmp_org root CA".

… что также наглядно видно в закладке "Путь сертификации" (речь идет о том, кем подписан клиентский сертификат).

Если нажать на кнопку "Импорт", то мы увидим уже знакомый нам интерфейс установки сертификатов. Тем самым, через этот интерфейс можно установить дополнительные персональные сертификаты 

2.2 Установка корневого сертификата через интерфейс управления сертификатами.

Если перейти на закладку "Доверенные корневые центры сертификации" в интерфейсе "сертификаты" Internet Explorer-а, то

… тут мы увидим большое количество установленных в систему корневых сертификатов различных организаций. Тут же находится и установленный нами корневой сертификат нашего собственного центра. Нажав на кнопку "Импорт" можно установить другие корневые сертификаты.

3. Настройка точки доступа.

Настройка точки доступа аналогична процедуре, описанной в предыдущей статье, поэтому подробно описывать этот процесс не будем.

По сравнению с предыдущим разом, изменилось лишь название (SSID) беспроводной сети, теперь она называется WPA-TLS.

4. Настройка беспроводной сети на клиенте.

Профиль опять-таки настраивается похожим на предыдущий случай образом. Но тут присутствуют существенные отличия.

Заходим в Zero Config Utility, жмем на "Изменить порядок предпочтения сетей".

В закладке "Беспроводные сети" жмем кнопку "Добавить".

В закладке "Связи" вводим имя сети (WPA-TLS), в качестве проверки подлинности опять выбираем WPA, а шифрование данных — AES.

Пока все то же самое, не так ли? А с закладки "Проверка подлинности" появляются отличия.

В качестве "Типа EAP" выставляем "Смарт карта или другой сертификат".

Галка "Проверять подлинность как у компьютера при доступности сведений о компьютере" пока не нужна, ее необходимость будет рассмотрена позже.

Теперь жмем на кнопку "Свойства".

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

После чего активировать "проверку сертификата сервера" и в появившемся внизу списке сертификатов корневых серверов выбрать наш личный центр — tmp_org root CA.

Конечно, можно не активировать проверку сертификата сервера, но ведь мы настраиваем безопасную сеть, не так ли? И должны убедиться, что точка доступа наша, так как обращается к нашему RADIUS-серверу. При подключении к точке доступа, она (а точнее RADIUS) предъявляет свой, серверный сертификат, также подписанный корневым tmp_org root CA. На клиенте проверяется валидность этого сертификата, и если все нормально, процесс установления соединения устанавливается.

Также можно оставить включенной проверку сертификата сервера, но не выбирать в списке корневой сертификат нашего центра.

Тогда при первом подключении к точке доступа, в трее выскочит окошко, предлагающее убедиться в валидности предъявляемого радиусом сертификата. После клика на нем,

появится окно, сообщающее, что корневым сертификатом для предъявленного сервером радиуса, является "tmp_org root CA". Если нажать ОК, то соединение продолжится.

Если же убрать галку с "проверка сертификата сервера", то никаких проверок валидности серверного сертификата на клиенте производиться не будет. Но это небезопасно — кто угодно может поставить собственную точку доступа, настроенную аналогично нашей (то же имя сети (SSID), те же параметры шифрования и собственный центр сертификации), в результате мы подключимся к чужой сети, возможно, с самыми печальными последствиями.

Последняя закладка — "Подключение" — в свойствах беспроводной сети позволяет активировать автоматическое подключение к сети, как только она будет обнаружена клиентом.

На этом настройка беспроводного клиента завершена. После закрытия всех окошек (нажатия на ОК), клиент автоматически будет подключаться к беспроводной сети, используя свой сертификат вместо логина с паролем:

5. Процесс подключения со стороны RADIUS-сервера.

Со стороны RADIUS-а (запущенного, напоминаю, в debug-режиме — radiusd -X), заключительная стадия процесса подключения клиента выглядит следующим образом: ===================================================== rad_recv: Access-Request packet from host 192.168.1.250:3072, id=0, length=195 User-Name = "test_user2" NAS-IP-Address = 192.168.1.250 Called-Station-Id = "000e8e7a2dd1" Calling-Station-Id = "0013d403ac86" NAS-Identifier = "000e8e7a2dd1" NAS-Port = 41 Framed-MTU = 1400 State = 0x8a5a90cabcfb886c9dbd61be9ed55b5e NAS-Port-Type = Wireless-802.11 EAP-Message = 0x0205003d0d00b21<…..> Message-Authenticator = 0x8223c428f4e032137683f4beb4d41394 # # # получили запрос от клиента test_user2 # # Processing the authorize section of radiusd.conf modcall: entering group authorize for request 5 modcall[authorize]: module "preprocess" returns ok for request 5 modcall[authorize]: module "chap" returns noop for request 5 modcall[authorize]: module "mschap" returns noop for request 5 rlm_realm: No '@' in User-Name = "test_user2", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 5 rlm_eap: EAP packet type response id 5 length 61 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 5 users: Matched entry DEFAULT at line 152 modcall[authorize]: module "files" returns ok for request 5 modcall: group authorize returns updated for request 5 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 5 rlm_eap: Request found, released from the list rlm_eap: EAP/tls rlm_eap: processing type tls rlm_eap_tls: Authenticate rlm_eap_tls: processing TLS eaptls_verify returned 7 rlm_eap_tls: Done initial handshake # # # переходим к EAP-TLS # # rlm_eap_tls: <<< TLS 1.0 Handshake [length 03c3], Certificate chain-depth=1, error=0 --> User-Name = test_user2 --> BUF-Name = tmp_org root CA --> subject = /C=RU/ST=Euro/L=Moscow/O=Temp Organisation/ OU=network IT/CN=tmp_org root CA/emailAddress=admin@tmp_org.ru --> issuer = /C=RU/ST=Euro/L=Moscow/O=Temp Organisation/ OU=network IT/CN=tmp_org root CA/emailAddress=admin@tmp_org.ru --> verify return:1 # # # проверка клиентского сертификата # # radius_xlat: 'test_user2' rlm_eap_tls: checking certificate CN (test_user2) with xlat'ed value (test_user2) hain-depth=0, error=0 --> User-Name = test_user2 --> BUF-Name = test_user2 --> subject = /C=RU/ST=Euro/L=Moscow/O=TempOrg/ OU=network IT/CN=test_user2/emailAddress=email@tmp_org.ru --> issuer = /C=RU/ST=Euro/L=Moscow/O=Temp Organisation/ OU=network IT/CN=tmp_org root CA/emailAddress=admin@tmp_org.ru --> verify return:1 TLS_accept: SSLv3 read client certificate A rlm_eap_tls: <<< TLS 1.0 Handshake [length 0106], ClientKeyExchange TLS_accept: SSLv3 read client key exchange A rlm_eap_tls: <<< TLS 1.0 Handshake [length 0106], CertificateVerify TLS_accept: SSLv3 read certificate verify A rlm_eap_tls: <<< TLS 1.0 ChangeCipherSpec [length 0001] rlm_eap_tls: <<< TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 read finished A rlm_eap_tls: >>> TLS 1.0 ChangeCipherSpec [length 0001] TLS_accept: SSLv3 write change cipher spec A rlm_eap_tls: >>> TLS 1.0 Handshake [length 0010], Finished TLS_accept: SSLv3 write finished A TLS_accept: SSLv3 flush data (other): SSL negotiation finished successfully SSL Connection Established # # # успешно # # eaptls_process returned 13 modcall[authenticate]: module "eap" returns handled for request 5 modcall: group authenticate returns handled for request 5 Sending Access-Challenge of id 0 to 192.168.1.250:3072 EAP-Message = 0x010600350d800000002b140301<…..> Message-Authenticator = 0x00000000000000000000000000000000 State = 0x5de53352b5dcb72f5edaee4447c52f57 Finished request 5 Going to the next request Waking up in 6 seconds… rad_recv: Access-Request packet from host 192.168.1.250:3072, id=0, length=140 User-Name = "test_user2" NAS-IP-Address = 192.168.1.250 Called-Station-Id = "000e8e7a2dd1" Calling-Station-Id = "0013d403ac86" NAS-Identifier = "000e8e7a2dd1" NAS-Port = 41 Framed-MTU = 1400 State = 0x5de53352b5dcb72f5edaee4447c52f57 NAS-Port-Type = Wireless-802.11 EAP-Message = 0x020600060d00 Message-Authenticator = 0x043c2a96c46a97c60efc5e36cb790d16 Processing the authorize section of radiusd.conf Calling-Station-Id = "0013d403ac86" modcall[authorize]: module "preprocess" returns ok for request 6 modcall[authorize]: module "chap" returns noop for request 6 modcall[authorize]: module "mschap" returns noop for request 6 rlm_realm: No '@' in User-Name = "test_user2", looking up realm NULL rlm_realm: No such realm "NULL" modcall[authorize]: module "suffix" returns noop for request 6 rlm_eap: EAP packet type response id 6 length 6 rlm_eap: No EAP Start, assuming it's an on-going EAP conversation modcall[authorize]: module "eap" returns updated for request 6 users: Matched entry DEFAULT at line 152 modcall[authorize]: module "files" returns ok for request 6 modcall: group authorize returns updated for request 6 rad_check_password: Found Auth-Type EAP auth: type "EAP" Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 6 rlm_eap: Request found, released from the list rlm_eap: EAP/tls rlm_eap: processing type tls rlm_eap_tls: Authenticate rlm_eap_tls: processing TLS rlm_eap_tls: Received EAP-TLS ACK message rlm_eap_tls: ack handshake is finished eaptls_verify returned 3 eaptls_process returned 3 rlm_eap: Freeing handler modcall[authenticate]: module "eap" returns ok for request 6 modcall: group authenticate returns ok for request 6 # # # выдача сессионного ключа клиенту # # Login OK: [test_user2/] (from client test_ap port 41 cli 0013d403ac86) Sending Access-Accept of id 0 to 192.168.1.250:3072 MS-MPPE-Recv-Key = 0xc5c40d559769601a78f9c<…..> MS-MPPE-Send-Key = 0xbb05a48f55a210d68e521b<…..> EAP-Message = 0x03060004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "test_user2" Finished request 6 Going to the next request Waking up in 6 seconds… =====================================================

6. Добавление FreeRadius в автостарт.

На этом настройка беспроводных клиентов с аутентификацией по цифровым сертификатам завершена. Осталось добавить запуск RADIUS-сервера в автостарт, если это не было сделано ранее (способ добавления описан во второй части цикла статей) и стартовать его.

Заключение.

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

В последней части речь пойдет о проблеме "первичности курицы и яйца"- использовании беспроводных клиентов в доменах Windows.

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

Для процесса аутентификации (подключения к беспроводной сети), нам необходим клиентский сертификат, лежащий в профиле. Для доступа к профилю, нам как минимум надо аутентифицироваться и на домен-контроллере. То есть, с одной стороны, для подключения к беспроводной сети нам нужно аутентифицироваться на домен-контроллере. А с другой — для аутентификации на домен-контроллере мы уже должны быть подключены к беспроводной сети. Замкнутый круг? :)

Второй момент. Выдали сотруднику клиентский сертификат на его ноутбук. Работает он в беспроводной сети, горя не знает. Потом сотрудник уволился. Как запретить ему доступ в сеть компании?

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

Навигация

• Часть первая — теоретически аспекты протокола WPA
• Часть вторая — WPA в режиме EAP-PEAP
• Часть третья — WPA в режиме EAP-TLS, создание сертификатов и настройка FreeRadius
• Часть четвертая — WPA в режиме EAP-TLS, настройка клиентов
• Часть пятая — EAP-TLS аутентификация компьютеров в доменных сетях Windows