[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 Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html