Replicated LDAP as backend

[Dameon Wagner]

On Fri, Jul 25 2014 at 08:35:38 +0200, Robert Wehn scribbled
 in "Re: Replicated LDAP as backend":
> 
> 
> On July 25, 2014 12:45:46 AM CEST, Paul van der Vlis <paul at vandervlis.nl> wrote:
> >op 24-07-14 19:16, Robert Wehn schreef:
> >> 
> >> Am 24.07.2014 11:44, schrieb Paul van der Vlis:
> >The command I give is to download a key, not to change anything.
> >But maybe it tries to write something too, no idea.
> 
> As you see in Thomas' answer it seems to do so

Indeed it does.  The only time that I know of that this would not be
the case is if you were using kadmin.local on the system and included
"-norandkey" in the ktadd command.  If you're using plain `kadmin`
then ktadd will generate new keys.

> >Does it make sence to run krb5-admin-server at the slave-kdc server
> >on the new location or is it better to stop this service?
> 
> I'm not sure if the kadmin server on the slave site can be
> configured to make the changes on the master site. If not I would
> turn it off.

I don't believe so, not at the Kerberos level anyway (there are tricks
you can play with LDAP to refer writes to a master, such as
configuring an "updateref", but I have no idea how well they would
interact with krb5-admin-server).

There's little point in configuring and running krb5-admin-server on a
slave kdc, unless you're preparing if for promotion to master (during
a DR situation for example).

Using an LDAP backend with multi-master replication _could_
potentially allow for having more than one active krb5-admin-server in
your realm, but I don't know if this is a supported configuration in
MIT (IIRC Heimdal may allow this, but I'm not sure if OpenLDAP's
multi-master replication is mature enough to recommend or rely on it
for something as core as Kerberos).

Cheers.

Dameon.

-- 
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><
Dameon Wagner, Systems Development and Support Team
IT Services, University of Oxford
><> ><> ><> ><> ><> ><> ooOoo <>< <>< <>< <>< <>< <><