Arial Georgia Tahoma Times New Roman Verdana

Сети и серверы » Аналитика и полезная информация

Защита беспроводных сетей, WPA: теория и практика (часть пятая)

Использование беспроводных сетей в доменах 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/<no User-Password attribute>] 
(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/<no User-Password attribute>] 
(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.

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