Freeradius + Google Autheticator + LDAP + Fortigate

  • Tutorial
Как быть, если двухфакторной аутентификации и хочется, и колется, а денег на аппаратные токены нет и вообще предлагают держаться и хорошего настроения.

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

Итак, дано


Домен Active Directory.

Пользователи домена, работающие через VPN, как многие нынче.

В роли шлюза VPN выступает Fortigate.

Сохранение пароля для VPN-клиента запрещено политикой безопасности.

Политику Fortinet в отношении собственных токенов менее чем жлобской не назовешь — бесплатных токенов аж 10 единиц, остальные — по очень некошерной цене. RSASecureID, Duo и им подобные не рассматривал, поскольку хочется опенсорса.

Предварительные требования: хост *nix с установленным freeradius, sssd — введен в домен, доменные пользователи могут спокойно на нем аутентифицироваться.

Дополнительные пакеты: shellinabox, figlet, freeeradius-ldap, шрифт rebel.tlf с репозитория https://github.com/xero/figlet-fonts.

В моем примере — CentOS 7.8.

Логика работы предполагается такая: при подключении к VPN пользователь должен ввести доменный логин и OTP вместо пароля.

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


В /etc/raddb/radiusd.conf меняется только пользователь и группа, от имени которых стартует freeradius, так как сервис radiusd должен уметь читать файлы во всех поддиректориях /home/.

user = root
group = root

Чтобы можно было использовать группы в настройках Fortigate, нужно передавать Vendor Specific Attribute. Для этого в директории raddb/policy.d создаю файл со следующим содержимым:

group_authorization {
    if (&LDAP-Group[*] == "CN=vpn_admins,OU=vpn-groups,DC=domain,DC=local") {
            update reply {
                &Fortinet-Group-Name = "vpn_admins" }
            update control {
                &Auth-Type := PAM
                &Reply-Message := "Welcome Admin"
                }
        }
    else {
        update reply {
        &Reply-Message := "Not authorized for vpn"
            }
        reject
        }
}

После установки freeradius-ldap в директории raddb/mods-available создается файл ldap.

Нужно создать символьную ссылку в каталог raddb/mods-enabled.

ln -s /etc/raddb/mods-available/ldap /etc/raddb/mods-enabled/ldap

Привожу его содержимое к такому виду:

ldap {
        server = 'domain.local'
        identity = 'CN=freerad_user,OU=users,DC=domain,DC=local'
        password = "SupeSecretP@ssword"
        base_dn = 'dc=domain,dc=local'
        sasl {
        }
        user {
                base_dn = "${..base_dn}"
                filter = "(sAMAccountname=%{%{Stripped-User-Name}:-%{User-Name}})"
                sasl {
                }
                scope = 'sub'
        }
        group {
                base_dn = "${..base_dn}"
                filter = '(objectClass=Group)'
                scope = 'sub'
                name_attribute = cn
                membership_filter = "(|(member=%{control:Ldap-UserDn})(memberUid=%{%{Stripped-User-Name}:-%{User-Name}}))"
                membership_attribute = 'memberOf'
        }
}

В файлах raddb/sites-enabled/default и raddb/sites-enabled/inner-tunnel в секции authorize дописываю имя политики, которая будет использоваться — group_authorization. Важный момент — имя политики определяется не названием файла в директории policy.d, а директивой внутри файла перед фигурными скобками.
В секции authenticate в этих же файлах нужно раскомментировать строку pam.

В файле clients.conf прописываем параметры, с которыми будет подключаться Fortigate:

client fortigate {
    ipaddr = 192.168.1.200
    secret = testing123
    require_message_authenticator = no
    nas_type = other
}

Конфигурация модуля pam.d/radiusd:

#%PAM-1.0
auth       sufficient   pam_google_authenticator.so
auth       include      password-auth
account    required     pam_nologin.so
account    include      password-auth
password   include      password-auth
session    include      password-auth

Дефолтные варианты внедрения связки freeradius с google authenticator предполагают ввод пользователем учетных данных в формате: username/password+OTP.

Представив количество проклятий, которое посыпется на голову, в случае использования дефолтной связки freeradius с Google Authenticator, было принято решение использовать конфигурацию модуля pam так, чтобы проверять только лишь токен Google Authenticator.

При подключении пользователя происходит следующее:

  • Freeradius проверяет наличие пользователя в домене и в определенной группе и, в случае успеха, производится проверка OTP токена.

Все выглядело достаточно удачно до момента, пока я не задумался «А как же произвести регистрацию OTP для 300+ пользователей?»

Пользователь должен залогиниться на сервер с freeradius и из-под своей учетной записи и запустить приложение Google authenticator, которое и сгенерирует для пользователя QR-код для приложения. Вот тут на помощь и приходит shellinabox в комбинации с .bash_profile.

[root@freeradius ~]# yum install -y shellinabox

Конфигурационный файл демона находится в /etc/sysconfig/shellinabox.
Указываю там порт 443 и можно указать свой сертификат.

[root@freeradius ~]#systemctl enable --now shellinaboxd

Пользователю остается лишь зайти по ссылке, ввести доменные креды и получить QR-код для приложения.

Алгоритм следующий:

  • Пользователь логинится на машину через браузер.
  • Проверяется доменный ли пользователь. Если нет, то никаких действий не предпринимается.
  • Если пользователь доменный, проверяется принадлежность к группе администраторов.
  • Если не админ, проверяется настроен ли Google Autheticator. Если нет, то генерируется QR-код и logout пользователя.
  • Если не админ и Google Authenticator настроен, то просто logout.
  • Если админ, то опять проверка Google Authenticator. Если не настроен, то генерируется QR-код.

Вся логика выполняется с использованием /etc/skel/.bash_profile.

cat /etc/skel/.bash_profile
# .bash_profile

# Get the aliases and functions
if [ -f ~/.bashrc ]; then
        . ~/.bashrc
fi

# User specific environment and startup programs
# Make several commands available from user shell

if [[ -z $(id $USER | grep "admins") || -z $(cat /etc/passwd | grep $USER) ]]
  then
    [[ ! -d $HOME/bin ]] && mkdir $HOME/bin
    [[ ! -f $HOME/bin/id ]] && ln -s /usr/bin/id $HOME/bin/id
    [[ ! -f $HOME/bin/google-auth ]] && ln -s /usr/bin/google-authenticator $HOME/bin/google-auth
    [[ ! -f $HOME/bin/grep ]] && ln -s /usr/bin/grep $HOME/bin/grep
    [[ ! -f $HOME/bin/figlet ]] && ln -s /usr/bin/figlet $HOME/bin/figlet
    [[ ! -f $HOME/bin/rebel.tlf ]] && ln -s /usr/share/figlet/rebel.tlf $HOME/bin/rebel.tlf
    [[ ! -f $HOME/bin/sleep ]] && ln -s /usr/bin/sleep $HOME/bin/sleep
  # Set PATH env to <home user directory>/bin
    PATH=$HOME/bin
    export PATH
  else
    PATH=PATH=$PATH:$HOME/.local/bin:$HOME/bin
    export PATH
fi


if [[ -n $(id $USER | grep "domain users") ]]
  then
    if [[ ! -e $HOME/.google_authenticator ]]
      then
        if [[ -n $(id $USER | grep "admins") ]]
          then
            figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"
            sleep 1.5
            echo "Please, run any of these software on your device, where you would like to setup OTP:
Google Autheticator:
AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605
Play Market - https://play.google.com/stor/apps/details?id=com.google.android.apps.authenticator2&hl=en
FreeOTP:
AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395
Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=en

And prepare to scan QR code.

"
            sleep 5
            google-auth -f -t -w 3 -r 3 -R 30 -d -e 1
            echo "Congratulations, now you can use an OTP token from application as a password connecting to VPN."
          else
            figlet -t -f $HOME/bin/rebel.tlf "Welcome to Company GAuth setup portal"
            sleep 1.5
            echo "Please, run any of these software on your device, where you would like to setup OTP:
Google Autheticator:
AppStore - https://apps.apple.com/us/app/google-authenticator/id388497605
Play Market - https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2&hl=en
FreeOTP:
AppStore - https://apps.apple.com/us/app/freeotp-authenticator/id872559395
Play Market - https://play.google.com/store/apps/details?id=org.fedorahosted.freeotp&hl=en

And prepare to scan QR code.

"
            sleep 5
            google-auth -f -t -w 3 -r 3 -R 30 -d -e 1
            echo "Congratulations, now you can use an OTP token from application as a password to VPN."
            logout
        fi
      else
        echo "You have already setup a Google Authenticator"
        if [[ -z $(id $USER | grep "admins") ]]
          then
          logout
        fi
    fi
  else
    echo "You don't need to set up a Google Authenticator"
fi


Настройка Fortigate:


  • Создаем Radius-сервер

  • Создаем необходимые группы, в случае необходимости разграничения доступа по группам. Имя группы на Fortigate должно соответствовать группе, которая передается в Vendor Specific Attribute Fortinet-Group-Name.

  • Редактируем необходимые SSL-порталы.

  • Добавляем группы в политики.



Плюсы данного решения:
  • Есть возможность аутентификации по OTP на Fortigate опенсорс решением.
  • Исключается ввод доменного пароля пользователем при подключении по VPN, что несколько упрощает процесс подключения. 6-цифровой пароль ввести проще, чем тот, который предусмотрен политикой безопасности. Как следствие, уменьшается количество тикетов с темой: «Не могу подключиться к VPN».

P.S. В планах докрутить это решение до полноценной двухфакторной авторизации с challenge-response.

Update:


Как и обещал, докрутил таки до варианта с challenge-response.
Итак:
В файле /etc/raddb/sites-enabled/default секция authorize выглядит следующим образом:

authorize {
    filter_username
    preprocess
    auth_log
    chap
    mschap
    suffix
    eap {
        ok = return
    }
    files
    -sql
    #-ldap
    expiration
    logintime
    if (!State) {
        if (&User-Password) {
            # If !State and User-Password (PAP), then force LDAP:
            update control {
                Ldap-UserDN := "%{User-Name}"
                Auth-Type := LDAP
            }
        }
        else {
            reject
        }
    }
    else {
        # If State, then proxy request:
        group_authorization
    }
pap
}

Секция authenticate теперь имеет следующий вид:

authenticate {
        Auth-Type PAP {
                pap
        }
        Auth-Type CHAP {
                chap
        }
        Auth-Type MS-CHAP {
                mschap
        }
        mschap
        digest
        # Attempt authentication with a direct LDAP bind:
        Auth-Type LDAP {
        ldap
        if (ok) {
            update reply {
                # Create a random State attribute:
                State := "%{randstr:aaaaaaaaaaaaaaaa}"
                Reply-Message := "Please enter OTP"
                }
            # Return Access-Challenge:
            challenge
            }
        }
        pam
        eap
}

Теперь проверка пользователя происходит по следующему алгоритму:
  • Пользователь вводит доменные креды в VPN-клиенте.
  • Freeradius проверяет валидность учетной записи и пароль
  • Если пароль верный, то отправляется запрос на токен.
  • Происходит проверка токена.
  • Профит).
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 16

    0
    двухфакторной аутентификации… хочется

    Логика работы предполагается такая: при подключении к VPN пользователь должен ввести доменный логин и OTP вместо пароля.

    А что выступает вторым фактором?
      0

      Доменный пароль пользователя

        0
        Который где? У пользователя на домашнем компе сохранён и вводится автоматом — вроде нет, политикой запрещено сохранение паролей…
        Пока вижу только упрощение доменного пароля до 6 цифр, которые постоянно меняются, т.е. это не совсем упрощение пароля, но тем не менее…

        Почему не раздать всем сертификаты без всяких логинов/паролей и раз в 1-3-6-месяцев их менять?..
          0

          Смарт карты с ключами конечно лучше, это не отрицается, но предложенный подход с OTP на VPN и доменным паролем далее весьма интересен. Гораздо лучше доменного пароля на VPN и несколько удобнее доменного пароля + OTP на VPN, именно потому что доменный в таком случае может требовать двойного ввода и неизбежно вызывает тягу его сохранить или упростить...

            0
            Данная реализация позволяет только сократить количество обращений в техподдержку, о чёс, впрочем, прямо написано в статье.
            А тягу сохранить и упростить вполне решают уже имеющиеся политики, как я понимаю.
            Про смарт-карты с ключами — вообще не понял, зачем сразу в крайности-то?
      0

      В ВПН клиенте запрещено сохранение пароля. В данном варианте вместо доменного пароля используется токен ОТП.

        0
        Если это ответ на мой вопрос, то можете, пожалуйста, конкретизировать, что у вас первый и второй фактор? У вас именно вместо пароля используется OTP? Тогда у вас один фактор — something that you have. Вторым мог бы служить пароль блокировки (screen lock) на телефоне (something that you know), но необходимо тогда гарантировать его наличие и автоматическую блокировку по timeout и выключению экрана, а для этого нужен MDM в каком-то виде, хоть Exchange policy, в статье про это ни слова.

        Ну или можно вернуть стандартную конкатенацию доменный пароль+OTP, которую вы убрали, не просто так к этому решению в настройках по умолчанию пришли.
          0

          Согласен, я не совсем корректно указал, что это решение — двухфакторная реализация. Над полноценной двухфакторной я ещё работаю. Тут больше была мысль убрать ввод пароля пользователем и заменить его на более простую вариацию.

            0
            OTP в случае Google Authenticator — это something that you know
            это пароль, только передаётся не в открытом виде
            эдакий CHAP с ручным приводом
              0

              Позволю себе не согласиться с Вами. Любой токен, будь то программный или аппаратный, — это все же "something that you have". Аппаратные и программные FortiTokens точно так же генерируют 30-секундный пароль.

                +1
                В том-то и дело, что не любой.
                Неизвлекаемый ключ, который генерируется прямо в токене — это that you have.
                А всё, что туда записывается извне — это that you know.

                И сам Google свой Authenticator позиционирует как инструмент двухэтапной, а не двухфакторной аутентификации.
                  0

                  Понял, да, Вы правы.

                    0

                    Только что перепроверил. Тогда и Fortinet со своим FortiTokens mobile лукавит, поскольку приложение работает по такому же принципу как и Google Authenticator.

          0
          Спасибо за публикацию. Проблема актуальная. Согласен что не совсем двухфакторная, но и то вперед. Попробовал настроить так же. Есть некоторые проблемы.
          1. Если на Centos юзер ни разу не заходил, то выдается ошибка об отсутствии Home directory.
            0
            Правильно, именно для этого и используется запуск freeradius от root, а в /etc/skel/.bash_profile внесены изменения, чтобы пользователь один раз зашел по вебу на сервер с радиусом и получил QR-код.
              0
              2. Почему то более менее все заработало, если указать в Fortigate соединение с Radius через PAP. В остальных вариантах всегда не подходит пароль.
              3. Непонятно как работает сам Google Authentificator. Мне непонятно сработал он правильно или нет, но после ввода ОТР получаю Permission Denied. Может быть с группами что-то не то просто.

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое