Я пытаюсь настроить сервер репликации для 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
Я думаю, это означает, что у потребителя нет действующего TGT.
Да, именно это и означает.
Как настроить потребителя для получения действительного TGT? Я читал некоторые старые источники, которые рекомендуют использовать k5start или задание cron. Это все еще способ сделать это?
Не уверен в cron, но k5start все еще хороший метод.
Но недавний MIT Kerberos поддерживает встроенный метод, называемый запуск ключа клиента, который намного проще настроить: просто добавьте $KRB5_CLIENT_KTNAME в среду slapd и укажите его в том же файле, что и $KRB5_KTNAME. (Предполагается, что у вас есть отдельная вкладка для ldap/*. Вам следует.)
И, наконец, вы можете указать slapd использовать gss-proxy, который похож на ssh-agent для Kerberos. Устанавливать GSS_USE_PROXY=1 и настройте / etc / gssproxy для распознавания slapd как инициатора (клиента) и как получателя (сервера).
На страницах руководства slapd.conf указано, что authcid и authzid могут использоваться вместе с bindmethod = sasl, но не указывает, как они должны быть отформатированы. Стоит мне поставить здесь DN или принципала kerberos или может что-то еще? Мне нужно это указывать?
Я не могу вспомнить, с какой целью авторизация обслуживает GSSAPI (если вообще есть) - IIRC, этот механизм автоматически использует идентификатор, определенный из вашего билета, поэтому нет необходимости указывать его вручную.
На принимающей стороне slapd преобразует полученный принципал Kerberos в псевдо-DN, например uid=foo@realm,cn=gssapi,cn=auth, и вы можете использовать его напрямую в ACL или использовать authz-regexp (он же olcAuthzRegexp), чтобы перевести его в более красивый DN.
Между тем, Authzid работает одинаково независимо от механизма. Это необязательно, но если вы его укажете, тогда это должно быть либо DN с префиксом dn:, или имя пользователя с префиксом u:. (Здесь имена пользователей, такие как authcids, преобразуются в псевдо-DN и проходят через olcAuthzRegexp, и полученное DN используется.)
Если политики разрешают, то slapd предоставит вам привилегии, которые есть у authzid. (Это похоже на sudo для LDAP.)
Я получил syncrepl с аутентификацией Kerberos, работающий со следующей конфигурацией. Этот сайт про nslcd.conf сказано, что authzid должен иметь форму «dn: <отличительное имя>» или «u: <имя пользователя>». Я также использовал k5start для создания файла кеша для someuser@REALM в /tmp/krb5cc_55, и сделал chown ldap:ldap. Обратите внимание, что 55 - это идентификатор ldap; однако я не уверен, что нужно называть файл так. В конфигурации моего провайдера я указал 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"