Radius — краткое руководство

Назначение

RADIUS — клиент-серверный протокол, работающий на прикладном уровне. Он является так называемым «протоколом ААА» (англ. «Protocol AAA»), что указывает на его назначение и области использования:

Аутентификация

Аутентификация (Authentication) — процесс, позволяющий аутентифицировать (проверить подлинность) субъекта по его идентификационным данным, например, по логину (имя пользователя, номер телефона и т. д.) и паролю;

Авторизация

Авторизация (Authorization)— процесс, определяющий полномочия идентифицированного субъекта, конкретного пользователя на доступ к определённым объектам или сервисам.

Учет

Учет (или контроль) — процесс, позволяющий вести сбор сведений и учётных данных об использованных ресурсах. Первичными данными, традиционно передаваемыми по протоколу RADIUS являются величины входящего и исходящего трафиков: в байтах/октетах (с недавних пор в гигабайтах). Однако протокол предусматривает передачу данных любого типа, что реализуется посредством VSA (Vendor Specific Attributes). Так, например, может учитываться время, проведенное в сети, посещаемые ресурсы и т. д.

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

Немного о методах EAP

Из википедии:EAP — фреймворк аутентификации, который часто используется в беспроводных сетях и соединениях точка-точка. Формат был впервые описан в RFC 3748 и обновлён в RFC 5247.
EAP используется для выбора метода аутентификации, передачи ключей и обработки этих ключей подключаемыми модулями называемыми методами EAP. Существует множество методов EAP, как определенных вместе с самим EAP, так и выпущенных отдельными производителями. EAP не определяет канальный уровень, он только определяет формат сообщений. Каждый протокол использующий EAP имеет собственный протокол инкапсуляции сообщений EAP.
Сами методы:

  • LEAP — проприетарный протокол, разработан CISCO. Найдены уязвимости. В настоящее время не рекомендуется использовать
  • EAP-TLS — хорошо поддерживаемый среди вендоров беспроводных соединений. Является безопасным протоколом, поскольку является преемником SSL стандартов. Настройка клиентской достаточно сложна. Нужен клиентский сертификат помимо пароля. Поддерживается во многих системах
  • EAP-TTLS — широко поддерживается во многих системах, предлагает хорошую безопасность, используя PKI сертификаты только на сервере аутентификации
  • EAP-MD5 — другой открытый стандарт. Предлагает минимальную безопасность. Уязвим, не поддерживает взаимную аутентификацию и генерацию ключей
  • EAP-IKEv2 — основан на Internet Key Exchange Protocol version 2. Обеспечивает взаимную аутентификацию и установление сеансового ключа между клиентом и сервером
  • PEAP — совместное решение CISCO, Microsoft и RSA Security как открытый стандарт. Широко доступен в продуктах, обеспечивает очень хорошую безопасность. Схож с EAP-TTLS, требуя только сертификат на серверной стороне
  • PEAPv0/EAP-MSCHAPv2 — после EAP-TLS, это второй широко используемый стандарт в мире. Используется клиент-серверная взаимосвязь в Microsoft, Cisco, Apple, Linux
  • PEAPv1/EAP-GTC — создан Cisco как альтернатива PEAPv0/EAP-MSCHAPv2. Не защищает аутентификационные данные в любом случае. Не поддерживаются в Windows OS
  • EAP-FAST — метод, разработанный Cisco для исправления недостатков LEAP. Использует Protected Access Credential (PAC). Полностью не доработан

Немного теории

Когда-то давно инженерами IEEE был придуман стандарт 802.1x. Этот стандарт отвечает за возможность авторизации пользователя сразу при подключении к среде передачи данных. Иными словами, если для соединения, например, PPPoE, вы подключаетесь к среде(коммутатору), и уже можете осуществлять передачу данных, авторизация нужна для выхода в интернет. В случае же 802.1x вы не сможете делать ничего, пока не авторизуетесь. Само конечное устройство вас не допустит. Аналогичная ситуация с Wi-Fi точками доступа. Решение же о допуске вас принимается на внешнем сервере авторизации. Это может быть RADIUS, TACACS, TACACS+ и т.д.

Терминология

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

  • Open — доступна всем
  • WEP — старое шифрование. Уже у всех плешь проедена о том, что его ненадо использовать вообще
  • WPA — Используется TKIP в качестве протокола шифрования
  • WPA2 — Используется шифрование AES

А теперь рассмотрим варианты того, как точка доступа узнает сама, можно ли предоставлять пользователю доступ к сети или нет:

  • WPA-PSK, WPA2-PSK — ключ к доступу находится в самой точке.
  • WPA-EAP, WPA2-EAP — ключ к доступу сверяется с некоторой удаленной базой данных на стороннем сервере

Также существует довольно большое количество способов соедининея конечного устройства к серверу авторизации (PEAP, TLS, TTLS. ). Я не буду их здесь описывать.

Общая схема сети

Для наглядного понимания приведем общую схему работы нашей будущей схемы:

Если словами, то клиенту, при подключении к Wi-Fi — точке предлагается ввести логин и пароль. Получив логин и пароль Wi-Fi точка передает эти данные RADIUS-серверу, на что сервер отвечает, что можно делать с этим клиентом. В зависимости от ответа, точка решает, дать ему доступ, урезать скорость или что-то еще. За авторизацию пользователей будет отвечать наш сервер с установленным freeradius. Freeradius является реализацией протокола RADIUS, который в свою очередь является реализацией общего протокола AAA. AAA — это набор средств для осуществления следующих действий: Authentication — проверяет допустимость логина и пароля. Authorization — проверяет наличие прав на выполнение некоторых действий. Accounting — учитывает ваши дейсвия в системе. Сам протокол передает имя пользователя, список атрибутов и их значений для него. То есть, например, атрибут Auth-Type := Reject — отклонить этого клиента, а Client-Password == «password» — сравнить атрибут в запросе со значением password. Вообще говоря, база аккаунтов и прав для них не обязательно должна храниться на RADIUS-сервере, да и базой может быть что угодно — никсовые пользователи, пользователи домена Windows… да хоть текстовый файлик. Но в нашем случае все будет в одном месте.

Configuring FreeRADIUS to use SQL

Edit /etc/mods-available/sql module and enter the SQL dialect, driver, server, username and password details to connect to your SQL server and the RADIUS database. The database and table names should be left at the defaults if you used the default schema. For testing/debug purposes, uncomment the line — FreeRADIUS will dump all SQL commands to the log file specified here.

Next enable the sql module by executing

    cd mods-enabled
    ln -s ../mods-available/sql sql

Edit / (or whatever site config you use) and uncomment the line containing in the section.

Additionally, edit and uncomment the line containing ‘sql’ under «authorize {}».

Also uncomment the line saying ‘sql’ in the accounting{} section to tell FreeRADIUS to store accounting records in SQL as well.

Optionally add or uncomment ‘sql’ to the session{} section if you want to do Simultaneous-Use detection.

Optionally add or uncomment ‘sql’ to the post-auth{} section if you want to log all Authentication attempts to SQL.

Optionally, if you want to strip all realm names (i.e. you want user joe@domain.com to authenticate as just ‘joe’), then in file , under the ‘query config: username’ section, you MAY need to adjust the line(s) referring to sql_user_name. For example, in uncomment the line:

…and comment out the following line referring to just User-Name. If you want to see what’s happening here, switch on all the logging options in radiusd.conf and run radiusd in debug mode (-X) to see what’s happening : you’ll see » user@domain» being passed to SQL when using User-Name, but just «user» when using Stripped-User-Name. Of course, set all your other SQL options as needed (database login details, etc)

»’You should not change/delete any other lines in the config file without reading and understanding the comments!»’

The config you use (e.g. sites-enabled/default) should then look something like this:

 authorize {
        preprocess
        chap
        mschap
        suffix
        eap
        # We leave "files" enabled to allow creation of test users in the "users" file
        files
        sql
        pap
 }
 accounting {
        # We leave "detail" enabled to additionally log accounting to /var/log/radius/radacct
        detail
        sql
 }

Протоколы ААА

Радиус — это протокол AAA для таких приложений, как доступ к сети или мобильность IP. Помимо Radius, у нас есть следующие протоколы в AAA:

Контроллер доступа к терминалу Система контроля доступа (TACACS)

TACACS — это протокол удаленной аутентификации, который используется для связи с сервером аутентификации, обычно используемым в сетях Unix. TACACS позволяет серверу удаленного доступа взаимодействовать с сервером аутентификации, чтобы определить, имеет ли пользователь доступ к сети.

TACACS +

TACACS + обеспечивает управление доступом для маршрутизаторов, серверов сетевого доступа и других сетевых вычислительных устройств через один или несколько централизованных серверов. Он использует TCP и предоставляет отдельные службы аутентификации, авторизации и учета. Он работает в порту 49.

Механизм работы

Как уже упоминалось, RADIUS — прикладной протокол.
На транспортном уровне используется протокол UDP, порты: 1812 и 1813.

Общая структура сети

Несмотря на то, что существует множество способов построения сетей с использованием RADIUS, общая структура может быть представлена в следующем виде:

Общая структура сети

Место NAS (Network Access Server) может занимать VPN-сервер, RAS (Remote Access Server), сетевой коммутатор и т. д.
Конечный RADIUS-сервер может быть частью исключительно локальной сети или же иметь доступ к сети Интернет.
Базы аутентификации хранят информацию о пользователях (абонентах) и правах их доступа к различным сервисам. Термин «база» в данном случае является собирательным, так как данные могут хранится как в локально, в текстовых файлах и различного рода базах данных, так и на удаленных серверах (SQL, Kerberos, LDAP, Active Directory и т. д.).

Структура пакета

Общая структура RADIUS-пакета имеет вид:

Общая структура RADIUS-пакета

Код показывает тип операции, к которой принадлежит данный код. Так, выделяют следующие коды:

Код Операция
1 Access-Request
2 Access-Accept
3 Access-Reject
4 Accounting-Request
5 Accounting-Response
11 Access-Challenge
12 Status-Server (экспериментальная возможность)
13 Status-Client (экспериментальная возможность)
255 Зарезервировано

Идентификатор служит для различения запросов и ответов.
Поле длины указывает размер всего пакета, с учетом длины кода, идентификатора, самого поля длины, аутентификатора и AVP.
Аутентификатор используется для аутентификации ответа от сервера и шифрования пароля.
AVP или пары «атрибут — значение» (англ. «Atribute-Value Pairs») содержат непосредственно сами передаваемые данные — как запроса, так и
ответа, и участвуют во всех стадиях обмена данными: аутентификации, авторизации и учете. Структура AVP:

Тип (8 бит) Длина (8 бит) Значение

Поле типа служит для указания атрибута, содержащегося в пакете. Выделяют 63 атрибута, в числе которых: имя пользователя и пароль (коды 1 и 2, соответственно), тип сервиса (6), ответ сервера (18), состояние RADIUS-прокси (33), состояние учета (40) и задержка учета (41) и т.д.
Длина указывает размер значения атрибута, которое непосредственно содержится в последнем поле.

Аутентификация и авторизация

  1. Access-Accept — доступ получен, можно начинать использование ресурсов. Пакет, несущий данный ответ, также может содержать дополни-тельную информацию: IP, выданный пользователю, допустимую продолжительность сессии, максимальный объем передаваемого трафика и т.д.;
  2. Access-Challenge — требуется ввод дополнительных данных (PIN, дополнительного пароля). Использование этого ответа позволяет проводить процедуры сложной аутентификации в рамках защищенного сетевого туннеля, установленного напрямую между пользовательской и серверной машинами (для избежания «оседания» данных на сервере доступа);
  3. Access-Reject — доступ запрещен из-за неверно указанных пользовательских данных или отсутствия пользователя в базе.

Список атрибутов RADIUS

Код Атрибуты
1 User-Name
2 Пользовательский пароль
3 CHAP-пароль
4 NAS-IP-адрес
5 NAS-Port
6 Тип Обслуживания
7 Framed-Protocol
8 Framed-IP-адрес
9 Framed-IP-Netmask
10 Рамка-маршрутизация
11 Фильтр-Id
12 Framed-MTU
13 Рамка-сжатие
14 Логин-IP-Host
15 Логин-Сервис
16 Логин-TCP-порт
17 (Неприсвоенный)
18 Ответ-сообщение
19 Callback-Number
20 Callback-Id
21 (Неприсвоенный)
22 Framed-Route
23 Framed-IPX-сети
24 состояние
25 Учебный класс
26 Vendor-Specific
27 Session-Timeout
28 Idle-Timeout
29 Termination-Action
30 Called-Station-Id
31 Вызов-Station-Id
32 NAS-Identifier
33 Proxy-State
34 Логин-LAT-Service
35 Login-LAT-Node 3
36 Логин-LAT-Group
37 Framed-AppleTalk-Link
38 Framed-AppleTalk-Network
39 Framed-AppleTalk-Zone
40-59 (зарезервировано для учета)
60 CHAP-вызов
61 NAS-Port-Type
62 Порт-Limit
63 Логин-LAT-Port

Настройка Network Policy Server (NPS)

Теперь переходим к настройке Network Policy Server (NPS) для этого запускайте оснастку «Сервер политики сети». Для начала зарегистрируйте этот сервер в AD, правой кнопкой «Зарегистрировать сервер в AD». Потом можно выключить политики, которые создались по умолчанию (также легко, правой кнопкой выключить). Затем можете запускать мастер настройки сервера.

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

Затем можно указать клиентов RADIUS сервера. Под этим понимается сервера, которым нужны услуги RADIUS сервера, например наш VPN сервер, но так как он находится на нашем локальном компьютере, то здесь можно ничего не заполнять.

На следующем этапе у Вас спросят, какой метод проверки подлинности Вы хотите использовать, выберите вариант MS-CHAPv2.

Далее добавьте группу пользователей, которые имеют право на подключения к VPN серверу. Свою группу я назвал VPN.

Потом Вас попросят настроить ip-фильтры, но мы этого делать не будем, жмем далее и попадаем на этап настройки шифрования, здесь опять ничего не меняем (по умолчанию все галочки включены). Переходим к следующему этапу, где необходимо указать «Имя сферы» мы это тоже пропускаем и жмем далее, где нам уже скажут, что настройка прошла успешно. Жмем «Готово».

Теперь можете раскрыть политики, выберете «Политики запросов на подключение» нажмите правой кнопку на созданную Вами политику и нажмите свойства, перейдите на вкладку условия и нажмите добавить. Найдите там раздел «Ограничение по дням недели и времени суток» и жмите еще раз добавить. Настройте время так, как Вам нужно, для нашей с Вами тестовой задачи это с 20:00 по 21:00.

Теперь можно переходить к тестированию, в настройках подключения клиента указываем адрес 192.168.1.1 (в реальность внешний IP адрес или DNS имя).

Все, на этом наша с Вами тестовая задача выполнена. Но сразу могу сказать, что возможностей у NPS сервера очень много и Вы можете задавать свои сетевые политики для своей локальной сети, при выполнении некоторых условий. Например, компьютеры должны быть в домене и у них должен быть включен NAP агент. Но об этом и многом другом будем разговаривать в следующих статьях.

НравитсяНе нравится

Configuring FreeRadius to use SQL

Edit either /etc/raddb/sql.conf or /etc/raddb/postgresql.conf and enter the server, name and password details to connect to your SQL server and the RADIUS database. The database and table names should be left at the defaults if you used the default schema. For testing/debug purposes, switch on sqltrace if you wish — FreeRadius will dump all SQL commands to the debug output with this on.

In /etc/raddb/radiusd.conf ensure that the line saying:

 $INCLUDE  sql.conf

is uncommented.

You will also need to edit /etc/raddb/sql.conf, and direct it to the appropriate database (PostgreSQL, MySQL, etc.), by edit the line:

 database = "mysql"

with the name of the database that you are using.

If you’re stripping all realm names (i.e. you want user joe@domain.com to authenticate as just ‘joe’), then in file raddb/sql/database/dialup.conf , under the ‘query config: username’ section, you MAY need to adjust the line(s) referring to sql_user_name. I needed to do this originally because we want to dump all realms, but you probably won’t need to do this with the latest FreeRadius. For example, in our case I needed to uncomment the line:

             sql_user_name = '%{Stripped-User-Name}'

…and comment out the following line referring to just User-Name. If you want to see what’s happening here, switch on all the logging options in radiusd.conf and run radiusd in debug mode (-X) to see what’s happening : you’ll see » user@domain» being passed to SQL when using User-Name, but just «user» when using Stripped-User-Name. Using the latter, realms worked for me (basically, I strip everything, as all user names are unique on the server anyway). Of course, set all your other SQL options as needed (database login details, etc)

Edit /etc/raddb/sites-available/default and uncomment the line containing ‘sql’ in the authorize{} section. The best place to put it is just after the ‘files’ entry. Indeed, if you’ll just be using SQL, and not falling back to text files, you could comment out or delete the ‘files’ entry altogether.

Additionally, edit /etc/raddb/sites-available/inner-tunnel and uncomment the line containing ‘sql’ under «authorize {}». .

Also uncomment the line saying ‘sql’ in the accounting{} section to tell FreeRADIUS to store accounting records in SQL as well.

Optionally add or uncomment ‘sql’ to the session{} section if you want to do Simultaneous-Use detection.

Optionally add or uncomment ‘sql’ to the post-auth{} section if you want to log all Authentication attempts to SQL.

You should not change/delete any other lines in the config file without reading and understanding the comments!

Your radiusd.conf should then look something like this:

 accounting {
        # We leave "detail" enabled to _additionally_ log accounting to /var/log/radius/radacct
        detail
        sql
 }

Роуминг


Роуминг с использованием прокси-сервера RADIUS AAA.

RADIUS обычно используется для облегчения роуминга между интернет-провайдерами , например:

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

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

Царства

Область обычно добавляется к имени пользователя и разделяется знаком «@», напоминая доменное имя адреса электронной почты. Это известно как постфиксное обозначение области. Другое распространенное использование — это префиксная нотация, которая включает добавление области к имени пользователя и использование ‘\’ в качестве разделителя. Современные серверы RADIUS позволяют использовать любой символ в качестве разделителя области, хотя на практике обычно используются ‘@’ и ‘\’.

Области также могут быть составлены с использованием как префиксной, так и постфиксной нотации, чтобы учесть сложные сценарии роуминга; например, somedomain.com \ username@anotherdomain.com может быть действительным именем пользователя с двумя областями.

Прокси-операции

Когда сервер RADIUS получает запрос AAA для имени пользователя, содержащего область, сервер будет ссылаться на таблицу настроенных областей. Если область известна, сервер затем будет передавать запрос настроенному домашнему серверу для этого домена. Поведение прокси-сервера в отношении удаления области из запроса («зачистки») зависит от конфигурации большинства серверов. Кроме того, проксирующий сервер можно настроить для добавления, удаления или перезаписи запросов AAA, когда они снова проксируются через какое-то время.

Прокси-цепочка возможна в RADIUS, а пакеты аутентификации / авторизации и учета обычно маршрутизируются между устройством NAS и домашним сервером через ряд прокси. Некоторые из преимуществ использования цепочек прокси включают улучшения масштабируемости, реализацию политик и корректировку возможностей. Но в сценариях роуминга NAS, прокси и домашний сервер обычно могут управляться разными административными объектами. Следовательно, фактор доверия между прокси-серверами приобретает большее значение в таких междоменных приложениях. Кроме того, отсутствие сквозной безопасности в RADIUS повышает критичность доверия между задействованными прокси-серверами. Цепочки прокси описаны в RFC 2607 .

Безопасность

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

Пример настройки Radius

Начнём с того, что создадим в домене две локальных группы безопасности с ограниченными и полными правами Radius.

Создание группы с полными правами

В первую группу включим пользователей которым нужно предоставить полный административный доступ на управление коммутаторами, во вторую соответственно, — доступ только на чтение текущей конфигурации и состояния устройств. При этом, стоит помнить, что для пользователей, которые будут включаться в эти группы должно быть установлено разрешение в домене, дающее право удалённого доступа (значение настройки Network Access Permission на закладке Dial-In свойств учетной записи пользователя)

Аналогично создаётся группа для пользователей с ограниченным доступом.

Установка ролей сетевой политики и служб доступа

В предыдущих версиях Windows Server функция RADIUS обеспечивалась службой Internet Authenticate Service (IAS). Начиная с Windows Server 2008, она обеспечивается сетевой политикой (Network Policy) и службами доступа (Access Services). Сюда входят предыдущие службы IAS наряду с новым компонентом NAP.

1. Перейдите Start> Server Manager, выберите Roles и нажмите Add Roles;

2. Выберите Network Policy and Access Services, и нажмите Далее:

3. Выберите только Network Policy Server:

Добавление клиентов на сервер RADIUS

1. Перейдите Start > Admin Tools > Network Policy Server > RADIUS Clients and Servers

2. Правый клик RADIUS Clients, New:

3. Вводим желаемое имя. Указываем Shared secret (это общий ключ для завязки устройства на RADIUS, для каждого клиента можно указать индивидуальный):

Значение поля Friendly name может отличаться от DNS имени. Оно потребуется нам в дальнейшем для идентификации конкретного сетевого устройства при создании политик доступа – Remote Access Policy. Опираясь на это имя мы сможем задавать например маску по которой будут обрабатываться определённой политикой доступа несколько разных RADIUS клиентов.

4. На вкладке Advanced выбрать Vendor name: Cisco

Создание политик доступа на сервере RADIUS

С помощью политик доступа NPS мы произведём связку созданных ранее записей о коммутаторах-клиентах RADIUS и доменных групп безопасности, определяющих уровень доступа к этим коммутаторам. То есть в нашем случае будет создано две политики доступа — с полными правами и ограниченными.

1. Перейдите Start > Admin Tools > Network Policy Server:

2. Правый клик по Network Policies, New:

3. Укажите имя для политики, и выберем тип соединения Unspecified:

4. Указываем условия

На следующем шаге Specify Conditions нам нужно добавить условия при которых будет применяться данная политика RADIUS. Добавим два условия, – чтобы пользователь, проходящий авторизацию, входил в определенную доменную группу безопасности (созданную ранее группу Radius), и устройство, к которому осуществляется доступ, имело определённое имя «Friendly name» (созданное ранее).

Здесь важно понимать, что для условия с Windows Group использование встроенных групп безопасности таких как, например, Domain Admins не является хорошей практикой с точки зрения безопасности.

5. Через кнопку Add добавим условия по типам Windows Group и Client Friendly Name.

6. Выбираем Windows Group:

7. Указываем желаемую группу домена:

Radius на Windows server 2016.

Наконец «Долгая дорога в дюнах» закончилась, и мы пришли к корпоративному управляемому Wi-fi решению. В начале думали про решение Cisco или Aruba, но к сожалению текущий бюджет никак не располагает к решениям подобного плана. В итоге, в ходе долгих поисков истины и раздумий, решили остановиться на решении Ubnt (отдельно благодарю Александра за нужные советы). Конечно, это не одного поля ягоды с решением Cisco или Aruba, но в текущей ситуации, что есть, то есть.

Как говорил мой командир: «На пожаре и Х… водопровод» (да простят меня за мой русский).

Итак, решение выбрано, задача настроить корпоративный внутренний и гостевой сегменты Wi-fi с авторизацией на Radius сервере.

VPN сервер уже готов, осталось настроить RADIUS, сегодня как раз об этом. На первый взгляд, развернуть и настроить RADIUS сервер, не такая уж сложная задача, но немного загнались с сертификатом, пришлось «поплясать с бубном», ну об этом далее по порядку.

Для начала необходимо запросить сертификат с Центра сертификации, центр сертификации у нас уже есть, поэтому его установку в этом посте я пропущу.

MMC-Файл-Добавить или удалить оснастку-Добавляем Сертификаты-Учетной записи компьютера-Локальным компьютером.

Находим наш центр сертификации

Запрашиваем сертификат (*.p12), сохраняем его на диск, далее устанавливаем его в Личные сертификаты на будущий радиус сервер

Далее добавляем роль самого RADIUS сервера

Далее запускаем Сервер политики сети

Добавляем в раздел RADIUS-клиенты свои Wi-fi точки доступа или сервер управления точками доступа если он поддерживает эту возможность (в этом случае он будет выполнять роль RADIUS клиента)

Общий секрет, указываем тот, который в последствии укажем на Wi-fi точке (IP адрес точки в той подсети, где она находится).

Переходим к политике запросов на подключение

Вот тут, если нажать на:защищенные EAP(PEAP)-Изменить, мы должны видеть свой сертификат, если он был правильно запрошен и установлен.

Далее настраиваем Сетевые политики

На первый взгляд настройка RADIUS сервера на этом закончена, но это еще не все.

На эту тему есть четкие рекомендации, про которые я совсем забыл (спасибо Александру, что он напомнил):

если сервер не включен в группу RAS and IAS, то его надо туда добавить:

На всякий случай проверяем, что все так, как должно быть, открываем на сервере локальную политику (gpedit.msc)

И проверяем следующий пункт

Далее на точке или точках Wi-fi указываем авторизацию WPA Enterprise.

Здесь же хотел поблагодарить Романа, за подробные разъяснения по неясным моментам по серверу управлению Wi-fi и настройкам непосредственно Wi-fi.

И получаем далее авторизуем с доменными учетными данными, пользователей подключаемых к корпоративному Wi-fi.

Почитать по теме можно здесь:

или здесь:

Всем хорошей работы!!!

Hard dependencies

See for how to satisfy these dependencies on your platform.

libtalloc (since >= v3.0.x)

Talloc is a hierachical memory allocator used/created by the Samba project.

It is used heavily in version >= v3.0.x and greatly simplifies managing complex trees of memory allocation, and local slab allocation.

C11 (since >= v4.0.x)

Since v4.0.x (and the now deprecated v3.1.x) FreeRADIUS has a hard dependency on C11 support (available in GCC >= 4.9.0).

If you see an error message like

That means your compiler does not support C11, and you’ll need to one that does.

For clang this means versions >= 3.0 (released after 2011-12-01), and GCC versions >= 4.9 (released after 2014-04-22).

libkqueue or native kqueue support (since >= v4.0.x)

kqueue is the eventing interface used by the BSDs (including OSX). After evaluating the native eventing APIs of different operating systems and wrappers such as libuv, libev, libevent etc… the FreeRADIUS core team decided to standardise on kqueue.

For Linux and Solaris users, this means there’s a hard dependency on the shim library, libkqueue, which wraps epoll (the native Linux eventing API), providing a kqueue compatible interface.

Summary

Sub-menu: Standards:

RADIUS, short for Remote Authentication Dial-In User Service, is a remote server that provides authentication and accounting facilities to various network apliances. RADIUS authentication and accounting gives the ISP or network administrator ability to manage PPP user access and accounting from one server throughout a large network. The MikroTik RouterOS has a RADIUS client which can authenticate for HotSpot, PPP, PPPoE, PPTP, L2TP and ISDN connections. The attributes received from RADIUS server override the ones set in the default profile, but if some parameters are not received they are taken from the respective default profile.

The RADIUS server database is consulted only if no matching user acces record is found in router’s local database.

Traffic is accounted locally with MikroTik Traffic Flow and Cisco IP pairs and snapshot image can be gathered using Syslog utilities. If RADIUS accounting is enabled, accounting information is also sent to the RADIUS server default for that service.

SQL Schema and usage

In general, the SQL schema mirrors the layout of the ‘users’ file. So for configuring check
items and reply items, see ‘man 5 users’, and the examples in the ‘users’ file.

The SQL module employs two sets of check and reply item tables for processing in the authorization
stage. One set of tables (radcheck and radreply) are specific to a single user. The other set of
tables (radgroupcheck and radgroupreply) is used to apply check and reply items to users that are
members of a certain SQL group. The usergroup table provides the list of groups each user is a
member of along with a priority field to control the order in which groups are processed.

When a request comes into the server and is processed by the SQL module, the flow goes something
like this:

  • Search the radcheck table for any check attributes specific to the user
  • If check attributes are found, and there’s a match, pull the reply items from the radreply table
  • for this user and add them to the reply
  • Group processing then begins if any of the following conditions are met:

    • The user IS NOT found in radcheck
    • The user IS found in radcheck, but the check items don’t match
    • The user IS found in radcheck, the check items DO match AND Fall-Through is set in the radreply table
    • The user IS found in radcheck, the check items DO match AND the read_groups directive is set to ‘yes’
  • If groups are to be processed for this user, the first thing that is done is the list of groups
    this user is a member of is pulled from the usergroup table ordered by the priority field. The
    priority field of the usergroup table allows us to control the order in which groups are processed,
    so that we can emulate the ordering in the users file. This can be important in many cases.
    For each group this user is a member of, the corresponding check items are pulled from
    radgroupcheck table and compared with the request. If there is a match, the reply items for this
    group are pulled from the radgroupreply table and applied.
  • Processing continues to the next group IF:

    • There was not a match for the last group’s check items OR
    • Fall-Through was set in the last group’s reply items (The above is exactly the same as in the
      users file)
  • Finally, if the user has a attribute set or the Default Profile option is
    set in the sql.conf, then steps 4-6 are repeated for the groups that the profile is a member of.

For any fairly complex setup, it is likely that most of the actual processing will be done in the
groups. In these cases, the user entry in radcheck will be of limited use except for things like
setting the user’s password. So, one might have the following setup:

usergroup table:

In the SQL configuration file are _alt queries, these are called when the first SQL query fails or
doesn’t alter (insert, delete, update) any rows in the Database.

Как настроить роутер правильно — на примере ASUS

Вновь приветствую Вас, дорогие читатели, посетители и прочие личности.

Сегодня мы кратенько поговорим о довольно популярной теме, а именно, настройке роутера, т.е. опишем наиболее популярные из них и расскажем, что они означают. Детальные и конкретные практические советы будут отдельной статьей, сегодня же больше терминология с некоторыми пояснениями и комментариями. Так или иначе, думаю, будет интересно и полезно. Перед прочтением рекомендую ознакомиться со статьей «Терминология компьютерной сети или что есть что »

В качестве примера был взят всё еще популярный Asus WL-520gc . В общем и целом, настройки роутеров других моделей и производителей будут иметь похожую структуру, главное понять некие принципы и схему настройки. Что касается выбора роутера, то эта тема уже поднималась, а именно, была упомянута в статье «Как выбрать роутер. Советы и рекомендации.».

Оцените статью
Рейтинг автора
5
Материал подготовил
Андрей Измаилов
Наш эксперт
Написано статей
116
Добавить комментарий