Replicated LDAP as backend

[Robert Wehn]

Hello Paul,

Am 24.07.2014 11:44, schrieb Paul van der Vlis:
> Hello Benjamin,
>
> op 24-07-14 03:58, Benjamin Kaduk schreef:
>> That should be a fine setup. The only thing that seems worth noting
>> is that the "old" Kerberos server (KDC) is the master KDC, so
>> administrative actions must be done against that site (and will not
>> be possible from the new location if there is no connection between
>> the two locations).
> Thanks for your help!
>
> Is it important to study the docs for a slave-KDC, or is this setup for
> when you don't have a replicated LDAP backend?
>
> I am wondering a bit why this does not work on a client on the new
> leocation:
> -------
> root at client:~# kadmin -p paul/admin -q "ktadd nfs/$(hostname --fqdn)"
> Authenticating as principal paul/admin with password.
> Password for paul/admin at DOMAIN.NL:
> kadmin: Kerberos database constraints violated while changing
> nfs/client.domain.nl's key
> --------
> Maybe kadmin tries to write something to the LDAP?
> Or is it not-related?
> On the old location this works fine.
as Benjamin pionted out, if your LDAP Backend is master/slave, the on
the slave location the Kerberos Server is also a slave, as changes can't
be done there (not replicated back).

So your kadmin server can only be on the "Master Site", no "kadmin" to
the slave server is possible. If your Master Server is not reachable
kadmin (and password changes) cannot be done until the connection is
online again.

regards, Robert.

-- 

Dr. Robert Wehn ........................ http://www.rz.uni-augsburg.de
Universität Augsburg, Rechenzentrum ............. Tel. (0821) 598-2047
86135 Augsburg .................................. Fax. (0821) 598-2028