[Freeipa-devel] More types of replica in FreeIPA

[Ondrej Hamada]

On 03/13/2012 01:13 AM, Dmitri Pal wrote:
> 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.
>
Sorry for inactivity, I was struggling with a lot of school stuff.

I've summed up the main goals, do you agree on them or should I 
add/remove any?


GOALS
===========================================
Create Hub and Consumer types of replica with following features:

* Hub is read-only

* Hub interconnects Masters with Consumers or Masters with Hubs
   or Hubs with other Hubs

* Hub is hidden in the network topology

* Consumer is read-only

* Consumer interconnects Masters/Hubs with clients

* Write operations should be forwarded to Master

* Consumer should be able to log users into system without
   communication with master

* Consumer should cache user's credentials

* Caching of credentials should be configurable

* CA server should not be allowed on Hubs and Consumers

-- 
Regards,

Ondrej Hamada
FreeIPA team
jabber: ohama at jabbim.cz
IRC: ohamada