Pull to refresh

Comments 17

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

я правильно понимаю что в данной реализании нельзя сделать 2 разных группы доступа так, чтобы они могли отрабатываться и одновременно(мог зайти юзер с группой для RDP и другой группой для SSH)?

Sign up to leave a comment.

Articles