I've been using rootdn passwords over TLS with slurpd and since switching to syncrepl. Seeing a posting by Quanah Gibson-Mount <[EMAIL PROTECTED]> some weeks ago about k5start and KRB5CCNAME, I was inspired to try to make the switch.
I grabbed kstart-3.5 and installed it and installed a sasl-regexp in the LDAP master: sasl-regexp uid=ldap-manager/.*,cn=WPI.EDU,cn=gssapi,cn=auth ldap:///ou=access,dc=WPI,dc=EDU??one?(cn=manager) On the client, I tried starting k5start and slapd and an update works ok. I set a short ticket life and renewal time in this test: # setenv KRB5CCNAME "FILE:/tmp/ldap-manager.slapd.tkt" # k5start -f /var/openldap-manager -k /tmp/ldap-manager.slapd.tkt -K 4 -l 5m -U -b # klist Ticket cache: FILE:/tmp/ldap-manager.slapd.tkt Default principal: ldap-manager/[EMAIL PROTECTED] Valid starting Expires Service principal 08/30/06 09:21:07 08/30/06 09:26:07 krbtgt/[EMAIL PROTECTED] # /usr/local/libexec/slapd -d 16384 -f /usr/local/etc/openldap/slapd.seethe.conf @(#) $OpenLDAP: slapd 2.3.25 (Aug 9 2006 11:19:23) $ [EMAIL PROTECTED]:/tools/src/openldap/RHEL4-x86_64/openldap-2.3.25/servers/slapd slapd starting request done: ld 0x8b1e20 msgid 1 request done: ld 0x8b1e20 msgid 2 request done: ld 0x8b1e20 msgid 3 request done: ld 0x8b1e20 msgid 4 request done: ld 0x8b1e20 msgid 5 syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) <= bdb_equality_candidates: (entryUUID) index_param failed (18) syncrepl_entry: be_search (0) syncrepl_entry: wpieduPersonUUID=2af586df6800b3389cbe7bcbf2a920df,ou=People,dc=WPI,dc=EDU syncrepl_entry: be_modify (0) do_syncrep2: LDAP_RES_INTERMEDIATE - REFRESH_DELETE syncrepl_entry: LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_MODIFY) <= bdb_equality_candidates: (entryUUID) index_param failed (18) syncrepl_entry: be_search (0) syncrepl_entry: wpieduPersonUUID=2af586df6800b3389cbe7bcbf2a920df,ou=People,dc=WPI,dc=EDU syncrepl_entry: be_modify (0) Suspended # bg [1] /usr/local/libexec/slapd -d 16384 -f /usr/local/etc/openldap/slapd.seethe.conf & # klist Ticket cache: FILE:/tmp/ldap-manager.slapd.tkt Default principal: ldap-manager/[EMAIL PROTECTED] Valid starting Expires Service principal 08/30/06 09:21:07 08/30/06 09:26:07 krbtgt/[EMAIL PROTECTED] 08/30/06 09:21:38 08/30/06 09:26:07 ldap/[EMAIL PROTECTED] So far, everything looks good. An update went through and the ldap ticket was established. However, after the ticket expires, a subsequent update does not take place and a new ldap ticket isn't obtained. I'm using this syncrepl setup in the client. syncrepl rid=1 provider=ldap://utility5.wpi.edu type=refreshAndPersist retry="60 +" searchbase="dc=WPI,dc=EDU" scope=sub starttls=yes bindmethod=sasl I had chosen refreshAndPersist since I would like the slave to be updated quickly after the master. I had used that with bindmethod=simple since switching from slurpd updates. Stopping slapd, I see a sasl error which, I guess, is indicative of the expiration problem: # fg /usr/local/libexec/slapd -d 16384 -f /usr/local/etc/openldap/slapd.seethe.conf ^C daemon: shutdown requested and initiated. slapd shutdown: waiting for 1 threads to terminate sb_sasl_write: failed to encode packet: generic failure slapd stopped. Changing the syncrepl setup to be: syncrepl rid=1 provider=ldap://utility5.wpi.edu type=refreshOnly interval=0:0:0:5 retry="60 +" searchbase="dc=WPI,dc=EDU" scope=sub starttls=yes bindmethod=sasl it seems to work, since new connections are made. Do I need to give up on the "instant" updates which I had enjoyed for years with slurpd and recently with syncrepl refreshAndPersist in order to use SASL/GSSAPI, or am I missing something? Setting up encryption, authentication, etc. at such a short-interval seems like high overhead. I'd like normal updates to be even quicker than 5 seconds, also; they always have been. I noticed in making this log that this particular slave is 2.3.25, not 2.3.27 like the master, but I have production 2.3.27 slave/master that shows the same problem. Thanks in advance for any help anyone can provide.
