2.5F Аутентификация30.11.2016 21:48

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

Хочу поделиться опытом по настройке 2.5 факторной аутентификации удаленных пользователей. Почему 2.5, думаю, вы поймете из содержания, если считать модель »1. Что знаю. 2. Что имею. 3. Кем являюсь» эталонной. Если заинтересовало, прошу!

Что нужно сделать попытался нарисовать на схеме:

4aa832b5d07f46b18747b7ebc3afb982.jpg

Вкратце: удаленный пользователь имеет 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 факторная аутентификация готова. Если я что-то забыл и у вас не завелось, пишите в комментариях, постараюсь помочь)

Комментарии (4)

  • 30 ноября 2016 в 17:13

    0

    ↑

    ↓

    >Добавляем к паролю код из приложения на телефоне (без пробелов) — 0.5 фактор

    К сожалению, это всё тот-же фактор, что и токен. Фактор владения. С тем-же успехом можно 2 токена в компьютер втыкать. В чем смысл?

    • 30 ноября 2016 в 17:21

      0

      ↑

      ↓

      Спасибо за комментарий. Условно некоторые пользователи, нарушая инструкции, оставляют токены в USB включенными, и такая мера как одноразовый код из телефона, который (телефон) обычно все носят с собой и уделяют ему куда большее внимание чем «синей, фиолетовой, красной» непонятной «плюшке», все же, думаю помогает в защите от «дурачка».

  • 30 ноября 2016 в 17:20

    0

    ↑

    ↓

    У вас задача задолбать пользователя количеством окошек для ввода разных данных, что ли?

    И с факторами непонятно что получилось. Аутентификация с токена УЖЕ двухфакторная — первым фактором является сам физический токен, вторым — запомненный пин-код. Логин-пароль в AD тут ничего не добавляет (при аутентификации в AD сертификаты наоборот применяют для того, чтобы пользователю НЕ НАДО было вводить логин-пароль в силу низкой безопасности этого метода).

    • 30 ноября 2016 в 17:26

      0

      ↑

      ↓

      Нет задачи «задолбать» пользователей, есть задача минимизации рисков. По поводу терминологии — вы правы, но хотелось бы этапы разделить по технологии, поэтому так и написано.

© Habrahabr.ru