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

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

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

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

Что такое аутентификация обхода mac?

Аутентификация обхода MAC: означает, что терминал не отвечает на запрос аутентификации 802.1X от устройства управления доступом после того, как терминал получает доступ к сети в среде аутентификации 802.1X. Чтобы облегчить доступ терминала к сети, устройство контроля доступа автоматически получает MAC-адрес терминала и отправляет его на сервер RADIUS в качестве учетных данных для доступа к сети для проверки.

Аутентификация обхода MAC имеет те же характеристики, что и аутентификация MAC.

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

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

DOM1.LOCALDOM3.LOCAL

(win2003). Создаю в

DOM3.LOCAL

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

allow_internet

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

AUTHSRVallow_internet

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

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

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

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

DOM3.LOCAL

или

DOM1.LOCAL

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

DOM2.LOCAL

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

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

DC.DOM3.LOCAL

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

Freeradius

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

yum install freeradius freeradius-utils freeradius-ldap -y

Linux

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

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

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

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

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

Non-samsung

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

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

Radius аутентификации | juniper networks

Samsung

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

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

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

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

Windows 10

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

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

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

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

В чем разница между аутентификацией mac и аутентификацией обхода mac:

Аутентификация MAC не относится к аутентификации 802.1X и применима к сценариям, когда тупые терминалы получают доступ к сети через MAC-адреса.

Аутентификация с помощью обхода MAC относится к аутентификации 802.1X. Она применима к сценариям, когда сотрудники и терминалы, которые не могут активно инициировать аутентификацию, получают доступ к сети. На этапе аутентификации 802.1X сотрудники завершают аутентификацию с помощью учетной записи и пароля. Для тупых терминалов MAC-адрес используется для доступа к сети после сбоя аутентификации 802.1X.

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

В:

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

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

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

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

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

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

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

Идеи конфигурации аутентификации обхода mac

Идеи конфигурации: 
 Переключить часть: 
dot1x  enable ------------Включить dot1x глобально
dot1x authentication-method eap  ---------метод аутентификации dot1x eap
int  xxx
	dot1x enable  ----------Включить dot1x
	dot1x mac-bypass -------Включить аутентификацию обхода MAC (переключить традиционный режим)

 Раздел переменного тока
1.  Настроить список устройств (MAC-адрес)

2.Настроить аутентификацию

3.Настроить авторизацию 
A.  Динамический ACL
B.Результаты авторизации
C.  Авторизоваться

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

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

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

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

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

Контроллер ubiquiti

На контроллере поднимаем отдельную сеть. Пусть будет 192.168.2.0/24

Идем в настройки -> профиль. Cоздаем новый:

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

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

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

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

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

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

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

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

Конфигурация части переменного тока:

1. Добавьте MAC-адрес терминала, который нуждается в MAC-аутентификации

2. Настройте правила аутентификации:

3. Настроить динамический acl.

4. Настройте результаты авторизации:

5. Настройте правила авторизации:

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

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

Немного о методах 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 вопрос из разряда: «А зачем?», «А почему так произошло?», «А что, теперь постоянно менять придётся?» и так далее и тому подобное.

Особенности mac-аутентификации:

1. На терминале не требуется устанавливать клиент аутентификации.

2. Терминалу не нужно вводить номер счета и пароль, а аутентификация выполняется автоматически.

3. Безопасность ниже, чем 802.1X и Portal.

   Причина более низкого уровня безопасности заключается в том, что MAC-адреса легко подделываются. Рекомендуется применять схему проверки подлинности MAC только к сетевым принтерам и IP-телефонам и открывать только те права доступа к сети, которые необходимы для развития бизнеса после получения разрешения.

Принцип аутентификации обхода mac:

Рисунок: процесс аутентификации обхода MAC

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

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

DOM3.LOCAL

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

DOM2.LOCAL

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

DOM3.LOCAL

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

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

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

Проверка подключения

Как уже было сказано выше, более или менее точно процесс установки беспроводной связи иллюстрирует интерфейс Mac OS Х.

После того, как в списке подключений нашли соответствующий пункт (по умолчанию он называется Zyxel), операционная система показывает окно ввода имени пользователя и пароля/ключа, хранящегося в системе RADIUS.

Рисунок 10. Запрос имени пользователя и пароля для входа в беспроводную сеть.

Далее происходит передача сертификата. В OS X об этом свидетельствует окно для подтверждения использования сертификата.

Рисунок 11. Окно проверки сертификата. Дополнительно нажата кнопка «Показать сертификат».

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

Процесс аутентификации mac:

Рисунок: блок-схема аутентификации MAC

1. Предварительное соединение устанавливается между клиентом и устройством перед аутентификацией.
2. Когда устройство обнаруживает любой из пакетов ARP / DHCP / ND / DHCPv6, отправленных пользователем, оно запускает аутентификацию MAC пользователя.
3. В соответствии с конфигурацией устройство отправляет имя пользователя и пароль на сервер аутентификации для аутентификации.
4. Сервер аутентификации проверяет полученные имя пользователя и пароль и отправляет успешный пакет аутентификации на устройство после успешной аутентификации. В то же время пользователи добавляются в свой онлайн-список пользователей.
5. После получения успешного пакета аутентификации устройство переводит интерфейс в авторизованное состояние, позволяя пользователям получать доступ к сети через интерфейс. В то же время пользователи добавляются в свой онлайн-список пользователей.

Сравнение аутентификации mac и аутентификации обхода mac

• Аутентификация MAC: Выполните аутентификацию MAC напрямую.
• Аутентификация обхода MAC: 802.1x во-первых, длительное отсутствие ответа (30S) без ответа, с использованием MAC в качестве пользователя и пароля для отправки аутентификации. Использовать с 802.1X

Сценарии применения аутентификации mac:

Аутентификация MAC применима к сценариям, в которых терминалы (такие как IP-телефоны, сетевые принтеры и камеры), которые не могут быть установлены с клиентом аутентификации, автоматически используют MAC-адрес в качестве пользователя и пароля для доступа к сети.

Сценарии применения обхода mac:

Аутентификация с обходом MAC применима к средам аутентификации 802.1X. Терминалы, которые не могут установить клиенты аутентификации 802.1X (также известные как тупые терминалы, такие как IP-телефоны, сетевые принтеры и камеры), используют MAC-адреса в качестве пользователей и пароли для автоматического доступа к сети. сцена.

Терминал активно выходит из системы и отключается:

Рисунок: клиент инициирует незарегистрированный запрос аутентификации

1. Клиент отправляет запрос на деавторизацию.
2. Устройство доступа отправляет пакет остановки учета (ACCOUNTING-REQUEST) на сервер RADIUS, останавливает авторизацию порта и удаляет пользователя из онлайн-списка.
3. Сервер RADIUS отправляет ответное сообщение об остановке учета (ACCOUNTING-RESPONSE) на устройство доступа и удаляет пользователя из онлайн-списка.

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

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

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

Рисунок 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:

Форма имени пользователя:

В зависимости от формата и содержимого имени пользователя, используемого устройством доступа для проверки личности пользователя, формат имени пользователя, используемый при аутентификации MAC, можно разделить на три типа:

• Формат MAC-адреса: устройство использует MAC-адрес пользователя в качестве имени пользователя для аутентификации и может использовать MAC-адрес или пользовательскую строку в качестве пароля.
• Форма фиксированного имени пользователя. Независимо от значения MAC-адреса пользователя все пользователи используют фиксированное имя пользователя и пароль, указанные на устройстве доступа, вместо MAC-адреса пользователя в качестве идентификационной информации для аутентификации. Поскольку несколько пользователей могут проходить проверку подлинности на одном и том же интерфейсе, все пользователи проверки подлинности MAC на интерфейсе используют одно и то же фиксированное имя пользователя для проверки подлинности. Серверу необходимо настроить только одну учетную запись пользователя, чтобы удовлетворить всех прошедших проверку пользователей. Требования к аутентификации. Это относится к сетевым средам, где клиентам доверяют больше.
• Формат опции DHCP: устройство аутентифицирует поле опции DHCP пользователя и фиксированный пароль вместо MAC-адреса пользователя в качестве идентификационной информации. Этот метод должен гарантировать, что устройство поддерживает аутентификацию MAC, запускаемую DHCP-пакетами.

Являются ли типы служб аутентификации обхода mac и аутентификации mac одинаковыми?

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

Заключение

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