[Freeipa-devel] More types of replica in FreeIPA

Mon Apr 9 13:05:01 UTC 2012

On 04/06/2012 09:15 AM, Ondrej Hamada wrote:
> 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.
>
Note that the groups created on the masters will be replicated to the 
hubs, so the hubs will know about those groups.