[Freeipa-devel] More types of replica in FreeIPA

[Ondrej Hamada]

On 04/04/2012 06:16 PM, Ondrej Hamada wrote:
> 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.
>
Ad distribution of user's Krb creds:
When the user logs on any Consumer for a first time, he has to 
authenticate against master. If succeeds, he will be added to a specific 
user group. Each consumer will have one of these groups. These groups 
will be used by LDAP filters in fractional replication to distribute the 
Krb creds to the chosen Consumers only.

This will be more complicated because of the HUBs (as Simo already 
said). The easiest way will be to let the Hubs contain all the creds - 
but this solution might result in massive network traffic when the users 
start logging in. Other solution might be creating similar user group 
for each Hub. Because every replica will be Master(from 389-DS point of 
view) - it will hold record about everyone of its suppliers and 
consumers and thus it will be possible to decide who belongs to which 
user group.

-- 
Regards,

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