2.5F Аутентификация

Привет, привет! Поздравляю всех причастных с днем ИБэшника )

Хочу поделиться опытом по настройке 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

Из опыта появлявшихся ошибок, мне было бы удобнее настраивать в следующем порядке:

1. RADIUS
2. Google
3. SSSD
4. PAM
5. 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»

Когда все готово можно протестировать:

1. После запуска AnyConnect появится окно eToken PKI Client
2. Выбираем свой сертификат. Вводим пароль от контейнера — 1 фактор
3. Далее вводим учетные данные пользователя AD (логин+пароль) — 2 фактор
4. Добавляем к паролю код из приложения на телефоне (без пробелов) — 0.5 фактор

2.5 факторная аутентификация готова. Если я что-то забыл и у вас не завелось, пишите в комментариях, постараюсь помочь )

Автор: kimssster

Источник