Attributes: requires-pre-auth

Keytypes(salttype[(salt-value)]): des-cbc-crc(pw-salt),

des-cbc-md4(pw-salt), des-cbc-md5(pw-salt), des3-cbc-sha1(pw-salt)

kadmin> exit

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

Взвесим «за» и «против»

Итак, давайте взвесим, какие преимущества достигаются комбинацией Kerberos и LDAP. Быть может, не стоило все это и городить.

Перечислим положительные приобретения:

n  Вся аутентификационная и бюджетная информация хранится в одной базе и, значит, может быть архивирована единым образом.

n  Появляется возможность «заморозки» изменений в базе Kerberos, что позволяет сделать его работу более надежной.

n  Появляется второй канал репликации базы Kerberos за счет реплики LDAP. То есть возрастает доступность (availability) службы KDC.

Теперь подсчитаем отрицательные:

n  У KDC появляется зависимость от дополнительной службы, надежность предоставления сервиса которой надо гарантировать теперь вдвойне.

n  Хотя использование мастер-ключа не позволяет вскрыть или подменить ключи принципалов, но гарантия того, что они не будут простого уничтожены, теперь лежит на другом сервисе и его настройках. Значит, в подобной схеме хранения надежность определяется по наислабейшему компоненту. Скорее всего, таким нужно считать LDAP.

Во всех руководствах по созданию KDC записано требование размещать KDC на отдельном хосте, который более ничем не может быть занят. Ну разве что SSH для администрирования. Но здесь же основанием для сочетания Kerberos и LDAP главными были мотивы интегрального характера. С другой стороны, есть успешный пример такой интеграции – разработка фирмы Microsoft под названием ActiveDirectory. Конечно, вопросы безопасности нужно прорабатывать очень тщательно и применительно к конкретному составу приложений, которые будет обслуживать LDAP. Поскольку если в общей директории хранится еще и информация Kerberos, то надо будет оградить ее от потенциально небезопасных приложений.

Ну и последнее соображение. Как следует из материалов работы [5], использование LDAP в качестве хранилища увеличило среднее время обработки запроса с 8 мс до 2.4 с, то есть почти в 300 раз. Конечно, измерения проводились на области, содержащей 1000 принципалов, и на не очень сильном компьютере. Но даже с поправкой на закон Мура надо учитывать фактор снижения производительности при переводе системы на подобную конфигурацию.

Ссылки:

1. Заметки по настройке размещения пользовательских бюджетов в LDAP: http://www.barabanov.ru/arts/LDAPremarks-2.pdf.

2. Домашний сайт проекта Heimdal: http://www.pdc.kth.se/heimdal.

3. Схема для размещения информации Kerberos в LDAP: http://www.barabanov.ru/arts/kerberos_over_ldap/krb5-kdc.schema.

4. Лидер в области разработок АиА с использованием LDAP: http://www.padl.com.

5. Different database methods in Heimdal. Assar Westerlund, Swedish Institute of Computer Science: http://www.chips.chalmers.se/Chips/conference/made2000/presentations/danielsson.et.al.pdf.