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 <[email protected]> > 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 <>< <>< <>< <>< <>< <>< ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
