[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
errant SASL/GSSAPI setup?
I've been using rootdn passwords over TLS with slurpd and since switching to
syncrepl. Seeing a posting by Quanah Gibson-Mount <quanah@stanford.edu> 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/seethe.wpi.edu@WPI.EDU
Valid starting Expires Service principal
08/30/06 09:21:07 08/30/06 09:26:07 krbtgt/WPI.EDU@WPI.EDU
# /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) $
root@SEETHE.WPI.EDU:/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/seethe.wpi.edu@WPI.EDU
Valid starting Expires Service principal
08/30/06 09:21:07 08/30/06 09:26:07 krbtgt/WPI.EDU@WPI.EDU
08/30/06 09:21:38 08/30/06 09:26:07 ldap/utility5.wpi.edu@WPI.EDU
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.