Ссылки по теме
- http://web.mit.edu/kerberos/
- https://help.ubuntu.com/community/Kerberos
- https://help.ubuntu.com/10.04/serverguide/kerberos.html
- http://k5wiki.kerberos.org/wiki/Pkinit_configuration
О Kerberos
Kerberos - это протокол аутентификации, который использует комбинацию криптографии и третьей доверенной стороны для безопасной аутетификации по сети через недоверенный канал передачи данных. Дополнительная информация о протоколе Kerberos доступна на сайте MIT's Kerberos site. Статья Designing an Authentication System представляет собой оипсание принципов, лежащих в основе схеме аутентификации Kerberos.
Эта статья предназначена для системных администраторов, которые хотят настроить Kerberos-аутентификацию с использованием токенов Рутокен.
Существует несколько имплементаций Kerberos. Эта статья предлагает инструкцию по настройке MIT версии, которая есть в репозиториях большинства современных дистрибутивов Linux. Настройке Heimdal версии похожа по принципам, но отличается синтаксисом некоторых команд.
Microsoft's Active Directory - это одна из закрытых реализаций Kerberos аутентификации. Данная инструкция содержит несколько советов по конфигурации интеграции с Active Directory. В среде Active, KDC это обычно один из сервисов предоставляемы Domain Controller (DC). Если вы хотите настроить интеграцию с Active Directory Domain, то вы можете переходить к разделу Настройка клиента.
Перед установкой
Центральной частью схемы аутентификации Kerberos является третья доверенная сторона - Key Distribution Center (KDC), которая является централизованным хранилище информации о пользователях. Перед разворачиванием Kerberos, должен быть выбран сервер, который будет выполнять роль KDC. Физическая и сетевая безопасность критичны для этого сервера, так как его компрометация ведет к компрометации всего realm.
Выбор хорошего имени для realm так же важен. По правилам, имя realm это доменное имя сайта в верхнем регистре. Например, для сайта или доменной зоны example.com рекомендуется выбрать EXAMPLE.COM в качестве имени realm.
Проверка модели устройства
- Подключите USB-токен к компьютеру.
- Для определения названия модели USB-токена откройте Терминал и введите команду:
$ lsusb
В результате в окне Терминала отобразится название модели USB-токена:
Убедитесь, что используете: Aktiv Rutoken ECP
Параметры стенда
Данная инструкция была протестирована для сервера и клиента работающих под управлением Astra Linux 1.4.
При использовании других дистрибутивов могут понадобится дополнительные действия.
В случае возникновения проблем при настройке - обращайтесь в службу технической поддержки.
<username> = testuser
<realm> = AKTIV-TEST.RU
<server> = server.aktiv-test.ru
<client> = client.aktiv-test.ru
Предварительные требования
Все серверы и клиенты, которые входят в realm Kerberos должны иметь возможность взаимодействовать между собой. Время между устройствами в realm должно быть синхронизовано. Далее описано как этого добиться.
Host Names
Каждый сервер внутри Kerberos realm должен иметь Fully Qualified Domain Name (FQDN).
Kerberos так же ожидает, что FQDN сервера является reverse-resolvable. Если выяснение доменного имени по IP недостпно, то установите значение переменной rdns в значение false на клиентах в файле krb5.conf
Note |
---|
Active Directory сильно зависит от DNS, поэтому весьма вероятно что ваш Active Directory Domain Controller уже имеет роль DNS. В этом случае убедитесь в том, что каждый сервер имеет свое FQDN перед выполнением тестов, описанных ниже в этом разделе. |
Если сервер уже имеет назначенное FQDN, проверьте коректность обнаружение forward и reverse выполнив на клиенте следующие команды:
Code Block | ||
---|---|---|
| ||
$ nslookup server.example.com $ nslookup <server ip address> |
Note |
---|
Если вы используете Astra Linux (или другой дистрибутив), то для установки программы nslookup, вам необходимо установить пакет dnsutils. Вы можете воспользоваться Synaptic Package Manager или выполнить из командной строки $ apt-get install dnsutils |
Вывод первой команды должен содержать IP адрес сервера. Вывод второй команды должен содержать FQDN сервера.
Если у сервера нет назначенного FQDN и сервис DNS не доступен, то вы можете отредактировать локальные файлы hosts (обычно они находятся в /etc) на сервере добавив туда следующую строку:
127.0.0.1 server.aktiv-test.ru localhost server
А на каждом клиенте добавить строку
<IP-address> server.aktiv-test.ru <IP-address> server
Где IP-address - это IP адрес сервера. В нашем примере это будет 10.0.0.1.
После этого проверьте работу локальных DNS имен используя команду nslookup как показано выше.
Наличие соединения
Для проверки соединения между хостави выполните ping для каждого хоста по его FQDN:
Code Block | ||
---|---|---|
| ||
$ ping server.aktiv-test.ru PING server.aktiv-test.ru (10.0.0.1) 56(84) bytes of data. 64 bytes from server.aktiv-test.ru (10.0.0.1): icmp_seq=1 ttl=128 time=0.176ms |
Вывод комнады ping показывает успешное определение IP адреса по FQDN, и простой ответ от сервера. Ответ от сервера является подтверждением того, что между хостом и сервером есть соединение.
Проблемы при работе ping указывают на проблемы настройки сервера или клиента.
Синхронизация времени
Протокол Kerberos требует синхронизации времени сервера и клиента: если системные часы клиентов и сревера расходятся, то аутентификация не будет выполнена. Простейший способ синхронизировать системные часы - использование Network Time Protocol (NTP) сервера. Astra Linux 1.4 по-умолчанию синхронизует время с российскими NTP-серверами. Для настройки собственного NTP-сервера смотрите документацию на ваш дистрибутив (например, UbuntuTime для Ubuntu).
Note |
---|
Active Directory Domain Controllers обычно так же являются NTP серверами. |
Брандмауэры
Так же как и все остальные сетевые службы, Kerberos должен иметь возможность проходить через любые брандмауеры между хостами. Инструкция Kerberos System Administration Manual имеет детальное описание портов, которые необходимо открыть при настройке брандмауэров.
Установка и настройка KDC
Для установки KDC выполните следующие команды на сервере
Code Block | ||
---|---|---|
| ||
$ sudo apt-get install krb5-kdc krb5-admin-server krb5-pkinit opensc pcscd |
Эти пакеты доступны в основном репозитории.
kdc.conf
Ниже представлен пример конфигурационного файла /etc/krb5kdc/kdc.conf для нашего случая:
Code Block | ||
---|---|---|
| ||
[kdcdefaults] kdc_ports = 750,88 default_realm = AKTIV-TEST.RU [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 kdc_ports = 750,88 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = des3-hmac-sha1 supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm default_principal_flags = +preauth } [logging] kdc = FILE:/var/local/krb5kdc/kdc.log admin_server = FILE:/var/local/krb5kdc/kadmin.log |
Если вы используете настройки для логирования, показанные выше, то вам необходимо выполнить
Code Block | ||
---|---|---|
| ||
$ sudo mkdir /var/local/krb5kdc |
для создания каталога, в который будут сохраняться логи.
Note |
---|
Мы настоятельно рекомендуем настроить пути для логирования. Это поможет вам диагностировать проблемы и ошибки при настройке и работе Kerberos |
krb5.conf
Ниже представлен пример конфигурационного файла /etc/krb5.conf для нашего случая:
Code Block | ||
---|---|---|
| ||
[libdefaults] default_realm = AKTIV-TEST.RU # The following krb5.conf variables are only for MIT Kerberos. krb4_config = /etc/krb.conf krb4_realms = /etc/krb.realms kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true # The following libdefaults parameters are only for Heimdal Kerberos. v4_instance_resolve = false v4_name_convert = { host = { rcmd = host ftp = ftp } plain = { something = something-else } } fcc-mit-ticketflags = true [realms] AKTIV-TEST.RU = { kdc = server.aktiv-test.ru admin_server = server.aktiv-test.ru default_domain = aktiv-test.ru } [domain_realm] .aktiv-test.ru = AKTIV-TEST.RU aktiv-test.ru = AKTIV-TEST.RU [login] krb4_convert = true krb4_get_tickets = false |
Создание базы данных Kerberos
Для создания базы данных Kerberos выполните команду:
Code Block | ||
---|---|---|
| ||
$ krb5_newrealm |
Kerberos использует Access Control List (ACL) для определения прав доступа к Kerberos admin daemon. По-умолчанию этот файл находится в /etc/krb5kdc/kadm5.acl. Содержание файла по-умолчанию подходит для большинства realm, однако вам могут понадобится дополнительные записи в этом файле, в зависимости от конфигурации сети.
Code Block | ||
---|---|---|
| ||
# This file is the access control list for krb5 administration. # When this file is edited run /etc/init.d/krb5-admin-server restart to activate # One common way to set up Kerberos administration is to allow any principal # ending in /admin is given full administrative rights. # To enable this, uncomment the following line: */admin@AKTIV-TEST.RU * |
Principals
Principals это записи в базе данных Kerberos, которые представляют собой пользователей и сервисы в сети. Каждый пользователь или сервис, который использует аутентификацию в Kerberos realm должен иметь principal, определенный в базе данных Kerberos.
Пользовательские principals представляются в виде principal@REALM.NAME.
Например, пользователь tom в realm AKTIV-TEST.RU должен иметь principal tom@AKTIV-TEST.RU в базе данных Kerberos.
Principal сервиса представляется в виде service/server.fqdn@REALM.NAME. Например, FTP сервис lab.example.com в realm AKTIV-TEST.RU должен иметь principal ftp/lab.example.com@AKTIV-TEST.RU в базе данных Kerberos.
Имена principal регистрозависимы.
kadmin
Kerberos realm администрируется при помощи утилиты kadmin. Это интерактивный интерфейс, который позволяет администратору создавать, получать, обновлять и удалять realm principle. kadmin может быть запущена на любом компьютере, который является частью Kerberos realm, при условии, что пользователь имеет права доступа. Однако, из соображений безопасности, рекомендуется запускать kadmin на KDC.
Вы можете так же использовать альтренативную программу kadmin.local. Выполнение kadmin.local из под пользователя root на KDC позволяет администратору проходить аутентификацию без существующих principal. Это обычно не требуется после правильной настройки всего окружения.
Для запуска утилиты kadmin выполните следующую команду:
Code Block | ||
---|---|---|
| ||
$ kadmin -p <principal> |
Замените <principal> корректным именем principal. По-умолчанию, principal admin/admin имеет права доступа администратора для realm, поэтому вы можете использовать:
Code Block | ||
---|---|---|
| ||
$ kadmin -p admin/admin |
Типичные задачи администрирования
- Добавление пользователя:
Code Block | ||
---|---|---|
| ||
$ kadmin: addprinc user |
Имя realm по-умолчанию добавляется к имени principal автоматически.
- Удаление пользователя:
Code Block | ||
---|---|---|
| ||
$ kadmin: delprinc user |
- Показать список principal:
Code Block | ||
---|---|---|
| ||
$ kadmin: listprincs |
Добавление сервиса:
Code Block | ||
---|---|---|
| ||
$ addprinc service/server.fqdn |
Имя realm по-умолчанию добавляется к имени principal автоматически.
- Удаление сервиса
Code Block | ||
---|---|---|
| ||
$ kadmin: delprinc service/server.fqdn |
Проверка локальной аутентификации по паролю
Выполним на сервере создание пользователя и попробуем пройти локальную аутентификацию.
Code Block | ||
---|---|---|
| ||
$ sudo kadmin.local # username = testuser # password = test kadmin.local:$ addprinc <username> # ... kadmin.local:$ quit $ kinit <username> ... $ klist ... $ kdestroy |
Ниже представлен вывод после выполнения команды klist, который свидетельствует о корректном получении тикета:
Code Block | ||
---|---|---|
| ||
Ticket cache: FILE:/tmp/krb5cc_1000 Default principal: testuser@AKTIV-TEST.RU Valid starting Expires Service principal 06.10.2016 16:58:08 07.10.2016 02:58:08 krbtgt/AKTIV-TEST.RU@AKTIV-TEST.RU renew until 07.10.2016 16:58:06 |
Настройка клиента
Note |
---|
Перед настройкой, убедитесь, что клиент удовлетворяет условиям, указанным в разделе Предварительные требования. |
Для поддержки аутентификации с помощью Kerberos установите на клиент следующие пакеты
Code Block | ||
---|---|---|
| ||
$ sudo apt-get install krb5-user libpam-krb5 libpam-krb5 krb5-pkinit libengine-pkcs11-openssl opensc pcscd |
krb5-config
Установка krb5-config позволит сгенерировать файл /etc/krb5.conf file. Выполните:
Code Block | ||
---|---|---|
| ||
$ sudo dpkg-reconfigure krb5-config |
От вас потребуется ввести:
- имя realm - AKTIV-TEST.RU
- имя Kerberos сервера для данного realm - server.aktiv-test.ru
- имя сервера администрирования для данного realm - server.aktiv-test.ru
Ручная настройка: /etc/krb5.conf
Если настройка с помощью krb5-config по каким-то причинам не удалась, вы можете настроить клиента Kerberos в ручном режиме отредактировав файл конфигурации /etc/krb5.conf. Этот вариант позволяет задать множество дополнительых параметров, которые нельзя задать при настройке с помощью krb5-config. Ниже представлен пример файла конфигурации для нашего примера.
Code Block | ||
---|---|---|
| ||
[libdefaults] default_realm = AKTIV-TEST.RU # The following krb5.conf variables are only for MIT Kerberos. krb4_config = /etc/krb.conf krb4_realms = /etc/krb.realms kdc_timesync = 1 ccache_type = 4 forwardable = true proxiable = true # The following libdefaults parameters are only for Heimdal Kerberos. v4_instance_resolve = false v4_name_convert = { host = { rcmd = host ftp = ftp } plain = { something = something-else } } fcc-mit-ticketflags = true [realms] AKTIV-TEST.RU = { kdc = server.aktiv-test.ru admin_server = server.aktiv-test.ru } [domain_realm] .aktiv-test.ru = AKTIV-TEST.RU aktiv-test.ru = AKTIV-TEST.RU [login] krb4_convert = true krb4_get_tickets = false |
Проверка удаленной аутентификации
Для проверки работы Kerberos, запросите Ticket-Granting Ticket (TGT) с помощью команды kinit, как показано ниже.
Note |
---|
Имя realm регистро зависимо. |
Code Block | ||
---|---|---|
| ||
# username = testuser # password = test $ kinit -p testuser@AKTIV-TEST.RU Password for testuser@AKTIV-TEST.RU: <password> ... $ klist ... $ kdestroy |
Ниже представлен вывод после выполнения команды klist, который свидетельствует о корректном получении тикета:
Code Block | ||
---|---|---|
| ||
Default principal: testuser@AKTIV-TEST.RU Valid starting Expires Service principal 06.10.2016 17:27:10 07.10.2016 03:27:10 krbtgt/AKTIV-TEST.RU@AKTIV-TEST.RU renew until 07.10.2016 17:27:07 |
Настройка аутентификации по токенам
Настройка на сервере
Создать ключ и сертификат CA, выполнив команды:
Code Block | ||
---|---|---|
| ||
$ openssl genrsa -out CA_key.pem 2048 $ openssl req -key CA_key.pem -new -x509 -out CA_cert.pem |
Создать файл pkinit_extensions со следующим содержимым
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
[ kdc_cert ] basicConstraints=CA:FALSE # Here are some examples of the usage of nsCertType. If it is omitted keyUsage = nonRepudiation, digitalSignature, keyEncipherment, keyAgreement #Pkinit EKU extendedKeyUsage = 1.3.6.1.5.2.3.5 subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer # Copy subject details issuerAltName=issuer:copy # Add id-pkinit-san (pkinit subjectAlternativeName) subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:kdc_princ_name [kdc_princ_name] realm = EXP:0, GeneralString:${ENV::REALM} principal_name = EXP:1, SEQUENCE:kdc_principal_seq [kdc_principal_seq] name_type = EXP:0, INTEGER:1 name_string = EXP:1, SEQUENCE:kdc_principals [kdc_principals] princ1 = GeneralString:krbtgt princ2 = GeneralString:${ENV::REALM} [ client_cert ] # These extensions are added when 'ca' signs a request. basicConstraints=CA:FALSE keyUsage = digitalSignature, keyEncipherment, keyAgreement extendedKeyUsage = 1.3.6.1.5.2.3.4 subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer subjectAltName=otherName:1.3.6.1.5.2.2;SEQUENCE:princ_name # Copy subject details issuerAltName=issuer:copy [princ_name] realm = EXP:0, GeneralString:${ENV::REALM} principal_name = EXP:1, SEQUENCE:principal_seq [principal_seq] name_type = EXP:0, INTEGER:1 name_string = EXP:1, SEQUENCE:principals [principals] princ1 = GeneralString:${ENV::CLIENT} |
Создать ключ и сертификат KDC, выполнив команды:
Code Block | ||
---|---|---|
| ||
$ openssl genrsa -out KDC_key.pem 2048 # создание запроса $ openssl req -new -out KDC.req -key ./KDC_key.pem # подпись запроса $ REALM=AKTIV-TEST.RU; export REALM $ CLIENT=server.aktiv-test.ru; export CLIENT $ openssl x509 -req -in ./KDC.req -CAkey ./CA_key.pem -CA ./CA_cert.pem -out ./KDC.pem -extfile ./pkinit_extensions -extensions kdc_cert -CAcreateserial |
Перенести следующие файлы в /var/lib/krb5kdc/:
KDC.pem
KDC_key.pem
CA_cert.pem
Для этого можно воспользоваться командой:
Code Block | ||
---|---|---|
| ||
$ sudo cp ./KDC.pem ./KDC_key.pem ./CA_cert.pem /var/lib/krb5kdc |
Включить preauth на сервере. Для этого в секцию kdcdefaults конфигурационного файла /etc/krb5kdc/kdc.conf необходимо вставить следующие строки:
Code Block | ||||||
---|---|---|---|---|---|---|
| ||||||
[kdcdefaults] ... pkinit_identity = FILE:/var/lib/krb5kdc/kdc.pem,/var/lib/krb5kdc/kdckey.pem pkinit_anchors = FILE:/var/lib/krb5kdc/cacert.pem |
Включить preauth для пользователя:
Code Block | ||
---|---|---|
| ||
$ sudo kadmin.local kadmin.local$: modprinc +requires_preauth testuser |
Установка библиотеки PKCS#11
Скачайте и установите библиотеку для вашей операционной системы http://www.rutoken.ru/support/download/pkcs/
Создание запроса на сертификат от пользователя testuser. Необходимо вставить токен пользователя в сервер.
Code Block | ||
---|---|---|
| ||
$ pkcs11-tool --module /usr/lib/librtpkcs11ecp.so --keypairgen --key-type rsa:2048 -l --id 45 ... $ openssl OpenSSL> engine dynamic -pre SO_PATH:/usr/lib/engines/engine_pkcs11.so -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre MODULE_PATH:/usr/lib/librtpkcs11ecp.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 0:45 -keyform engine -out client.req engine "pkcs11" set. PKCS#11 token PIN: ... OpenSSL> quit |
Note |
---|
Путь до библиотеки librtpkcs11ecp.so, opensc-pkcs11.so и engine_pkcs11.so может отличаться в разных ОС |
Подпись заявки ключем CA
Code Block | ||
---|---|---|
| ||
$ REALM=AKTIV-TEST.RU; export REALM $ CLIENT=server.aktiv-test.ru; export CLIENT $ openssl x509 -CAkey ./CA_key.pem -CA ./CA_cert.pem -req -in ./client.req -extensions client_cert -extfile ./pkinit_extensions -out client.pem |
Конвертируем сертификат из формата PEM в формат CRT:
Code Block | ||
---|---|---|
| ||
$ openssl OpenSSL> x509 -in client.pem -out client.crt -outform DER |
Записать сертификат на токен:
Code Block | ||
---|---|---|
| ||
$ pkcs11-tool --module /usr/lib/librtpkcs11ecp.so -l -y cert -w ./client.crt --id 45 |
Полученный файл - client.pem - необходимо перенести на клиентский компьютер.
Настройка на клиенте
Подписанный сертификат пользователя (client.pem) необходимо скопировать с сервера в /etc/krb5/ на клиенте
Скопировать сертификат CA (cacert.pem) c сервера в /etc/krb5/ на клиенте
Настроить Kerberos, изменив /etc/krb5.conf
Code Block | ||||
---|---|---|---|---|
| ||||
[libdefaults] default_realm = AKTIV-TEST.RU pkinit_anchors = FILE:/etc/krb5/CA_cert.pem # для аутентификации по локальному ключу # pkinit_identities = FILE:/etc/krb5/client.pem,/etc/krb5/clientkey.pem # для аутентификации по токену pkinit_identities = PKCS11:/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so |
Вставить токен в клиентский компьютер и проверить работу:
Code Block | ||
---|---|---|
| ||
$ kinit <username> |
Table of Contents | ||
---|---|---|
|