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