multiple kdc masters with resilient LDAP backend

[Simo Sorce]

On Tue, 2 Feb 2010 12:35:53 +0000
rhod davies <nomrhod at googlemail.com> wrote:

> Hi,
> 
> I've been reading through the mail archives, and doing the obligatory
> google search, but seem to be hitting a brick wall on trying to get a
> better understanding of something that should be trivial to get a
> handle on (I think).
> 
> MIT Kerberos 1.7 configured with a KLDAP backend to a multi-master
> resilient LDAP
> service; single realm.
> 
> I understand that we can run multiple KDCs in an autonomous way, but
> sharing the same data store (in LDAP), this is good, and what I want
> to have - i.e. a resilient KDC service.  We can misplace a data
> centre, but still offer a KDC service as LDAP has made sure that the
> data is replicated around the globe.
> 
> There are references to individual/groups who have done this, and all
> looks well.  However what are the pitfalls with this approach?
> Specifiaclly:
> 
> - Is any local state held by the krb5kdc process that would cause
> issues down the line?

The only thing that may not work as you may like is account lockouts,
unless you want to pay the price of having all aster write down to LDAP
for every AS request (unadvisable for performance and replication
traffic reasons).

> - Ar there any issues with running multiple master (same backing store
> - LDAP) for the same realm?

As long as your multi-master replication works properly there should be
no problems. Attribute level conflict resolution is strongly recommended
over object level conflict resolution to avoid loosing data when 2
servers change different attributes of the same object.

> In a similar vein can kadmind be made resilient in the same manner
> (all documents I've seen so far are catagorical that only one kadmind
> service should be running).

I don't use kadmind but I don't really see a big issue in having
multiple kadmind running as long as you don't abuse it to administer
the same data from 2 places at the same time and cause unnecessary
conflicts.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York