Эти материалы являются объектом авторского права и защищены законами РФ и международными соглашениями о защите авторских прав. Перед использованием материалов вы обязаны принять условия лицензионного договора на использование этих материалов, или же вы не имеете права использовать настоящие материалы

Авторская площадка "Наши орбиты" состоит из ряда тематических подразделов, являющихся моими лабораторными дневниками, содержащими записи за разное, иногда продолжительно отличающееся, время. Эти материалы призваны рассказать о прошедшем опыте, они никого ни к чему не призывают и совершенно не обязательно могут быть применимы кем-то ещё. Это только лишь истории о прошлом

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

Для того, чтобы клиенту каждый раз при запросе полномочий к разным ресурсам у сервера kerberos не надо было вводить пароль, авторизующий клиента в базе Kerberos, клиент в начале сессии запрашивает у сервера Kerberos суперблет (TGT, ticket-granting ticket) и соответствующий ему сессионный ключ (это вариант credetials - полномочий), по которым в дальнейшем производится авторизация клиента и выдаются дополнительные полномочия - в автоматическом режиме, незаметно для пользователя. Сервисы при это могут размещаться на разных серверах

Удобство от использования Kerberos заключается в том, что установленные на серверах авторизационные надстройки позволяют клиенту ввести пароль лишь единожды за сессию, независимо от количества серверов в сети. Другие механизмы, например каталог LDAP, позволяют хранить учетные записи и пароли в одном месте (базе LDAP), но при обращении к каждому конкретному серверу или даже сервису у клиента будет запрашиваться пароль, и автоматической авторизации в общем случае проводиться не будет (возможны, но не гарантиованы, варианты с кэшированием пароля клиентским ПО)

Иначе говоря, Kerberos - готовая система единого входа (single sign). При ее использовании сервисы на серверах конфигурируются сверять полученные при попытке доступа от пользователя полномочия с базой сервера Kerberos. А клиентское ПО при получении авторизационного запроса от сервиса автоматически получает у сервера Kerberos соответствующий Kerberos билет на основании полученного ранее супербилета и предает его сервису

Компьютерная система (сервера, сервисы для авторизации и пользователи - все находятся в базе Kerberos), использующая Kerberos авторизацию на основе одного ведущего и, возможно, нескольких вторичных серверов Kerberos, определяется как отдельный домен (область, ареал) управления Kerberos, или realm

Каждый объект, хранящийся в базе, независимо от того, сервис это, сервер или пользователь, называется принципал и описывается триплетом основное_имя/имя_инстанса@реалм, где основное имя можно понимать как тип объекта (например host для имени сервера), имя инстанса - уникальное имя конкретного объекта (например имя узла), реалм - административный домен (ареал) Kerberos. В составе учётной записи в базе хранится также ключ принципала, который можно задать при создании либо как пароль, либо же можно сгенерировать автоматически (kadmin => addprinc -randkey ...), что востребовано при создании принципалов хостов и сервисов. В дальнейшем данные о выбранных принципалах и ключах можно выгрузить в keytab файл для переноса на хост с сервисами, авторизующими через Kerberos

Например, каждый сервис является принципалом и должен иметь ключ шифрования, известный только сервису и серверу Kerberos. Такой ключ сохраняется в файле и именуется keytab файл или keytab. В одном файле может находиться и несколько ключей, а сам файл нужно хранить в секрете, т.к. он эквивалентен паролю

Каждый административный домен (realm) имеет свою базу записей, где в каждой записи отражен принципал, в том числе его пароль/ключ. Также каждый административный домен (realm) должен включать как минимум один сервер с мастер репликой базы, а также - опционально - могут существовать подчиненные сервера с дочерними репликами базы, периодически синхронизируемыми с мастер репликой

Важным термином является KDC (key distribution center) - это обслуживающий клиентов сервер Kerberos, в realm может быть один основной и несколько ведомых KDC, обеспечивающих выдачу ключей. Еще одно используемое понятие - административный сервер - позволяет производить удалённое управление базой Kerberos

Также есть возможность обеспечивать кросс - сертификацию различных realm, но этот раздел мы пока ОПУСКАЕМ

Основной конфигурационный файл - /etc/krb5.cfg - содержит информацию о расположении KDC и управляющих серверов, значение realm и другое. Этот файл размещается и на серверах, и на клиентах. В нем есть тонкости

• * (звёздочка) в конце строки означает конец описания соответствующего тэга (переменной). Т.е. переопределение переменной после звёздочки парсером конфигурационного файла будет проигнорировано
• существуют следующие секции, которые могут быть представлены или нет в конфигурационном файле
• libdefaults - дефолтные значения, используемые библиотекой Kerberos
• login - дефолтные значения, используемые программой login.krb5 (реализацие с поддержкой Kerberos)
• appdefaults - дефолтные значения, используемые приложениями Kerberos (здесь инициируется первое вхождение переменной, удовлетворяющее дополнительным условиям, если они есть
• realms - содержит подсекции, описывающие отдельные realm, в т.ч. описывающие расположение серверов для realm это наиболее модифицируемая секция
• domain_realm - карты мапирования DNS имен в поддомены домена управления (realm)
• loggins - опции конфигурирования работыпоцесса login
• capatchs - содержит пути для кросс - авторизации с другими доменами

Второй конфигурационный файл - /usr/local/var/krb5kdc/kdc.conf - содержит опции KDC в следующих секциях

• kdcdefaultsv- порты и опции работы с v.4
• realms - содержит подсекции, конфигурирующие соответствующие realm. Наиболее модифицируемая секция
• loggin - опять же опции журналирования

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

Мапирование имён хостов на реалм делается двумя путями

- либо правила в krb5.conf
- либо TXT записи в DNS для записи _kerberos.имя_домена, причём просматриваться при отсутствии в искомом будут и домены более верхних уровней - последовательно

Имя хоста KDC и дополнительные опции распознаётся рядом записей SRV DNS (качество приоритет порт хост), причём это добавлено в версии 5

• _kerberos._udp (порт доступа к KDC по UDP наиболее частая запись, по умолчанию 88 порт)
• _kerberos._tcp (порт доступа к KDC по TCP по умолчанию не используется в MIT, но можно включить. Или же для иных реализаций kerberos, по умолчанию 88 порт)
• _kerberos-master._udp (обычно не требуется)
• _kerberos-adm._tcp (749 порт по умолчанию для доступа к административному серверу)
• _kpasswd._udp (должен быть 464 на master KDC для смены пользователем своего пароля в базе)
• _kerberos_iv._udp (только если всключена поддержка 4 версии kerberos, отражает KDC версии 4)

Ниже приведён пример конфигурации DNS для использования в Kerberos инфраструктуре:

$ORIGIN наш.домен.
_kerberos                     TXT       "имя_REALM"
kerberos                      CNAME     имя_основного_KDC
kerberos-1                    CNAME     имя_резервного_KDC
kerberos-2                    CNAME     имя_резервного_2_KDC
_kerberos._udp                SRV       0 0 88 имя_основного_KDC
                              SRV       0 0 88 имя_резервного_KDC
                              SRV       0 0 88 имя_резервного_2_KDC
; параметр _kerberos._tcp опционален и согласно документации по умолчанию в MIT Kerberos не используется
_kerberos._tcp                SRV       0 0 88 имя_основного_KDC
                              SRV       0 0 88 имя_резервного_KDC
                              SRV       0 0 88 имя_резервного_2_KDC
_kerberos-master._udp         SRV       0 0 88 имя_основного_KDC
_kerberos-adm._tcp            SRV       0 0 749 имя_резервного_2_KDC
_kpasswd._udp                 SRV       0 0 464 имя_резервного_2_KDC


 

• kdb5_util - для манипулироания базой в целом (создание, удаление БД, dump и load, а также резервирование master key, который используется KDC для самоавторизации при старте KDC
• kadmin - для изменения данных в базе, управляет принципалами, политиками и таблицей ключей сервисов (keytabs) kadmin существует как локальная версия (без авторизации) и удаленная, включить удаленную можно улилитой krb5edit. Принципал для управления - kadmin/admin

Утилита kadmin. Команды get_principal (getprinc) и list_principal (listprinc) позволяют вывести список принципалов и детализацию конкретного принципала. Команды ad_principal, delete_principal и modify_principal говорят за себя. Также есть понятие именованных политик, хранящих параметры пароля - им соответствуют комннды get_policies (getpols), list_policies (listpols), add_policy, modify_policy, delete_policy. Добавление и удаление принципалов из keytab выполняется командами ktadd и ktremove, а просмотр добавленных принципалов командой klist -k

Утилита krb5_util. Позволяет дампить и восстанавливать базу (команды dump и restore), создавать новый stash файл (команда stash), создавать и уничтожать базу (команды create, в т.ч. create -s для создания и shash файла и destroy)

• подготовить файлы конфигурации /etc/krb5.conf, как минимум прописать реалм, адреса KDC и административного сервера, мапирование DNS
• подготовить файлы конфигурации /var/kerberos/krb5kdc/kdc.conf - как минимум прописать realm
• подготовить файлы конфигурации /var/kerberos/krb5kdc/kadm5.acl - как минимум прописать права администратору полные (*/admin@имя_realm) и пользователю на аутентификацию (*/*@имя_realm i)
• создать базу /usr/kerberos/sbin/kdb5_util create -r REALM_NAME -s (эта команда запросит ключ базы, а также сохранит его в кодированном виде в сташ - файл, что позволит не вводить пароль базы при каждом рестарте)
• создать принципала администратора /usr/kerberos/sbin/kadmin.local => addprinc admin/admin@REALM
• необходимо создать keytab для принципалов kadmin/admin и kadmin/changepw (сами они добавляются автоматом при создании базы) /usr/kerberos/sbin/kadmin.local => ktadd -k путь_к_keytab_из_kdc.conf kadmin/admin kadmin/changepw
• стартовать krb5kdc и kadmind

• создать принципала для каждого хоста с сервером kerberos (kdc), и для мастера и для ведомых серверов командой kadmin.local: addprinc -randkey host/FQDN_имя_хоста
• извлечь ключ в keytab файл kadmin: ktadd host/FQDN_имя_хоста и положить файл с ключом хоста в каталог /etc соответствующего хоста
• создать kpropd.acl для тиражирования базы, файл содержит перечень принципалов, которым разрешено обновлять дочернюю БД
• добавить запись в inet.d для демона kpropd или запустить kpropd иным способом
• сделать дамп мастер базы kdb5_util dump имя_файла_дампа
• растиржировать базы на slave сервера kprop -f имя_файла_дампа slave_kdc_host
• создать stash файлы для slave KDC (krb5_util stash и ввести мастер пароль базы)
• стартовать slave KDC: krb5kdc

Важная особенность - необходимо обеспечить соответствие имени хоста, отдаваемое командой hostname (для linux) и выгруженного в /etc/krb5.keytab принципала хоста на каждом сервере - и мастере и ведомых

Переключения между master и slave

• на мастере - kill kadmind, отключить тиражирование базы на slave сервера, запустить разовое ручное тиражирование
• на новом мастере - создать keytab и запустить kadmind, запустить cron тиражирование и поменять CNAME в DNS (или на каждом клиенте в krb5.conf)

• обеспечить наличие /etc/krb5.conf
• обеспечить описание kerberos сервисов в /etc/services
• опционально - DNS (на стороне сервера и клиентов)
• обязательна синхронизация времени участников realm
• настроить подсистему PAM. Либо руками, что здесь опускаем, либо (для RedHat систем) setup -> Аутентификация -> Использовать Kerberos -> Далее

Важно помнить, что для создания системы единого входа одной аутентификации недостаточно, необходимо также обеспечить доступность информации об атрибутах пользователей (соответствие unix user id, путь к домашнему каталогу, id основной группы и т.п., что обычно запрашивается через nsslib). Оптимальным здесь представляется одновременное разворачивание LDAP каталога, например на OpenLDAP. Некоторые сложности возникают в связи с отсутствием единой системы управления записями аутентификации (Kerberos) и каталога LDAP, удобной для промышленной эксплуатации (например, графической консоли, как это реализовано в MS Windows), а также отдельные хранилища учетных записей, что может обусловить необходимость в процедуре синхронизации и сверки записей. Здесь возможно пойти по нескольким путям, одним из которых является вынесение хранилищ в СУБД, однако этот путь представляется довольну трудоёмким, особенно для OpenLDAP, когда начальные работы и малейшие изменения в схеме могут потребовать серьёзных модификаций. Более приемлемым представляется вариант создания общего графического модуля, обеспечивающего одновременную модификацию в двух хранилищах, а также подготовка скриптовой процедуры сверки и синхронизации хранилищ учётных записей

• создать принципала (addprinc -randeky host/имя_узла@REALM, ktadd => /etc/krb5.keytab на клиенте)
• создать принципала (addprinc -randeky тип_сервиса/имя_узла@REALM, ktadd => /etc/krb5.keytab тот же keytab на клиенте)
• заместить ПО его кебиризованной версией в intet.d

Белонин С.С. (С), май 2004 года