Введение в круг понятий Kerberos  
  Обзор Kerberos  


Настоящие материалы являются авторскими, права автора защищены Законами РФ и международными соглашениями. Для использования настоящих материалов вам необходимо ознакомиться и полностью принять лицензионное соглашение. В случае, если вы не принимаете настоящее лицензионное соглашение полностью, вы не имеете права пользоваться настоящими материалами


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, в которой должны быть включены административные привелегии для администратора и пользовательские для пользователей

 
  Использование DNS  

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

- либо правила в 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)

 
  Cоздание новой базы  

  • подготовить файлы конфигурации /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
 
  Cоздание slave KDC - для каждого KDC  

  • создать принципала для каждого хоста с сервером 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 года

(даты последующих модификаций не фиксируются)


 
     
   
   
    Нравится      

(C) Белонин С.С., 2000-2018. Дата последней модификации страницы:2018-01-09 13:25:38