Хочу поделиться опытом по настройке 2.5 факторной аутентификации удаленных пользователей. Почему 2.5, думаю, вы поймете из содержания, если считать модель «1. Что знаю. 2. Что имею. 3. Кем являюсь» эталонной. Если заинтересовало, прошу!
Что нужно сделать попытался нарисовать на схеме:
Вкратце: удаленный пользователь имеет eToken (Alladin), учетку в Active Directory, входящую в определенную группу и одноразовый пароль из мобильного приложения Google Authenticator. Ему нужно успешно подключиться к некоторому сервису.
На Хабре есть статья, в которой описаны основные моменты по настройке CISCO ASA, AnyConnect, Google Auth и Freeradius. Дублировать смысла не вижу, все практически так, за исключением следующего.
Рекомендую установить утилиты RADIUS сервера для тестирования командой radtest и дебага radiusd -X
yum install freeradius freeradius-utils
Из опыта появлявшихся ошибок, мне было бы удобнее настраивать в следующем порядке:
- RADIUS
- SSSD
- PAM
- CISCO
Но как обычно не все так просто и по порядку. На github нужные нам компоненты Google лежат тут «The pluggable authentication module (PAM) is in a separate project.» При установке могут возникнуть различного рода ошибки, тут надо читать и доустанавливать, если необходимо инструменты разработчиков и библиотеки (gcc, libqrencode и т.п.).
Теперь, что не вышло (может и вышло, но он решил не писать об этом) у автора статьи, приведенной выше.
Для возможности использования учетных записей из AD необходимо установить SSSD и компоненты.
yum install sssd realmd adcli
Далее добавляем RADIUS сервер в домен:
realm join ваш_домен
Разрешаем доступ пользователям из заранее опреденной группы в AD:
realm permit -g ваша_группа_из_AD
На данном этапе может возникнуть проблема с именем домена (.ru, .net, .test и т.п.) Записи 1 уровня могут не определяться, соответственно имя вашего домена может быть неполным, это повлияет на процесс аутентификации и конфигурацию RADIUS сервера.
В моем случае это выглядело так username@domain, где domain это только имя 2 уровня. К чему это может привезти? Вы просто не сможете успешно аутентифицироваться, если не закомментировать следующие строки в файле /etc/raddb/policy.d/filter
# if ((&User-Name =~ /@/) && (&User-Name !~ /@(.+)\\.(.+)$/)) {
# update reply {
#Reply-Message += "Rejected: Realm does not have at least one dot separator"
# }
# reject
# }
Иначе введенные вами данные будут отфильтрованы, как ошибочные. Для того чтобы создать доменному пользователю Google Authenticator делаем следующее:
su – domain_user@domain
google-authenticator
Этот пользователь должен быть членом группы, которую мы указали выше командой realm permit.
На этом этапе тоже возникают проблемы, механизмы безопасности не дадут создать домашнюю директорию для нового пользователя. Эта директория необходима для файла ~google-authenticator, в котором содержится информация с кодами верификации и ключом для каждого пользователя.
Чтобы это исправить необходимо компонент SELinux перевезти в разрешительный режим:
setenforce permissive
Далее нужно перейти в /etc/pam.d/radiusd и записать следующий конфиг:
#%PAM-1.0
auth requisite pam_google_authenticator.so forward_pass
auth required pam_sss.so use_first_pass
account required pam_nologin.so
account include password-auth
session include password-auth
Не забудьте про NTP и синхронизируйте время, иначе одноразовые пароли работать не будут, а в файле /var/log/secure будет сообщение «invalid code»
Когда все готово можно протестировать:
- После запуска AnyConnect появится окно eToken PKI Client
- Выбираем свой сертификат. Вводим пароль от контейнера — 1 фактор
- Далее вводим учетные данные пользователя AD (логин+пароль) — 2 фактор
- Добавляем к паролю код из приложения на телефоне (без пробелов) — 0.5 фактор
2.5 факторная аутентификация готова. Если я что-то забыл и у вас не завелось, пишите в комментариях, постараюсь помочь )
Комментарии (7)
ildarz
30.11.2016 17:20+1У вас задача задолбать пользователя количеством окошек для ввода разных данных, что ли?
И с факторами непонятно что получилось. Аутентификация с токена УЖЕ двухфакторная — первым фактором является сам физический токен, вторым — запомненный пин-код. Логин-пароль в AD тут ничего не добавляет (при аутентификации в AD сертификаты наоборот применяют для того, чтобы пользователю НЕ НАДО было вводить логин-пароль в силу низкой безопасности этого метода).
kimssster
30.11.2016 17:26Нет задачи «задолбать» пользователей, есть задача минимизации рисков. По поводу терминологии — вы правы, но хотелось бы этапы разделить по технологии, поэтому так и написано.
ildarz
01.12.2016 10:26А «минимизация рисков» у вас не такое же красивое слово, как про «эталонную модель», которая не имеет никакого отношения к вашему случаю? Чтобы риски минимизировать, для начала их надо правильно оценить. Общепринятый в индустрии подход — аутентификация по сертификату на токене ВМЕСТО парольной, а не ВМЕСТЕ с ней. Вы бы задумались, почему так, а не просто строили решение на основании пролетарского чутья.
xforce
>Добавляем к паролю код из приложения на телефоне (без пробелов) — 0.5 фактор
К сожалению, это всё тот-же фактор, что и токен. Фактор владения. С тем-же успехом можно 2 токена в компьютер втыкать. В чем смысл?
kimssster
Спасибо за комментарий. Условно некоторые пользователи, нарушая инструкции, оставляют токены в USB включенными, и такая мера как одноразовый код из телефона, который (телефон) обычно все носят с собой и уделяют ему куда большее внимание чем «синей, фиолетовой, красной» непонятной «плюшке», все же, думаю помогает в защите от «дурачка».
Deosis
А почему нельзя использовать RFID токен?
Пользователь носит его в кармане, а компьютер считывает его на расстоянии в один метр.
Как только П отошел, проверка токена не срабатывает.
Так намного удобнее. Не нужно доставать, потом убирать обратно.
kimssster
Технология интересная и ее можно использовать, но нужно устройство считывания, а в данном случае еще все это надо на удаленных (или домашних) компах, что не очень вписывается