RADIUS

Материал из Xgu.ru

Перейти к: навигация, поиск
stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.


RADIUS (Remote Authentication Dial In User Service, служба удалённой аутентификации дозванивающихся пользователей) — сетевой протокол, предназначенный для обеспечения централизованной аутентификации, авторизации и учёта (Authentication, Authorization, and Accounting, AAA) пользователей, подключающихся к различным сетевым службам. Используется, например, при аутентификации пользователей WiFi, VPN, в прошлом, dialup-подключений, и других подобных случаях. Описан в стандартах RFC 2865 и RFC 2866.

Содержание

[править] Протокол RADIUS

[править] Свойства RADIUS

В соответствии со стандартом RADIUS, это:

  • Базирующийся на UDP протокол, который не использует прямых соединений
  • Использует модель безопасности hop-by-hop
  • Без состояний (stateless)
  • Поддерживает аутентификацию PAP и CHAP по PPP
  • Использует MD5 для скрытия паролей
  • Предоставляет более 50 пар атрибут/значение с возможностью создавать специфичные для производителя пары
  • Поддерживает модель AAA
  • Поддерживается большинством коммерческих устройств удалённого доступа

[править] Ограничения RADIUS

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

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

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

В-четвертых, RADIUS имеет не всегда достаточный уровень масштабируемости. На первой странице RFC замечание от IESG:

« Experience has shown that [RADIUS] can suffer degraded performance and lost data when used in large scale systems, in part because it does not include provisions for congestion control. Readers of this document may find it beneficial to track the progress of the IETF's AAA Working Group, which may develop a successor protocol that better addresses the scaling and congestion control issues. »

[править] Доступные RADIUS-серверы

Существует огромнейшее количество RADIUS-серверов, отличающихся своими возможностями и лицензией, по которой они распространяются.

Свободно распространяемые RADIUS-серверы:

Коммерческие RADIUS-серверы:

  • IAS - Internet Authentication Service - RADIUS-сервер от MS (Пример настройки RADIUS-сервера в Windows 2003)


Кроме того существует множество RADIUS-серверов, встроенных в биллинговые системы. Например, такие как:

Далее рассматривается FreeRADIUS. Это один из самых популярных и самых мощных RADIUS-серверов, существующих сегодня. Это хорошо масштабируемый, гибкий, настраиваемый и надёжный RADIUS-сервер.

[править] Инсталляция и настройка FreeRADIUS

[править] Инсталляция и настройка FreeRADIUS

Запуск RADIUS-сервера в режиме отладки:

# radiusd -sfxxyz -l stdout

В версии, поставляющейся в debian, файл называется freeradius (/usr/sbin/freeradius), а запуск в отладочном режиме, согласно официальной документации [1] осуществляется опцией -X, т.е.

# freeradius -X

Проверка конфигурационного файла FreeRadius-сервера:

# radiusd -c

[править] Конфигурационные файлы FreeRADIUS

FreeRADIUS использует несколько конфигурационных файлов. У каждого файла есть свой man, который описывает формат файла и примеры конфигураций.

radiusd.conf

Главный конфигурационный файл в котором указываются пути к другим конфигурационным файлам, log файлы, устанавливаются различные параметры контролируемые администратором.

dictionary

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

clients.conf

В файле содержится описание клиента. Синтаксис записей следующий:

client <hostname|ip-address|ip-network> { <attribute> = <value> }

Обязательные атрибуты secret и shortname, опционально можно задать атрибут nastype, который определяет тип клиента (все возможные типы описаны в man clients.conf)

Пример задания клиента:

client 192.168.0.0/16 {
       secret          = password
       shortname       = my-network
}

hints

Определяет префикс/суффикс для пользовательских имен - атрибут user-name. Используется для отсечения префикса/суффикса в ситуациях когда:

  1. Атрибут user-name перед авторизацией/тарификацией нужно избавить от имени домена и т.п., переданного клиентом, таким образом препроцессор трансформирует 'user@domain.com' в 'user'
  2. Необходимо одному и тому же пользователю предоставлять разные сервисы и/или использовать разные схемы авторизации/аутентификации. Тогда для пользователя 'user' при входе как 'user.ppp' или 'user.telnet' можем определить разные схемы авторизации и при входе как 'user.telnet' можем добавить проверку вхождения в группу telnet-пользователей.


huntgroups

Позволяет определить разные группы NAS, к сожалению критерий для включения в группу один - IP-адрес NAS (дополнительно можно указывать порт или диапазон портов). При разборе users файла конфигурации позволяет использовать различные схемы авторизации/аутентификации/учета исходя из значения атрибута Huntgroup-Name

Пример:

# CISCO group 
ciscogrp     NAS-IP-Address == 192.168.10.1
ciscogrp     NAS-IP-Address == 192.168.10.2
ciscogrp     NAS-IP-Address == 192.168.10.3

# Apache
apache       NAS-IP-Address == 192.168.11.4

# HP group
hpgroup      NAS-IP-Address == 192.168.12.1
hpgroup      NAS-IP-Address == 192.168.12.2

[2]

> I configure /etc/raddb/users as follows:
> test    Auth-Type := Local, User-Password == "testing"

That should be

 test    Auth-Type = Local, User-Password := "testing"

See the "man" page for the "users" file, and other posts to this list.

Alan DeKok. 

[править] Настройка атрибутов FreeRADIUS для динамического размещения порта коммутатора в VLAN'е по результатам аутентификации

Для динамического размещения порта коммутатора в VLANе по результатам аутентификации используются туннельные атрибуты (tunnel attributes):

  • [64] Tunnel-Type=VLAN (type 13)
  • [65] Tunnel-Medium-Type=802 (type 6)
  • [81] Tunnel-Private-Group-ID=VLANID (или VLAN name)

RADIUS-сервер включает туннельные атрибуты в Access-Accept сообщение.

Это основные атрибуты, которые нужны для динамического размещения порта в VLAN'е по результатам аутентификации. Другие атрибуты RADIUS относящиеся к использованию 802.1x перечислены в RFC 3580.

Значения этих атрибутов для конкретного пользователя указываются в файле users (/etc/freeradius/users):

nata    Cleartext-Password := "password"
        Tunnel-Type = 13,
        Tunnel-Medium-Type = 6,
        Tunnel-Private-Group-Id = 30

[править] Инсталляция и настройка dialupadmin

Программа dialupadmin предназначена для администрирования RADIUS-сервера через Web.


В данный момент dialupadmin работает только с PHP4 для PHP5 заработчик его еще не адаптировал

[править] Совместное использование ActiveDirectory и FreeRADIUS

В отличие от других LDAP-серверов, active directory не возвращает ничего в атрибуте userPassword. Из-за этого нельзя использовать Active Directory для выполнения аутентификации CHAP, MS-CHAP или EAP-MD5. Можно использовать только аутентификацию PAP. Для этого в секции "authenticate" нужно указать "ldap".

Для выполнения аутентификации MS-CHAP с помощью домена Active Directory, необходимо использовать NTLM-аутентификацию. Для этого потребуется проинсталлировать Samba.

Подробнее об этом в конфигурационном файле radiusd.conf и здесь RLM_LDAP.


Шаги по инсталляции и настройке:

  1. Проинсталлировать FreeRADIUS
  2. Проинсталлировать Samba-сервер
  3. Включить Samba-сервер в домен Active Directory
    • Убедиться, что wbinfo -u и wbinfo -g работает
  4. Изменить настройки FreeRADIUS для использования модуля NTLM-аутентификации

Auth_using_WinXP.pdf

Note: By default, Windows XP can take up to two minutes to prompt for 802.1x authentication credentials. This process can be expedited by modifying the registry using the following procedure:

  1. Click on Start, Select Run, and run regedit.exe
  2. Navigate to the key
     HKEY_LocalMachine/Software/Microsoft/EAPOL/Parameters/General/Global
  3. Right-click on Global and select New and DWORD Value
  4. Name the new value SupplicantMode
  5. Once created, Right click this new option and select Modify
  6. Change the Value data to 3
  7. Reboot the system for the new registry changes to take effect.


[3] I am assuming your domain is uing Internet Authentication Server (IAS) and 802.1x to authenticate the access by wireless user. In this case where 802.1x authentication is enabled, there is a registry key that controls how your wireless client authenticates to the backend IAS server. If you set the registry key HKEY_LOCAL_MACHINE\Software\Microsoft\EAPOL\Parameters\General\Global\AuthMo de to 1, what will happen is that the machine will authenticate to the domain before any user log on using machine credential (Machine Authentication) so that it will pull down any security setting the domain enforces, assuming the authentication succeeds. When the user logs on later, the user will need to do User Authentication as you normally do. By the way, if this reg key is not present, by default it is already to set to 1 and you already get the above behavior.


[4] [5] [6]

[7]


Заодно хочу поделиться мнением по разделу "Совместное использование             
ActiveDirectory и FreeRADIUS" статьи "RADIUS":                                  
по-моему не самый красивый подход пользовать NTLM-аутентификацию через вызов    
скриптом внешней утилиты ntlm_auth,                                             
после ввода Samba в AD домен (вариант из "FreeRADIUS. Tutorial for AD           
Integration").                                                                  
                                                                                
Более изящных решений вижу 3:                                                   
1. (nss_krb5 + pam_krb5 + rlm_pam) или (nss_krb5 + rlm_krb5) если уж хотите     
Kerberos, модуль rlm_krb5 есть не во                                            
всех freeRADIUS 1.6 готовых сборках - часто нужно собирать руками и кажется     
(не помню) не работает без nss_krb5                                             
(пока клиент ОС не видит пользователя своим, или патчить модуль) - по моему     
опыту прикрутки вообще поведение такой                                          
схемы странное krb5-клиент авторизируется, rlm_krb5 - нет. Плюс Kerberos        
требует синхронизации времени на клиенте                                        
и AD KDC.                                                                       
2. (nss_ldap + pam_ldap + rlm_pam) или просто и красиво (rlm_ldap), в любом     
случае нужен SSL (а то странная схема                                           
авторизации с голыми паролями в запросах), что в общем не проблема (правда      
AD не понимает tls_start, пользуемся                                            
только ldaps://)                                                                
3. (nss_winbind + pam_winbind + rlm_pam), что по-сути есть аналогом             
предложенного в "FreeRADIUS. Tutorial for                                       
AD Integration" способа но без скрипта и запуска ntlm_auth.                     
                                                                                
                                                                                
---                                                                             
Яцюта М.В. 

[править] cisco VPN-сервер и RADIUS

Данный пример описывает настройку маршрутизаторов cisco для организации pptp-доступа (да и других тунелирующих протоколов - pppoe, l2tp) из внешней сети (злых интернетов) в локальный сегмент сети. Основное назначение - доступ сотрудников к рабочему месту, доступ администратора к локальной сети предприятия из неожиданных мест. В качестве базы паролей используется файл users с паролями в plain-text (авторизация пользователей при этом происходит по ms-chap/ms-chap-v2). Пользователи получают при подключении ip-адрес, однозначно привязанный к их логину

Предполагаемая конфигурация полностью совместима с обычным windows-режимом создания VPN-соединения (т.е. может быть организована без дополнительного ПО). Доступ с linux-машин осуществляется с помощью пакета ppptp-linux (и команды pon).

Условные адреса:

192.168.1.1 - radius-сервер 192.168.2.2 - cisco 192.168.3.0/24 - сегмент для vpn-соедиенний

Конфигурация циски (только часть, относящаяся к конфигурированию VPN):

aaa new-model (включить aaa)
aaa authentication ppp OUR-VPN-NAME group radius (aaa для идентификации ppp пользователей группы OUR-VPN-NAME использовать
данные радиус-сервера)
aaa authorization network OUR-VPN-NAME group radius (aaa авторизовать пользователей из группы OUR-VPN-NAME на пользование
ресурсами сети (пересылку данных) исходя из того, что ответит радиус)
!
vpdn enable (ключить vpdn, то бишь включить VPN-сервер)
vpdn-group 1 (настройки первой группы, то бишь настройки по-умолчанию)
    accept-dialin (настройки приёма соединения)
        protocol pptp (используем протокол PPTP)
        virtual-template 1 (каждому пришедшему пользователю создаётся виртуальный интерфейс, который и устанавливает 

ppp-соединение с пользователем, эта опция указывает, исходя из какого шаблона создаётся этот виртуальный интерфейс)

!
interface Virtual-Template1 (собственно, декларация шаблона)
   ip unnumbered FastEthernet0/0 (пакеты выбрасываются в интерфейс без машрутизации)
   no peer default ip address (У пира нет адреса по-умолчанию (адрес говорит радиус))
   ppp encrypt mppe auto (если можно, то включить шифрование)
   ppp authentication ms-chap-v2 ms-chap OUR-VPN-NAME (для аутоидентификации PPP использовать протоколы ms-chap 

(обоих версий) и использовать OUR-VPN-NAME (см секцию aaa выше))

   ppp authorization OUR-VPN-NAME (аналогично для авторизации - см секцию aaa)
!
radius-server host 192.168.1.1 auth-port 1812 acct-port 1813 (адрес и порты RADIUS-сервера)
radius-server key myradiuspassword (пароль для связи с сервером).

Отладка процесса может быть включена командами debug ppp (см варианты подсказки по ?) и debug radius (аналогично). Выключение дебага no debug all. Просмотр лога - sh log, сброс лога - clear log.

Конфигурация сервера

После установки freeradius (положение и имена файлов конфигурации для версии в составе debian lenny).

/etc/freeradius/clients.conf, дописать:

client 192.168.2.2 {
        secret = myradiuspassword
        shortname = vpngate
}

/etc/freeradius/sites-enabled/default: закомментировать все строчки со словом 'unix' (отключает unix-авторизацию)

/etc/freeradius/users, добавить пользователей:

user1        Cleartext-Password := "pass1"
               Framed-IP-Address = 192.168.3.101

user2        Cleartext-Password := "pass2"
               Framed-IP-Address = 192.168.3.102

Перезапуск радиуса /etc/init.d/freeradius restart, запуск в отладочном режиме (после выполнения /etc/init.d/freeradius stop): freeradius -X

(не забудте прописать на маршрутизаторах сети (не циско!) маршрут для сегмента, в котором выдаются адреса (в нашем случае, 192.168.3.0/24).


[править] Настройка IAS (RADIUS-сервер в Windows Server 2003)

Основная страница: IAS

[править] Дополнительная информация

RFC, имеющие отношение к RADIUS:

Настройка FreeRADIUS:

Примеры использования FreeRADIUS:

[править] Книги

  • RADIUS By Jonathan Hassell, O'Reilly, October 2002, ISBN: 0-596-00322-6

[править] Материалы по контролю доступа в сеть на Xgu.ru

Источник — «http://xgu.ru:81/wiki/RADIUS»
На других языках