WiFi Enterprise. FreeRadius + FreeIPA + Ubiquiti
Уже были описаны некоторые примеры организации корпоративного WiFi. Здесь я распишу как реализовал подобное решение и проблемы с которыми пришлось столкнуться при подключении на разных устройствах. Будем использовать уже имеющийся LDAP с заведенными пользователями, поднимем FreeRadius и настроим WPA2-Enterprise на контроллере Ubnt. Вроде все просто. Посмотрим…
Немного о методах EAP
Прежде чем приступить к выполнению задачи, надо определиться какой метод аутентификации будем использовать в нашем решении.
EAP — фреймворк аутентификации, который часто используется в беспроводных сетях и соединениях точка-точка. Формат был впервые описан в RFC 3748 и обновлён в RFC 5247.
EAP используется для выбора метода аутентификации, передачи ключей и обработки этих ключей подключаемыми модулями называемыми методами EAP. Существует множество методов EAP, как определенных вместе с самим EAP, так и выпущенных отдельными производителями. EAP не определяет канальный уровень, он только определяет формат сообщений. Каждый протокол использующий EAP имеет собственный протокол инкапсуляции сообщений EAP.
Да, все верно. Общение между FreeRadius и FreeIPA будет проходить именно в так. В режиме дебага можно отследить как отправляются username и password. Да и пусть отправляются, только у вас есть доступ к серверу FreeRadius.
Подробнее о работе EAP-TTLS можно почитать тут
FreeRADIUS
FreeRadius будем поднимать на CentOS 7.6. Здесь ничего сложного, ставим обычным способом.
Из пакетов ставится версия 3.0.13. Последнюю можно взять на https://freeradius.org/
После этого FreeRadius уже работает. Можно в /etc/raddb/users расскоментировать строчку
Запустить в сервер в режиме дебага
И делаем тестовое подключение с localhost
Получили ответ Received Access-Accept Id 115 from 127.0.0.1:1812 to 127.0.0.1:56081 length 20, значит все хорошо. Идем дальше.
Подключаем модуль ldap.
И сразу его изменим. Нам нужно, чтобы FreeRadius мог обращаться к FreeIPA
Перезапускаем radius-сервер и проверяем синхронизацию пользователей LDAP:
Редактируем eap в mods-enabled/eap
Здесь добавим два экземпляра eap. Они будут отличаться только сертификатами и ключами. Чуть ниже объясню, почему именно так
Далее редактируем site-enabled/default. Интересуют разделы authorize и authenticate.
В секции authorize убираем все модули, которые нам не нужны. Оставляем только ldap. Добавляем проверку клиента по username. Именно для этого мы добавляли выше два экземпляра eap.
Далее нужно прописать в политиках, какие имена можно использовать для анонимного входа. Редактируем policy.d/filter.
Нужно найти строчки похожие на это:
И ниже в elsif добавить нужные значения:
Теперь нам нужно переместиться в директорию certs. Сюда нужно положить ключ и сертификат от доверенного центра сертификации, который у нас уже есть и нужно сгенерировать самоподписанные сертификаты для eap-guest.
Изменяем параметры в файле ca.cnf.
Такие же значения прописываем в файле server.cnf. Меняем только
commonName:
Готово. Полученные server.crt и server.key у нас уже прописаны выше в eap-guest.
И последнее, добавим наши точки доступа в файл client.conf. У меня их 7. Чтобы не добавлять каждую точку отдельно, пропишем только сеть в которой они находятся (у меня точки доступа находятся в отдельном VLAN).
Контроллер Ubiquiti
Прописываем адрес и порт radius-сервера и пароль, который прописывали в файле clients.conf:
Создаем новое имя беспроводной сети. В качестве метода аутентификации выбираем WPA-EAP (Enterprise) и указываем созданный radius-профиль:
Все сохраняем, применяем и идем дальше.
Настройка клиентов
Начнем с самого сложного!
Windows 10
Сложность сводится к тому, что Windows пока еще не умеет подключаться к корпоративному WiFi по домену. Поэтому приходится вручную закидывать наш сертификат в хранилище доверенных сертификатов. Здесь можно использовать как самоподписанный так и от центра сертификации. Я буду использовать второй.
Вручную прописываем имя сети и меняем тип безопасности. После нажимаем на изменить параметры подключения и во владке Безопасность выбираем проверку подлинности сети — EAP-TTLS.
Заходим в параметры, прописываем конфиденциальность аутентификации — client. В качестве доверенного центра сертификации выбираем добавленный нами сертификат, ставим галочку «Не выдавать пользователю приглашение, если не удается авторизовать сервер» и метод проверки подлинности выбираем — незашифрованный пароль (PAP).
Далее заходим в дополнительные параметры, ставим галочку на «Укажите режим проверки подлинности». Выбираем пункт «Проверка подлинности пользователя» и нажимаем на сохранить учетные данные. Здесь надо будет ввести username_ldap и password_ldap
Все сохраняем, применяем, закрываем. Можно подключаться к новой сети.
Linux
Я проверял на Ubuntu 18.04, 18.10, Fedora 29, 30.
Для начала, скачиваем себе сертификат. Я не нашел в Linux, есть ли возможность использовать системные сертификаты и есть ли там вообще такое хранилище.
Будем подключаться по домену. Поэтому нужен сертификат удостоверяющего центра, у которого был приобретен наш сертификат.
Все подключение делается в одном окне. Выбираем нашу сеть:
anonymous — client
domain — домен, на который выпущен сертификат
Android
non-Samsung
C 7 версии при подключении WiFi можно использовать системные сертификаты, указав только домен:
domain — домен, на который выпущен сертификат
anonymous — client
Samsung
Как уже писал выше, Samsung-устройства не умеют использовать системные сертификаты при подключении WiFi, и у них нет возможности подключаться по домену. Поэтому надо вручную добавить корневой сертификат центра сертификации (ca.pem, берем на Radius сервере). Вот здесь будет использовать самоподписанный.
Скачиваем сертификат себе на устройство и устанавливаем его.
При этом, надо будет установить рисунок разблокировки экрана, пин-код или пароль, если он еще не установлен:
Я показал сложный вариант установки сертификата. На большинстве устройств достаточно просто нажать на скаченный сертификат.
Когда сертификат установлен, можно переходить к подключению:
сертификат — указываем тот, который устанавливали
анонимный пользователь — guest
macOS
Здесь указываем имя своей сети
Security Type — WPA2 Enterprise
Accepted EAP Types — TTLS
User Name и Password — оставляем пустыми
Inner Authentication — PAP
Outer Identity — client
Вкладка Trust. Здесь указываем наш домен
Все. Профиль можно сохранять, подписывать и распространять на устройства
Процесс аналогичен macOS. Нужно использовать профиль (можно прям такой же как для macOS. Как создавать профиль в Apple Configurator, смотреть выше).
Скачиваем профиль, устанавливаем, вводим учетные данные, подключаемся:
На этом все. Мы настроили Radius сервер, синхронизировали его с FreeIPA и указали точкам доступа Ubiquiti использовать WPA2-EAP.
Возможные вопросы
В: как передавать профиль/сертификат сотруднику?
О: Все сертификаты/профили я храню на фтп с доступом через веб. Поднял гостевую сеть с ограничением по скорости и доступом только в интернет, за исключением фтп.
Аутентификация держится 2 дня, после чего сбрасывается и клиент остается без интернета. Т.о. когда сотрудник хочет подключиться к WiFi, сначало он подключается к гостевой сети, заходит на фтп, скачивает нужный ему сертификат или профиль, устанавливает их, и после может подключаться к корпоративной сети.
В: почему не использовать схему с MSCHAPv2? она же более безопасная!
О: во-первых, такая схема хорошо работает на NPS (Windows Network Policy System), в нашей реализации необходимо дополнительно настраивать LDAP (FreeIpa) и хранить хэши паролей на сервере. Доп. настройки делать не желательно, т.к. это может привести к различным проблемам сихронизации УЗ. Во-вторых, хеш представляет собой MD4, так что это не особо повышает безопасность
В: можно ли авторизовывать устройтсва по mac-адресам?
В: зачем вообще все эти сертификаты использовать? можно же и без них подключаться
О: сертификаты используются, чтобы авторизовать сервер. Т.е. устройство при подключении проверяет тот ли это сервер, которому можно доверять или нет. Если тот, то аутентификация проходит дальше, если нет, соединение закрывается. Можно подключаться без сертификатов, но если злоумышленик или сосед поднимет у себя дома radius-сервер и точку доступа с таким же именем как у нас, он сможет легко перехватить учетные данные пользователя (не забываем, что они передаются в открытом виде). А когда используется сертификат, враг увидит у себя в логах только наши вымышленные User-Name — guest или client и ошибку типа — Unknown CA Certificate
Inner-tunnel
This virtual server handles only inner tunnel requests for EAP-TTLS and PEAP types.
This next section allows testing of the «inner-tunnel» authentication methods. The testing is independent from the «default» server. The example listener here is configured to accept packets only sent from localhost, to localhost.
Note: There are no accounting requests inside of EAP-TTLS or PEAP tunnels.
If the above test works, then the inner tunnel has been configured correctly. To check if PEAP will work, use the following:
If the above command works, then PEAP should work. If not, then fix the inner tunnel configuration so that it works.
Note: Do not run any PEAP tests. It won’t help. Instead, concentrate on fixing the inner tunnel configuration. Do nothing else.
Authorization.
First preprocess (hints and huntgroups files), then realms, and finally look in the «users» file.
The order of the realm modules determines the order in which a matching realm is searched.
Make sure that ‘preprocess’ comes before any realm if hint setup is required for the remote radius server.
When an MS-CHAP-Challenge attribute is used for authentication at user login, the mschap module finds the MS-CHAP-Challenge attribute and adds Auth-Type := MS-CHAP to the request. This addition causes the server to use the mschap module for authentication.
The module below pulls crypt’d passwords from `/etc/passwd or /etc/shadow using the system APIs to get the password. To read /etc/passwd or /etc/shadow directly, see the passwd module.
The following looks for IPASS style ‘realm/’ and, if not found, looks for ‘@realm’ and decides whether or not to proxy based on those results.
When using multiple kinds of realms, it is prudent to set ignore_null = yes for all of them. Otherwise, if the first style of realm doesn’t match, the other styles won’t be checked.
Note: proxying the inner tunnel authentication means that the user may use one identity in the outer session (e.g., «anonymous») and a different one here (e.g., «user@example.com»). The inner session will then be proxied elsewhere for authentication. If this section is not set up correctly, then the user’s actions may cause the authentication to be forwarded to another RADIUS server but the accounting logs would not be sent to the other server. This makes it difficult to bill people for their network activity.
The «suffix» module takes strips the domain (e.g., «@example.com») from the User-Name attribute, and the next few lines ensure that the request is not proxied.
To proxy the inner tunnel request, delete the next few lines.
This module takes care of EAP-MSCHAPv2 authentication.
It also sets the EAP-Type attribute in the request attribute list to the EAP type from the packet.
This section reads the ‘users’ file.
This section looks in an SQL database. The schema of the database is meant to mirror the ‘users’ file.
See also «Authorization Queries» in sql.conf
The dash before the module name below is so that the server will start if the module is not configured.
When using /etc/smbpasswd in combination with mschap authentication, uncomment this line and enable the smbpasswd module.
The ldap module reads passwords from the LDAP database.
The dash before the module name below is so that the server will start if the module is not configured.
The following enforces daily limits on time spent logged in.
This module should be listed last so that the other modules get a chance to set Auth-Type for themselves.
Authentication
In general, manually setting the Auth-Type attribute is not recommended. The server will usually figure it out on its own and will use the correct authentication method. The most common side effect of erroneously setting the Auth-Type attribute is that one authentication method will work but the others will not.
The common reasons to set the Auth-Type attribute by hand are to either forcibly reject the user ( Auth-Type := Reject ) or forcibly accept the user ( Auth-Type := Accept ).
The following provides PAP authentication when a back-end database listed in the authorize section supplies a password. The password can be clear-text or encrypted.
Most people want CHAP authentication.
For CHAP authentication, back-end databases listed in the authorize section must supply a Cleartext-Password attribute; encrypted passwords won’t work.
Pluggable Authentication Modules (pam).
To use ldap for authentication, uncomment the following line.
Note: uncommenting this line means «check plain-text password against the ldap database». When uncommenting this line, be aware that EAP won’t work, as it does not supply a plain-text password.
The following is a session database that is used for checking Simultaneous-Use. Either the radutmp or sql module can handle this section.
Note: The sql module is much faster than radutmp.
See «Simultaneous Use Checking Queries» in sql.conf
Post-Authentication
Once it is known that the user has been authenticated, there are additional steps that can be taken.
Note that the last packet of the inner-tunnel authentication may not be the last packet of the outer session. So updating the outer reply might or might not work. The exact functionality depends on both the inner and outer authentication methods.
If a reply attribute needs to be sent in the outer session, then the only safe way to send it is to set use_tunneled_reply = yes and then to update the inner-tunnel reply.
For privacy to remain, see the Chargeable-User-Identity attribute from RFC 4372.
To use it, just uncomment the line below.
To have a log of authentication replies, uncomment the following line and enable the detail reply_log module.
After authenticating the user, this section does another SQL query.
See «Authentication Logging Queries» in sql.conf
The dash before the module name below is so that the server will start if the module is not configured.
Instead of sending the query to the SQL server, the following writes it into a log file.
If edir_account_policy_check = yes has been set in the ldap module sub-section of the modules section, then uncomment the following.
These attributes are for the inner session only. They must not be sent in the outer reply.
Access-Reject packets are sent through the REJECT sub-section of the post-auth section.
The following adds the ldap module name (or instance) if edir_account_policy_check = yes has been set in the ldap module configuration.
log failed authentications in SQL, too.
The following lets the outer session know which module failed and why.
When the server proxies a request to a home server, that request is first passed through the pre-proxy stage. This stage can re-write the request or cancel the proxy.
Only a few modules currently have this method.
Uncomment the following line to change attributes as defined in the preproxy_users file.
Uncomment the following line to filter requests sent to remote servers based on the rules defined in the ‘attrs.pre-proxy’ file.
To have a log of packets proxied to a home server, uncomment the following line and the ‘detail pre_proxy_log’ section.
When the server receives a reply to a request it proxied to a home server, the request may be massaged here in the post-proxy stage.
To have a log of replies from a home server, uncomment the following line and the ‘detail post_proxy_log’ section.
Uncomment the following line to filter replies from remote proxies based on the rules defined in the ‘attrs’ file.
When proxying LEAP, the eap module must be configured and it must be listed here in the post-proxy stage.
The nostrip option must also be used in the realm configuration. Otherwise, the User-Name attribute in the proxied request will not match the user name hidden inside of the EAP packet, and the end server will reject the EAP request.
If the server tries to proxy a request and fails, then the request is processed through the modules in this section.
The main use of this section is to permit robust proxying of accounting packets. The server can be configured to proxy accounting packets as part of normal processing. Thus, if the home server goes down, accounting packets can be logged to a local «detail» file for processing with radrelay. When the home server comes back up, radrelay will read the detail file and send the packets to the home server.
With this configuration, the server always responds to Accounting-Requests from the NAS, but only writes accounting packets to disk if the home server is down.
FreeRADIUS, OpenLDAP и EAP/PEAP аутентификация
Приветствую. Прошу помощи, ибо совсем сломал мозг следующей задачей:
Необходимо реализовать процедуру аутентификации пользователей при коннекте к беспроводной сети и направление пользователя в указанный в аккаунте VLAN. Wi-Fi точка настроена на обращение к Radius’у, который, в свою очередь, должен запрашивать аккаунты у LDAP’а. Между Радиусом и точкой настроен протокол PEAP для аутентификации, а PEAP, в свою очередь, использует EAP-MSCHAPv2.
НО! На данный момент работает только схема, при которой аккаунт хранится в файле users на Радиусе. А забрать аккаунт с LDAP’а ни в какую не выходит. Выкладываю конфиги
radiusd.conf (не полностью, лишь значимую часть):
ldap.attrmap (также не полностью):
users (аутентификация именно для этого юзера работает прекрасно):
Логи в первом комменте.
Обращает на себя внимание следующий отрывок лога:
Как исправить ситуацию идей уже никаких нет.
Как исправить ситуацию идей уже никаких нет.
dump типичной записи пользователя из ldap сюда приложите пожалуйста.
А в каком виде хранится пароль?
Password values are octet strings.
checkItem Cleartext-Password userPassword
checkItem Cleartext-Password homeDirectory
В ldap в homeDirectory у vlan40 положите ваш пароль в чистом виде.
Да, Спасибо огромное!
Только вот интересно, в чем причина хранения userPassword’а в виде octetString, если это вызывает подобные проблемы? Придется занимать лишнее поле паролем.
в чем причина хранения userPassword’а в виде octetString, если это вызывает подобные проблемы?
В том, что хранить userpassword’ы в чистом виде приходит в голову только сумасшедшим людям.
Ну так настраиваем TLS и все, нет проблемы. Ладно, проблема решена, еще раз спасибо, zgen.
Ну так настраиваем TLS и все, нет проблемы
Ну так а что ж в shadow/passwd хеши хранят от паролей, а не пароли в чистом виде, раз нет проблемы? 😉
Нужна ваша помошь по настройке Freeradius
Срочно нужна ваша помощь.
Вобщем задача у меня один в один как ваша:
Необходимо реализовать процедуру аутентификации пользователей при коннекте к беспроводной сети и направление пользователя в указанный в аккаунте VLAN. Wi-Fi точка настроена на обращение к Radius’у, который, в свою очередь, должен запрашивать аккаунты у LDAP’а. Между Радиусом и точкой настроен протокол PEAP для аутентификации, а PEAP, в свою очередь, использует EAP-MSCHAPv2.
Еще даполнительно к этому(как буд-то этого не хватает) привязать Active Directory (win2008) как альтернативу LDAP.
А проблемма заключается в том что с линуксом я знаком всего месяца 4, препад-гад показал как файлы в консоли копировать и раздал задачи, типо «только в практике рождается умение».
Помио этого еще и в ПХП по ушы завалил со своим ZENDом.
еще одна проблема что нглицкая мова мне не дается 🙁
Так вот что меня интересует:
