Radius сервер для wifi

Radius сервер для wifi

Посетителей: 12080 | Просмотров: 22734 (сегодня 1) Шрифт:

В первой части мы узнали, зачем предприятием использовать Enterprise режим Wi-Fi Protected Access (WPA or WPA2), а не Personal (PSK) режим. Мы узнали, что 802.1X проверка подлинности в режиме Enterprise требует использование RADIUS сервера, который включен в Windows Server.

Мы уже установили и настроили службу сертификатов в Windows Server 2008. В этой части мы продолжим установку и настройку сетевой политики и служб доступа. Затем мы настроим беспроводные контроллеры и/или точки доступа (APs) на использование шифрования, а также параметры RADIUS. Затем мы настроим клиентские компьютеры. И наконец, мы сможем подключиться.

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

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

В окне начальной настройки (Initial Configuration Tasks) пролистайте вниз и выберите Добавить роли (Add roles). Если вы закрыли и свернули это окно, нажмите Пуск> Диспетчер сервера, выберите Роли и нажмите Добавить роли.

Выберите Сетевая политика и службы доступа (Network Policy and Access Services) (рисунок 1), и нажмите Далее.

Рисунок 1: Выбор установки ролей сетевой политики и служб доступа

Просмотрите введение и нажмите Далее.

Выберите следующее (рисунок 2):

  • Сервер сетевой политики (Network Policy Server)
  • Серверы маршрутизации и удаленного доступа (Routing and Remote Access Servers)
  • Службы удалённого доступа (Remote Access Services)
  • Маршрутизация (Routing)

Рисунок 2: Выбор установки первых четырех опций

Нажмите Далее. Затем нажмите Установить, подождите завершения установки и нажмите Закрыть.

Теперь можно начать настройку NPS для функции RADIUS: нажмите Пуск, введите nps.msc и нажмите Enter.

Для опции Стандартная конфигурация (Standard Configuration) выберите опцию RADIUS сервер для 802.1X Wireless или проводных подключений (RADIUS server for 802.1X Wireless or Wired Connections) (рисунок 3) из раскрывающегося меню.

Рисунок 3: Выбор RADIUS сервера для 802.1X

Нажмите Настроить 802.1X.

Для типа 802.1X подключений выберите Защищать беспроводные подключения (Secure Wireless Connections) (рисунок 4), и нажмите Далее.

Рисунок 4: Выбор защиты беспроводных подключений

Для каждого беспроводного контроллера и/или точки доступа нажмите Добавить, чтобы создать новую запись клиента RADIUS. Как показано на рисунке 5, нужно указывать дружественные имена, которые помогут вам определить их среди прочих, IP или DNS адреса и общий секрет (Shared Secret).

Рисунок 5: Ввод информации для беспроводного контроллера или точки доступа

Эти общие секреты важны для проверки подлинности и шифрования. Делайте их сложными и длинными, как пароли. Они должны быть уникальными для каждого контроллера/AP. Позже вам нужно будет ввести такие же общие секреты для соответствующих контроллеров/AP. Не забывайте держать их в секрете, храните их в безопасном месте.

Для способа проверки подлинности (Authentication Method) выберите Microsoft Protected EAP (PEAP), поскольку мы будем использовать PEAP.

Нажмите кнопку Настроить’, выберите ранее созданный сертификат и нажмите OK.

В окне указания групп пользователей (рисунок 6) нажмите Добавить.

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

В диалогах выбора группы введите группы или нажмите дополнительно (Advanced) для поиска доступных групп. Если вы не создали дополнительные группы, вам, возможно, придется выбрать Пользователей домена (Domain Users) для разрешения пользователей и Компьютеры домена (Domain Computers) для проверки подлинности машин, если ваши контроллеры/APs поддерживают их. Если вы получите сообщение об ошибке, говорящее о том, что домен не существует, перезапустите сервер Active Directory Domain Services и попробуйте еще раз.

После добавления нужных групп нажмите Далее для продолжения.

В окне настройки VLAN (рисунок 7), если ваша сеть (коммутаторы и контроллеры/APs) поддерживает VLAN и они настроены, нажмите Настроить’, чтобы установить функцию VLAN.

Рисунок 7: Нажмите кнопку настройки для определения параметров VLAN

По окончании настройки VLANs нажмите Далее.

Просмотрите параметры и нажмите Готово.

Настройка беспроводных контроллеров и/или точек доступа

Пришло время настроить беспроводные контроллеры или точки доступа (APs). Вызовите веб-интерфейс путем ввода IP адреса точек доступа или контроллеров в браузер. Затем перейдите в параметры беспроводной сети.

Выберите WPA-Enterprise или WPA2-Enteprise. Для типа шифрования выберите TKIP, если используется WPA (TKIP if using WPA) или AES, если используется WPA2 (AES if using WPA2). Затем введите IP адрес RADIUS сервера, которым должна быть только что настроенная машина Windows Sever. Введите общий секрет, созданный ранее для этого контроллера/AP. Сохраните параметры.

Установка ЦС сертификата на клиентских машинах

В первой части цикла вы создавали собственный Центр сертификации (ЦС) и сертификат сервера. Таким образом, нужно установить ЦС на все клиентские компьютеры. В этом случае клиент может выполнить проверку сервера перед прохождением проверки подлинности.

Если вы используете сеть доменов с Active Directory, вам, возможно, понадобится развернуть этот сертификат с помощью групповой политики. Однако вы также можете установить его вручную.

Для просмотра и управления сертификатами в Windows Server 2008, вызовите диспетчер сертификатов (Certificate Manager). Если вы сохранили эту MMC на свой компьютер в первой части, откройте ее. В противном случае выполните эти шаги еще раз:

  1. Нажмите Пуск, введите MMC и нажмите Enter.
  2. В окне консоли MMC выберите Файл>Добавить или удалить оснастку.
  3. Выберите Сертификаты и нажмите Добавить.
  4. Выберите Учетная запись компьютера и нажмите Далее.
  5. Выберите Локальный компьютер, нажмите Готово и OK.

Совет: и опять же, вы можете сохранить эту консоль MMC на компьютер для более удобного доступа в будущем: нажмите Файл>Сохранить.

Теперь разверните Сертификаты (Локальная учетная запись компьютера (Local Computer Account)), разверните Личные (Personal) и нажмите Сертификаты (Certificates).

Как показано на рисунке 8, нажмите правой клавишей на сертификате, у которого значение «Выдан для» (Issued To) заканчивается на CA, перейдите к пункту Все задачи и выберите Экспорт’. Затем следуйте указаниям мастера экспорта. Когда мастер вас спросит, не экспортируйте закрытый ключ, а используйте DER формат. Вам, возможно, придется экспортировать его на флешку, чтобы можно было брать его с собой к клиентским машинам.

Рисунок 8: Экспортирование ЦС сертификата для установки на клиенты

Теперь на клиентских компьютерах дважды нажмите на сертификате и нажмите кнопку Установить сертификат (Install Certificate) (рисунок 9). Используйте мастер для импорта сертификата в хранилище Доверенные корневые центры сертификации (Trusted Root Certificate Authorities).

Читайте также:  Размер фото обложки на фейсбук

Рисунок 9: Установка ЦС сертификата на клиенте.

Настройка сетевых параметров на клиентских компьютерах

Теперь можно настроить сетевые параметры. Как и с установкой сертификатов, можно продвигать сетевые настройки на клиенты с помощью групповой политики, если вы работаете в сети доменов с Active Directory. Однако можно также настроить клиентов вручную, как в нашем случае для Windows XP, Vista и 7.

Сначала, вручную создаем сетевой профиль или предпочитаемую запись сети. Для Типа безопасности (Security Type) выберите WPA-Enterprise или WPA2-Enteprise. Для Типа шифрования (Encryption Type) выберите TKIP, если используется WPA или AES, если используется WPA2.

Откройте сетевой профиль и выберите закладку Безопасность (в Vista и 7) или Проверка подлинности (в XP). В XP отметьте опцию Включить IEEE 802.1x проверку подлинности для этой сети.

Для Способ проверки подлинности сети (Network Authentication method) (в Vista и 7, как показано на рисунке 10) или EAP Type (в XP), выберите Protected EAP (PEAP). В XP также уберите флажки с опций внизу окна.

Рисунок 10: Выбор PEAP для способа проверки подлинности

В Windows 7 (только) нажмите кнопку Дополнительные параметры (Advanced Settings) в закладке Безопасность. Затем в окне дополнительных параметров отметьте опцию Указать способ проверки подлинности (Specify authentication mode), выберите Проверка подлинности пользователя (User Authentication) и нажмите OK, чтобы вернуться в закладку безопасности.

Нажмите кнопку Параметры (в Vista и 7) или Свойства (в XP).

В диалоге свойств Protected EAP Properties выполните эти шаги (рисунок 11):

  • Отметьте первую опцию, Проверять сертификат сервера (Validate server).
  • Отметьте вторую опцию, Подключаться к этим серверам (Connect to these servers), и введите полные имена компьютеров серверов. При необходимости дважды нажмите на нем в Windows Server, выбрав Пуск > Диспетчер сервера.
  • В окне списка Доверенных корневых центров сертификации выберите сертификат ЦС, который вы импортировали.
  • Выберите Защищённый пароль (Secured password (EAP-MSCHAP v2)) для способа проверки подлинности.

Рисунок 11: Настройка свойств PEAP

  • Нажмите кнопку Настроить. Если вы работаете в сети доменов с Active Directory, лучше отметить эту опцию. В противном случае снимите флажок с этой опции, чтобы можно было вводить имя пользователя и пароль при подключении к сети.

Наконец, нажмите OK в диалоге windows для сохранения параметров.

И, наконец, подключаемся и входим!

Когда сервер, APs и клиенты настроены, нужно попробовать подключиться.

На клиентском компьютере выбираем сеть из списка доступных сетевых подключений. Если вы не настроили клиента на автоматическое использование входа в Windows, вам нужно будет ввести учетные данные для входа, как показано на рисунке 12. Используйте учетную запись на Windows Server, принадлежащую к группе, настроенной ранее в разделе установки сетевой политики и служб доступа. Если вы выбрали группу пользователей домена, учетная запись администратора должна быть разрешена по умолчанию.

Рисунок 12: Окно входа.

Заключение

Теперь у вас должна быть сеть с 802.1X проверкой подлинности и защитой Enterprise шифрованием, благодаря Windows Server 2008 и предоставляемой им функции RADIUS. Мы настроили сервер, беспроводные APs, и клиентов на использование PEAP проверки подлинности. Конечные пользователи смогут входить с помощью своих учетных записей.

Для управления параметрами сервера RADIUS, такими как добавление или удаление APs, используйте утилиту Network Policy Server: нажмите Пуск>Все программы> Инструменты администрирования>Сервер сетевой политики.

Коротко по настройке Wi Fi подключения на Windows 7 по протоколу WPA ENTERPRISE (Radius Server).

Создаем в ручную подключение к сети Wi Fi:

Нажимаем создать Новую сеть

Вводим основные параметры подключения к сети:

  • Имя сети: my_network
  • Тип безопасности: WPA2-Enterprise
  • Тип шифрования: AES
  • Галочка — Запускать это подключение автоматически

Нажимаем Изменить параметры подключения

  • Тип безопасности: WPA2-Enterprise
  • Тип шифрования: AES
  • Выбрать метод проверки подлинности сети — Microsoft: Защищенные EAP (PEAP)
  • Галочка: Запомнить мои данные для этого подключения при каждом входе в систему

Далее нажимаем кнопку Дополнительные параметры:

  • Укажите режим проверки подлинности: Ставим галку — Проверка подлинности пользователя или компьютера
  • Галка включить единую регистрацию для сети

Нажимаем кнопку Параметры:


Здесь:

  • Убираем галочку: Проверят сертификат сервера
  • Выбрать метод проверки подлинности: Защищенный пароль (EAP-MSCHAP)
  • Ставим галочку: Включить быстрое переподключение

Нажимаем кнопку Настроить возле надписи:

  • Выбрать метод проверки подлинности: Защищенный пароль (EAP-MSCHAP)

Обязательно убираем галку:

  • При подключении: Использовать автоматически имя входа и пароль из Windows (и имя домена, если существует)

Инструменты пользователя

Инструменты сайта

Содержание

Цель: организовать закрытую сеть WiFi cо списком доступа по MAC-адресу и централизованным управлением этим списком на точках доступа TP-Link TL-WR842ND.

Требуемый уровень безопасности допускает организацию доступа к беспроводной сети на основе списка разрешенных MAC-адресов. В тоже время есть потребность ограничить любого желающего от доступа к сети. Хотя с другой стороны, любой желающий, просканировав эфир, может определить MAC-адреса разрешенных пользователей, и подключиться к сети скопировав полученный MAC на свой беспроводной интерфейс. Это противоречие и предстоит разрешить в работе: ограничить возможность доступа к сети «любому желающему» наиболее простыми методами с возможностью централизованного управления доступом (без надобности вносить изменения на каждой точке доступа в отдельности).

Для знакомства с теорией безопасности Wi-Fi , то неплохой обзор есть на Хабре: WPA2-Enterprise, или правильный подход к безопасности Wi-Fi сети

Добавим то, что автор при сравнении WPA2 Personal и WPA2 Enterprise основным отличием считает использование индивидуального ключа на каждого пользователя в WPA2 Enterprise .

А нам интересен WPA2 Enterprise для централизованного управления клиентами, а именно ведения списка MAC -адресов.

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

RADIUSPicking Auth-TypeAuthenticating

Вот мой вольный перевод этой статьи, за достоверность не ручаюсь.

И на всякий случай синхронизирую термины:

Большинство проблем с конфигурацией связаны с непониманием концепции FreeRADIUS . Редактирование конфигурационных файлов и перебор возможных опций не поможет понять концепцию.

Ни вы, ни радиус не знает и не решает, что клиент вам пришлет в запросе. Ответственность за то, что содержится в запросе лежит 100% на клиенте.

Читайте также:  Как просверлить арматуру в потолке

Радиус сервер смотрит на запрос и говорит:

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

Сервер начинает опрашивать модули этапа авторизации (в конфиге есть отдельная секция authorize <> ):

В какой-то момент один из модулей скажет:

Модули делают это на основании просмотра ключевых атрибутов пришедших в запросе, таких как MS-CHAP-Challenge (для MS-CHAP ), или CHAP-Challenge (для CHAP ), or EAP-Message (для EAP ). Или же на основании предположения, что надо бы добавить что-то в каждый запрос.

Если модуль думает, что у него есть шанс чтобы ещё и аутентифицировать пользователя, он скажет:

Если модуль ничего не распознаёт, или знает, что нет необходимости что-то искать, то он просто ничего не делает.

В конце авторизации, сервер проверит добавлен ли Auth-Type к запросу. Если нет, то немедленно отклонит запрос.

Давайте предположим, что клиент отправил запрос с атрибутом User-Password, и модуль pap включен в секции autorize <> . Тогда pap модуль установит Auth-Type = pap.

Таким образом, сервер снова обратится к модулю pap, но уже на стадии аутентификации ( она также имеет свою секцию в конфиге authenticate <> ), pap ответит:

Итак, затем идет сравнение локального заранее известного правильного пароля с тем, который ввел пользователь (пришел в запросе). Это то, как работает аутентификация.

«правильный» пароль (заранее известный правильный пароль) был добавлен другим модулем. Например, модуль pap просто выполняет PAP аутентификацию и ничего больше. Преимущества такого подхода в том, что «правильный» пароль может быть добавлен в запрос из текстового файла users , SQL , LDAP , /etc/passwd , внешней программы и т.д. и т.п. в очень широких пределах.

Например, если подключен модуль LDAP в секции authorize <> , и сервер обрабатывает запрос, то если модуль найдет у себя запись с паролем (где-нибудь в каталоге LDAP), то он добавит этот пароль в запрос, чтобы другой модуль на этапе аутентификации мог использовать его.

Что, если клиент отправит MSCHAP запрос? Что будет с этим запросом делать радиус-сервер?

В этом случае, модуль mschap ищет в запросе атрибут MS-CHAP на этапе авторизации и когда находит устанавливает атрибут Auth-Type на себя (mschap), но уже для этапа аутентификации. Модуль базы данных (например, такой как LDAP, выше) получает информацию о «правильном» пароле и добавляет её в запрос. Затем модуль mschap вызывается уже для процесса аутентификации. Он просматривает запрос в поисках «правильного» пароля либо в виде текста, либо в виде NT-HASH (почему? Смотрите таблицу протоколов http://deployingradius.com/documents/protocols/compatibility.html ). Если ни один требуемый вид пароля не будет предоставлен хранилищем данных, то mschap скажет:

Но сервер уже исчерпал варианты, его единственный вариант был mschap, так как это то, что клиент послал в запросе. Mschap модуль не смог ничего сделать, потому что ему не предоставили «правильный» пароль. Таким образом сервер за неимением вариантов запрос отклоняет. MSCHAP данные могли быть корректными, но у сервера не было способа убедиться в этом. Поэтому он ответил отказом.

Выводы

На имеющихся беспроводных маршрутизаторах TP-Link TL-WR842ND с заводской прошивкой у нас есть возможность использовать следующие типы защиты: WPA2–PSK, WPA2–Enterprise. Остальные варианты не рассматривались из-за их неактуальности: открытая сеть не соответствует поставленной цели; WEP – давно скомпрометирован; WPA-PSK/Enterprise – есть же WPA2 c более строгим подходом к шифрации.

WPA2-PSK – использует Pre-shared key, который в общем случае устраивал бы, но так как было желание управлять допущенными к сети MAC-адресами пользователей централизованно, а не на каждой точке в отдельности, доставляет некоторое неудобство.

WPA2-Enterprise – использует RADIUS-сервер для авторизации/аутентификации; учет пользователей (accounting) не поддерживается точкой доступа TP-Link TL-WR842ND. Отправляет в запросе к RADIUS MAC-адрес пользователя – следовательно можно вести список разрешенных MAC на RADIUS-сервере. WR842ND не умеет подставлять MAC-адрес вместо имени пользователя и пароля (такая возможность есть, например, в RouterOS от Mikrotik), поэтому придется заводить учетные данные (пользователь/пароль) либо на каждого пользователя можно с привязкой к MACy, либо одну общую учетку, о которой будут осведомлены все заинтересованные пользователи, а список MAC-адресов будет вестись отдельно.

Так как централизованно управлять списком доступа на основании MAC-адресов позволяет RADIUS-сервер, то выбор защиты Wi-Fi сети пал на WPA2-Enterprise.

WPA2-Enterprise поддерживает ряд методов аутентификации EAP. Для Window актуальны EAP-TLS и EAP-PEAPv0. EAP-TLS – поможет избавить пользователя от введения логина и пароля, но здесь встанет другая задача по разворачиванию инфраструктуры открытых ключей и распределению сертификатов. Причем встанет проблема установки сертификатов на мобильных устройствах. Хоть данный метод самый надёжный, но из-за сложности развёртывания и сопровождения для наших нужд он отпадает.

EAP-PEAPv0 с MS-CHAPv2 – от пользователя требуется доверие к точке доступа/серверу и знание связки логин/пароль. Доверие к точке доступа/серверу достигается проверкой предъявляемого сервером сертификата, либо отключением этой проверки. Суть метода состоит в создании защищённого туннеля внутри которого осуществляется аутентификация пользователя по методу MS-CHAPv2. Простое развёртывание и сопровождение, особенно если слепо доверять точке доступа/серверу. Но страдает безопасность от «активных» злоумышленников.

Метод EAP-PEAPv0 с MS-CHAPv2 существенно проще в реализации, чем EAP-TLS и позволит организовать закрытую сеть, тем самым «любому желающему» будет гораздо сложнее, нежели просто определить разрешенный MAC-адрес, если конечно у него не будет альтернативного метода получения доступа к учетным данным.

Реализация метода EAP-PEAPv0 с MS-CHAPv2 во FreeRADIUS позволяет выдавать пользователю индивидуальную связку логин/пароль и привязывать их к MAC-адресу его оборудования. Хотя для наших целей это было признано нецелесообразным из-за дополнительной нагрузки на администраторов сети по сопровождению пользователей. Поэтому будет общий логин/пароль на всех, так как некоторые wi-fi клиенты не дают возможности оставлять данные поля пустыми.

Итог: беспроводной маршрутизатор TP-Link TL-WR842ND будет работать в режиме точки доступа с методом безопасности WPA2-Enterprise, который предполагает использование RADIUS-сервера. RADIUS-сервер на базе FreeRADIUS будет реализовывать список доступа на основе MAC-адресов и производить аутентификацию пользователей по методу EAP-PEAPv0 с MS-CHAPv2. При данном методе, пользователю необходимо доверять точеке доступа/серверу (или проверять сертификат для установки доверия) и знать учетные данные (логин/пароль) для прохождения MS-CHAPv2 аутентификации.

Демон FreeRADIUSa после установки сразу же стартует, то есть после выполнения команды apt-get install freeradius мы имеем на выходе запущенный RADIUS-сервер. Официальная документация рекомендует вносить как можно меньше изменений в исходную конфигурацию, ибо она продумана для многих типичных задач RADIUS-сервера. FreeRADIUS «из коробки» уже умеет работать с WPA2-Enterprise, в том числе и с EAP-PEAPv0 c внутритуннельной аутентификацией MS-CHAPv2. Поэтому настройка FreeRADIUS заключается в том, чтобы создать собственный сертификат сервера, завести клиентов (точки доступа) , завести учетные данные для MS-CHAPv2 и добавить возможность фильтрации запросов по MAC-адресами из разрешенного списка.

Читайте также:  Мелодия без звука на телефон

Следует отметить, что приведенные команды и фрагменты конфигурации тестировались на Debian 7.5 c FreeRADIUS 2.1.12+dfsg-1.2

2.1 Создание production-сертификатов

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

Инструменты для создания сертификатов нужных freeradius у Debian лежат по пути /usr/share/doc/freeradius/examples/certs. Содержимое этого каталога следует скопировать в /etc/freeradius/certs. Необходимы файлы:

А также можно скопировать README, в котором расписано что и зачем нужно и как этим пользоваться, поэтому дальше пойдут необходимые команды с краткими пояснениями, за более подробной инфой в README.

Для работы скриптов понадобится openssl и make.

Создаем файл с параметрами Диффи-Хеллмана, если он вдруг отсутствует в каталоге /etc/freeradius/certs:

Результат работы: файл dh

Создаём корневой сертификат или сертификат удостоверяющего центра. Если до этого уже были какие-то сертификаты (обычно тестовые), то удаляем:

Редактируем под себя файл ca.cnf . Следует обратить внимание на default_md = md5 (лучше поставить sha1), default_days = 365 ( возможно через год не захочется генерировать новый сертификат, тогда лучше ставить побольше), input_password/output_password и нужно отредактировать под себя всю секцию [certificate_authority] .

Результаты работы: ca.pem , ca.key и ca.der – сертификат удостоверяющего центра, его закрытый ключ и сертификат в формате понятном для Windows соответсвенно.

Создание серверного сертификата: Редактируем под себя файл server.cnf . Следует обратить внимание на default_md = md5 (лучше поставить sha1), default_days = 365 ( возможно через год не захочется генерировать новый сертификат, тогда лучше ставить побольше), input_password/output_password и нужно отредактировать под себя всю секцию [server] . Важно чтобы значение commonName отличалась от соответствующего сертификата удостоверяющего центра.

Результат работы: помимо прочих файлы server.pem и server.key – сертификат и закрытый ключ сервера.

В конфигурации пути к сертификатам сгенерированным в папке /etc/freeradius/certs прописаны по умолчанию.

Если был изменён пароль на закрытый ключ сервера ( output_password ), то его придется указать в конфиге. А также нужно закомментировать путь к скрипту создания временных сертификатов. Это делается в файле /etc/freeradius/eap.conf в следующей секциии:

2.2 Описываем RADIUS-клиентов (точки доступа)

Добавляем в файл /etc/freeradius/clietns.conf следующее:

2.3 Заводим учетные данные для аутентификации по логину и паролю

В файл /etc/freeradius/users добавляем первую строку следующего содержания:

2.4 Добавляем список доступа на основе MAC-адресов

Конфигурация FreeRADIUS не поддерживает списка MAC-адресов из коробки. Хотя MAC-адрес можно указать как дополнительный атрибут проверки в файле /etc/freeradius/users , например:

Для запроса с именем пользователя user будет проверяться пароль и сравниваться атрибут Calling-Station-Id . Чтобы это работало в случае ЕAP-PEAP следует в файле /etc/freeradius/eap.conf установить параметр сopy_request_to_tunnel = yes в секции приведённой ниже:

Точка доступа в запросе шлет параметр Calling-Station-Id = “MAC-адрес«, причем формат представления MAC-адреса может быть различным на разных точках доступа. Чтобы избежать проблем из-за различного представления MAC-адреса, следует их приводить к одному виду. Для этого в фйле /etc/freeradius/policy.conf имеется уже готовая процедура — r ewrite.calling_station_id . Чтобы ей воспользоваться её название нужно вставить в начало секции authorize <> после объявления preprocess (если он есть) в файлах /etc/freeradius/site-available/default и /etc/freeradius/site-available/inner-tunnel следующим образом:

Процедура нормализует формат MAC-адреса в атрибуте Callin-Station-Id из запроса, пришедшего на сервер, к формату xx-xx-xx-xx-xx-xx — нижний регистр и все через «минус». Поэтому в файле /etc/freeradius/user следует придерживаться данного формата. В принципе уже можно делать список доступа для фильтрации по MAC.

Вариант1.

Достаточно в файл users в самое его начало добавлять нужных пользователей с параметром Calling-Station-Id , если учетные данные нужны одинаковые, то можно их просто повторить, например:

Тем самым на одну пару логин/пароль вешаем три различных MAC-адреса.

Вариант2.

Можно пойти другим путём и создать для списка разрешенных MAC-адресов отдельный файл. Для этого создаем в каталоге /etc/freeradius/ файл authorized_macs и объявляем его в модуле files . Для этого вставляем в конец файла /etc/freeradius/modules/files следующий кусок конфига:

Чтобы проверка MAC-адресов из файла /etc/freeradius/authorized_macs выполнялась, нужно в файл /etc/freeradius/sites-available/default в секцию authorize <> после объявления rewrite.calling_station_id вставить прокомментированные строки:

Теперь файл authorized_macs заполняем разрешенными для авторизации MAC-адресами. Каждый MAC на новой строке. Следует учитывать, что формат строго следующий: xx-xx-xx-xx-xx-xx , где x-либо цифра, либо буквы от a до f в нижнем регистре. Например:

Следует отметить, что атрибут Calling-Station-Id указанный в файле users для определённой пары логин/пароль также будет действовать, но его проверка будет осуществляться на этапе, который проходит позднее. Так что если поступит запрос со значением Calling-Station-Id , не указанном в файле authorized_macs, то этот запрос сразу отклонится, вне зависимости, что указано в файле users.

Итог: выше описаны необходимые измения в конфигурации по-умолчанию, чтобы получить требуемый функционал от freeradius. Еще нужно настроить точки доступа, куда нужно вписать IP адрес RADIUS-сервера и секретную фразу из секций client <> . Также в конфигурации описано много лишних методов аутентификации и модулей дополнительной обработки, которые можно удалить/закомментировать без ущерба функционалу. При выбранном типе аутентификации у FreeRADIUS нет возможности выдавать клиентам IP адреса и прочие сетевые настройки, это должен делать отдельный DHCP-сервер.

При изменении файлов конфигурации, в том числе файлов users и authorized_macs требуется принудительное перечитывание конфига сигналом SIGHUP :

При изменениях в конфиге radiusd.conf лучше демон перезагрузить:

Чтобы проверить конфигурацию следует запускать демон в режиме отладки:

При таком запуске можно увидеть как freeradius распарсил конфиг и увидеть как он обрабатывает запросы. Очень помогает при отыскании различных проблем или при объяснении неожиданного поведения.

В комплекте идет полезная утилитка radtest – простой RADIUS-клиент. С ней можно проводить некоторые простые тесты для проверки конфигурации. Возможный пример использования (тестирование внутритуннельной аутентификации по порту 18120):

Ссылка на основную публикацию
Max payne mobile не запускается
Макс Пейн снова в деле! Мобильный порт игры на ОС Андроид – то, чего так долго ждали ее преданные фанаты....
Hp envy 15 j011sr
Класс : домашний Платформа (кодовое название) : Intel Shark Bay Тип процессора : Intel Core i5 Код процессора : 4200M...
Hp laserjet 1300 driver windows 10
Sat, 01/10/2015 - 13:15 Драйвера для черно-белого лазерного принтера HP LaserJet 1300. Для OS Windows XP, 7, 8, 8.1. Устройство...
Max крутящий момент нм
Интересная познaвательная статья для любителей ездить на автомобилях с дизельным двигателем. Лошадиные силы решают всё – такой вывод можно сделать,...
Adblock detector