☰

LDAP syncrepl с аутентификацией Kerberos

tag-icon • tag-icon ldap replication openldap kerberos
LDAP syncrepl с аутентификацией Kerberos

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

При запуске потребителя возникает следующая ошибка:

GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information 
(Credentials cache file '/tmp/krb5cc_55' not found)

Я думаю, это означает, что у потребителя нет действительного TGT. Как мне настроить потребителя, чтобы получить действительный TGT? Я читал некоторые старые источники, которые рекомендуют использовать k5start или задание cron. Это все еще способ сделать это?

На страницах руководства slapd.conf указано, что authcidи authzidможет использоваться в сочетании с bindmethod=sasl, но не указано, как их следует форматировать. Должен ли я указать здесь DN или принципал kerberos или, может быть, что-то еще? Нужно ли мне указывать их?

спасибо за помощь

Конфигурация потребителя:

database        bdb
suffix          "dc=example"
rootdn          "uid=someuser,cn=realm,cn=gssapi,cn=auth"
directory       /var/lib/ldap
dirtyread
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100
syncrepl rid=1
    provider=ldap://provider.realm
    type=refreshAndPersist
    starttls=yes
    searchbase="dc=example"
    schemachecking=off
    bindmethod=sasl
    saslmech=gssapi
    retry="10 +"

Конфигурация провайдера

database        bdb
suffix          "dc=example"
rootdn          "uid=someuser,cn=realm,cn=gssapi,cn=auth"
directory       /var/lib/ldap
dirtyread
overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

решение1

Я думаю, это означает, что у потребителя нет действительного TGT.

Да, именно это и означает.

Как настроить потребителя для получения действительного TGT? Я читал некоторые старые источники, которые рекомендуют использовать k5start или cron job. Это все еще способ сделать это?

Не уверен насчет cron, но k5start все равно хороший метод.

Но недавняя версия Kerberos от MIT поддерживает встроенный метод, называемыйинициирование keytab клиента, который гораздо проще в настройке: просто добавьте $KRB5_CLIENT_KTNAMEв среду slapd и укажите тот же файл, что и $KRB5_KTNAME. (Это предполагает, что у вас есть отдельная keytab для ldap/*. Так и должно быть.)

И наконец, вы можете указать slapd использовать gss-proxy, который похож на ssh-agent для Kerberos. Установите GSS_USE_PROXY=1и настройте /etc/gssproxy для распознавания slapd как инициатора (клиента) и акцептора (сервера).

На страницах руководства slapd.conf указано, что authcid и authzid можно использовать вместе с bindmethod=sasl, но не указано, как их следует форматировать. Должен ли я указать здесь DN или принципал kerberos или что-то еще? Нужно ли мне указывать их?

Я не помню, с какой цельюauthcidобслуживается с помощью GSSAPI (если таковой имеется) – IIRC, этот механизм автоматически использует идентификатор, определенный из вашего тикета, поэтому нет необходимости указывать его вручную.

На принимающей стороне slapd преобразует полученный принципал Kerberos в псевдо-DN, например uid=foo@realm,cn=gssapi,cn=auth, и вы можете использовать его в списках контроля доступа напрямую или использоватьauthz-регулярное выражение(также известный какolcAuthzRegexp), чтобы перевести его в более удобное DN.

Тем временем,authzidработает одинаково независимо от механизма. Это необязательно, но если вы его указываете, то это должно быть либо DN с префиксом dn:, либо имя пользователя с префиксом u:. (Здесь имена пользователей, как и authcids, преобразуются в псевдо-DN и проходят черезolcAuthzRegexp, и используется полученное DN.)

Если политики позволяют, то slapd предоставит вам привилегии, имеющиеся у authzid. (Это как sudo для LDAP.)

решение2

Я получил syncrepl с аутентификацией Kerberos, работающую со следующей конфигурацией.Этот сайтabout nslcd.conf говорит, что это authzidдолжно быть в форме "dn:<отличительное имя>" или "u:<имя пользователя>". Я также использовал k5start для создания файла кэша для someuser@REALMat /tmp/krb5cc_55и сделал chown ldap:ldap. Обратите внимание, что 55 — это ldap uid; однако я не уверен, что нужно называть файл так. В конфигурации моего провайдера я указал someuserкак rootdnразрешить ему доступ ко всей базе данных.

Я просто хочу пояснить, что это то, что сработало у меня, но у меня ограниченное понимание LDAP, поэтому я не могу гарантировать, что это будет работать где-то еще, и я не знаю, все ли в этой конфигурации необходимо.

syncrepl rid=1
    provider=ldap://provider.realm
    type=refreshAndPersist
    starttls=yes
    searchbase="dc=realm"
    schemachecking=off
    retry="10 +"
    tls_cacert="/path/to/ca.crt"
    bindmethod=sasl
    saslmech=gssapi
    authcid="someuser@REALM"
    authzid="uid=someuser,cn=realm,cn=gssapi,cn=auth"

Связанный контент