Freeradius два фактора без фактора конкатенации
У меня есть маршрутизатор cisco, предоставляющий сервер SSL VPN, который общается с freeradius, который, в свою очередь, использует модули pam и два модуля pam (sss & yubico) для обеспечения двухфакторной аутентификации для VPN.
В мире все хорошо, и это работает, за исключением того, что для этого мне нужно объединить пароль пользователя и токен yubikey в один ответ. Мои пользователи предпочли бы двухэтапный пароль и ответ на вызов (в основном по причинам "слишком запутанным"). Можно ли это сделать?
На данный момент у меня есть один раздел конфигурации аутентификации радиуса, который определяет использование модуля радиуса PAM в качестве бэкэнда. Я очень плохо знаком с радиусом, но я думаю, что мог бы использовать модуль pam дважды в двух отдельных "фазах" и каждый раз давать разный pam_auth, так что используются два разных конфигурационных файла pam, каждый из которых находится на отдельном модуле pam (Мфу с одной, юбикей с другой)? Я бы полагался на pam дважды, потому что freeradius не поддерживает ни yubikey, ни sss из коробки (я знаю, что он поддерживает ldap, но я хочу, чтобы sss получал восстановление после сбоя записи DNS SRV и т. Д.).
Я не уверен, возможно ли это вообще, и мне не повезло найти где-нибудь документальное подтверждение?
У freeradius, очевидно, есть много конфигурационных файлов, но если они необходимы, я могу опубликовать их.
2 ответа
Попытавшись настроить Yubikey для этого в течение некоторого времени (но не с OpenVPN), я пришел к выводу, что, если это сработает, оно должно поддерживаться как приложением, так и PAM. То есть приложение должно знать, что нужно запрашивать три вещи (вместо обычных двух), а лежащая в основе библиотека PAM должна знать, что нужно ожидать, что ей будут переданы три вещи (и использовать их соответствующим образом).
У библиотеки yubikey PAM, кажется, нет такой поддержки, или, по крайней мере, она не была надежной, пока я все еще пытался сделать эту работу.
Вместо этого я решил перейти на использование yubikey в режиме OATH и обнаружил, что правильная трехфазная аутентификация намного лучше обрабатывается обоими sshd и основной pam_oath библиотека.
Я не могу сказать, поддерживает ли OpenVPN это лучше, так как я не пробовал, но вы можете рассмотреть его как вариант, если вы не можете заставить работать режим yubikey должным образом. Это имеет дополнительное преимущество: если кто-то из ваших пользователей по какой-то причине не может использовать yubikey (например, OpenVPN от конечной точки без USB-порта), существует ряд других реализаций OATH, которые можно использовать, например, на смартфоне для освобождения под залог. эти конкретные пользователи без необходимости полностью пересмотреть вашу двухфакторную инфраструктуру.
В случае, если вас это заинтересует, мою статью о sshd/yubikey/OATH/ двухфакторной / трехфазной аутентификации можно найти здесь.
Изменить: нет, под приложением я имел в виду OpenVPN. OpenVPN должен знать, что нужно (фактически) запрашивать два отдельных пароля и имя пользователя, а модуль PAM для поддержки должен знать, что он должен ожидать эти три токена и комбинировать их так, чтобы это было приемлемо для FreeRADIUS. Это почти несущественно, что это за согласованный метод, пока токены проверены; важно то, что клиентская сторона всего механизма аутентификации знает, как запрашивать и как обращаться с тремя разными токенами.
Попытка выкрутить свою собственную, подчиняя PAM вызову плагина RADIUS дважды, каждый раз с разными аргументами, и надеясь, что он каким-то волшебным образом выйдет при стирке, кажется мне обреченным на провал (а также чреват потенциальными пробелами в безопасности),
Мое более широкое представление о том, что вы с большей вероятностью найдете встроенное решение, использующее OATH, чем специфичные для yubikey обработчики токенов, поскольку я знаю из того, что я пытался, что специфичные для yubikey обработчики не выглядели как трехканальные подходы, предпочитая подход catenate-password-and-OTP (который мне тоже не нравится).
RADIUS предлагает ответ на вызов. То есть вы могли бы сначала предоставить пароль для сервера радиуса, сервер RADIUS проверил бы пароль, и, если пароль верный, не отвечайте повторно с Access-Accept, но с Access-Challenge. Затем клиент Radius (pam_module) запросит вторую аутентификацию, и значение OTP может быть отправлено на сервер RADIUS. Если вторая часть (значение OTP) была правильной, сервер RADIUS, наконец, ответил бы с ACCESS-Accept.
privacyIDEA предлагает ответ на вызов для нескольких OTP-токенов (HOTP, Yubikey) и модуль FreeRADIUS, поддерживающий ответ на вызов.
Глядя на код freeradius, похоже, что pam_radius_auth также поддерживает ответ на вызов, но я еще не тестировал его.