Мне было поручено настроить freeRADIUS, чтобы запрашивать у пользователя второй фактор аутентификации (например, Google Authenticator OTP), НО без предварительной проверки пароля пользователя.
Я вхожу в это совершенно слепым, без опыта работы с RADIUS. У нас есть веб-приложение, которое предлагает пользователю войти в систему, поэтому аутентификация по паролю уже выполнена. Затем нам нужно запросить у пользователя второй фактор аутентификации, чтобы выполнить определенные действия. Мы не хотим постоянно просить пользователя ввести свой пароль (а кэширование его локально, по-видимому, запрещено), поэтому мы хотели бы как-то настроить freeRADIUS так, чтобы он:
Это вообще возможно? Как я уже сказал, у меня нет предыдущего опыта работы с RADIUS, поэтому извиняюсь, если это глупый вопрос.
Я сам в этом разобрался. Если кому интересно, это связано с настройкой в /etc/pam.d/radiusd
Во-первых, следуйте одному из этих руководств, чтобы настроить Google Authenticator в качестве второго фактора на вашем сервере freeRADIUS:
https://networkjutsu.com/freeradius-google-authenticator/ https://www.supertechguy.com/help/security/freeradius-google-auth/
Когда дело доходит до внесения изменений в /etc/pam.d/radiusd, используйте одну из следующих конфигураций:
Чтобы запросить пароль И Google Auth OTP:
реквизит аутентификации pam_google_authenticator.so forward_pass
требуется авторизация pam_unix.so use_first_pass
требуется учетная запись pam_unix.so audit
необходим аккаунт pam_permit.so
Чтобы запросить ТОЛЬКО для Google Auth OTP (т.е. без пароля):
требуется авторизация pam_google_authenticator.so
требуется учетная запись pam_unix.so audit
необходим аккаунт pam_permit.so
Обратите внимание, что это не отправляет ответ на запрос - это просто означает, что пароль не нужно вводить в первую очередь.
Radius - это сетевой протокол аутентификации / авторизации / учета. Он работает на уровне 3 модели OSI.
Ваше веб-приложение работает на уровне 7.
Так что здесь есть небольшая ошибка. Вы можете использовать Radius для аутентификации сетевых подключений, таких как Wi-Fi или сетевые порты, но вам нужно что-то на основе http для вашего веб-приложения.
Я делаю некоторые предположения, но похоже, что у вас есть сервер Radius для аутентификации пользователей в вашей сети, и вы использовали ту же базу данных пользователей для аутентификации пользователей в вашем веб-приложении. Независимо от того, использует ли веб-приложение протокол Radius для аутентификации пользователей, ваши пользователи не говорят на Radius, когда они вводят имя пользователя и пароль на веб-страницу, поэтому Radius не собирается вам в этом помогать - это нужно делать в веб-приложение.
Если ваше веб-приложение имеет доступ к RADIUS-серверу, возможно, можно будет определить, какой пользователь аутентифицирован, и на основе этого авторизовать запрос / OTP, но это логика веб-приложения. Никакая конфигурация FreeRadius не может сделать это за вас.
Поэтому я бы рекомендовал сделать шаг назад и подумать, где хранятся ваши пользовательские данные. Хотя вы можете проходить аутентификацию на сервере freeRadius, Radius - это всего лишь протокол, а на сервере есть база данных пользователей. Это может быть сервер LDAP, база данных SQL, pam или просто текстовый файл.
Предполагая, что у вас есть общая база данных пользователей, вы можете добавить какое-то приложение единого входа Oauth / SAML (Okta и PingID - некоторые коммерческие примеры) в поток аутентификации каждой службы, чтобы вход в одном месте выполнялся эффект в другом. При наличии единого входа вы можете либо изменить свое веб-приложение, чтобы в определенных точках потребовать второй фактор (он должен знать существующий секрет OTP пользователя, или вы можете потребовать, чтобы они установили другой для этой цели), либо вы можете использовать какая-то политика и повторная аутентификация, если используемая вами технология SSO поддерживает это.
В заключение, я не вижу способа сделать это только в freeRadius, и даже если бы вы могли, вероятно, не стоит. И чтобы выполнить часть авторизации, вам всегда нужно будет модифицировать приложение, если только вы не реализуете какой-нибудь ужасный прокси-сервер посредника, который полностью ставит под угрозу безопасность.