[Freeipa-devel] More types of replica in FreeIPA

[Ondrej Hamada]

On 04/04/2012 03:02 PM, Simo Sorce wrote:
> On Tue, 2012-04-03 at 18:45 +0200, Ondrej Hamada wrote:
>> 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
> We need to define how this can be done, it will almost certainly mean
> part of the consumer is writable, plus it also means you need additional
> access control and policies, on what the Consumer should be allowed to
> see.
Right, in such case the Consumers and Hubs will have to be masters (from 
389-DS's point of view).

>> * Consumer should cache user's credentials
> Ok what credentials ? As I explained earlier Kerberos creds cannot
> really be cached. Either they are transferred with replication or the
> KDC needs to be change to do chaining. Neither I consider as 'caching'.
> A password obtained through an LDAP bind could be cached, but I am not
> sure it is worth it.
>
>> * Caching of credentials should be configurable
> See above.
>
>> * CA server should not be allowed on Hubs and Consumers
> Missing points:
> - Masters should not transfer KRB keys to HUBs/Consumers by default.
Add point:
     - storing of the Krb creds must be configurable and disabled by default
> - We need selective replication if you want to allow distributing a
> partial set of Kerberos credentials to consumers. With Hubs it becomes
> complicated to decide what to replicate about credentials.
>
> Simo.
>
Rich mentioned that they are planning support for LDAP filters in 
fractional replication in the future, but currently it is not supported.


-- 
Regards,

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