В продолжение давней темы про использование двухфакторной аутентификации в ОС GNU/Linux позвольте рассказать про схему работы и настройку аутентификации с помощью Kerberos. В этой статье мы рассмотрим процесс настройки MIT Kerberos для аутентификации пользователей по сертификатам и ключевым парам, находящимся на USB-токене. Также материалы, изложенные в статье, можно использовать для настройки аутентификации в домене Windows.

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

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

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

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

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

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

Файлы настроек Kerberos

На сервере:

• /etc/krb5kdc/kdc.conf — настройки KDC

На клиенте и сервере:

• /etc/kbr5.conf — настройки сервера аутентификации (описание realms, доменных имен и других настроек)

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

Для начала необходимо развернуть среду, в которой будет производиться аутентификация. Наиболее просто это сделать, взяв две виртуальные машины, находящиеся в одной подсети. Достаточно установить на одну виртуальную машину какую-нибудь Ubuntu (это будет наш сервер), а затем клонировать ее и получить клиента. При написании статьи я воспользовался свежей Ubuntu 12.10 (x86) и виртуальной машиной от VMWare. Чтобы виртуальным машинам было удобнее видеть друг друга по сети, стоит переключить сетевые карты в Bridged-режим.
Важно! Следите за тем, чтобы время на клиенте и сервере было синхронизировано, это необходимо для корректной работы Kerberos.

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

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

Установка необходимых пакетов

На сервере нам потребуются:

• krb5-kdc – сервис KDC
• krb5-admin-server – административный сервер Kerberos (он ведет контроль учетных записей пользователей)
• krb5-pkinit – модуль расширения Kerberos для аутентификации по сертификатам

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

• krb5-user – базовый набор утилит для работы клиентской аутентификации
• krb5-config – файлы настроек Kerberos
• krb5-pkinit
• libpam-krb5 – модуль PAM для использования Kerberos-аутентификации
• pcscd, opensc, libengine-pkcs11-openssl – пакеты, необходимые для работы с токенами

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

• Default realm: AKTIV-TEST.RU
• Имена серверов (admin server и KDC): aktiv-test.ru (он же прописан в /etc/hosts на клиенте)
• Пользователь: testuser@AKTIV-TEST.RU

Настройка Kerberos

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

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

$ sudo krb5_newrealm 

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

$ sudo dpkg-reconfigure krb5-config 

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

[domain_realm] .aktiv-test.ru = AKTIV-TEST.RU aktiv-test.ru = AKTIV-TEST.RU 

Теперь создадим на сервере нового пользователя c именем testuser

$ sudo kadmin.local # username = testuser # password = test # добавляем нового пользователя и устанавливаем его пароль kadmin.local:$ addprinc testuser # ... kadmin.local:$ quit 

На клиенте теперь можно проверить, правильно ли мы настроили сеть и Kerberos:

$ kinit testuser@AKTIV-TEST.RU # вводим пароль пользователя $ klist # и видим выданный ticket, после чего его можно удалить следующей командой $ kdestroy 

Настройка аутентификации по открытому ключу

Для работы модуля pkinit нам придется воспользоваться openssl в качестве мини-УЦ, чтобы создать ключевые пары и сертификаты клиента и сервера.

На сервере:

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

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

Создадим ключевую пару для KDC, заявку на сертификат и выпишем его сами себе.
Здесь нам потребуется специальный файл расширений OpenSSL (pkinit_extensions), в котором будут указаны дополнительные поля сертификатов, используемых в Kerberos. В частности, мы зададим:

• Extended Key Usage (EKU) – идентификатор (OID), говорящий о том, как планируется использовать сертификат
• otherName – поле, задающее нашего принципала, для которого выписывается сертификат

$ openssl genrsa -out kdckey.pem 2048  # создание запроса $ openssl req -new -out kdc.req -key kdckey.pem # подпись запроса $ REALM=AKTIV-TEST.RU; export REALM $ CLIENT=aktiv-test.ru; export CLIENT # содержимое файла pkinit_extensions см. по ссылке выше $ openssl x509 -req -in kdc.req -CAkey cakey.pem -CA cacert.pem -out kdc.pem -extfile pkinit_extensions -extensions kdc_cert –CAcreateserial 

После этого перенесем следующие файлы в /var/lib/krb5kdc/:

• kdc.pem
• kdckey.pem
• cacert.pem

На сервере отредактируем настройки Kerberos (файл /etc/krb5kdc/kdc.conf) для использования ключей и сертификатов сервера и УЦ:

[kdcdefaults]     kdc_tcp_ports = 88     pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem     pkinit_anchors = FILE:/var/lib/krb5kdc/cacert.pem [realms]     AKTIV-TEST.RU = {         database_name = /var/lib/krb5kdc/principal         admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab         acl_file = /etc/krb5kdc/kadm5.acl         key_stash_file = /etc/krb5kdc/stash         max_life = 10h 0m 0s         max_renewable_life = 7d 0h 0m 0s         master_key_type = des3-hmac-sha1         supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3         default_principal_flags = +preauth     } 

Далее на сервере необходимо включить предварительную аутентификацию для нашего пользователя.

$ kadmin.local kadmin.local$: modprinc +requires_preauth testuser 

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

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

$ pkcs15-init --erase-card -p rutoken_ecp $ pkcs15-init --create-pkcs15 --so-pin "87654321" --so-puk "" $ pkcs15-init --store-pin --label "User PIN" --auth-id 02 --pin "12345678" --puk "" --so-pin "87654321" –finalize 

Сгенерируем на токене ключевую пару RSA 2048 бит и создадим заявку на сертификат. Важно заметить, что пути до библиотек engine_pkcs11.so и opensc-pkcs11.so на вашей системе могут отличатся, поэтому сначала стоит проверить их расположение.

# на данном шаге важно запомнить ID ключевой пары, его мы используем позже $ pkcs15-init -G rsa/2048 --auth-id 02 --id 42 --label "testuser's key" --public-key-label "testuser's public key" # ... $ openssl # на multiarch-системах opensc-pkcs11.so и engine_pkcs11.so могут лежать в других местах OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/openssl/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:opensc-pkcs11.so (dynamic) Dynamic engine loading support [Success]: SO_PATH:/usr/lib/openssl/engines/engine_pkcs11.so [Success]: ID:pkcs11 [Success]: LIST_ADD:1 [Success]: LOAD [Success]: MODULE_PATH:opensc-pkcs11.so Loaded: (pkcs11) pkcs11 engine OpenSSL> req -engine pkcs11 -new -key 1:42 -keyform engine -out client.req -subj "/C=RU/ST=Moscow/L=Moscow/O=Aktiv/OU=dev/CN=testuser/emailAddress=testuser@mail.com" engine "pkcs11" set. PKCS#11 token PIN:  OpenSSL> quit 

После этого мы получим файл-заявку client.req, которую необходимо поместить на сервер и выписать сертификат пользователя на основе данных УЦ:

$ REALM=AKTIV-TEST.RU; export REALM $ CLIENT=testuser; export CLIENT $ openssl x509 -CAkey cakey.pem -CA cacert.pem -req -in client.req -extensions client_cert -extfile pkinit_extensions -out client.pem 

Затем стоит перезапустить сервер и KDC:

$ /etc/init.d/krb5-admin-server restart $ /etc/init.d/krb5-kdc restart 

На выходе работы openssl мы получим файл с сертификатом клиента client.pem. Его нужно перенести на клиентскую машину, положить в /etc/krb5/ и записать на токен:

$ pkcs15-init --store-certificate client.pem --auth-id 02 --id 42 --format pem 

И в завершение нам потребуется внести в файл конфигурации Kerberos настройку, которая укажет, какие данные использовать для аутентификации (в нашем случае это сертификат УЦ и путь до модуля PKCS#11). В документации MIT Kerberos указаны различные параметры, которые позволяют настроить выбор аутентификационных данных на токене, в нашем же случае мы просто указываем модуль PKCS#11, поскольку в данной ситуации этого достаточно.

[libdefaults]     default_realm = AKTIV-TEST.RU # путь к сертификату УЦ     pkinit_anchors = FILE:/etc/krb5/cacert.pem # путь к модулю PKCS#11     pkinit_identities = PKCS11:/usr/lib/opensc-pkcs11.so 

Проверим, можем ли мы получить ticket на клиенте, используя данные с токена:

$ kinit testuser # на этом этапе у нас должны спросить PIN-код от токена $ klist	 

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

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

$ sudo pam-auth-update 

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

Заключение

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

Полезные ссылки

• Описание протокола Kerberos
• Официальная документация
• Инструкция по настройке от сообщества Ubuntu
• Настройка PKINIT