Выполнение 2FA через Freeradius с нашим собственным приложением 2FA - PullRequest
0 голосов
/ 05 апреля 2020

Некоторые данные DATA:

  • Freeradius v3.0.17
  • Active Directory как LDAP
  • OTP-приложение, разработанное нами самим

Чего мы хотим добиться, так это 2FA через Freeradius. Мы используем аутентификацию с ntlm_auth для MS AD, и с другой стороны, у нас есть собственный OTP-скрипт (это работает в другом решении). Сначала у нас есть политика, которая разделяет USER и Token, как это -> username: OTP. Это работает. Этот процесс вызывается в верхней части раздела авторизации на сайте по умолчанию

on policy.d/pol_usernamemultiotp.authorize:

pol_usernamemultiotp.authorize {
if ( &User-Name =~ /^(.*):([0-9]{6})$/) {
                update request {
                        Stripped-User-Name := "%{1}"
                        User-OTP := "%{2}"
                }
        }
}

ntlm_auth работает правильно. Когда мы добавляем следующий код в раздел авторизации по умолчанию, аутентификация переходит к типу аутентификации: = LDAP и не будет выполняться через ntlm_auth.

    update control {
          Auth-Type := `/bin/bash /etc/freeradius/3.0/otpIB.sh '%{Stripped-User-Name}' '%{User-OTP}' '%{Client-IP-Address}'`
   }

   (this script returns "Accept" or "Reject" depending if the OTP is correct.)

Мы также пытаемся поместить этот элемент управления обновлением в раздел после авторизации по умолчанию. НО, вот проблема. Давайте покажем вам с журналами де Freeradius -X

(0) mschap: Program returned code (0) and output 'NT_KEY: C1964544A5B93877F0D3FE7D9E5791D0'
(0) mschap: Adding MS-CHAPv2 MPPE keys
(0)     [mschap] = ok
(0)   } # authenticate = ok
(0) # Executing section post-auth from file /etc/freeradius/3.0/sites-enabled/default
(0)   post-auth {
(0)     update control {
(0)       Executing: /bin/bash /etc/freeradius/3.0/otpIB.sh '%{Stripped-User-Name}' '%{User-OTP}' '%{Client-IP-Address}':
(0)       EXPAND %{Stripped-User-Name}
(0)          --> fdelfranco
(0)       EXPAND %{User-OTP}
(0)          --> 770355
(0)       EXPAND %{Client-IP-Address}
(0)          --> 10.40.9.3
(0)       Program returned code (0) and output 'Reject'
(0)       Auth-Type := Reject
(0)     } # update control = noop
(0)     update {
(0)       No attributes updated
(0)     } # update = noop
(0)     policy remove_reply_message_if_eap {
(0)       if (&reply:EAP-Message && &reply:Reply-Message) {
(0)       if (&reply:EAP-Message && &reply:Reply-Message)  -> FALSE
(0)       else {
(0)         [noop] = noop
(0)       } # else = noop
(0)     } # policy remove_reply_message_if_eap = noop
(0)   } # post-auth = noop
(0) Sent Access-Accept Id 195 from 10.40.9.99:1812 to 10.40.9.3:21481 length 0
(0)   MS-CHAP2-Success 0xf9533d36433832463034413330323043344533314246333736383533364234324641453142383843383145
(0)   MS-MPPE-Recv-Key = 0x66e467b713b84475fa5ed19d93207ef3
(0)   MS-MPPE-Send-Key = 0x75f6cbee712186fe6ebeca98ea9ab063
(0)   MS-MPPE-Encryption-Policy = Encryption-Allowed
(0)   MS-MPPE-Encryption-Types = RC4-40or128-bit-Allowed
(0) Finished request

NTLM_AUTH отлично работает и дает и Access-Accept, полностью игнорируя скрипт и Auth-Type: = Reject, который возвращает!

Почему Radius игнорирует состояние «отклонить» из сценария и авторизует пользователя ??

Некоторые предложения?

Редактировать:

Сегодня Нам удалось получить эту вещь работает без проблем, но работает. Мы создаем как новый тип Auth, и помещаем туда политику таким образом, когда мы делаем parte Authorize, он вызывает этот псевдо-тип Auth в разделе Authenticate файла Defaul, а затем, после этого, делает вызов для нашего собственная политика, где мы указали наш собственный сценарий оболочки, который правильно выполняет проверку одноразового пароля.

Он отлично работает с клиентом Cisco VPN, Forti Client и с собственным клиентом Ma c для IPSE C.

1 Ответ

0 голосов
/ 18 апреля 2020

Auth-Type должен быть установлен на reply, а не control.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...