[Freeipa-devel] More types of replica in FreeIPA

[Dmitri Pal]

On 03/12/2012 06:10 PM, Simo Sorce wrote:
> 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.
>
I agree. I am just trying to structure the discussion a bit so that all
what you are saying can be captured in the design document and then we
can pick a subset of what Ondrej will actually implement. So let us
capture all the complexity and then do a POC for just LDAP part.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/