Зачем и почему это?
Так сложились обстоятельства, что мне пришлось администрировать уже настроенную RADIUS аутентификацию пользователей одного доверенного домена на узле Mikrotik, который либо пропускал в интернет пользователей, либо нет. Раньше такого настраивать не приходилось, был в распоряжении просто уже готовый настроенный «черный ящик».
Как сделать чтобы заработало?
Вижу цель — не вижу препятствий. Создаю двустороннее доверие DOM1.LOCAL с DOM3.LOCAL (win2003). Создаю в DOM3.LOCAL глобальную группу allow_internet, включаю туда пользователей.
Причина = Не удается установить подключение из-за отказа в разрешении на удаленный доступ для учетной записи пользователя. Чтобы разрешить удаленный доступ, включите такое разрешение для учетной записи пользователя или, если в ней указано, что управление доступом осуществляется с помощью соответствующей политики удаленного доступа, включите разрешение на удаленный доступ для этой политики.
И т.к. недостаток моих знаний не позволил мне понять, что собственно тут-то и кроется ответ, начались изыскания. Никаких следов в логах на контроллерах доменов DOM3.LOCAL или DOM1.LOCAL от этого события не было. Гугл по такой ошибке выдает вообще что-то к делу не относящееся (сплошной RDP).
Поиск в групповых политиках на «рабочем» DOM2.LOCAL ничего не дал. Я даже попробовал проксирование RADIUS запросов, подняв на DC.DOM3.LOCAL также службу проверки подлинности в интернете и трансляцию туда запросов с именем пользователя вида «DOM3*». Тем не менее в логе прокси-RADIUS сервера была точно такая же ошибка и отказ в доступе.
Dot1x
Зачем нужен dot1X и как его настроить.. очень много интересных слов можно было бы тут написать, но все сказано до нас. Например на канале одного прекрасного тренера или wiki
Половина смысла с саркальной точки зрения в dot1x в том, что в случае успешной проверки подлинности наше устройство попадет в влан указанный нами в микротике или в влан который мы поличим в качестве атрибута у радиуса. Если проверка подлинности пройдет с отказом или ответ не будет получен от радиуса (например в случае его недоступности), то порт перейдет в изолироованный режим (будет заблокирован любой трафик на порту) или в случае если указан Reject VLAN ID то попадет в влан, для которого мы настроили(я надеюсь все таки настроили) максимально безопасные правила форейвола для чужеродных устройств .
Начнем с микротика:
Настроим политики сети: В условиях необходимо отобрать проводные клиенты
Параметры аутентификации:
В настройках атрибутами выдадим рабочий влан
К примеру вот так выглядит отказ в авторизации:
А вот так успешное подключение:
Radius server на базе winsrv 2022 для mikrotik
В данной статье опишу конфигурацию Радиус сервера, для подключения к нему Mikrotik в качестве клиента.
Данная функция полезна, если у вас есть собственный домен на базе Active Directory, и вы не хотите каждый раз заводить VPN пользователей в ручную. Так же с помощью RADIUS сервера, можно настроить аутентификацию непосредственно на сам Mikrotik с помощью доменных учеток или аутентификацию на Wi-Fi
В общем, штука полезная.
Во время написания статьи все указанные настройки проводил на Windows Server 2022, но думаю она так же актуальна и для Windows Server 2022
Первое что нам нужно — сам Windows Server, в данной статье не описываю его установку. Думаю, раз вы дошли до этого материала, то развернуть WinSrv и выполнить базовую настройку Mikrotik вы в состоянии.
К делу.
Переходим к добавлению компонентов
- Диспетчер серверов — Добавить роли и компоненты
- Далее — Установка Ролей и Компонентов — Выбрать целевой сервер — Службы политики сети и доступы — (Копмпоненты) Далее — Установить
После установки переходим к настройке:
- Средства — сервер политики сети
- ПКМ на NPS — Зарегистрировать сервер в Active Directory
- ПКМ на RADIUS-клиенты — Новый документ
- Устанавливаем флаг «Включит этот RADIUS-клиент»
- Понятное имя — Указываем понятное имя
- Адрес (IP или DNS) — указываем IP адрес или DNS имя Mikrotik.
- Общий секрет — Генерируем и сохраняем себе секретный ключ для обмена Mikrotik и RADIUS-сервера. Или используйте свой вариант ключа.
- Развернуть политики — пкм на «Сетевые политики» — Создать новый документ
Задаем имя политики
- Далее — Тип порта NAS — Асинхронная (модем)
- Далее — Оставляем только Service-Type = Login
- На последнем окошке проверяем что указали правильные параметры и нигде не ошиблись. Клацаем Готово
- Настраиваем Брандмауэр
- Правила для входящих подключений — Предопределенные — Сервер политики сети
- Выбираем правила с портами 1813/udp и 1812/udp
- Далее — Разрешить подключение.
Переходим к настройке Mikrotik
- PPP — Secrets — PPP Authentication & Accounting – Use Radius
- Переходим в меню Radius и устанавливаем адрес сервера и секретный ключ
На этом настройка завершена. Теперь для подключения VPN можно использовать доменную учётку.
Другие стати по теме:
Авторизация через radius на mikrotik с подстановкой локальной группы
Всем доброго дня! Я работаю начинающим сетевым администратором в крупной федеральной компании со смешанной сетью, cisco, mikrotik, juniper.
И вот однажды появилась следующая задача.
Исходные данные:
1. Есть региональный системный администратор, у которого в подчинении несколько системных администраторов. У каждого системного администратора есть РУ — региональный узел, где головными устройствами стоят 2 Mikrotik 1100ahx2 и cisco c3550, по магазинам — MikroTik RB751G-2HnD.
2. На каждом Микротике заведена локальная группа с именем, совпадающем с городом: Омск — OMS, Кемерово — KMR, с полными правами на Микротик.
Задача:
Сделать авторизацию регионального администратора через Radius только в пределах своей зоны ответственности, допустим OMS и KMR.
Задача есть, пробуем выполнять.
Настраиваем Radius на Микротике:
/radius add service=login address=10.0.x.10 secret=xxx disabled=no
/user aaa set use-radius=yes
Устанавливаем FreeRadius на Linux, у меня был Debian: apt-get install freeradius
У меня подсеть на Микротиках 172.16.0.0/12,
пишем в /etc/freeradius/clients.conf
client 172.16.0.0/12 {
secret = xxx
shortname = Network_Devices
}
Затем, не забываем /etc/freeradius/dictionary
VENDOR Mikrotik 14988
BEGIN-VENDOR Mikrotik
ATTRIBUTE Mikrotik-Recv-Limit 1 integer
ATTRIBUTE Mikrotik-Xmit-Limit 2 integer
ATTRIBUTE Mikrotik-Group 3 string
ATTRIBUTE Mikrotik-Wireless-Forward 4 integer
ATTRIBUTE Mikrotik-Wireless-Skip-Dot1x 5 integer
ATTRIBUTE Mikrotik-Wireless-Enc-Algo 6 integer
ATTRIBUTE Mikrotik-Wireless-Enc-Key 7 string
ATTRIBUTE Mikrotik-Rate-Limit 8 string
ATTRIBUTE Mikrotik-Realm 9 string
ATTRIBUTE Mikrotik-Host-IP 10 ipaddr
ATTRIBUTE Mikrotik-Mark-Id 11 string
ATTRIBUTE Mikrotik-Advertise-URL 12 string
ATTRIBUTE Mikrotik-Advertise-Interval 13 integer
ATTRIBUTE Mikrotik-Recv-Limit-Gigawords 14 integer
ATTRIBUTE Mikrotik-Xmit-Limit-Gigawords 15 integer
ATTRIBUTE Mikrotik-Wireless-PSK 16 string
ATTRIBUTE Mikrotik-Total-Limit 17 integer
ATTRIBUTE Mikrotik-Total-Limit-Gigawords 18 integer
ATTRIBUTE Mikrotik-Address-List 19 string
ATTRIBUTE Mikrotik-Wireless-MPKey 20 string
ATTRIBUTE Mikrotik-Wireless-Comment 21 string
ATTRIBUTE Mikrotik-Delegated-IPv6-Pool 22 string
# MikroTik Values
VALUE Mikrotik-Wireless-Enc-Algo No-encryption 0
VALUE Mikrotik-Wireless-Enc-Algo 40-bit-WEP 1
VALUE Mikrotik-Wireless-Enc-Algo 104-bit-WEP 2
VALUE Mikrotik-Wireless-Enc-Algo AES-CCM 3
VALUE Mikrotik-Wireless-Enc-Algo TKIP 4
END-VENDOR Mikrotik
Все, теперь нам нужно создать пользователя в /etc/freeradius/users:
regSA User-password :=12345
Auth-Type = CHAP,
Mikrotik-Group := OMS
Перезапускаем FreeRadius и пробуем зайти на омские Микротики. Все работает.
Но теперь пробуем зайти на кемеровские. Получаем группу read, с правами только на чтение. В чем дело? Смотрим лог на Микротике и видим:
В активных пользователях:
Ты забыл прописать группу для Кемерова, скажете вы. Прописываем:
regSA User-password :=12345
Auth-Type = CHAP,
Mikrotik-Group := OMS, KMR
Рестартим freeradius. Пробуем, получаем тоже самое. Получается, что для одного пользователя мы можем указать только одну группу. Потому что при авторизации всегда берется первая указанная. Тупик? Нет, пара часов гугла, исследование FreeRadius и нахожу выход.
В radiusd.conf есть обработчик post-auth, решаю попробовать использовать его.
Пишем:
post-auth {
if (User-Name == «regSA») { проверяем имя пользователя
if (NAS-IP-Address =~ /172.22.(2(2[4-9]|[3-4][0-9]|5[0-5])).([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))/) { и проверяем IP
update reply {
Mikrotik-Group := «OMS» если все сошлось, то выдаем микротику группу, которая на нем есть
}
}
if (NAS-IP-Address =~ /172.20.(6[4-9]|[7-8][0-9]|9[0-5]).([0-9]|[1-9][0-9]|1([0-9][0-9])|2([0-4][0-9]|5[0-5]))/) {
update reply {
Mikrotik-Group := «KMR»
}
}
}
} закрываем весь post-auth
NAS-IP-Address — это IP адрес с которого прилетает запрос на авторизацию. Используется регулярка, но так как я с ними на ВЫ, то использовал для генерации сайт www.analyticsmarket.com/freetools/ipregex
Теперь в /etc/freeradius/users: убираем группу, как абсолютно лишний для нас атрибут
regSA User-password :=12345
Auth-Type = CHAP
После рестарта FreeRadius понимаем, что у нас все работает, что на омские микротики регионал попадает с группой OMS, на кемеровские — с KMR.
Почему нельзя было в users поставить Mikrotik-Group := «full»? Можно было, но тогда региональный сисадмин получил доступ ко всем Микротикам по всей России, что конечно же нехорошо. Такие права есть только у избранных.
Благодарности:
Спасибо @aslancherkesov за злого редактора и свежий взгляд на буквы.
Диагностика
Не всегда наши настройки сразу работают так как надо, иногда что то идет не так, и очень хочется понять что именно. Для того что бы понять в чем причина у нас есть :
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
Тест:
Как оно работает?
Итак, начал смотреть как это все работает в текущей схеме. На первый (да и не первый тоже) взгляд все по учебнику:
- На неком компьютере домена AUTHSRV.DOM1.LOCAL (win2003), поднята «Служба проверки подлинности в интернете».
- В ней прописан клиент — Mikrotik, с общим секретом.
- Домен DOM1.LOCAL (win2008) имеет двустороннее доверие с DOM2.LOCAL (win2003).
- В DOM2.LOCAL создана глобальная группа allow_internet, в которую добавлены пользователи, которые должны успешно проходит аутентификацию на Mikrotik.
- На компьютере AUTHSRV.DOM1.LOCAL создана локальная группа allow_internet, в которую включена глобальная группа доверенного домена DOM2.LOCALallow_internet.
- Соответственно в настройках службы проверки подлинности создана политика удаленного доступа, разрешающая доступ, если пользователь входит в группу AUTHSRVallow_internet.
Все выглядит логично и действительно работает как ожидается.
Компоненты кейса
Суппликант – устройство которое намерено пройти процедуру авторизации и аутентификации.
Аутентификатор – устройство к которому подключается суппликант, которое получает у суппликанта данные авторизации и которое проверяет их на RADIUS сервере. NB! Является клиентом для радиус-сервера.
RADIUS сервер (он же радиус сервер, он же сервер аутентификации).
Настройка
Установку роли описывать не буду, существует 100500 статей в картинках, например: тыц
Добавление радиус клиента на радиус-сервере Нам нужно заполнить “понятное имя”, IP адрес и придумать пароль (а.к.а. “секрет”), который понадобится при настройке аутентификатора (mikrotik в нашем случае)
Политики запросов на подключение и Стетевые политики очень похожи при настройке, и нужно понимать разницу между ними. Первые нужны для того что бы при определенных условиях определить сервер на котором будет проходить проверка аутентификации клиента (к примеру локально или на другом удаленном радиус сервере) а так же для некоторых манипуляций с атрибутами.
Политики имеют порядок и обрабатываются по нему одна за другой. Если подключение не соответствует условиям политики, то проверяется следущая и так далее. К примеру, это поможет разделить правила обработки для проводныхбеспроводных и впн клиентов. {.is-warning}
Добавление политики запросов на подключение
Добавление сетевой политики
Некоторые типовые кейсы применения радиус сервера :
централизованная аутентификация на устройствах поддерживающих aaa
аутентификация для vpn (pptpl2tp)
аутентификация в wifi
аутентификация устройств при подключении к порту 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, если вы используете радиус через медленные каналы с большими задержками, стоит увеличить это значение.
Теперь можно начинать настраивать интересные вещи.
Определение, назначение, общие сведения
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 или модем)» на значение «Управление на основе политики удаленного доступа» (которое до смены режима работы домена было недоступно) следующим скриптом:
Set objOU = GetObject(“LDAP://dc=DOM3,dc=local”)
Выводы
RADIUS в сетевой среде очень полезен в плане безопасности и удобен в плане централизованного управления. Настраивать не так уж и сложно, главное читать, понимать документацию и логи.
Если какой то из пунктов непонятен, пишите. попробую показать или помочь разобраться.
Если в статье нашли ошибки, неточности или знаете как сделать лучше тоже пишите.