Использование беспроводных сетей в доменах Windows
- 1. Создание сертификата компьютера
- 2. Создание сертификата пользователя
- 3. Установка сертификатов через MMC
- 4. Настройка беспроводной сети на клиенте.
- 5. Настройка точки доступа
- 6. Процесс подключения со стороны RADIUS-сервера
- 7. Проверка соответствия CN-поля сертификата имени компьютера
- Заключение
- Навигация
Предыдущая статья была посвящена настройке клиентской части 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. Создание сертификата компьютера.
Для начала создадим сертификат компьютера. Он создается абсолютно аналогично пользовательскому сертификату, по уже описанному в третьей части алгоритму.
Наш компьютер называется testcomp1. Создаем сертификат для него: #---------------------------------------------------- # ./sign_cert.sh client_cert testcomp1 #----------------------------------------------------
Называние поля 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-сервера
Для детального наблюдения за процессом, запускаем Radius в режиме отладки: #---------------------------------------------------- # radiusd -X #----------------------------------------------------
В данном случае нас интересует только процесс подключения с использованием сертификата компьютера, так как подключение с использованием пользовательского сертификата мы уже видели.
После того, как рабочая станция включится и операционная система полностью загрузится (до момента, когда появится ctrl+alt+del экран) нужно подождать еще секунд 20..40. Это время необходимо ОС для обнаружения беспроводной сети — только после этого произойдет попытка подключения к ней.
То есть, если попытаться нажать три заветных клавиши раньше и попробовать аутентифицироваться в домене, у вас, скорее всего, ничего не выйдет.
Процесс подключения компьютера к беспроводной сети с аутентификацией по компьютерному сертификату выглядит следующим образом: ===================================================== rad_recv: Access-Request packet from host 192.168.1.254:2055, id=0, 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: <<< TLS 1.0 Handshake [length 03c4], Certificate chain-depth=1, error=0 --> 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 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: 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-а
/etc/raddb/eap.conf
в секции 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 = %{User-Name} check_cert_cn = %{Stripped-User-Name:-%{User-Name}} #----------------------------------------------------
После этого необходимо перезапустить Radiusd.
В результате мы увидим следующую картину: ===================================================== rad_recv: Access-Request packet from host 192.168.1.254:2059, id=0, 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: <<< TLS 1.0 Handshake [length 03c4], Certificate chain-depth=1, error=0 --> 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 записывать имя компьютера вместе с префиксом — неплохой вариант. А можно просто отрезать префикс перед проверкой. Это делается следующим образом.
Открываем файл
/etc/raddb/hints
и записываем в его конец следующую конструкцию: #---------------------------------------------------- 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, id=0, 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, id=5, 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: <<< TLS 1.0 Handshake [length 03c4], Certificate chain-depth=1, error=0 --> 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 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 <………> # # и так далее # 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.
В следующей, последней статье цикла, будет рассказано, как можно отзывать сертификаты, то есть запрещать их владельцам подключаться к беспроводной сети.
Навигация
- Часть первая — теоретически аспекты протокола WPA
- Часть вторая — WPA в режиме EAP-PEAP
- Часть третья — WPA в режиме EAP-TLS, создание сертификатов и настройка FreeRadius
- Часть четвертая — WPA в режиме EAP-TLS, настройка клиентов
- Часть пятая — EAP-TLS аутентификация компьютеров в доменных сетях Windows
:no_upscale()/https://cdn.ixbt.site/ixbt-data/jp8xQvedXd/covers/IsI4GojhLyJbCJajXlgRnYy7GztO2iXhIvVlRRMc.jpg)
:no_upscale()/https://cdn.ixbt.site/ixbt-data/U80AxQ2TZv/covers/Qw35uV0mpLx0euXvtoR19bPN90CTVZJeCnlxVmax.jpg)
:no_upscale()/https://cdn.ixbt.site/ixbt-data/Tiky4gksYV/covers/7RINz0bJ5dhMAw8HGjBSZtIid2K44nRSBJIWm3Xx.jpg)