1

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
onlyanegg
  • 163
  • 1
  • 9

2 Answers2

3

I think this means that the consumer doesn't have a valid TGT.

Yes, that's exactly what it means.

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?

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 for ldap/*. 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).

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?

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 with u:. (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.)

user1686
  • 8,717
  • 25
  • 38
1

I got syncrepl with kerberos authentication working with the following configuration. This website about nslcd.conf says that authzid should be of the form "dn:<distinguished name>" or "u:<user name>". I also used k5start to create a cache file for someuser@REALM at /tmp/krb5cc_55, and did chown ldap:ldap. Note that 55 is the ldap uid; however, I'm not sure that it's necessary to name the file this. In my provider configuration, I specified someuser as the rootdn to allow it to have access to the entire database.

I just want to clarify that this is what worked for me, but I have a limited understanding of ldap, so I can't guarantee it will work elsewhere, and I don't know if everything in this config is necessary. 

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"
onlyanegg
  • 163
  • 1
  • 9