Re: ldapmodify when using syncrepl fails due to referral (ITS#2715)

[Luke Howard <lukeh@PADL.COM>]

>Okay, that is a major departure from how things were done previously via 
>slurpd (slurpd had to have permission to bind to the slave).  Well, that 
>makes things interesting.  I'll have to figure out how we want to set that 
>up on our end, as it means we now have to run a process to get kerberos 
>tickets on all the replica's, and grant them access into the master, which 
>they previously didn't have.

We wrote a SLAPI plugin that spawns a thread, gets a ticket to the master,
and stores it in a MEMORY: credentials cache.

Because this is done asynchronously (it can't be done at startup because,
in our case, the KDC uses the LDAP server) there is a race condition where
the consumer fails to bind to the master because it, at that point, lacks
a ticket. I'm yet to test how well the syncrepl code recovers from this.

The real solution is to do it synchronously but, in our case, this would
mean integrating the KDC logic into the LDAP server. It's not a bad idea
in some respects... 

Where the KDC is not integrated with the LDAP server you could certainly
acquire the initial TGT at plugin startup time, or just use a separate
process to maintain a file-based credentials cache as is common.

-- Luke