Настройка двухфакторной аутентификации в домене Astra Linux Directory / Хабр

Краткое введение

Для начала проведем небольшой ликбез по терминологии Kerberos и рассмотрим доступные реализации этого протокола в ОС на базе GNU/Linux. Сразу оговорюсь, что мне не удалось найти однозначного перевода терминов, использующихся в Kerberos, поэтому для избежания путаницы основные термины я буду дублировать на английском.

Итак, начнем. Если процитировать Википедию, то

Kerberos – сетевой протокол аутентификации, позволяющий передавать данные через незащищённые сети для безопасной идентификации. Ориентирован, в первую очередь, на клиент-серверную модель и обеспечивает взаимную аутентификацию – оба пользователя через сервер подтверждают личности друг друга.

Стоит отметить, что Kerberos в первую очередь является протоколом, а не конкретной системой аутентификации. Его реализации используются в различных операционных системах, в том числе и в Windows, как метод аутентификации пользователей в домене. Существует несколько open source реализаций протокола Kerberos, например оригинальная MIT Kerberos и Heimdal.

Немного вводных об astra linux directory (ald) и jacarta pki

Домен

Astra Linux Directory (ALD)

предназначен для организации единого пространства пользователей (домена локальной вычислительной сети) в автоматизированных системах.

ALD использует технологии LDAP, Kerberos5, Samba/CIFS и обеспечивает:

— это линейка PKI-токенов для строгой аутентификации пользователей в корпоративных системах, безопасного хранения ключевых контейнеров программных СКЗИ и цифровых сертификатов российского производителя – компании

В среде Astra Linux Directory (ALD) электронные ключи JaCarta PKI могут использоваться для двухфакторной аутентификации пользователя в домене ALD и отказа от паролей. Кроме того, с этими же электронными ключами можно выполнять различные сценарии внутри ОС, после аутентификации, такие, как: электронная подпись, хранение ключевых контейнеров, доступ к Web-ресурсам, проброс ключа в сессии MS Windows. Доступ к VDI сервисам, таким, как VmWare или Citrix.

Авторизация в домене ms windows server по ключам

Гораздо более сильным, чем пара логин/ пароль, способом регистрации сотрудника в информационной системе
фирмы являются электронные ключи-токены. Токен есть принципиально невзламываемый чип, который содержит подписанный
сертификат пользователя.

Домен Windows Server 2008/ 2003 поддерживает авторизацию по электронным ключам (при помощи
встроенного сервера сертификатов), причем для усиления безопасности такой способ авторизации может быть объявлен единственно
возможным – с запретом входа в систему по традиционной паре логин/ пароль. При этом вход по токену осуществляется как при
логине на персональный компьютер или терминал – участник домена Windows Server, так и при попытке авторизации на сервере в режиме терминального доступа.

При извлечении карты доступ к компьютеру или серверу немедленно блокируется, для повторного входа нужно набрать уникальный
пин-код. Сервер сертификатов, встроенный в любую версию MS Windows Server Standard и выше, осуществляет централизованное
управление выдачей цифровых сертификатов стандарта X.509 и их привязку к пользователям домена, позволяет устанавливать
сроки действия сертификатов, отзывать их и выпускать новые.

Ключи-токены выпускаются либо в виде USB-брелка, либо в виде смарт-карты, в последнем случае в компьютере или терминале
должен быть установлен специальный считыватель смарт-карт. Преимущество смарт-карты состоит в том, что в нее может быть
встроена RFID-метка, и карта становится универсальным средством доступа как в помещения фирмы,
так и в компьютерную сеть.

Некоторые модели ключей eToken поддерживают российиские алгоритмы шифрования и сертифицированы ФСБ России

WIT Company оказывает услуги по введению системы доступа к информационным ресурсам предприятия с помощью е-токенов и смарт карт фирмы Аладдин Р.Д.

Сервер сертификатов MS Windows Server 2008 – запрос сертификата:

Авторизация с помощью сертификата ssl на nginx let’s encrypt

# mkdir /etc/ssl/crm.example.ru
# cd /etc/ssl/crm.example.ru
# mkdir db
# mkdir db/certs
# mkdir db/newcerts
# touch db/index.txt
# echo "01" > db/serial
# chmod 700 ./

[ ca ]
default_ca             		= CA_CITENAME          	# Секция по умолчанию для подписи сертификатов

[ CA_CITENAME ]
droot                  		= /etc/ssl/crm.example.ru # Корневой каталог хранилища
dir                    		= $droot/db            	# Каталог базы хранилища
certs                  		= $dir/certs           	# Каталог сертификатов
new_certs_dir          		= $dir/newcerts        	# Каталог для новых сертификатов (pem)

database               		= $dir/index.txt       	# Файл базы сертификатов
serial                 		= $dir/serial          	# Файл серийного номера

# Файл доверенного сертификата
certificate            		= $droot/ca.crt
# Закрытый ключ доверенного сертификата
private_key            		= $droot/ca.key

default_days           		= 365                  	# Срок действия нового сертификата (дни)
default_crl_days       		= 7                    	# Срок действия списка отозванных сертификатов
default_md             		= md5                  	# Использовать алгоритм MD5

policy                 		= policy_citename      	# Политика секции

[ policy_citename ]
countryName            		= optional             	# Необязательный параметр
stateOrProvinceName    		= optional             	# .......................
localityName           		= optional             	# .......................
organizationName       		= optional             	# .......................
organizationalUnitName 		= optional             	# .......................
commonName             		= supplied             	# обязательный параметр
emailAddress           		= supplied             	# .....................

[ req_distinguished_name ]
countryName                     = Название страны (2-буквенный код)
countryName_default             = RU
countryName_min                 = 2
countryName_max                 = 2

stateOrProvinceName             = Название области (полное название)
stateOrProvinceName_default     = Tyumen region

localityName                    = Название местности (например, город)
localityName_default            = Tyumen

0.organizationName              = Название организации
0.organizationName_default      = EXAMPLE

organizationalUnitName          = Название организационной единицы (например, отдел)

commonName                      = Ваше имя
commonName_max                  = 64

emailAddress                    = Email адрес
emailAddress_max                = 64

# openssl req -new -newkey rsa:2048 -nodes -keyout ca.key -x509 -days 365 
-subj "/C=RU/ST=Tyumen region/L=Tyumen/O=EXAMPLE/OU=CRM/CN=crm.example.ru/[email protected]" 
-out ca.crt

# openssl req -new -newkey rsa:2048 -nodes -keyout ca.key -x509 -days 365 -out ca.crt

# openssl rsa -noout -text -in ca.key              (для ключа)
# openssl x509 -noout -text -in ca.crt             (для сертификата)

# openssl req -new -newkey rsa:2048 -nodes -keyout client01.key 
-subj "/C=RU/ST=Tyumen region/L=Tyumen/O=EXAMPLE/OU=CRM/CN=User example1/[email protected]" 
-out client01.csr

#openssl req -new -newkey rsa:2048 -nodes -keyout client01.key -out client01.csr

# openssl rsa -noout -text -in client01.key             (для ключа)
# openssl req -noout -text -in client01.csr             (для запроса)

# openssl ca -config ca.config -in client01.csr -out client01.crt -batch

# openssl pkcs12 -export -in client01.crt -inkey client01.key 
-certfile ca.crt -out client01.p12 -passout pass:123ewqasdcxz

# chmod 600 /etc/ssl/crm.example.ru/client*.crt
# chmod 600 /etc/ssl/crm.example.ru/client*.key

# mv ./client01.* db/certs/

            ssl_client_certificate      /etc/ssl/crm.example.ru/ca.crt;
            ssl_verify_client           on;
            ssl_verify_depth            1;

Базовые настройки

После установки пакетов на сервере нужно инициализировать realm командой

$ sudo krb5_newrealm

А на клиенте – обновить файлы конфигурации:

$ sudo dpkg-reconfigure krb5-config

Также на клиенте и сервере надо добавить следующие строки в /etc/krb5.conf:

Дальнейшие действия будем выполнять на клиенте

Отформатируем токен

На клиент надо поставить следующие пакеты:

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

На сервере:

Создадим ключевую пару и сертификат нашего «УЦ». Здесь мы сгененируем ключ УЦ и создадим самоподписанный сертификат с помощью openssl. В реальном мире ключ естественно надо надежно защитить от попадания в чужие руки.

$ openssl genrsa -out cakey.pem 2048 
# ...
$ openssl req -key cakey.pem -new -x509 -out cacert.pem
# ...

Создадим ключевую пару для KDC, заявку на сертификат и выпишем его сами себе.

Здесь нам потребуется специальный файл расширений OpenSSL (

), в котором будут указаны дополнительные поля сертификатов, используемых в Kerberos. В частности, мы зададим:

Настройка pam-аутентификации с использованием kerberos

Ранее при настройке клиентской машины мы поставили пакет libpam-krb5. Он поможет нам выполнить аутентификацию в Kerberos при входе в систему, а также в приложениях, использующих системную аутентификацию (например login, lightdm и проч.). Для подключения модуля PAM достаточно выполнить команду

$ sudo pam-auth-update

и выбрать в диалоге необходимые модули аутентификации. Для более тонкой настройки можно заглянуть в файл /etc/pam.d/common-auth и отредактировать его по желанию. Структуру файла я описывал в

Настройка клиента. проверка работоспособности

Создайте на клиенте каталог

/etc/krb5/

. Скопируйте в

/etc/krb5/

сертификат CA

(cacert.pem)

c сервера.

Настройте kerberos в /etc/krb5.conf. Секцию [libdefaults] дополните следующими строками.

Настройка рабочего окружения

Для начала необходимо развернуть среду, в которой будет производиться аутентификация. Наиболее просто это сделать, взяв две виртуальные машины, находящиеся в одной подсети. Достаточно установить на одну виртуальную машину какую-нибудь Ubuntu (это будет наш сервер), а затем клонировать ее и получить клиента.

Важно!

Следите за тем, чтобы время на клиенте и сервере было синхронизировано, это необходимо для корректной работы Kerberos.

Настройка сети

Клиенты Kerberos ищут свои сервера по доменным именам, поэтому необходимо настроить DNS и убедиться, что имена серверов успешно разрешаются. В нашем примере достаточно занести доменное имя сервера в /etc/hosts, что я и сделал. Схема «сети» изображена ниже.

Общая схема аутентификации по сертификатам

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

1. Пользователь запрашивает доступ к некоторой сетевой службе;
2. По запросу сервер посылает клиенту свой серверный сертификат (сертификат SSL). Клиент проверяет его на валидность. Если проверка провалилась, на этом всё заканчивается;
3. Если проверка прошла успешно, клиент запрашивает доступ к ресурсам службы;
4. Служба сконфигурирована на обязательную аутентификацию пользователя и отправляет клиенту доступные (на сервере) методы аутентификации. В нашем случае это требование клиентского сертификата;
5. Клиент посылает на сервер публичную часть своего сертификата и некоторый объём подписанных клиентским сертификатом данных. Сервер проверяет клиентский сертификат на валидность. Если сертификат не прошёл проверку — разговор клиента и сервера на этом завершается. Если сертификат прошёл проверку, сервер пытается сопоставить (или ассоциировать) сертификат с учётной записью пользователя. Если сопоставление не удалось — разговор завершается.
6. Если учётная запись найдена и сертификат удалось сопоставить с ней, сервер начинает установку защищённого канала. После установки этого канала, сервер предоставляет пользователю ресурсы в том объёме, в котором это позволяют списки доступа (ACL, например).

Я посчитал нужным немного развернуть последний пункт, чтобы вы понимали общее устройство этого канала (поскольку, у людей есть некоторые заблуждения на этот счёт):

1. Клиент запрашивает установку безопасного канала;
2. Сервер отвечает согласием и пересылает клиенту список поддерживаемых симметричных протоколов шифрования;
3. Клиент посылает на сервер свой список протоколов симметричного шифрования;
4. Клиент и сервер договариваются и выбирают наиболее подходящий протокол. Например, — Я умею DES и 3DES, а что умеешь ты? — А я умею только 3DES и AES. — Отлично, давай тогда использовать 3DES;
5. Клиент на своей стороне генерирует сессионный симметричный ключ шифрования и шифрует его открытым ключом сертификата сервера. Этот процесс называется Key exchange. Как мы знаем, прочитать этот ключ сможет только веб сервер, т.к. только он владеет закрытым ключом, который ассоциирован с конкретным сертификатом SSL;
6. После этого, все передаваемые данные шифруются именно этим сессионным ключом. Помните, что при передаче данных сертификаты уже не используются (а многие считают, что все данные шифруются открытыми ключами сертификатов). Сертификаты используются только при обновлении сессионного ключа (который периодически меняется).

Немного другой процесс происходит при интерактивном логоне или логоне на сервер терминалов посредством Remote Desktop при помощи смарт-карты.

Подготовка смарт-карты. выпуск ключей и сертификата пользователя

Убедитесь в том, что установлены пакеты

libengine-pkcs11-opensslopensc

. Подключите устройство, которое следует подготовить.

Проинициализируйте устройство, установите PIN-код пользователя. Помните, что инициализация устройства удалит все данные на JaCarta PKI без возможности восстановления.

Для инициализации необходимо воспользоваться утилитой pkcs11-tool.

pkcs11-tool –slot 0 –init-token –so-pin 00000000 –label ‘JaCarta PKI’ –module /lib64/libASEP11.so,

где:

–slot 0 — указывает, в какой виртуальный слот подключено устройство. Как правило, это слот 0, но могут быть и другие значения – 1,2 и т.д.;

–init-token – команда инициализации токена;

–so-pin 00000000 – PIN-код администратора JaCarta PKI. По умолчанию имеет значение 00000000;

–label ‘JaCarta PKI’ – метка устройства;

–module /lib64/libASEP11.so — указывает путь до библиотеки libASEP11.so. Устанавливается в рамках пакета idprotectclient см. раздел «Установка драйверов на сервер и клиент».

Для задания PIN-кода пользователя используйте команду:

pkcs11-tool –slot 0 –init-pin –so-pin 00000000 –login –pin 11111111 –module /lib64/libASEP11.so,

где:

–slot 0 — указывает, в какой виртуальный слот подключено устройство. Как правило, это слот 0, но могут быть и другие значения – 1,2 и т.д.;

–init-pin – команда установки PIN-кода пользователя;

–so-pin 00000000 – PIN-код администратора JaCarta PKI. По умолчанию имеет значение 00000000;

Пример демо-зоны

Предполагается, что ALD уже развернут, существует минимум один доменный пользователь, который может аутентифицироваться по паролю, время клиента и сервера совпадают.

Терминология kerberos

• Билет (ticket) – временные данные, выдаваемые клиенту для аутентификации на сервере, на котором располагается необходимая служба.
• Клиент (client) – некая сущность в сети (пользователь, хост или сервис), которая может получить билет от Kerberos.
• Центр выдачи ключей (key distribution center, KDC) – сервис, выдающий билеты Kerberos.
• Область (realm) – сеть, используемая Kerberos, состоящая из серверов KDC и множества клиентов. Имя realm регистрозависимо, обычно пишется в верхнем регистре и совпадает с именем домена.
• Принципал (principal) – уникальное имя для клиента, для которого разрешается аутентификация в Kerberos. Записывается в виде root[/instance]@REALM.

Установка драйверов на сервер и клиент

Для обеспечения работы со смарт-картой

JaCarta PKI

на клиенте и сервере установите следующие пакеты:

libccid, pcscd, libpcsclite1

. После установки этих обязательных пакетов установите

, который можно загрузить с официального сайта «Аладдин Р.Д.».

Для обеспечения работы со смарт-картой подсистемы Kerberos добавочно к предустановленным пакетам ald/kerberos установите пакет krb5-pkinit на клиенте и сервере.

Для обеспечения возможности выпуска ключей и сертификатов на JaCarta PKI на сервере также установите пакеты libengine-pkcs11-openssl и opensc.

Установка и настройка центра сертификации на сервере

В качестве центра сертификации

(CA)

будет использован

OpenSSL

OpenSSL — криптографический пакет с открытым исходным кодом для работы с SSL/TLS. Позволяет создавать ключи RSA, DH, DSA и сертификаты X.509, подписывать их, формировать CSR и CRT.

Логон смарт-картой или pkinit

Интерактивная аутентификация в Active Directory по сертификату не является самостоятельным механизмом. Как и всегда, основной протокол аутентификации в домене — Kerberos. Чтобы обеспечить взаимодействие между аутентификацией по смарт-карте и Керберосом, применяется нехитрый протокол PKINIT.

Примечание: если у пользователя уже есть соответствующий сервисный тикет (TGS), выполняются только шаги 5 и 6.

Заключение

Применение протокола Kerberos для централизованной аутентификации в связке с централизованным созданием хранением и раздачей учетных записей (например, посредством каталога на базе OpenLDAP) позволяет создать «домен UNIX», полностью состоящий из машин под управлением свободного программного обеспечения.