- Защита беспроводных сетей, WPA: теория и практика (часть пятая)
- Использование беспроводных сетей в доменах Windows
- 1. Использование беспроводных сетей в доменах Windows.
- 1. Создание сертификата компьютера.
- 2. Создание сертификата пользователя.
- 3. Установка сертификатов через MMC
- 4. Настройка беспроводной сети на клиенте.
- 5. Настройка точки доступа
- 6. Процесс подключения со стороны RADIUS-сервера
- 7. Проверка соответствия CN-поля сертификата имени компьютера
- Заключение
Защита беспроводных сетей, WPA: теория и практика (часть пятая)
Использование беспроводных сетей в доменах Windows
Предыдущая статья была посвящена настройке клиентской части WPA шифрования по протоколу EAP-TLS.
В предпоследней статье серии мы рассмотрим вопросы использования EAP-TLS в доменных сетях Windows.
Обращаю внимание, что для понимания нижеследующего материала, читателю необходимо ознакомиться со всеми предыдущими статьями этого цикла.
Как обычно, для дальнейшей работы нам потребуется все то, что упоминалось в предыдущей части. А именно:
- беспроводной клиент — в данном случае использовался ноутбук Toshiba Satellite M40-101 со встроенной беспроводной картой Intel PRO/Wireless 2200BG с установленной операционной системой Windows XP pro + SP2
- точка доступа с поддержкой WPA — ей являлась Gigabyte GN BR404W.
- RADIUS-сервер — был использован FreeRadius сервер версии 1.1.1, работающий под операционной системой Gentoo Linux.
- OpenSSL — был использован пакет openssl-0.9.7j.
1. Использование беспроводных сетей в доменах Windows.
И действительно, задумаемся — если клиентский сертификат, на основе которого клиент аутентифицируется на Radius-сервере, хранится в профиле пользователя, доступ к которому операционная система разрешает лишь после того, как клиент аутентифицировался в домене (то есть нажал заветные клавиши ctrl+alt+del и ввел свой логин/пароль), то, как нам быть в случае беспроводного подсоединения к сети? Ведь в этом случае на этапе «ctrl+alt+del», когда мы еще не аутентифицировались в домене, доступа к нашему профилю (в котором и хранится пользовательский сертификат) еще нет. Это не зависит от того, перемещаемый ли профиль (то есть, хранится на домен-контроллере) или локальный (хранится локально, на клиентской рабочей станции).
Другими словами, чтобы аутентифицироваться в домене, нам необходимо иметь доступ к домен-контроллеру. А для этого необходим доступ к сети. Но доступа к сети у нас еще нет, так как для подключения к сети нам необходим пользовательский сертификат. Добраться до которого можно, только после установления сетевого (беспроводного в нашем случае) соединения.
Мда… Что же делать?
На самом деле выход достаточно прост. В этом случае, необходимо использовать два сертификата.
Один из них — пользовательский, тот, что и обсуждался в предыдущих двух статьях. Он служит для установления беспроводного соединения уже после логина в домен.
«Но как же получить доступ к домену?» — спросите вы. Очень просто — для этого необходимо создать второй цифровой сертификат, для аккаунта компьютера. После окончания загрузки операционной системы Windows (как только процесс дойдет до ctrl+alt+del окошка), система пытается аутентифицироваться в беспроводной сети с использованием сертификата компьютера, если таковой существует.
Если аутентификация с помощью компьютерного сертификата завершится успешно, беспроводное соединение (и доступ к локальной сети) будет установлено. Понятно, что компьютерный сертификат должен быть предварительно установлен в системе, а профиль беспроводного соединения настроен (настройка беспроводного соединения подробно рассматривалась в предыдущей статье).
В результате при попытке пользователя аутентифицироваться в домене, процедура успешно завершится (разумеется, при условии, что такой пользователь в этом домене существует, и пользователь не ошибся с паролем).
После успешной аутентификации операционная система подгрузит пользовательский профиль, найдет там пользовательский сертификат. После этого беспроводное соединение будет установлено заново, уже с использованием найденного в профиле сертификата. Что показательно, при отсутствии такового в профиле (или неправильном, устаревшем и т.д. сертификате), беспроводное соединение не будет восстановлено. То есть пользователя пустит в домен, профиль загрузится (даже в том случае, если он перемещаемый), после чего беспроводная сеть перестанет работать. Соответственно в случае завершения работы пользователя и перемещаемого профиля, в этой ситуации (отсутствие беспроводной сети) профиль не сможет быть загружен обратно на домен-контроллер.
1. Создание сертификата компьютера.
Для начала создадим сертификат компьютера. Он создается абсолютно аналогично пользовательскому сертификату, по уже описанному в третьей части алгоритму.
Называние поля CN сертификата в общем случае может не совпадать с названием рабочей станции, на которой этот сертификат будет установлен. Но в настройках Radius-сервера можно ввести проверку на идентичность этого поля и имени машины. В случае несовпадения — отказать в соединении.
После ввода всех необходимых параметров и отработки скрипта мы получим на выходе файл testcomp1.p12 — его и установим в дальнейшем на нашу рабочую станцию.
2. Создание сертификата пользователя.
Аналогичным образом создаем сертификат пользователя, пусть это будет test_user2:#—————————————————- # ./sign_cert.sh client_cert test_user2 #—————————————————-
В результате получаем файл test_user2.p12
3. Установка сертификатов через MMC
Пара способов установки клиентских сертификатов уже была описана в четвертой части:
- через интерфейс управления IE
- установка «напрямую» (щелчком мыши)
К сожалению, так можно установить только клиентские сертификаты (и корневые). И те и другие будут храниться в профиле пользователя.
Для установки сертификата компьютера, который будет храниться в системном профиле (куда ОС будет иметь доступ даже без наличия сети), необходимо воспользоваться Microsoft Managment Console (MMC).
Для этого идем в «Пуск» -> «Выполнить».
В окне запуска программы пишем «mmc» и жмем клавишу «OK».
В открывшемся окне консоли необходимо добавить оснастку сертификатов.
Для этого идем в меню «Консоль». И выбираем пункт «Добавить или удалить оснастку».
На закладке «Изолированная оснастка» жмем кнопку «добавить».
В появившемся списке выбираем оснастку «Сертификаты» и жмем кнопку «Добавить».
Появляется меню, в котором необходимо выбрать, какими сертификатами мы будем управлять.
Пункт «моей учетной записи пользователя» позволит добавить оснастку управления пользовательскими сертификатами. Именно ими мы и управляли в предыдущей статье с помощью интерфейса IE.
Добавляем пользовательскую оснастку.
Теперь таким же образом добавляем оснастку для управления сертификатами учетной записи компьютера:
Сертификаты компьютера невозможно добавить напрямую или через IE. Они добавляются только через MMC-консоль.
При добавлении оснастки управления сертификатами компьютера, появляется меню, где можно указать, каким именно компьютером мы хотим в данный момент управлять — выбираем «локальным компьютером» (в принципе, администратор домена может удаленно управлять оснастками и на удаленных машинах).
В результате мы добавили две оснастки — для управления сертификатами пользователя и компьютера.
Теперь подробнее рассмотрим, что эти оснастки из себя представляют.
Раскрываем дерево сертификатов текущего пользователя. Идем вниз по дереву: «Личные» -> «Сертификаты».
Если в предыдущей статье мы уже добавляли пользовательский сертификат test_user2, то мы увидим его здесь. Если еще не добавляли, то его следует добавить аналогично нижеописанному для сертификата компьютера (правой кнопкой на «сертификаты» -> «Все задачи» -> «Импорт»).
Аналогично с корневым сертификатом центра CA — в предыдущей статье мы уже добавляли его, поэтому он уже есть в списке доверенных сертификатов. А если сертификат еще не был добавлен, действуем по аналогии с добавлением корневого CA для машинного аккаунта ( это будет описано ниже: правой кнопкой на «сертификаты» -> «Все задачи» -> «Импорт»).
Теперь переходим на оснастку управления сертификатами для локального компьютера:
Раскрываем «Доверенные корневые центры сертификации». В появившемся списке у нас отсутствует сертификат нашего CA-центра «tmp_org root CA».
Необходимо его добавить:
Правой кнопкой мыши жмем на «Сертификаты». В появившемся меню выбираем верхний пункт — «Все задачи». Далее жмем на «Импорт».
Появляется уже знакомый нам «Мастер импорта». Жмем «Далее».
Выбираем .crt файл, содержащий корневой (самоподписанный) сертификат нашего сертификационного центра, и жмем кнопку «Далее».
Мастер предлагает выбрать, куда помещать сертификат — выбираем «Поместить в доверенные корневые центры сертификации». И жмем кнопку «Далее».
Мастер завершает свою работу — жмем «Готово».
Выскакивающее окошко сообщает, что сертификат успешно установлен.
Теперь корневой сертификат нашего центра CA появился в списке доверенных для компьютерного аккаунта.
Теперь можно установить и сам сертификат компьютера. Это делается аналогичным образом:
Щелкаем на пункт «Личные» в оснастке сертификатов локального компьютера, выбираем «Все задачи» и жмем на «Импорт».
Выбираем сертификат компьютера (testcomp1.p12) и жмем «Далее».
Система сама разберется, куда помещать сертификат. Но можно и указать, что помещать сертификат необходимо в личное хранилище.
После нажатия на «Далее» система сообщает об успешной установке компьютерного сертификата.
После чего он появится в списке.
В итоге мы установили корневой, пользовательский и компьютерный сертификаты, как для учетной записи компьютера, так и для пользователя.
Осталось лишь настроить профиль беспроводной сети и точку доступа, после чего можно проверять работоспособность полученной системы.
4. Настройка беспроводной сети на клиенте.
Конфигурирование профиля беспроводной сети клиента ничем не отличается от того алгоритма, что был рассмотрен в четвертой части. Единственное, на что стоит обратить внимание, так это на активированную опцию «проверять подлинность как у компьютера»…
В закладке «Проверка подлинности». Этот пункт как раз и отвечает за возможность аутентификации посредством сертификата компьютера (в нашем случае) при старте системы, еще до загрузки профиля пользователя.
5. Настройка точки доступа
Конфигурация точки доступа полностью аналогична описанной в четвертой части серии.
6. Процесс подключения со стороны RADIUS-сервера
В данном случае нас интересует только процесс подключения с использованием сертификата компьютера, так как подключение с использованием пользовательского сертификата мы уже видели.
После того, как рабочая станция включится и операционная система полностью загрузится (до момента, когда появится ctrl+alt+del экран) нужно подождать еще секунд 20..40. Это время необходимо ОС для обнаружения беспроводной сети — только после этого произойдет попытка подключения к ней.
То есть, если попытаться нажать три заветных клавиши раньше и попробовать аутентифицироваться в домене, у вас, скорее всего, ничего не выйдет.
Процесс подключения компьютера к беспроводной сети с аутентификацией по компьютерному сертификату выглядит следующим образом: ===================================================== rad_recv: Access-Request packet from host 192.168.1.254:2055, length=190 Message-Authenticator = 0x8d4d4ec2b0bac44e42b068c5cd7f4b78 Service-Type = Framed-User User-Name = «host/testcomp1» Framed-MTU = 1488 Called-Station-Id = «00-20-ED-07-7F-0B:GIGABYTE» Calling-Station-Id = «00-0E-35-EE-67-0F» NAS-Port-Type = Wireless-802.11 Connect-Info = «CONNECT 54Mbps 802.11g» EAP-Message = 0x0200001301686f73742f74657374636f6d7031 NAS-IP-Address = 192.168.1.254 NAS-Port = 1 NAS-Port-Id = «STA port # 1» # # # получили запрос от клиента testcomp1 # # # хорошо видно, что полученное Radius-ом имя компьютера имеет префикс «host/» # # Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 modcall[authorize]: module «preprocess» returns ok for request 0 modcall[authorize]: module «chap» returns noop for request 0 modcall[authorize]: module «mschap» returns noop for request 0 rlm_realm: No ‘@’ in User-Name = «host/testcomp1», looking up realm NULL rlm_realm: No such realm «NULL» modcall[authorize]: module «suffix» returns noop for request 0 rlm_eap: EAP packet type response id 0 length 19 rlm_eap: No EAP Start, assuming it’s an on-going EAP conversation modcall[authorize]: module «eap» returns updated for request 0 users: Matched entry DEFAULT at line 152 users: Matched entry DEFAULT at line 171 modcall[authorize]: module «files» returns ok for request 0 modcall: leaving group authorize (returns updated) for request 0 rad_check_password: Found Auth-Type EAP auth: type «EAP» Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Requiring client certificate rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 rad_recv: Access-Request packet from host 192.168.1.254:2055, id=5, length=251 Message-Authenticator = 0x5308eee7 Service-Type = Framed-User User-Name = «host/testcomp1» Framed-MTU = 1488 State = 0x5b7c4a6b2a68b1bf1ecb976fd6cad127 Called-Station-Id = «00-20-ED-07-7F-0B:GIGABYTE» Calling-Station-Id = «00-0E-35-EE-67-0F» NAS-Port-Type = Wireless-802.11 Connect-Info = «CONNECT 54Mbps 802.11g» EAP-Message = 0x0205003e0d00213 NAS-IP-Address = 192.168.1.254 NAS-Port = 1 NAS-Port-Id = «STA port # 1» Processing the authorize section of radiusd.conf modcall: entering group authorize for request 5 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 = «host/testcomp1», 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 62 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 users: Matched entry DEFAULT at line 171 modcall[authorize]: module «files» returns ok for request 5 modcall: leaving 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: User-Name = host/testcomp1 —> 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 chain-depth=0, error=0 —> User-Name = host/testcomp1 —> BUF-Name = testcomp1 —> subject = /C=RU/ST=Euro/L=Moscow/O=TempOrg/OU=network IT/ CN=testcomp1/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 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: leaving group authenticate (returns handled) for request 5 Sending Access-Challenge of id 5 to 192.168.1.254 port 2055 Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Service-Type = Framed-User EAP-Message = 0x010600350d80000 Message-Authenticator = 0x00000000000000000000000000000000 State = 0x4d473451f4579956cf6bb6655e32b2f3 Finished request 5 Going to the next request Waking up in 5 seconds… rad_recv: Access-Request packet from host 192.168.1.254:2055, id=6, length=195 Message-Authenticator = 0x95849cb3f4072b8d73144e4348914c04 Service-Type = Framed-User User-Name = «host/testcomp1» Framed-MTU = 1488 State = 0x4d473451f4579956cf6bb6655e32b2f3 Called-Station-Id = «00-20-ED-07-7F-0B:GIGABYTE» Calling-Station-Id = «00-0E-35-EE-67-0F» NAS-Port-Type = Wireless-802.11 Connect-Info = «CONNECT 54Mbps 802.11g» EAP-Message = 0x020600060d00 NAS-IP-Address = 192.168.1.254 NAS-Port = 1 NAS-Port-Id = «STA port # 1» Processing the authorize section of radiusd.conf modcall: entering group authorize for request 6 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 = «host/testcomp1», 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 users: Matched entry DEFAULT at line 171 modcall[authorize]: module «files» returns ok for request 6 modcall: leaving 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: leaving group authenticate (returns ok) for request 6 # # # выдача сессионного ключа клиенту # # Login OK: [host/testcomp1/] (from client test_ap port 1 cli 00-0E-35-EE-67-0F) Sending Access-Accept of id 6 to 192.168.1.254 port 2055 Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Service-Type = Framed-User MS-MPPE-Recv-Key = 0xd165d3667774 MS-MPPE-Send-Key = 0xb39b1f53821a EAP-Message = 0x03060004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = «host/testcomp1» Finished request 6 Going to the next request Waking up in 5 seconds… — Walking the entire request list — Cleaning up request 0 ID 0 with timestamp 44f5be80 Waking up in 1 seconds… — Walking the entire request list — Nothing to do. Sleeping until we see a request. =====================================================
Хорошо видно, что процесс практически не отличается от аналогичного, где для аутентификации используется клиентский сертификат.
7. Проверка соответствия CN-поля сертификата имени компьютера
Теперь давайте включим проверку соответствия поля CN сертификата и имени компьютера.
CN поле сертификата соответствует «testcomp1». Компьютер тоже называется «testcomp1».
Для активации такой проверки необходимо в конфигурационном файле Radius-а
в секции tls раздела eap
добавить следующую переменную: #—————————————————- # If check_cert_cn is set, the value will # be xlat’ed and checked against the CN # in the client certificate. If the values # do not match, the certificate verification # will fail rejecting the user. # #check_cert_cn = %
После этого необходимо перезапустить Radiusd.
В результате мы увидим следующую картину: ===================================================== rad_recv: Access-Request packet from host 192.168.1.254:2059, length=190 Message-Authenticator = 0xdcea34538eb91ce57b7b98f0fa9edabf Service-Type = Framed-User User-Name = «host/testcomp1» Framed-MTU = 1488 Called-Station-Id = «00-20-ED-07-7F-0B:GIGABYTE» Calling-Station-Id = «00-0E-35-EE-67-0F» NAS-Port-Type = Wireless-802.11 Connect-Info = «CONNECT 54Mbps 802.11g» EAP-Message = 0x0200001301686f73742f74657374636f6d7031 NAS-IP-Address = 192.168.1.254 NAS-Port = 1 NAS-Port-Id = «STA port # 1» # # получили запрос от клиента testcomp1 # # переданное имя пользователя содержит префикс «host/» # rad_recv: Access-Request packet from host 192.168.1.254:2059, id=5, length=251 Message-Authenticator = 0x2f9d19ed28366 Service-Type = Framed-User User-Name = «host/testcomp1» Framed-MTU = 1488 State = 0x0254404d140dacbc485b2ff8c3dbe2ff Called-Station-Id = «00-20-ED-07-7F-0B:GIGABYTE» Calling-Station-Id = «00-0E-35-EE-67-0F» NAS-Port-Type = Wireless-802.11 Connect-Info = «CONNECT 54Mbps 802.11g» EAP-Message = 0x0205003e0 NAS-IP-Address = 192.168.1.254 NAS-Port = 1 NAS-Port-Id = «STA port # 1» 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 = «host/testcomp1», 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 62 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 users: Matched entry DEFAULT at line 171 modcall[authorize]: module «files» returns ok for request 5 modcall: leaving 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 rlm_eap_tls: User-Name = host/testcomp1 —> 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: ‘host/testcomp1’ # # проверяем соответствие CN-поля сертификата # и имени пользователя (компьютера) # rlm_eap_tls: checking certificate CN (testcomp1) with xlat’ed value (host/testcomp1) rlm_eap_tls: Certificate CN (testcomp1) does not match specified value (host/testcomp1)! # # CN-поле сертификата (testcomp1) не совпадает # с именем пользователя (host/testcomp1), полученными Radius-ом # chain-depth=0, error=0 —> User-Name = host/testcomp1 —> BUF-Name = testcomp1 —> subject = /C=RU/ST=Euro/L=Moscow/O=TempOrg/OU=network IT/ CN=testcomp1/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:0 rlm_eap_tls: >>> TLS 1.0 Alert [length 0002], fatal certificate_unknown TLS Alert write:fatal:certificate unknown TLS_accept:error in SSLv3 read client certificate B 5612:error:140890B2:SSL routines:SSL3_GET_CLIENT_CERTIFICATE: no certificate returned:s3_srvr.c:2015: rlm_eap_tls: SSL_read failed in a system call (-1), TLS session fails. # # Radius отказал в подключении # In SSL Handshake Phase In SSL Accept mode eaptls_process returned 13 modcall[authenticate]: module «eap» returns handled for request 5 modcall: leaving group authenticate (returns handled) for request 5 =====================================================
Подсоединиться к беспроводной сети не удалось… Почему? Ведь имя компьютера было testcomp1, CN-поле сертификата содержало то же самое значение… в чем дело?
Так то оно так, но еще в самом начале было отмечено, что Windows передает имя компьютера вместе с префиксом «host/». Разумеется, полученное имя не совпадает с тем, что записано в поле CN сертификата…
Что же делать? Можно в поле CN записывать имя компьютера вместе с префиксом — неплохой вариант. А можно просто отрезать префикс перед проверкой. Это делается следующим образом.
и записываем в его конец следующую конструкцию: #—————————————————- DEFAULT Prefix == «host/» Hint = «EAP», Service-Type = Framed-User, Framed-Protocol = EAP #—————————————————-
Это означает, что если полученное radius-ом имя не подпадет под какие-то другие, явно указанные, фильтры, и будет иметь префикс «host/», то нужно не учитывать префикс в дальнейших проверках и перейти к EAP аутентификации.
Перезапускаем radiusd еще раз и видим: ===================================================== rad_recv: Access-Request packet from host 192.168.1.254:2056, length=190 Message-Authenticator = 0xaebdeb7e49e35391e8b2869eb6c50faf Service-Type = Framed-User User-Name = «host/testcomp1» Framed-MTU = 1488 Called-Station-Id = «00-20-ED-07-7F-0B:GIGABYTE» Calling-Station-Id = «00-0E-35-EE-67-0F» NAS-Port-Type = Wireless-802.11 Connect-Info = «CONNECT 54Mbps 802.11g» EAP-Message = 0x0200001301686f73742f74657374636f6d7031 NAS-IP-Address = 192.168.1.254 NAS-Port = 1 NAS-Port-Id = «STA port # 1» # # # получили запрос от клиента testcomp1 # # переданное имя пользователя содержит префикс «host/» # Processing the authorize section of radiusd.conf modcall: entering group authorize for request 0 hints: Matched DEFAULT at 79 modcall[authorize]: module «preprocess» returns ok for request 0 modcall[authorize]: module «chap» returns noop for request 0 modcall[authorize]: module «mschap» returns noop for request 0 rlm_realm: No ‘@’ in User-Name = «host/testcomp1», looking up realm NULL rlm_realm: No such realm «NULL» modcall[authorize]: module «suffix» returns noop for request 0 rlm_eap: EAP packet type response id 0 length 19 rlm_eap: No EAP Start, assuming it’s an on-going EAP conversation modcall[authorize]: module «eap» returns updated for request 0 users: Matched entry DEFAULT at line 152 users: Matched entry DEFAULT at line 171 modcall[authorize]: module «files» returns ok for request 0 modcall: leaving group authorize (returns updated) for request 0 rad_check_password: Found Auth-Type EAP auth: type «EAP» Processing the authenticate section of radiusd.conf modcall: entering group authenticate for request 0 rlm_eap: EAP Identity rlm_eap: processing type tls rlm_eap_tls: Requiring client certificate rlm_eap_tls: Initiate rlm_eap_tls: Start returned 1 modcall[authenticate]: module «eap» returns handled for request 0 modcall: leaving group authenticate (returns handled) for request 0 rad_recv: Access-Request packet from host 192.168.1.254:2056, length=251 Message-Authenticator = 0xdddeb03bf63ce74ab4308f2823631b5a Service-Type = Framed-User User-Name = «host/testcomp1» Framed-MTU = 1488 State = 0x686f28574dd95d3fa8c76bb3f42cd349 Called-Station-Id = «00-20-ED-07-7F-0B:GIGABYTE» Calling-Station-Id = «00-0E-35-EE-67-0F» NAS-Port-Type = Wireless-802.11 Connect-Info = «CONNECT 54Mbps 802.11g» EAP-Message = 0x0205003e0d00b NAS-IP-Address = 192.168.1.254 NAS-Port = 1 NAS-Port-Id = «STA port # 1» Processing the authorize section of radiusd.conf modcall: entering group authorize for request 5 hints: Matched DEFAULT at 79 # # в файле /etc/raddb/hints имя пользователя подходит под заданный нами DEFAULT Prefix # 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 = «host/testcomp1», 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 62 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 users: Matched entry DEFAULT at line 171 modcall[authorize]: module «files» returns ok for request 5 modcall: leaving 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 rlm_eap_tls: User-Name = host/testcomp1 —> 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: ‘testcomp1’ rlm_eap_tls: checking certificate CN (testcomp1) with xlat’ed value (testcomp1) chain-depth=0, error=0 —> User-Name = host/testcomp1 —> BUF-Name = testcomp1 # # проверка соответствия CN-поля сертификата и имени пользователя # (компьютера) успешно произведена # от имени пользователя уже отрезали префикс «host/» # —> subject = /C=RU/ST=Euro/L=Moscow/O=TempOrg/OU=network IT/ CN=testcomp1/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 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 # # и так далее # Login OK: [host/testcomp1/] (from client test_ap port 1 cli 00-0E-35-EE-67-0F) Sending Access-Accept of id 6 to 192.168.1.254 port 2056 Framed-IP-Address = 255.255.255.254 Framed-MTU = 576 Service-Type = Framed-User MS-MPPE-Recv-Key = 0xb5c7b3f895690 MS-MPPE-Send-Key = 0x0895cb7f87d821 EAP-Message = 0x03060004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = «host/testcomp1» Finished request 6 Going to the next request Waking up in 6 seconds… # # до успешной выдачи сессионного ключа # =====================================================
Вуаля! Проверка прошла успешно.
Если имя компьютера не совпадет с содержимым CN-поля машинного сертификата, в доступе к беспроводной сети такому компьютеру будет также отказано (по причине несовпадения имени и CN-поля).
Заключение
В этой статье мы научились создавать и использовать сертификаты для учетной записи компьютера. Поэтому беспроводные сети можно использовать и для работы доменных пользователей в сетях Windows.
В следующей, последней статье цикла, будет рассказано, как можно отзывать сертификаты, то есть запрещать их владельцам подключаться к беспроводной сети.
Источник