I'm trying to set up a replication server for LDAP using syncrepl. I would like to use Kerberos to authenticate the consumer, because we have it set up, and it seems more secure. The database definitions for my provider and consumer are below.
When I start the consumer, I get this error:
GSSAPI Error: Unspecified GSS failure. Minor code may provide more information
(Credentials cache file '/tmp/krb5cc_55' not found)
I think this means that the consumer doesn't have a valid TGT. How do I configure the consumer to get a valid TGT? I've read some older sources that recommend using k5start or a cron job. Is this still the way to do it?
The slapd.conf manual pages state that authcid
and authzid
can be used in conjunction with bindmethod=sasl
, but it doesn't specify how these should be formatted. Should I put a DN here or a kerberos principal or maybe something else? Do I need to specify these?
Thank you for your help
Consumer config:
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 +"
Provider Config
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
Best Answer
Yes, that's exactly what it means.
Not sure about cron, būt k5start is still a good method.
But recent MIT Kerberos supports a built-in method called client keytab initiation, which is much simpler to set up: just add
$KRB5_CLIENT_KTNAME
to slapd's environment, and point it at the same file as$KRB5_KTNAME
. (This is assuming you have a separate keytab forldap/*
. You should.)And finally you can tell slapd to use gss-proxy, which is like ssh-agent for Kerberos. Set
GSS_USE_PROXY=1
and configure /etc/gssproxy to recognize slapd as both an initiator (client) and acceptor (server).I can't remember what purpose the authcid serves with GSSAPI (if any at all) – IIRC, this mechanism automatically uses the identity determined from your ticket, so there's no need to manually specify it.
On the accepting side, slapd will convert the received Kerberos principal to a pseudo-DN like
uid=foo@realm,cn=gssapi,cn=auth
, and you can use it in the ACLs directly, or use authz-regexp (aka olcAuthzRegexp) to translate it to a nicer DN.Meanwhile, authzid works the same way independent of mechanism. It's optional, but if you do specify it, then it must be either a DN prefixed with
dn:
, or a username prefixed withu:
. (Usernames here, like authcids, get converted to a pseudo-DN and go through olcAuthzRegexp, and the resulting DN is used.)If policies allow, then slapd will grant you the privileges that the authzid has. (It's like sudo for LDAP.)