radius сервер что такое
Как работает RADIUS?
Параметры загрузки
Содержание
Введение
Протокол службы дистанционной аутентификации пользователей по коммутируемым линиям (RADIUS) был разработан корпорацией Livingston Enterprises в качестве протокола аутентификации и учета для сервера доступа. Спецификация RADIUS RFC 2865 
заменяет RFC 2138. Стандарт учета RADIUS RFC 2866 заменяет RFC 2139.
Предварительные условия
Требования
Для данного документа отсутствуют предварительные условия.
Используемые компоненты
Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.
Условные обозначения
Подробные сведения об условных обозначениях см. в документе Условное обозначение технических терминов Cisco.
Общие сведения
Соединение между сервером доступа к сети (NAS) и сервером RADIUS основано на протоколе UDP (User Datagram Protocol). В общем виде протокол RADIUS представляет собой службу без установления соединения. Вопросы, связанные с доступностью сервера, повторной передачей и временем ожидания, решаются устройствами с поддержкой RADIUS лучше, чем протоколом передачи.
RADIUS – протокол типа «клиент-сервер». Клиент RADIUS обычно представляет собой сервер NAS, а сервер RADIUS – процесс-демон на компьютере с ОС Windows NT или UNIX. Клиент передает сведения о пользователе указанным серверам RADIUS и выполняет различные действия в зависимости от возвращенного ответа. Серверы RADIUS принимают запросы подключения пользователей, выполняют аутентификацию пользователей и возвращают данные о конфигурации, необходимые для обслуживания пользователя клиентом. Сервер RADIUS может действовать как промежуточный для других серверов RADIUS или серверов аутентификации другого типа.
На этом рисунке показано взаимодействие удаленного пользователя с клиентом или сервером RADIUS.
Пользователь инициализирует аутентификацию PPP с сервером NAS.
NAS запрашивает имя пользователя и пароль (для протокола аутентификации пароля [PAP]) или хэш-строку (для протокола аутентификации с косвенным согласованием [CHAP]).
Пользователь отправляет ответ.
Клиент RADIUS посылает серверу RADIUS имя пользователя и зашифрованный пароль.
Сервер RADIUS выдает один из ответов: Accept (принято), Reject (отклонено) или Challenge (требуется вторичная аутентификация).
Клиент RADIUS выбирает действие в зависимости от служб и их параметров, объединенных с сообщениями Accept или Reject.
Аутентификация и авторизация
Сервер RADIUS может поддерживать множество методов аутентификации пользователя. Для проверки подлинности имени пользователя и пароля, предоставляемых серверу, могут использоваться протоколы PPP, PAP, CHAP, вход UNIX и другие механизмы аутентификации.
Обычно процесс входа пользователя состоит из передачи запроса (Access-Request) с сервера NAS на сервер RADIUS и получения соответствующего ответа с сервера (Access-Accept или Access-Reject). Пакет Access-Request содержит имя пользователя, зашифрованный пароль, IP-адрес сервера NAS и порт. Первоначально серверы RADIUS размещались на UDP-порту 1645, что создавало конфликт со службой datametrics. По причине этого конфликта документ RFC 2865 официально закрепил за протоколом RADIUS порт 1812. Большинство устройств и приложений Cisco поддерживают оба набора номеров портов. Формат запроса также содержит информацию о типе сеанса, который собирается инициировать пользователь. Например, если запрос представлен в символьном режиме, то вывод должен выглядеть как Service-Type = Exec-User, но если запрос представлен в пакетном режиме PPP, то вывод выглядит как Service Type = Framed User и Framed Type = PPP.
По получении от NAS запроса Acceess-Request сервер RADIUS производит поиск указанного имени пользователя в базе данных. Если имя пользователя не найдено в базе данных, это значит, что загружен профиль по умолчанию, или сервер RADIUS немедленно отправляет сообщение Access-Reject. Данное сообщение Access-Reject может сопровождаться текстовым сообщением, в котором указывается причина отказа в доступе.
В RADIUS аутентификация и авторизация объединены. Если имя пользователя найдено и пароль правильный, то сервер RADIUS возвращает подтверждение доступа, включая список пар «атрибут-значение», которые описывают параметры, необходимые для данного сеанса. В числе типичных параметров: тип службы (сеанс интерпретатора или кадрирование), тип протокола, назначенный пользователю IP-адрес (статический или динамический), применяемый список доступа или статический маршрут для установки в таблицу маршрутизации NAS. Данные конфигурации на сервере RADIUS определяют компоненты, которые будут установлены на сервер NAS. Рисунок ниже показывает аутентификацию RADIUS и последовательность авторизации.
Функции учета протокола RADIUS могут использоваться независимо от функций аутентификации или авторизации RADIUS. Учетная функция RADIUS позволяет посылать данные в начале и в конце сеансов, отображая ресурсы (такие как время, пакеты, байты и т. п.), использованные во время сеанса. Для удовлетворения потребностей безопасности и биллинга поставщик услуг Интернета (ISP) может использовать программное обеспечение RADIUS по управлению доступом и учету. В большинстве устройств Cisco в качестве порта учета RADIUS используется порт 1646, но также может быть выбран номер 1813 (по причине изменения номеров портов, закрепленного документом RFC 2139 ).
Подлинность транзакций между клиентом и сервером RADIUS подтверждается с помощью общего секретного ключа, никогда не пересылаемого по сети. Кроме того, обмен паролями пользователей между клиентом и сервером RADIUS выполняется в зашифрованном виде для исключения вероятности перехвата пароля пользователя злоумышленниками через прослушивание незащищенной сети.
RADIUS
Материал из Xgu.ru
 |
| Данная страница находится в разработке. Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной. |
Если вы считаете, что её стоило бы доработать как можно быстрее, пожалуйста, скажите об этом.
RADIUS (Remote Authentication Dial In User Service, служба удалённой аутентификации дозванивающихся пользователей) — сетевой протокол, предназначенный для обеспечения централизованной аутентификации, авторизации и учёта (Authentication, Authorization, and Accounting, AAA) пользователей, подключающихся к различным сетевым службам. Используется, например, при аутентификации пользователей WiFi, VPN, в прошлом, dialup-подключений, и других подобных случаях. Описан в стандартах RFC 2865 и RFC 2866.
Содержание
[править] Протокол RADIUS
[править] Свойства RADIUS
В соответствии со стандартом 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-серверов, встроенных в биллинговые системы. Например, такие как:
Далее рассматривается FreeRADIUS. Это один из самых популярных и самых мощных RADIUS-серверов, существующих сегодня. Это хорошо масштабируемый, гибкий, настраиваемый и надёжный RADIUS-сервер.
[править] Инсталляция и настройка FreeRADIUS
[править] Инсталляция и настройка FreeRADIUS
Запуск RADIUS-сервера в режиме отладки:
Проверка конфигурационного файла FreeRadius-сервера:
[править] Конфигурационные файлы FreeRADIUS
FreeRADIUS использует несколько конфигурационных файлов. У каждого файла есть свой man, который описывает формат файла и примеры конфигураций.
Главный конфигурационный файл в котором указываются пути к другим конфигурационным файлам, log файлы, устанавливаются различные параметры контролируемые администратором.
Это файл обычно статический и его не надо изменять. Он определяет все возможные атрибуты RADIUS использующиеся в других конфигурационных файлах.
В файле содержится описание клиента. Синтаксис записей следующий:
Обязательные атрибуты secret и shortname, опционально можно задать атрибут nastype, который определяет тип клиента (все возможные типы описаны в man clients.conf)
Пример задания клиента:
[править] Настройка атрибутов FreeRADIUS для динамического размещения порта коммутатора в VLAN’е по результатам аутентификации
Для динамического размещения порта коммутатора в VLANе по результатам аутентификации используются туннельные атрибуты (tunnel attributes):
RADIUS-сервер включает туннельные атрибуты в Access-Accept сообщение.
Это основные атрибуты, которые нужны для динамического размещения порта в VLAN’е по результатам аутентификации. Другие атрибуты RADIUS относящиеся к использованию 802.1x перечислены в RFC 3580.
Значения этих атрибутов для конкретного пользователя указываются в файле users (/etc/freeradius/users):
[править] Инсталляция и настройка 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.
Шаги по инсталляции и настройке:
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:
[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.
[править] cisco VPN-сервер и RADIUS
Предполагаемая конфигурация полностью совместима с обычным windows-режимом создания VPN-соединения (т.е. может быть организована без дополнительного ПО). Доступ с linux-машин осуществляется с помощью пакета ppptp-linux (и команды pon).
Конфигурация циски (только часть, относящаяся к конфигурированию VPN):
ppp-соединение с пользователем, эта опция указывает, исходя из какого шаблона создаётся этот виртуальный интерфейс)
(обоих версий) и использовать OUR-VPN-NAME (см секцию aaa выше))
После установки freeradius (положение и имена файлов конфигурации для версии в составе debian lenny).
/etc/freeradius/sites-enabled/default: закомментировать все строчки со словом ‘unix’ (отключает unix-авторизацию)
/etc/freeradius/users, добавить пользователей:
(не забудте прописать на маршрутизаторах сети (не циско!) маршрут для сегмента, в котором выдаются адреса (в нашем случае, 192.168.3.0/24).
RADIUS — немного о Mikrotik, NPS и не только
Changelog
Определение, назначение, общие сведения
Позволяет повысить безопасность сети и централизованно управлять доступами.
Сервер RADIUS может иметь свою базу данных с учетными данными (например файлы или mysql) или работать в паре с другим сервером, например Active Directory.
Кроме AAA позволяет передать некоторые дополнительные данные (настройки) клиенту прошедшему аутентификацию, в том числе vendor-specific attributes (VSA). У Mikrotik такие тоже есть, позже пройдемся по самым интересным.
Существуют много популярных приложений радиус сервера, самый популярные: freeRADIUS и Служба NPS (Network Policy Server) Windows Server. Более подробно мы рассмотрим второй вариант.
Компоненты кейса
RADIUS сервер (он же радиус сервер, он же сервер аутентификации).
Настройка
Установку роли описывать не буду, существует 100500 статей в картинках, например: тыц
Добавление радиус клиента на радиус-сервере. Нам нужно заполнить «понятное имя», IP адрес и придумать пароль (а.к.а. «секрет»), который понадиобится при настройке аутентификатора (mikrotik в нашем случае)
Политики запросов на подключение и Стетевые политики очень похожи при настройке, и нужно понимать разницу между ними. Первые нужны для того что бы при определенных условиях определить сервер на котором будет проходить проверка аутентификации клиента (к примеру локально или на другом удаленном радиус сервере) а так же для некоторых манипуляций с атрибутами. Вторые же позволяют определить набор условий по которым возможно обозначить разрешить или отклонить запроос клиента на подключение.
Политики имеют порядок и обрабатываются по нему одна за другой. Если подключение не соответствует условиям политики, то проверяется следущая и так далее. К примеру, это поможет разделить правила обработки для проводных\беспроводных и впн клиентов.
Добавление политики запросов на подключение
Добавление сетевой политики
Некоторые типовые кейсы применения радиус сервера :
централизованная аутентификация на устройствах поддерживающих aaa
аутентификация для vpn (pptp\l2tp)
аутентификация в wifi
Итак подробнее, + некоторые плюшки. Для всех наших пунктов нам нужно настроить радиус клиента в mikrotik
Теперь можно начинать настраивать интересные вещи.
1. настроим вход на микротик
Стоит уделить внимание параметру default-group он означает группу по умолчанию, в которая применится к пользователю.
Теперь настроим NPS:
А вот так будет выглядеть настройка необходимого нам атрибута, из которого микротик определит в какую группу поместить подключенного пользователя.
Сразу попробуем авторизоваться и видим что попали в нужную группу read
В методах проверки подлинности указываем :
Политика mikrotik-admin-network будет отличаться тем что в условиях выберем группу admins-network а значение отрибута MIKROTIK_GROUP зададим как full Результат ожидаемый, мы залогинились в микротик под полными правами:
Перейдем к впн, и к стразу более интересному сценарию.
В настройки правил форейвола для ограничения доступа подсетей я пожалуй не буду углубляться, подразумевается что вы понимаете как из одной подсети запретить доступ к ресурсу и как разрешить. (с) предпологается, что вы немного сетевик. Касательно примера подсети 10.10.21.0/24 необходимо разрешить форвард в подсети серверов и management а подсети 10.10.22.0/24 необходимо разрешить только доступк корпоративным сервисам, но не к сетям управления.
Знакомым нам образом добавим атрибут указывающий какой профиль микротика использовать.
Методы проверки подлинности используем как и в прошлый раз. В настройках Сервера VPN рекомендуется указать точно такой же тип.
Настроим тестовое поключение и увидим что получили IP из пула для сетевых администраторов.
Теперь настроим политику для обычных пользователей:
Wifi и Dot1x
Прежде чем перети к самому вкусному, хочется сделать выбор как мы будем проходить авторизацию, можно выбрать по логину и паролю, компьютеру, использовать mac адрес как логин и пароль.. и наконец пойти самым сложным интересным путем, использовать сертификаты. В качестве предварительной подготовки нам необходимо:
настроить службу центра сертификации Windows тыц, актуально и для следующего пункта
настроить GPO для распространения CA сертификата домена тыц
GPO автоматического получения сертификата компьютера docs.microsoft
GPO включение службы dot1X (проводная автонастройка) и создать Политики проводных сетей (802.3) для выбора способа проверки подлинности тыц
GPO Автоматическое подключение к Wifi до логина пользователя тыц
Данные пункты не маленькие что бы включать их в эту статью, но достаточно освещены в статьях интернета.
Настройку WiFi каждый настраивает как ему удобно. Я к примеру, предпочитаю CapsMan, даже если это будет единственная AP в сети. В любом случае нас интересует только Security Profile/Security Cfg.
А в методах проверки подлинности следующее.
Какие радиус атрибуты могут быть нам полезны:
устанавливать лимиты по обьему или/и скорости трафика
и многие другие параметры из вики, либо их комбинации с условиями сетевой политики, смотря сколько у вас фантазии 🙂
dot1x
Зачем нужен dot1X и как его настроить.. очень много интересных слов можно было бы тут написать, но все сказано до нас. Например на канале одного прекрасного тренера или wiki
Начнем с микротика:
Настроим политики сети: В условиях необходимо отобрать проводные клиенты
В настройках атрибутами выдадим рабочий влан
К примеру вот так выглядит отказ в авторизации:
А вот так успешное подключение:
IPSEC
С недавнего времени стало популярно настраивать vpn через ipsec ikev2, но многих пугает морока с клиентскими сертификатами. В этом плане использовать учетные данные из AD гораздо удобнее.
Для начала включим в настроках добавленного радиус клиента что он будет использоваться для ipsec
Дефолтные конфиги в ipsec не принято трогать. поэтому будем создавать свои.
Создадим «группу конфигов»
/ip ipsec policy group add name=ipsec
Настроим Profile (фаза 1)
/ip ipsec profile add dh-group=modp1024 enc-algorithm=aes-192,3des name=ipsec
Создадим пир для входящих подключений
/ip ipsec peer add exchange-mode=ike2 name=ipsec passive=yes profile=ipsec send-initial-contact=no
Создадим настройки proposals (фаза 2)
/ip ipsec proposal add name=ipsec
Добавим пулл ip адресов которые будут выдаваться клиентам
/ip pool add name=pool1 ranges=10.20.0.10-10.20.0.250
Добавим Mod config, из которого клиенты получают префиксы подсетей за впн и dns
/ip ipsec mode-config add address-pool=pool1 name=ipsec split-include=0.0.0.0/0,10.20.0.0/16
Создадим шаблонную политику шифрования трафика
/ip ipsec policy add group=ipsec proposal=ipsec template=yes
Если планируете подключаться из windows машин в домене, то можете импортировать сертификат из своего CA и разлить его политикой на ноутбуки\компьютеры.
Если нет своего CA то можно сгенерировать сертификат на микротике. но тогда прийдется опять таки его импортировать на клиентах вручную или через GPO.
И на мой взгляд самый удобный способ, воспользоваться сертификатом letsecrypt, кстати в ros7 есть команда для автоматического получения сертификата.
Или приобрести коммерческий сертификат. У меня в примере Letsencrypt, обратите внимание что необходимо добавить так же все промежуточные сертификаты.
/ip ipsec identity add auth-method=eap-radius certificate=lefull,lefull_1,lefull_2 generate-policy=port-strict mode-config=ipsec peer=ipsec policy-template-group=ipsec
Добавляем политику на NPS сервере
В методах проверки подлинности разрешаем аутентификацию по паролю используюя ms-chap v2
После этого можно подключаться клиентом, все должно работать )
Если желательно расписать как настраивать клиента на mikrotik дайте знать )
Диагностика
Не всегда наши настройки сразу работают так как надо, иногда что то идет не так, и очень хочется понять что именно. Для того что бы понять в чем причина у нас есть :
политики сети и доступа
возможны проблемы из за windows брандмауера починить можно
или для англоязычной версии:
radclient из пакета freeradius-utils. Позволяет из командной строки проверить некоторые типы авторизации, к примеру подключение к vpn
Выводы
RADIUS в сетевой среде очень полезен в плане безопасности и удобен в плане централизованного управления. Настраивать не так уж и сложно, главное читать, понимать документацию и логи.
Если какой то из пунктов непонятен, пишите. попробую показать или помочь разобраться.
Если в статье нашли ошибки, неточности или знаете как сделать лучше тоже пишите.
Благодарности:
Спасибо @aslancherkesov за злого редактора и свежий взгляд на буквы.