Ldap kerberos authentication linux

• LDAP
• Kerberos

Information on this page may be partially out of date (2014). More recent information on setting up LDAP + Kerberos can be found at LDAP/OpenLDAPSetup#Kerberos

LDAP and Kerberos together make for a great combination. Kerberos is used to manage credentials securely (authentication) while LDAP is used for holding authoritative information about the accounts, such as what they’re allowed to access (authorization), the user’s full name and uid. You can also add in helpful things such as an external email address or a room number in a structured way.

Most other LDAP setups involve in storing passwords in the LDAP directory itself using the userPassword attribute. While this is ok for a basic setup, one can do much better with just a little effort.

Overview

This guide is intended as a Debian-focused update to excellent guides, such as http://aput.net/

jheiss/krbldap/howto.html. Many of the workarounds have been fixed in recent releases of Debian, however there are still a few places one can easily get snagged.

The goal of this document is to create a Single Sign-On (SSO) system without using NIS or passwords stored in LDAP. This includes a client setup which can successfully use Kerberos for authentication and LDAP for authorization. A number of common clients are shown, such as a standard shell login and Apache2 integration.

With LDAP comes many solutions to very similar problems. Many people use LDAP due to an existing Active Directory setup, so certain tools need to be used to deal with its quirks. As this guide starts from scratch, it can be done as simply as possible. By far the simplest way to integrate Kerberos + LDAP together on one system is to use PAM (authentication) and NSS (authorization).

This document was originally written based on experience with Debian/etch and Debian/lenny. Please update accordingly.

Kerberos server

There are plenty of guides for setting up a Kerberos server on Debian. Once you have a KDC set up with a test principal, come back to this document.

LDAP Server

See LDAP/OpenLDAPSetup to get your server set up.

Getting your feet wet with LDAP

A very helpful tool for getting one’s feet wet with LDAP is phpldapadmin. While it’s certainly no replacement for a proper account management system, it lets you create accounts and tinker with attributes while conforming to the schemas.

LDAP data structure

Starting an LDAP server from scratch can be a bit daunting, as it starts out as a blank, unstructured slate. One tool to help get started is the migrationtools package. If one is familiar with /etc/passwd and /etc/group, one can see how that then translates to the world of LDAP using /usr/share/migrationtools/migrate_passwd.pl and friends. See LDAP/MigrationTools for more information. These tools create posixGroup and posixAccount objects which the NSS module below is familiar with.

The common hierarchical structure of ou=Users,dc=example,dc=com and ou=Groups,dc=example,dc=com seems to work quite well for most software out-of-the-box.

Kerberos client

Install the following packages:

krb5-config krb5-clients krb5-user

The Kerberos client setup is pretty straightforward using the krb5-config package’s config.

If you’re having trouble, check the following:

ensure krb5.conf is set properly. Things to check for:

ensure your domain is mapped in the domain_realm section at the bottom; this is used by the GSSAPI LDAP integration and will cause weird problems if you happen to be in a subdomain of any of the defaults.

ensure your default_realm is proper

ensure your realm is defined in the realms section

You can test that Kerberos is set up properly by doing:

If everything’s working fine, you should see a ticket when you klist.

Client Login Setup

To set up a machine for logins using this style of LDAP+Kerberos, you need to set up PAM and NSS.

Instead of using LDAP PAM as described in LDAP/PAM, set up PAM to authenticate using Kerberos. Install libpam-krb5 and then proceed to /usr/share/doc/libpam-krb5/README.Debian.gz which has great directions to get going. If your Kerberos environment was properly set up above, then you should have logins working nicely.

Read over LDAP/PAM. While LDAP isn’t used for authentication, there are some handy tricks listed there for setting up login access restriction.

See LDAP/NSS to get started. There is nothing special you need to do beyond ensure that you properly configure /etc/libnss-ldap.conf.

libnss-ldap seems to work well for simple setups.

If you’re having trouble authenticating when everything else seems fine, try doing /etc/init.d/nscd restart or stopping the daemon entirely. It can get in the way when first setting up LDAP.

Once NSS is set up, restart SSH:

Apache2

Basic authentication over SSL

Basic + SSL is a quick way to set up restricted access to websites. It’s not the best, usability wise (this is usually the fault of most browsers for not exposing identity management at all), but it works well enough for most internal-use cases.

Set up PAM. Ensure that you can login to the server using LDAP + Kerberos credentials

install libapache2-mod-auth-pam libapache2-mod-auth-sys-group and then a2enmod auth_pam auth_sys_group

Set up SSL. You never want to do Basic authentication across the wild ‘net without some SSL protecting it. d-a.org article

In your virtual host for your given site, you can restrict a path as follows:

Other options are to use libapache2-mod-auth-kerb or libapache2-mod-authn-sasl, but neither of those provide group information from LDAP. It might be possible to pull that in using the authnz_ldap that comes with Apache2, but that module seems quite intent on performing the authentication phase, which is in our case is supposed to be handled by Kerberos, not LDAP.

Further Information Sources

Debian-LAN provides a complete implementation of kerberized LDAP

Источник

Kerberos и LDAP

Содержание

Kerberos и LDAP

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

Репликация баз данных учетных записей Kerberos между двумя серверами может усложниться и добавить дополнительную базу данных пользователей в вашей сети. К счастью MIT Kerberos может быть настроен на использование каталога LDAP как базы учетных записей.

Настройка OpenLDAP

Для начала требуется загрузить на сервер OpenLDAP необходимую схему, которая содержит поддержку соединения по сети с первичным и вторичным KDC. Кроме того эта глава подразумевает, что у вас настроена репликация LDAP между как минимум двумя серверами. Информацию по настройке OpenLDAP смотрите в разделе OpenLDAP сервер.

2. Далее распакуйте файл kerberos.schema.gz:

3. Схема kerberos должна быть добавлена к дереву cn=config. Процедура добавления новой схемы к slapd детально описана в секции Изменение базы данных настройки slapd.

Сначала создадим файл настроек с именем schema_convert.conf или другим значащим именем, содержащим следующие строки:

Создадим временный каталог для хранения LDIF файлов:

Теперь используем slapcat для конвертирования файлов схемы:

Измените имена файла и каталога выше для соответствия вашим именам, если они отличаются.

Отредактируйте созданный файл /tmp/cn\=kerberos.ldif, изменив следующие атрибуты:

и удалите следующие строки в конце файла:

Значения атрибутов могут отличаться, просто убедитесь, что атрибуты удалены.

Загрузите новую схему с помощью ldapadd:

Добавьте индекс для атрибута krb5principalname:

В конце обновите списки контроля доступа (ACL ):

Настройка первичного KDC

С настроенным OpenLDAP самое время настроить KDC.

1. Сначала установим необходимые пакеты, введя из терминала:

2. Теперь редактируем /etc/krb5.conf добавив следующие опции в соответствующие секции:

3. Далее используем утилиту kdb5_ldap_util для создания области:

5. Копируем сертификат CA из сервера LDAP :

и редактируем /etc/ldap/ldap.conf для использования этого сертификата:

Теперь будут добавлены атрибуты krbPrincipalName, krbPrincipalKey, krbLastPwdChange и krbExtraData к объекту пользователя uid=steve,ou=people,dc=example,dc=com. Используйте утилиты kinit и klist для проверки, что пользователю действительно выдали билет.

Настройка вторичного KDC

1. Сначала установим необходимые пакеты. Введите в терминале:

2. Далее редактируем /etc/krb5.conf для использования LDAP :

3. Создаем тайник для пароля соединения с LDAP :

4. Теперь на первичном KDC копируем /etc/krb5kdc/.k5.EXAMPLE.COM тайник с главным ключом на вторичный KDC. Убедитесь что копирование файла происходит через зашифрованное соединение, такое как scp или через физический носитель.

5. Возвращаемся на вторичный KDC чтобы только (пере)стартовать ldap сервер:

6. И в конце стартуем сервис krb5-kdc:

7. Убедитесь, что два ldap сервера (и kerberos вдобавок) синхронизированы.

Ссылки

Kerberos Admin Guide содержит некоторые дополнительные детали.

Для дополнительной информации по kdb5_ldap_util смотрите главу 5.6 и страницу руководства kdb5_ldap_util.

Также смотрите Kerberos и LDAP на Ubuntu wiki.

Источник

9. Kerberos KDC с использованием OpenLDAP в качестве бэкэнда и аутентификацией SASL GSSAPI

В этом разделе мы научимся использовать OpenLDAP 2.4 в качестве хранилища принципалов (principals) Kerberos и разберем, как настраивать клиентские рабочие станции. Kerberos — это сетевой протокол, который работает на основе билетов (tickets) и позволяет передавать данные через незащищённые сети для безопасной идентификации и аутентификации. Его дизайн преимущественно опирается на клиент-серверную модель и позволяет произвести взаимную аутентификацию субъекта и объекта доступа. Сообщения протокола устойчивы к прослушиванию и атакам повтора. Kerberos работает на основе криптографии с симметричным ключом и требует наличия доверенной третьей стороны, а так же может применяться с использованием криптографии с открытым ключом на некоторых этапах процесса аутентификации.

В этом руководстве в роли сервера Kerberos будем использовать ldap-srv. Но ничто не мешает Вам использовать для этого отдельную машину.

9.1 Настройка сервера

Где работаем: ldap-srv

Включите NTP и убедитесь, что сервер и клиенты синхронизированы! Мы не будем описывать, как настраивать NTP. Вы можете найти множество примеров в сети, если потребуется.

Теперь, когда наш сервер OpenLDAP настроен, мы можем приступить к конфигурированию сервера Kerberos. В этом разделе мы опишем, как развернуть центр распределения ключей Kerberos (KDC, Key Distribution Center) для области (realm) EXAMPLE.COM. Начнём с установки необходимых пакетов. В процессе будет так же установлено несколько пакетов-зависимостей. Пакет wamerican создаст файл /usr/share/dict/words, используемый kadmind. Вместо него можно использовать любой другой словарь или несколько словарей. Чтобы посмотреть их список, посмотрите содержимое метапакета wordlist.

В разделе 2.5 мы уже установили схему Kerberos для OpenLDAP сервера, но давайте лишний раз убедимся, что она на месте:

Схема на месте. В ней содержится достаточно много объектов. Чтобы посмотреть их все, используйте следующий запрос:

Эта команда должна вернуть список объектов. Это важно, потому что если новых атрибутов Kerberos LDAP нет, то kdb5_ldap_util(8) выдаст следующую ошибку:

Итак, у нас есть набор схемы данных и объекты. Но есть ли у нас контейнер для принципалов Kerberos?

Нет, нету. Создадим его, а заодно — пользователя и группу, которые будут использоваться Kerberos для взаимодействия с сервером OpenLDAP. Используем для этой цели вот такой LDIF-файл 9.1-kerberos.ldif:

Загрузим этот файл в базу данных нашего сервера каталогов:

Зададим пароль для пользователя krbadmin. Сохраните пароль в надежном месте (например, используя keepass или gpg).

Создадим конфигурационный файл Kerberos /etc/krb5.conf:

Теперь создадим список контроля доступа (ACL) администратора Kerberos. Не путайте этот ACL с ACL OpenLDAP. Это не одно и то же. Чуть ниже мы поработаем с ACL для OpenLDAP. Создадим файл /etc/krb5kdc/kadm5.acl с таким содержимым:

Отредактируем /etc/krb5kdc/kdc.conf, конфигурационный файл службы аутентификации (AS, Authentication Service) и центра распределения ключей (KDC):

В отдельном терминале включите просмотр журнала сервера OpenLDAP. Так мы сможем увидеть сообщения, генерируемые командой kdb5_ldap_util(8):

Создайте каталог-тайник для пароля. В файле /etc/krb5.conf он указан в переменной ldap_service_password_file :

Извлеките пароль пользователя cn=krbadmin,ou=users,dc=example,dc=com , используя kdb5_ldap_util(8):

Вам будет предложено ввести мастер-пароль базы данных. Очень важно, чтобы Вы НЕ ЗАБЫЛИ этот пароль!

В основном терминале выполните следующую команду для добавления записей Kerberos в базу данных OpenLDAP:

Вышеуказанная команда создаст несколько записей в cn=kerberos,ou=services,dc=example,dc=com . Чтобы увидеть их, выполните запрос:

Но может ли кто-нибудь кроме пользователя cn=admin увидеть нашу информацию Kerberos? Это было-бы не очень мудро. Поэтому давайте взглянём на ACL нашего сервера OpenLDAP:

Что нам надо сделать, так это дать права доступа на чтение/запись администратору Kerberos ( cn=krbadmin,ou=users,dc=example,dc=com ) к поддереву cn=kerberos,ou=services,dc=example,dc=com . Никакой другой пользователь не должен иметь доступа к этой информации (за исключением администратора каталога).

Для этого сформируем LDIF-файл 9.1-kerberos.acl.ldif:

Загрузим данные в сервер каталогов:

Убедитесь, что новые ACL работают. Суперпользователь и пользователь cn=admin,dc=example,dc=com должны иметь доступ к поддереву cn=kerberos,ou=services,dc=example,dc=com . Пользователь cn=nssproxy,ou=users,dc=example,dc=com не сможет обнаружить само существование контейнера Kerberos, а cn=krbadmin,ou=users,dc=example,dc=com должен не только видеть контейнер, но и иметь для него права на чтение/запись. Мы так же должны убедиться, что обычные пользователи всё ещё могут использовать сервер OpenLDAP для аутентификации и что они могут менять себе пароли.

Этот запрос возвращает поддерево cn=kerberos,ou=services,dc=example,dc=com :

Следующий запрос должен завершиться с ошибкой No such object (32) :

Теперь с клиентской машины убедимся, что пользователь, учётная запись которого хранится на сервере каталогов, может менять свой пароль:

Где работаем: ldap-client

Где работаем: ldap-srv

Настало время настроить журналирование. Для начала добавим в конфигурацию rsyslog следующие строки (/etc/rsyslog.conf):

Создадим файлы журналов и зададим для них права доступа:

Настроим logrotate. Создадим два конфигурационных файла.

Файл /etc/logrotate.d/krb5kdc для демона krb5-kdc:

Файл /etc/logrotate.d/kadmind для демона krb5-admin-server:

Перезапустим демон rsyslog, чтобы конфигурация вступила в силу. Добавим демоны krb5-kdc и krb5-admin-server в автоматический запуск, затем запустим их:

Загляните в журнал /var/log/krb5kdc.log. Вы должны увидеть там подобную строку:

Проверим, что наши демоны слушают необходимые порты. Порт 88 (krb5kdc), порты 464 и 749 (kadmind):

Поздравляю, теперь у Вас есть рабочий сервер аутентификации (AS) и сервер распределения ключей (KDC) MIT Kerberos 5!

Что дальше? В первую очередь нам необходимо создать принципал для локального сервера. Затем — принципал для пользователя test.user. Сделаем это так (разобъём вывод на части, чтобы добавить комментарии):

Здесь мы создаём принципал машины для текущего сервера (на котором залогинены). Далее жирный шрифт — вводимый нами текст:

После создания принципала сервера мы можем добавить его в набор ключей Kerberos (/etc/krb5.keytab):

Следующим шагом создадим принципал для моего пользователя pablo и зададим для него пароль:

Теперь создадим принципал пользователя с правами администратора. Помните файл /etc/krb5kdc/kadm5.acl? Вот где он вступает в игру. С помощью этого файла пользователи с префиксом /admin имеют права администратора на доступ к области Kerberos. Это значит, что они могут создавать и удалять записи пользователей и политики доступа. Поэтому убедитесь, что Вы знаете этих пользователей и доверяете им!

Посмотрим список текущих принципалов в области:

А эта команда выведет подробную информацию о принципале host/ldap-srv.example.com@EXAMPLE.COM:

Обратите внимание, что был создан новый файл /etc/krb5.keytab. Вот почему мы запустили бинарник kadmin.local от имени суперпользователя. Иначе мы получили бы следующую ошибку:

Только суперпользователь имеет доступ на чтение к файлу-тайнику (/etc/krb5.d/stash.keyfile).

Давайте посмотрим, что записано в /etc/krb5.keytab:

Как мы можем видеть, это список ключей шифрования машины ldap-srv. Неудивительно, что доступ предоставлен только суперпользователю!

У нас осталась ещё одна вещь на сервере, которую надо поправить. Это ошибка в журнале /var/log/slapd.log. Создадим LDIF-файл 9.1-kerberos.indexes.ldif, который внесёт поправки в индексы:

Добавим эти индексы в сервер каталогов:

Отлично! Теперь у нас есть настроенный KDC!

9.2 Настройка клиента

С действующим KDC мы можем заставить клиентские машины и сервисы использовать его. Обозначим основные цели по настройке клиентов, чтобы интегрировать их в инфраструктуру Kerberos:

1. 1. Аутентификация Kerberos для sshd.
2. 2. Аутентификация OpenLDAP с помощью SASL GSSAPI.
3. 3. Применение аутентификации SASL GSSAPI для AutoFS.

9.2.1 Аутентификация Kerberos для sshd

Где работаем: ldap-client

ВНИМАНИЕ! Клиенты Kerberos должны иметь возможность подключения к TCP портам KDC с номерами 88 и 749!

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

Во время установки в качестве области Kerberos можете задать EXAMPLE.COM, а в качестве серверов, обслуживающих область, ldap-srv.example.com.

Отредактируйте конфигурацию клиента в файле /etc/krb5.conf следующим образом:

Создайте новый принципал машины для этого хоста. Мы запускаем команду kadmin от имени суперпользователя, чтобы можно было записать результирующий файл /etc/krb5.keytab. Иначе мы получим не очень понятную ошибку No such file or directory while adding key to keytab . Мы так же должны использовать модификатор -p , чтобы дать понять команде kadmin, от имени какого принципала мы хотим подключиться. Если мы его не зададим, то получим ошибку Client not found in Kerberos database while initializing kadmin interface , потому что не создавали принципал root/admin@EXAMPLE.COM. Не создавайте этот принципал! Мы хотим знать, кто подключается с правами администратора (пользователи с префиксом /admin). Если создадим — не сможем различать администраторов между собой.

Эта команда создала файл /etc/krb5.keytab.

Теперь мы можем отредактировать /etc/ssh/sshd_config и включить аутентификацию Kerberos. Не забудьте добавить test.group в директиву AllowGroups . Иначе мы не сможем протестировать конфигурацию и увидим ошибку в файле /var/log/auth.log.

Запустите на клиентской рабочей станции отображение файла журнала:

А пока вернёмся на сервер.

Где работаем: ldap-srv

Создадим принципал пользователя test.user:

Возьмём билет Kerberos у test.user и прикинемся этим пользователем. Сначалы мы уничтожим свои собственные билеты (если они есть), используя kdestroy, затем возьмём билет test.user с помощью kinit, а в итоге проверим, что он у нас есть с помощью klist:

Теперь попробуем авторизоваться на клиенте без пароля, используя этот билет:

Где работаем: ldap-client

В открытом нами журнале на клиенте /var/log/auth.log мы должны увидеть что-то подобное:

Успех! Переходим к следующей цели.

9.2.2 Аутентификация OpenLDAP с помощью SASL GSSAPI

Где работаем: ldap-srv

Для настройки аутентификаци SASL GSSAPI мы должны изменить конфигурацию сервера OpenLDAP таким образом, чтобы он знал о существовании нашей области Kerberos. После этого мы можем настроить клиентов.

Подключимся к KDC и создадим новый принципал. Мы по-прежнему запускаем kadmin от имени суперпользователя, потому что хотим создать новый набор ключей в файле /etc/ldap/krb5.keytab, чтобы наш демон slapd имел свой набор.

Поменяем права доступа на этот файл, чтобы демон slapd смог его читать:

Создадим LDIF-файл 9.2.2-sasl.ldif с директивами SASL:

И загрузим его в базу данных службы каталогов:

На самом деле нам не нужно играться с olcSaslSecProps , но я оставил его, потому что пытался добавить ключевое слово noactive . Если при этом попытаться выполнить поиск, то получим следующую ошибку:

В данный момент такое поведение — не совсем то, что нам нужно. Может быть позже. Сейчас проверим, загрузил ли демон slapd нашу конфигурацию SASL:

Хорошо! Теперь нам нужно добавить параметр KRB5_KTNAME в файл /etc/default/slapd:

Для того, чтобы изменения вступили в силу, нам нужно перезапустить демон slapd:

Демон slapd снова запущен — мы можем переходить к настройке клиента.

Где работаем: ldap-client

Зайдём на клиентскую рабочую станцию по ssh от имени пользователя pablo:

Получим билет от KDC:

Все настройки для доступа на сервер у нас уже внесены в файл /etc/ldap/ldap.conf. Проверим, можем ли мы сделать запрос к LDAP-серверу:

Такая ошибка может показаться странной. Нужно указать механизм GSSAPI для доступа с помощью SASL. Такой вариант должен сработать:

Супер! Добавленный модификатор мы тоже можем внести в /etc/ldap/ldap.conf, чтобы его не приходилось вбивать вручную каждый раз:

Вы заметили, что OpenLDAP преобразовал имя принципала Kerberos в формат DN (Distinguished Name)? У нас был принципал с таким именем:

pablo@EXAMPLE.COM

… который был преобразован slapd в это:

dn:uid=pablo,cn=example.com,cn=gssapi,cn=auth

Это значит нам нужно вернуться на сервер и задать новые правила доступа (ACL), если мы хотим, чтобы наш Kerberos-принципал AutoFS мог читать информацию для автоматического монтирования.

9.2.3 Применение аутентификации SASL GSSAPI для autoFS

Вздохните поглубже, далее от Вас потребуется внимательность и терпение. 😉

Где работаем: ldap-srv

Вернёмся на наш сервер OpenLDAP и отредактируем правила доступа ACL. Но прежде чем мы продолжим, всегда неплохо проверить текущую конфигурацию. Теперь мы можем формировать запросы с использованием GSSAPI (без модификатора -x ):

Запрос вернёт нам четыре DN с атрибутами olcAccess :

Мы должны изменить ACL для olcDatabase=<0>config и olcDatabase=<1>mdb . Приготовьтесь, ACL станут немного сложней. Создадим LDIF-файл 9.2.3-gssapi.acl.ldif и запишем в него:

Ух! Вы поняли все производимые изменения? Напоминаю, что cn=admin,dc=example,dc=com ( RootDN ) всегда имеет полный доступ к olcDatabase=<1>mdb,cn=config . То же касается и olcDatabase=<0>config . Поэтому cn=admin явно не упомянут в ACL. Не волнуйтесь и внимательно прочитайте правила, одно за другим. У Вас всё получится 😉

Изменения масштабные, поэтому сделаем резервную копию на случай, если всё пойдёт наперекосяк:

Загрузим новые ACL в конфигурацию OpenLDAP:

Проверим, что cn=admin,dc=example,dc=com имеет права доступа к базе данных сервера OpenLDAP. Следующий запрос должен вернуть dn: cn=config :

Суперпользователь с UID и GID равными нулю имеет аналогичный уровень доступа:

Такой же уровень доступа имеют принципалы с префиксом /admin. Получим билет принципала и выполним запрос от его имени с помощью SASL:

Проверьте, работают ли права для пользователя cn=nssproxy . Следующая команда должна вернуть все DN из DIT кроме записей, в которых присутствует cn=kerberos :

А могут ли обычные пользователи менять свой пароль? Проверим это с клиентской рабочей станции.

Где работаем: ldap-client

Процесс обновления пароля изменился. Если мы попытаемся запустить команду passwd от имени пользователя, которого нет в локальном файле /etc/passwd, пароль будет изменен с использованием механизмов Kerberos:

Для спокойствия убедимся, что пароль поменялся в нужном месте. Сверим текущее время и время изменения пароля в принципале test.user@EXAMPLE.COM. Они должны различаться незначительно.

Время изменения пароля записывается в принципалах в атрибуте krbLastPwdChange . Запись содержит время по Гринвичу (GMT). Поэтому для начала посмотрим текущее время GMT на клиентской машине:

Теперь получим билет администратора, чтобы заглянуть в атрибуты принципала test.user@EXAMPLE.COM.

И наконец, отправим вот такой длиннющий запрос (ответ сервера — только последняя строчка) к серверу каталогов по атрибуту krbLastPwdChange :

Как мы можем видеть, пароль принципала test.user@EXAMPLE.COM был изменён четыре минуты назад (буква Z указывает на время по Гринвичу). Замечательно!

Теперь мы можем настроить клиентскую машину для использования механизма GSSAPI в работе с картами автомонтирования AutoFS. На этом этапе Вы должны быть авторизованы на клиентской машине от имени пользователя, домашний каталог которого не лежит на сервере NFS! Если это не так, авторизуйтесь повторно.

Перед тем как продолжить, проверьте, отмонтированы ли все каталоги NFS:

Проверьте общесистемную конфигурацию AutoFS в файле /etc/defaults/autofs:

Заметьте, что атрибут LOGGING установлен в значение debug , а OPTIONS — в -d -v . Это для того, чтобы помочь нам с поиском проблем, если они возникнут. В рабочей конфигурации этот параметр должен быть изменён. Мы вернёмся к этому через пару минут.

Далее нам нужно создать принципал Kerberos для демона autofs. Мы так же должны добавить ключи этого нового принципала в набор ключей нашего клиента.

Как мы можем видеть, ключи autofsclient теперь являются частью набора ключей клиента:

Теперь мы можем изменить порядок аутентификации autofs в файле /etc/autofs_ldap_auth.conf, используя механизм GSSAPI и новый принципал:

Перезапустим демон autofs:

Проверим журнал /var/log/syslog, всё ли работает?

Отлично! Попробуем перейти в каталог /nfs/home:

Супер! Изменим атрибуты LOGGING и OPTIONS в файле /etc/defaults/autofs на повседневные:

И перезапустим демон autofs:

Вот и всё! На этом фокусы с Kerberos закончились. 🙂

В следующем разделе мы опишем, как создавать резервную копию сервера OpenLDAP и восстанавливаться из неё. Затем мы настроим репликацию. Принимая во внимание зависимость наших клиентов от сервера OpenLDAP, нам надо обеспечить некоторый уровень отказоустойчивости.

OpenLDAP и Ubuntu на практике > Kerberos KDC с использованием OpenLDAP в качестве бэкэнда и аутентификацией SASL GSSAPI

Источник