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

Викторина на iXBT.com! Компания GAINWARD дарит победителям HD4870 1024 МБ!

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

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

Навигация

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