[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: errant SASL/GSSAPI setup?
--On Wednesday, August 30, 2006 10:19 AM -0400 "Allan E. Johannesen"
<aej@WPI.EDU> wrote:
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.
So, I've been thinking over all of this, and I actually see only one error:
You need to index entryUUID.
Lets talk about how this whole replication thing works:
(a) You get a K5 ticket (or it already exists, thanks to kstart, etc)
(b) You start the replica
(c) It connects to the master whenever the master is available. It makes a
*persistent* connection, since that is what you have specified
(d) Changes replicate.. time passes, k5start renews the ticket cache, the
ldap/* bit for the master disappears from the cache
(e) Changes continue to replicate
The reason things still work between (d) & (e) is because the connection is
*persistent*. The ldap/* bit for the master is only necessary for
establishing the initial connection. That is why replication continues to
work on my ldap slaves even though they don't have an ldap/* principal in
their ticket cache any more:
ldap4:/var/run# klist ldap_syncreplica.tkt
Ticket cache: FILE:ldap_syncreplica.tkt
Default principal: ldap/ldap4.stanford.edu@stanford.edu
Valid starting Expires Service principal
08/30/06 04:38:55 08/30/06 14:38:55 krbtgt/stanford.edu@stanford.edu
Now, the *next* time my replica has to rebind to the master, it will
negotiate a *new* connection and then the ticket cache will get a ldap/*
ticket.
So frankly, other than the missing index, I see nothing wrong with your
setup, and nothing to indicate that replication is failing due to anything
kerberos related.
--Quanah
--
Quanah Gibson-Mount
Principal Software Developer
ITS/Shared Application Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html