Re: errant SASL/GSSAPI setup?

["Allan E. Johannesen" <aej@WPI.EDU>]

>>>>> "quanah" == Quanah Gibson-Mount <quanah@stanford.edu> writes:

quanah> --On Wednesday, August 30, 2006 12:57 PM -0400 "Allan E. Johannesen"
quanah> <aej@WPI.EDU> wrote:


>> Yes, I should put that in there.  I just trimmed the "simple" stuff
>> (dn/password) out and put in "sasl".  I should have specified the mechanism.
>> 
>> Nothing else could work in my instance, anyway.

quanah> There is one more major difference between how we are doing syncrepl --
quanah> I use the actual ldap/* principals of my LDAP server, rather than a
quanah> single account instance.  That may be why it continues to work for me
quanah> across new negotiations.

In my first experiment, I picked one of the existing ldap principals, in this
case of a random slave, and did a ktadd to a new file on the experimental
system.  That caused the slave to fail until I ktadd'd the principal to the
/etc/krb5.keytab on the slave again.  I didn't notice the failure until some
time had passed...

I didn't expect it, but my ktadd on this test system caused the principal to
change in the kerberos store and that caused the ldap server on this other
system to fail.  I made the unfounded assumption that ktadd was read-only and
not harmful.

That's why I chose different principals.  I was just lazy to use an existing
one and I was punished by kerberos for my laziness.