[Freeipa-devel] More types of replica in FreeIPA

[Simo Sorce]

On Mon, 2012-03-12 at 17:40 -0400, Dmitri Pal wrote:
> On 03/12/2012 04:16 PM, Simo Sorce wrote:
> > On Mon, 2012-03-12 at 20:38 +0100, Ondrej Hamada wrote:
> >> USER'S operations when connection is OK:
> >> -------------------------------------------------------
> >> read data -> local
> >> write data -> forwarding to master
> >> authentication:
> >> -credentials cached -- authenticate against credentials in local cache
> >>                          -on failure: log failure locally, update
> >> data 
> >> about failures only on lock-down of account
> >> -credentials not cached -- forward request to master, on success
> >> cache 
> >> the credentials
> >>
> > This scheme doesn't work with Kerberos.
> > Either you have a copy of the user's keys locally or you don't, there is
> > nothing you can really cache if you don't.
> >
> > Simo.
> >
> Yes this is what we are talking about here - the cache would have to
> contain user Kerberos key but there should be some expiration on the
> cache so that fetched and stored keys periodically cleaned following the
> policy an admin has defined.

We would need a mechanism to transfer Kerberos keys, but that would not
be sufficient, you'd have to give read-only servers also the realm
krbtgt in order to be able to do anything with those keys.

The way MS solves hits (I think) is by giving a special RODC krbtgt to
each RODC, and then replicating all RODC krbtgt's with full domain
controllers. Full domain controllers have logic to use RODC's krbtgt
keys instead of the normal krbtgt to perform operations when user's
krbtgt are presented to a different server. This is a lot of work and
changes in the KDC, not something we can implement easily.

As a first implementation I would restrict read-only replicas to not do
Kerberos at all, only LDAP for all the lookup stuff necessary. to add a
RO KDC we will need to plan a lot of changes in the KDC.

We will also need intelligent partial replication where the rules about
which object (and which attributes in the object) need/can be replicated
are established based on some grouping+filter mechanism. This also is a
pretty important change to 389ds.

Simo.

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