корпоративный wi-fi на ubiquiti с порталом и доменной аутентификацией —

Как сделать чтобы заработало?

Вижу цель — не вижу препятствий. Создаю двустороннее доверие

DOM1.LOCALDOM3.LOCAL

(win2003). Создаю в

DOM3.LOCAL

глобальную группу

allow_internet

, включаю туда пользователей. Добавляю эту глобальную группу в

AUTHSRVallow_internet

и радостно пытаюсь авторизоваться.

Конечно же, ничего не заработало. В ответ приходит вот такой ответ:

Причина = Не удается установить подключение из-за отказа в разрешении на удаленный доступ для учетной записи пользователя. Чтобы разрешить удаленный доступ, включите такое разрешение для учетной записи пользователя или, если в ней указано, что управление доступом осуществляется с помощью соответствующей политики удаленного доступа, включите разрешение на удаленный доступ для этой политики.

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

DOM3.LOCAL

или

DOM1.LOCAL

от этого события не было. Гугл по такой ошибке выдает вообще что-то к делу не относящееся (сплошной RDP). Поиск в групповых политиках на «рабочем»

DOM2.LOCAL

ничего не дал.


Я даже попробовал проксирование RADIUS запросов, подняв на

DC.DOM3.LOCAL

также службу проверки подлинности в интернете и трансляцию туда запросов с именем пользователя вида «DOM3*». Тем не менее в логе прокси-RADIUS сервера была точно такая же ошибка и отказ в доступе.

Зачем и почему это?

Так сложились обстоятельства, что мне пришлось администрировать уже настроенную RADIUS аутентификацию пользователей одного доверенного домена на узле Mikrotik, который либо пропускал в интернет пользователей, либо нет. Раньше такого настраивать не приходилось, был в распоряжении просто уже готовый настроенный «черный ящик». Задача была добавить пользователей еще одного домена в эту схему аутентификации.

Чтобы я помнил эту историю вечно, сюда и описываю процесс.

Dot1x

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

Половина смысла с саркальной точки зрения в dot1x в том, что в случае успешной проверки подлинности наше устройство попадет в влан указанный нами в микротике или в влан который мы поличим в качестве атрибута у радиуса. Если проверка подлинности пройдет с отказом или ответ не будет получен от радиуса (например в случае его недоступности), то порт перейдет в изолироованный режим (будет заблокирован любой трафик на порту) или в случае если указан Reject VLAN ID то попадет в влан, для которого мы настроили(я надеюсь все таки настроили) максимально безопасные правила форейвола для чужеродных устройств .

Начнем с микротика:

Настроим политики сети: В условиях необходимо отобрать проводные клиенты

Параметры аутентификации:

В настройках атрибутами выдадим рабочий влан

К примеру вот так выглядит отказ в авторизации:

А вот так успешное подключение:

Freeradius

FreeRadius будем поднимать на CentOS 7.6. Здесь ничего сложного, ставим обычным способом.

yum install freeradius freeradius-utils freeradius-ldap -y

Из пакетов ставится версия 3.0.13. Последнюю можно взять на

Linux

Я проверял на Ubuntu 18.04, 18.10, Fedora 29, 30.

Для начала, скачиваем себе сертификат. Я не нашел в Linux, есть ли возможность использовать системные сертификаты и есть ли там вообще такое хранилище.

Будем подключаться по домену. Поэтому нужен сертификат удостоверяющего центра, у которого был приобретен наш сертификат.

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

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

anonymous — clientdomain — домен, на который выпущен сертификат

Non-samsung

C 7 версии при подключении WiFi можно использовать системные сертификаты, указав только домен:

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

domain — домен, на который выпущен сертификатanonymous — client

Samsung

Как уже писал выше, Samsung-устройства не умеют использовать системные сертификаты при подключении WiFi, и у них нет возможности подключаться по домену. Поэтому надо вручную добавить корневой сертификат центра сертификации (ca.pem, берем на Radius сервере). Вот здесь будет использовать самоподписанный.

Скачиваем сертификат себе на устройство и устанавливаем его.

Установка сертификата

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

При этом, надо будет установить рисунок разблокировки экрана, пин-код или пароль, если он еще не установлен:

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

Я показал сложный вариант установки сертификата. На большинстве устройств достаточно просто нажать на скаченный сертификат.

Когда сертификат установлен, можно переходить к подключению:

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

сертификат — указываем тот, который устанавливалианонимный пользователь — guest

Windows 10

Сложность сводится к тому, что Windows пока еще не умеет подключаться к корпоративному WiFi по домену. Поэтому приходится вручную закидывать наш сертификат в хранилище доверенных сертификатов. Здесь можно использовать как самоподписанный так и от центра сертификации. Я буду использовать второй.

Далее нужно создать новое подключение. Для этого идем в параметры сети и Интернет -> Центр управления сетями и общим доступом -> Создание и настройка нового подключения или сети:

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

Вручную прописываем имя сети и меняем тип безопасности. После нажимаем на изменить параметры подключения и во владке Безопасность выбираем проверку подлинности сети — EAP-TTLS.

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

Заходим в параметры, прописываем конфиденциальность аутентификации — client. В качестве доверенного центра сертификации выбираем добавленный нами сертификат, ставим галочку «Не выдавать пользователю приглашение, если не удается авторизовать сервер» и метод проверки подлинности выбираем — незашифрованный пароль (PAP).

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

Авторизация пользователя wi-fi в домене ad через freeradius (без сертификатов)

# Generated by authconfig on 2022/06/01 18:00:57
# DO NOT EDIT THIS SECTION (delimited by –start-line–/–end-line–)
# Any modification may be deleted or altered by authconfig in future

   workgroup = kvartira.ru
password server = server.kvartira.ru
realm = kvartira.ru
security = ads
idmap uid = 16777216-33554431
idmap gid = 16777216-33554431
template shell = /bin/false
winbind use default domain = true
winbind offline logon = true

Благодарности:

Спасибо @aslancherkesov за злого редактора и свежий взгляд на буквы.

Возможные вопросы

В: как передавать профиль/сертификат сотруднику?

О: Все сертификаты/профили я храню на фтп с доступом через веб. Поднял гостевую сеть с ограничением по скорости и доступом только в интернет, за исключением фтп. Аутентификация держится 2 дня, после чего сбрасывается и клиент остается без интернета. Т.о. когда сотрудник хочет подключиться к WiFi, сначало он подключается к гостевой сети, заходит на фтп, скачивает нужный ему сертификат или профиль, устанавливает их, и после может подключаться к корпоративной сети.

В: почему не использовать схему с MSCHAPv2? она же более безопасная!

О: во-первых, такая схема хорошо работает на NPS (Windows Network Policy System), в нашей реализации необходимо дополнительно настраивать LDAP (FreeIpa) и хранить хэши паролей на сервере. Доп. настройки делать не желательно, т.к. это может привести к различным проблемам сихронизации УЗ. Во-вторых, хеш представляет собой MD4, так что это не особо повышает безопасность

В: можно ли авторизовывать устройтсва по mac-адресам?

О: НЕТ, это не безопасно, злоумышленник может подменить мак-адреса, и тем более авторизация по мак-адресам не поддерживается на многих устройствах

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

Диагностика

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

Get-NetFirewallRule -DisplayGroup "Сервер политики сети" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any

или для англоязычной версии:

Get-NetFirewallRule -DisplayGroup "Network Policy Server" | where DisplayName -like "*RADIUS*" | Set-NetFirewallRule -Service Any 
  • radclient из пакета freeradius-utils. Позволяет из командной строки проверить некоторые типы авторизации, к примеру подключение к vpn

Тест:

Добавление radius клиента

Для того, чтобы сервер знал с какими устройствами налаживать общение нужно добавить их в RADIUS Clients.

Для примера, добавляю свой MikroTik wAP. Friendly name установил как Identity на устройстве и IP заданный на его единственном проводном интерфейсе. Для того, чтобы устройство смогло авторизоваться на сервере нужно ввести ключ. Он создается на сервере либо вручную, либо генерируется автоматически. Я предпочел второй вариант.

New-NpsRadiusClient –Address "10.1.1.21" –Name "router01" –SharedSecret "egEcM4myJCptphGlZ1UymS#qLh^urp@fJ1hF8dE6dwb27NI^oIJtTWKKp^MEsU6p"

image

Vendor name остановим на стандартном RADIUS.

Устройство добавлено.

Добавление сервера авторизации на mikrotik

Первым делом присвоим System/Identity равным router01 и IP с маской для интерфейса.

/system identity set name=router01
/ip address add address=10.1.1.21/24 interface=ether1 network=10.1.1.0

image

Как оно работает?

Итак, начал смотреть как это все работает в текущей схеме. На первый (да и не первый тоже) взгляд все по учебнику:

Все выглядит логично и действительно работает как ожидается.

Клиент для проверки подключения

В качестве платформы для проверки клиентского подключения — наиболее наглядно данный процесс отображается на последних версиях Mac OS X.

Компоненты кейса

  • Суппликант – устройство которое намерено пройти процедуру авторизации и аутентификации.

  • Аутентификатор – устройство к которому подключается суппликант, которое получает у суппликанта данные авторизации и которое проверяет их на RADIUS сервере. NB! Является клиентом для радиус-сервера.

  • RADIUS сервер (он же радиус сервер, он же сервер аутентификации).

Контроллер ubiquiti

На контроллере поднимаем отдельную сеть. Пусть будет 192.168.2.0/24Идем в настройки -> профиль. Cоздаем новый:

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

Прописываем адрес и порт radius-сервера и пароль, который прописывали в файле clients.conf:

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

Создаем новое имя беспроводной сети. В качестве метода аутентификации выбираем WPA-EAP (Enterprise) и указываем созданный radius-профиль:

WiFi Enterprise. FreeRadius   FreeIPA   Ubiquiti

Все сохраняем, применяем и идем дальше.

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

Это виртуальная машина со следующими характеристиками: RAM 1GB, 1xCPU, виртуальный диск 20GB (можно меньше, лишь бы разместилась операционная система и необходимые пакеты).

В роли гипервизора — Oracle Virtual Box 6.1.18

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

FreeRADIUS — из стандартного репозитория.

Корпоративный wi-fi на ubiquiti с порталом и доменной аутентификацией —

Всем привет. Хотим поделиться вариантом реализации корпоративного wifi на нескольких SSID с разными политиками доступа для каждой беспроводной сети и доменной аутентификацией.

Схема тестового стенда выглядит так:

Корпоративный Wi-Fi с помощью точек доступа Ubiquiti

Подробности под катом.

Итак, задача выглядит следующим образом. Точка должна вещать 3 беспроводных сети:

  • vlan 10 — SSID PL_Public — сеть с доменной авторизацией для подключения персональных устройств сотрудников к Internet без доступа к корпоративным ресурсам
  • vlan 20 — SSID PL_Private — сеть с доменной авторизацией для сотрудников, находящихся в домене в группе WIFI_PL_Private c доступом к корпоративным ресурсам
  • vlan 30 — SSID PL_Guest — сеть с одноразовыми паролями со сроком действия 8 часов, вводимыми через веб-портал

Первая задача — создаем на контроллере нужные беспроводные сети. Контроллер позволяет разлить настройки на все точки в сети.

В Profiles добавляем наш Radius-сервер, указав общий Secret. Точка должна быть добавлена как Radius Client на сервере. Если точек много, можно настроить nat, чтобы все точки виделись на сервере с одним IP.

Корпоративный Wi-Fi с помощью точек доступа Ubiquiti

Добавляем нужные SSID на контроллере.

Корпоративный Wi-Fi с помощью точек доступа Ubiquiti

Корпоративный Wi-Fi с помощью точек доступа Ubiquiti

Особенность решения заключается в том, что Radius-сервер должен применять разные политики аутентификации для этих SSID. Разделение по политикам можно сделать на основании поля Called-Station-ID, который передается в запросе аутентификации и представляет собой MAC точки и SSID.

Корпоративный Wi-Fi с помощью точек доступа Ubiquiti

Для этого создаем политику для Private vlan, которая проверяет, является ли пользователь членом доменной группы WIFI_PL_Private.

Корпоративный Wi-Fi с помощью точек доступа Ubiquiti

В условиях указываем регулярное выражение для Caller Station ID, позволяющее проверять SSID со всех точек в сети .*:PL_Private, а также проверку членства в группе.

Корпоративный Wi-Fi с помощью точек доступа Ubiquiti

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

Третья политика разрешает доступ к сети PL_Public для всех пользователей домена.

Вторая задача — гостевой портал для одноразовых паролей. Эта задача решается средствами самого контроллера UniFi.

Для сети PL_Guest определяем, что она является открытой и гостевой.

Корпоративный Wi-Fi с помощью точек доступа Ubiquiti

Во вкладке Guest Portal включаем Hotspot-аутентификацию, при желании кастомизируем стартовую страницу портала.

Корпоративный Wi-Fi с помощью точек доступа Ubiquiti

В настройках Hotspot включаем аутентификацию по ваучерам.

Корпоративный Wi-Fi с помощью точек доступа Ubiquiti

Нажав на ссылку Go to hotspot manager, генерируем ваучеры.

Корпоративный Wi-Fi с помощью точек доступа Ubiquiti

При попытке подключения к гостевой сети с телефона, видим приглашение ввести код ваучера:

Корпоративный Wi-Fi с помощью точек доступа Ubiquiti

После подключения видим в менеджере хотспота статистику.

Корпоративный Wi-Fi с помощью точек доступа Ubiquiti

Из VLAN, в котором находится гостевая сеть, должен быть доступ к UniFi контроллеру, так как портал крутится на нем.

Использованый материал

Настройка

Установку роли описывать не буду, существует 100500 статей в картинках, например: тыц

  1. Добавление радиус клиента на радиус-сервере Нам нужно заполнить “понятное имя”, IP адрес и придумать пароль (а.к.а. “секрет”), который понадобится при настройке аутентификатора (mikrotik в нашем случае)

    Корпоративный Wi-Fi на Ubiquiti с порталом и доменной аутентификацией —

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

    Политики имеют порядок и обрабатываются по нему одна за другой. Если подключение не соответствует условиям политики, то проверяется следущая и так далее. К примеру, это поможет разделить правила обработки для проводныхбеспроводных и впн клиентов. {.is-warning}

  1. Добавление политики запросов на подключение

  2. Добавление сетевой политики

Настройка клиентов


Начнем с самого сложного!

Некоторые типовые кейсы применения радиус сервера :

  1. централизованная аутентификация на устройствах поддерживающих aaa

  2. аутентификация для vpn (pptpl2tp)

  3. аутентификация в wifi

  4. аутентификация устройств при подключении к порту rj45 – dot802.1x

 Итак подробнее, некоторые плюшки.   Для всех наших пунктов нам нужно настроить радиус клиента в mikrotik

/radius add address=10.10.11.100 comment="PVE AD" secret=STRONG_SECRET_PASSWORD service=ppp,logi
n,hotspot,wireless,dhcp,ipsec,dot1x timeout=600ms

address –  Адрес радиус сервера secret – пароль, который мы совсем недавно настраивали для радиус клиента service – сервисы в mikrotik, которые могут использовать радиус для аутентификации.

Отдельно стоит отметить пункт timeout=600ms, если вы используете радиус через медленные каналы с большими задержками, стоит увеличить это значение.

Теперь можно начинать настраивать интересные вещи.

Немного о методах 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). Полностью не доработан

Из всего этого разнообразия, выбор все таки не велик. От метода аутентификации требовалось: хорошая безопасность, поддержка на всех устройствах (Windows 10, macOS, Linux, Android, iOS) и, собственно, чем проще, тем лучше. Поэтому выбор пал на EAP-TTLS в связке с протоколом PAP. Возможно возникнет вопрос — Зачем же использовать PAP? ведь он передает пароли в открытом виде?

О методах аутентификации

В предыдущих статьях, в частности: Особенности защиты беспроводных и проводных сетей. Часть 1 — Прямые меры защиты, — мы рассказывали о различных методах аутентификации.

Более или менее надёжным можно считать алгоритм защиты начиная с WPA2, а самый современный протокол аутентификации — WPA3, входящий в состав новшеств от WiFi 6. Но так как не все ещё перешли на WiFi 6, то WPA2 пока остаётся актуальным.

В свою очередь технология WPA2 подразделяется на два направления: WPA2 Personal и WPA2 Enterprise.

Вариант WPA2 Personal с PSK (Pre-Shared Key), проще говоря, «один-ключ-на все-устройства» используется в небольших (обычно в домашних сетях). При этом единственный ключ (длинная символьная строка не менее 8 символов) хранится на самой точке доступа и на каждом устройстве, подключаемом к беспроводной сети. Когда просят дать «пароль от WiFi», это тот самый ключ и есть.

При увеличении числа клиентов обслуживание такой беспроводной сети превращается в кошмар для сисадмина.

Если кто-то из пользователей со скандалом уволился, умудрился потерять ноутбук или случайно переслал ключ по почте (выложил общем чате, на форуме и так далее) …

В общем, при малейшем подозрении на компрометацию ключа выход может быть только один — сгенерировать новый ключ и заменить его везде: на всех точках доступа и у всех пользователей на всех устройствах. При этом нужно обязательно проверить работает ли доступ у всех пользователей на всех корпоративных (а иногда и личных) девайсах, а ещё ответить на 1000 и 1 вопрос из разряда: «А зачем?», «А почему так произошло?», «А что, теперь постоянно менять придётся?» и так далее и тому подобное.

Определение, назначение, общие сведения

RADIUS – это протокол, для авторизации, аутентификации и учёта (AAA).

Позволяет повысить безопасность сети и централизованно управлять доступами.

Сервер RADIUS может иметь свою базу данных с учетными данными (например файлы или mysql) или работать в паре с другим сервером, например Active Directory.

Кроме AAA позволяет передать некоторые дополнительные данные (настройки) клиенту прошедшему аутентификацию, в том числе vendor-specific attributes (VSA). У Mikrotik такие тоже есть, позже пройдемся по самым интересным.

Существуют много популярных приложений радиус сервера, самый популярные: freeRADIUS и Служба NPS (Network Policy Server) Windows Server. Более подробно мы рассмотрим второй вариант.

Перейдем к впн, и к стразу более интересному сценарию.

Предположим мы хотим отделить админов, от остальных работников. Выдадим админам профиль с подсетью которая будет иметь доступ к management vlan и не только, и выдадим отстальным сотрудникам профиль с подсетью которая будет меть ограниченый доступ только к 1c, RDP, etc.. . Предположим, мы используюем для впн l2tpipsec/ Для этого создадим в микротик два профиля в PPP -> profile

Причина всех бед

А причина всегда одна — безблагодатность. Оказывается, потому что

DOM3.LOCAL

работал в mixed-режиме, то на всех пользователях по-умолчанию на вкладке «Входящие звонки»/«Dial-in» атрибут «Разрешение на удаленный доступ (VPN или модем)» имеет значение «Запретить доступ», в отличие от

DOM2.LOCAL


Сменил режим работы домена

DOM3.LOCAL

на «native» и изменил на всех пользователях атрибут атрибут

«Разрешение на удаленный доступ (VPN или модем)»

на значение «Управление на основе политики удаленного доступа» (которое до смены режима работы домена было недоступно) следующим скриптом:

Проверка через ssh и winbox

Проверка подключения через SSH и экспорт конфигурации.

И проверяем авторизацию в Winbox.

Создание политики подключения

image

Подбираем подходящее название для политики.

Определяем наше устройство с которым будет работать сервер.

Я выбрал только Client Friendly Name со значением Router01. Это четко привязывает данный пункт политики к устройству через созданного клиента. Можно идентифицировать устройство Mikrotik по Identity выбрав NAS Identifier.

Без предварительной конфигурации устройства Identity = MikroTik.

Дальнейшая настройка политики.

На этапе выбора протокола аутентификации достаточно выбрать нешифрованный (о чем получите предупреждение) PAP для SSH или шифрованный CHAP для WinBox. Я выбрал оба. Если есть необходимость использовать web версию, то достаточно включить MS-CHAPv2, в остальном всё аналогично.

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

На данном этапе я не стал ничего трогать.

Итоговые установки политики.

У меня не получилось воспроизвести это через PowerShell, даже стандартный example с technet’а. Буду признателен, если подскажете почему.

netsh nps add crp name = "Request Policy Router01" state = "ENABLE" processingorder = "1" policysource = "0" conditionid ="0x1020" conditiondata = "router01" profileid = "0x1025" profiledata = "0x1" profileid = "0x1009" profiledata = "0x1" "0x2" profileid = "0x1fb0" profiledata = "TRUE"

image

Выбираем нужный приоритет двигая выше или ниже пункт политики.

Создание политики сети

image

Назовем её Routers.

Как и прежде, нужно определить условия.

Точка доступа

В качестве клиента (точки доступа) — используется модель Zyxel NWA210AX. Это современное устройство, поддерживающее интеграцию в облачной системе Zyxel Nebula и обладающее массой других достоинств.

Несмотря на то, что NWA210AX поддерживает новые протоколы безопасности WiFi 6 и может использовать сервис аутентификации Nebula, в нашем случае она прекрасно выступит в качестве устройства доступа в сети WPA 2 Enterprise.

Корпоративный Wi-Fi на Ubiquiti с порталом и доменной аутентификацией —
Рисунок 2. Точка доступа NWA210AX.

Установка и настройка сервера radius

Перед установкой рекомендуется настроить файервольные правила, в частности, разрешить порты 1812, 1813, а также, если понадобиться, выполнить настройку SELinux. Нашей целью было показать взаимодействие с RADIUS, поэтому такие нюансы, как настройка сети, файервола, других средств безопасности выходят за рамки статьи и остаются за кадром. И мы сразу переходим к установке FreeRADIUS.

sudo install freeradius freeradius-utils -y

Обратите внимание, мы устанавливаем не только пакет freeradius, но и дополнительные инструменты freeradius-utils.

Из этого пакета нам понадобится утилита radclient для проверки пользователей.

После окончания установки настроим запуск сервиса при старте системы:

sudo systemctl enable radiusd

Для проверки запустим FreeRADIUS:

sudo systemctl start radiusd

Проверим его состояние:

sudo systemctl status radiusd

Пример ответа системы:

radiusd.service - FreeRADIUS high performance RADIUS server.
Loaded: loaded (/usr/lib/systemd/system/radiusd.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2021-02-04 13:36:11 EST; 7min ago
Process: 953 ExecStart=/usr/sbin/radiusd -d /etc/raddb (code=exited, status=0/SUCCESS)
Process: 872 ExecStartPre=/usr/sbin/radiusd -C (code=exited, status=0/SUCCESS)
Process: 821 ExecStartPre=/bin/sh /etc/raddb/certs/bootstrap (code=exited, status=0/SUCCESS)
Process: 810 ExecStartPre=/bin/chown -R radiusd.radiusd /var/run/radiusd (code=exited, status=0/SUCCESS)
Main PID: 970 (radiusd)
Tasks: 6 (limit: 12425)
Memory: 82.9M
CGroup: /system.slice/radiusd.service
└─970 /usr/sbin/radiusd -d /etc/raddb
Feb 04 13:36:10 localhost.localdomain systemd[1]: Starting FreeRADIUS high performance RADIUS server....
Feb 04 13:36:10 localhost.localdomain sh[821]: server.pem: OK
Feb 04 13:36:11 localhost.localdomain systemd[1]: Started FreeRADIUS high performance RADIUS server..

Дополнительно проверить можно командой:

sudo ps aux | grep radiusd

Ответ системы должен быть примерно таким:

root 7586 0.0 0.2 112716 2200 pts/1 R  01:28 0:00 grep --color=auto radiusd
radiusd 13320 0.0 1.5 513536 15420 ? Ssl Dec23 0:00 /usr/sbin/radiusd -d /etc/raddb

Для настройки нам понадобится только два конфигурационных файла из каталога /etc/raddb:

Установка роли nps


Имеем Windows Server 2022 Datacenter с уже установленным доменом.

Выбираем сервер, на котором будет разворачиваться роль. Microsoft не рекомендует делать это на контроллере домена, но в некоторых best practices для уменьшения задержек дают совет ставить именно на него. Добавляем роль Network Policy and Access Server вместе с management tools для настройки.

Install-WindowsFeature NPAS -IncludeManagementTools

image

Запускаем любым удобным способом админку NPS. Например, через менеджер серверов.

Регистрируем сервер NPS в AD.

netsh ras add registeredserver

image

Выводы

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

Если какой то из пунктов непонятен, пишите. попробую показать или помочь разобраться.

Если в статье нашли ошибки, неточности или знаете как сделать лучше тоже пишите.

Заключение

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

Похожее:  RADIUS аутентификация пользователей доверенного домена / Хабр

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *