Регистрация Войти
Рейтинг:0
avatar Server

KDC не поддерживает тип шифрования при аутентификации в OpenLDAP.

флаг fr
Lars Hanke

Я использую сервер аутентификации Kerberos/LDAP уже много лет. Данные Kerberos хранятся внутри LDAP. Теперь у меня есть второй сайт, и я хочу отразить сервер на новом сайте. Это в основном работает, но есть странный побочный эффект. На каждом сервере работают KDC и LDAP. KDC общается с LDAP, используя локальный ldapi:///.

Если я использую оригинальный KDC krb1.example.com Я могу аутентифицироваться на главном LDAP и реплике. Если я использую реплицированный KDC krb2.example.com, я все еще могу аутентифицироваться на главном LDAP, но пробуя реплику, я получаю

Аутентификация SASL/GSSAPI запущена
ldap_sasl_interactive_bind_s: локальная ошибка (-2)
        дополнительная информация: SASL(-1): общий сбой: ошибка GSSAPI: неопределенный сбой GSS. Второстепенный код может предоставить дополнительную информацию (KDC не поддерживает тип шифрования)

Что странно, поскольку крб2 буквально клон контейнера LXC крб1 то естьконфигурации идентичны, безопасны для изменений, необходимых для репликации. Но еще больше озадачивает просмотр кэшей билетов после попытки запроса любого из серверов LDAP. С TGT от крб1

root@krb2:/# klist -e
Кэш билетов: ФАЙЛ:/tmp/krb5_cc_0.tkt
Принципал по умолчанию: [email protected]

Действительный начальный срок действия субъекта-службы
04.02.2022 01:05:29 04.02.2022 11:05:29 krbtgt/[email protected]
        продлевать до 05.02.2022 01:05:26, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
04.02.2022 01:05:42 04.02.2022 11:05:29 ldap/[email protected]
        продлевать до 05.02.2022 01:05:26, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
04.02.2022 01:05:53 04.02.2022 11:05:29 ldap/[email protected]
        продлевать до 05.02.2022 01:05:26, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

и из крб2:

root@krb2:/# klist -e
Кэш билетов: ФАЙЛ:/tmp/krb5_cc_0.tkt
Принципал по умолчанию: [email protected]

Действительный начальный срок действия субъекта-службы
04.02.2022 00:53:45 04.02.2022 10:53:45 krbtgt/[email protected]
        продлевать до 05.02.2022 00:53:41, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
04.02.2022 00:53:47 04.02.2022 10:53:45 ldap/[email protected]
        продлевать до 05.02.2022 00:53:41, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

который не имеет входа для ldap/krb2.example.com из-за ошибки. Но, по-видимому, нет никакой разницы в требуемых типах шифрования. Итак, почему он жалуется?

В настоящее время оба сервера LDAP относятся к крб1. Но из-за репликации LDAP все ключи должны быть идентичными, т.е. ключ из крб1 должно быть таким же, как из крб2, не так ли? А если ключи от крб1 работают для обоих серверов LDAP, почему ключ от сервера-реплики работает только для главного LDAP?

поддерживаемые_enctypes для царства в обоих /etc/krb5kdc/kdc.conf находятся support_enctypes = aes256-cts:нормальный arcfour-hmac:нормальный des3-hmac-sha1:нормальный des-cbc-crc:нормальный des:нормальный des:v4 des:norealm des:onlyrealm des:afs3. Ни в одном из них нет директив enctype. /etc/krb5.conf. Нет ссф конфигурация, используемая в любом LDAP. krbPrincipalName записи для крб2 существуют в обоих LDAP.

Даже если я получу TGT от крб2 а затем переключите krb5.conf к крб1 для билета службы я могу аутентифицироваться в LDAP на крб2.

Версия OpenLDAP 2.4.47, Kerberos 1.17 на обеих машинах (текущая стабильная версия Debian).

Обновлять: Оказалось, что репликация неполная, т.е. krbPrincipalKey не (надежно) реплицируется. я проверил slapd вывод отладки:

9 февраля 19:14:52 krb1 slapd[19560]: conn=1300 op=3 BIND authcid="sync/[email protected]" authzid="dn:uid=sync/krb2.example.com, cn=example.com,cn=gssapi,[email protected]"
9 февраля 19:14:52 krb1 slapd[19560]: conn=1300 op=3 BIND dn="cn=admin,dc=example,dc=com" mech=GSSAPI sasl_ssf=256 ssf=256

Так, синпров видимо связывает как cn=admin,dc=пример,dc=com, что и предназначено. Однако, если я сделаю

root@krb1:~# ldapsearch -b 'cn=KERBEROS,dc=example,dc=com' -D 'cn=admin,dc=example,dc=com' -Wx 'krbPrincipalName=ldap/krb2.example.com@ ПРИМЕР.COM'

тогда я вижу krbPrincipalKey. Так почему же это не тиражируется?

я перезагружаю slapd на крб2 с опциями -c рид=1,csn=0, который, как я понял, должен синхронизировать всю базу данных. Но поскольку у некоторых записей есть ключ, а у некоторых нет, я не верю, что это правда.

100
0 + 0
user1686 avatar
флаг fr
user1686
Что именно вы подразумеваете под «В настоящее время оба сервера LDAP относятся к krb1»? Вы говорите о KDC в krb5.conf, или о keytab, или о чем-то еще?
0
Ответить
user1686 avatar
флаг fr
user1686
Можете ли вы показать фактический процесс аутентификации, который не работает? Если контейнеры являются точными клонами, знает ли служба LDAP на kdc2, что она теперь называется `ldap/kdc2`, а не `ldap/kdc1`, т. оригинальный ключ?
0
Ответить
флаг fr
Lars Hanke
Да, имя хоста, IP-адрес, запись DNS, keytab, сертификаты TLS были адаптированы для соответствия новому экземпляру.
0
Ответить
флаг fr
Lars Hanke
Итак, что я сделал: ldapsearch -b "cn=admin,dc=example,dc=com" -H ldap://kdc?.uac.microsult.de. Установив /etc/krb5.conf в kdc2, я могу выполнить kinit, я могу запросить kdc1, но kdc2 не работает. Если затем я изменю kdc на krb1 в /etc/krb5.conf, запрос к kdc2 также завершится успешно, используя тот же самый билет.
0
Ответить
user1686 avatar
флаг fr
user1686
Можете ли вы вручную запросить билет у KDC «kdc2», используя «KRB5_TRACE=/dev/stderr kvno ldap/kdc2.uac.microsult.de», и если это не удастся, что krb5kdc сообщит в свой файл журнала? Можете ли вы убедиться, что оба KDC имеют одинаковую информацию в своих репликах LDAP (например, путем сброса их обоих через slapcat или через ldapsearch с аутентификацией rootdn/rootpw)? Можете ли вы запустить `kadmin.local` в обоих KDC, чтобы проверить, что они знают о принципале ldap/kdc2?
0
Ответить
user1686 avatar
флаг fr
user1686
Ах, и вы действительно не должны иметь этот параметр «supported_enctypes»… он, вероятно, не _вредит_ (пока), но список уже довольно устарел, и его явная настройка не служит никакой хорошей цели.
0
Ответить
флаг fr
Lars Hanke
Подсказка ```kadmin.local``` показала, что на сервере-реплике на самом деле нет ключей для некоторых принципалов. Я не видел этого, поскольку мой главный администратор для LDAP не видит ключей из-за ACL, то есть записи выглядели одинаково на обоих серверах. Однако субъект репликации должен видеть ключи. Так что, похоже, мне нужно устранить неполадки в ACL ``slapd``` и Authzid. Я еще не нашел подходящего значения отладки, чтобы увидеть, какие пользователи используют какой authzid для какого DN. Но это, по крайней мере, чисто проблема конфигурации LDAP.
0
Ответить
user1686 avatar
флаг fr
user1686
Уровень журнала `stats` был бы хорошим началом.
0
Ответить
Рейтинг:0
avatar Server
флаг fr
Lars Hanke

Проблема была решена путем бездельник основная база данных и слападд с нуля на потребителя.

Спасибо пользователю 1686 за то, что он указал на вещи, которые нужно проверить, чтобы заставить меня разорвать круговые мысли.

Причина проблемы заключалась в том, что некоторые участники Kerberos в LDAP не имели krbPrincipalKey атрибут. ldap/krb2.example.com будучи одним из тех. Это стало очевидным при использовании get_principal в kadmin.local на каждом сервере. Путаница возникла из-за использования неподходящего DN связывания и связанного с ним ACL. Кроме того, я был уверен, что использовал опционы для slapd для повторной выборки всей базы данных при запуске, чего не произошло.

Некоторые подводные камни, которые держали меня в ловушке: Поскольку с включенным TLS -Y ВНЕШНИЙ не работает, я использую специальные принципы Kerberos для обслуживания базы данных. Мой руководитель для cn=config не имеет доступа к учетным данным, хранящимся в основной базе данных, о чем я больше не знал. Таким образом, сравнение записей двух LDAP дало идентичные результаты. Хотя фактический участник репликации имеет доступ к учетным данным, я, вероятно, изначально использовал другое DN привязки, то есть до того, как я настроил Kerberos для репликации. Таким образом, записи, созданные в течение этого периода времени, были реплицированы без учетных данных, и синхронизация не исправить это позже.

0 + 0
флаг Moldova
Admin
Этот вопрос на других языках:

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.