[Freeipa-devel] More types of replica in FreeIPA

[Ondrej Hamada]

On 04/18/2012 08:30 PM, Rich Megginson wrote:
> On 04/17/2012 06:42 AM, Simo Sorce wrote:
>> On Tue, 2012-04-17 at 01:13 +0200, Ondrej Hamada wrote:
>>>>> 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.
>>>>
>>>>> * 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.
>>>>
>>>> - 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.
>>>>
>>> Can you please have a look at this draft and comment it please?
>>>
>>>
>>> Design document draft: More types of replicas in FreeIPA
>>>
>>> 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
>> Do we need to specify how this is done ? Referrals vs Chain-on-update ?
Both options are in game.
>>
>>> * Consumer should be able to log users into system without
>>>     communication with master
>>>
>>> * Consumer should be able to store user's credentials
>> Can you expand on this ? Do you mean user keys ?
Yes, the consumer should be able to store all data necessary for user 
being authenticated.
>>
>>> * Storing of credentials should be configurable and disabled by default
>>>
>>> * Credentials expiration on replica should be configurable
>> What does this mean ?
We should store credentials for a subset of users only. As this subset 
might change over time, we should flush the credentials for users that 
haven't showed up for some while (even despite the credentials are not 
expired yet).
>>
>>> * CA server should not be allowed on Hubs and Consumers
>>>
>>> ISSUES
>>> =================================================================
>>>
>>> - SSSD is currently supposed to cooperate with one LDAP server only
>> Is this a problem in having an LDAP server that doesn't also have a KDC
>> on the same host ? Or something else ?
>>
>>> - OpenLDAP client and its support for referrals
>> Should we avoid referrals and use chain-on-update ?
Maybe. I've come across several mentions that the referrals support in 
openldap client is not working properly.
>> What does it mean for access control ?
>> How do consumers authenticate to masters ?
>> Should we use s4u2proxy ?
>>
>>> - 389-DS allows replication of whole suffix only
>> What kind of filters do we think we need ? We can already exclude
>> specific attributes from replication.
>
> fractional replication had originally planned to support search 
> filters in addition to attribute lists - I think Ondrej wants to 
> include or exclude certain entries from being replicated

Yes, my point is, that the Consumer should strore credentials only for 
users that are authenticating against him, so we need to exclude some 
attributes, but just for specific subset of users.
>
>>
>>> - Storing credentials and allowing authentication against Consumer 
>>> server
>>>
>>>
>>> POSSIBLE SOLUTIONS
>>> =================================================================
>>>
>>> 389-DS allows replication of whole suffix only:
>>>
>>> * Rich said that they are planning to allow the fractional replication
>>> in DS to
>>>     use LDAP filters. It will allow us to do selective replication what
>>> is mainly
>>>     important for replication of user's credentials.
>> I guess we want to do this to selectively prevent replication of only
>> some kerberos keys ? Based on groups ? Would filtes allow that using
>> memberof ?
>
> Using filters with fractional replication would allow you to include 
> or exclude anything that can be expressed as an LDAP search filter
>
>>
>>> ______________________________________
>>>
>>> Forwarding of requests in LDAP:
>>>
>>> * use existing 389-DS plugin "Chain-on-update" - we can try it as a 
>>> proof of
>>> concept solution, but for real deployment it won't be very cool 
>>> solution
>>> as it
>>> will increase the demands on Hubs.
>> Why do you think it would increase demands for hubs ? Doesn't the
>> consumer directly contact the masters skipping the hubs ?
>
> Yeah, not sure what you mean here, unless you are taking the document 
> http://port389.org/wiki/Howto:ChainOnUpdate as the only way to 
> implement chain on update - it is not - that document was taken from 
> an early proof-of-concept for a planned deployment at a customer many 
> years ago.
>
you're right, my fault, i took it too much dogmatic
>>
>>> * better way is to use the referrals. The master server(s) to be 
>>> referred
>>>     might be:
>>>      1) specified at install time
>> This is not really useful, as it would break updates every time the
>> specified master is offline, it would also require some work to
>> reconfigure stuff if the mastrer is retired.
agree, just wanted to list the option, to be sure it's not the way
>>
>>>      2) looked up in DNS records
>> Probably easier to look up in LDAP, we have a record for each master in
>> the domain.
>>
>>>      3) find master dynamically - Consumers and Hubs will be in fact 
>>> master
>>>         servers (from 389-DS point of view), this means that every
>>> consumer or hub
>>>         knows his direct suppliers a they know their suppliers ...
>> Not clear what this means, can you elaborate ?
Replication agreements posses the information about suppliers. It means 
we can dynamically discover where are the masters by going through all 
nodes and asking who's their supplier. Thinking about it again, it will 
be probably very slow and less reliable. The lookup of dns records in 
LDAP would be better.
>>
>>>     ISSUE: support for referrals in OpenLDAP client
>> We've had quite some issue with referrals indeed, and a lot of client
>> software dopes not properly handle referrals. That would leave a bunch
>> of clients unable to modify the Directory. OTOH very few clients need to
>> modify the directory, so maybe that's good enough.
>>
>>> * SSSD must be improved to allow cooperation with more than one LDAP 
>>> server
>> Can you elaborate what you think is missing in SSSD ? Is it about the
>> need to fix referrals handling ? Or something else ?
I'm afraid of the situation when user authenticates and the information 
is not present on Consumer. If we'll use referrals and the 
authentication will have to be done against master, would the SSSD be 
able to handle it?
>>
>>> _____________________________________
>>>
>>> Authentication and replication of credentials:
>>>
>>> * authentication policies, every user must authenticate against master
>>> server by
>>> default
>> If users always contact the master, what are the consumers for ?
>> Need to elaborate on this and explain.
As was mentioned earlier in the discussion, there are two scenarios - in 
the first one the consumer serves only as a source of 
information(dns,ntp,accounts...), the second one allows distribution of 
credentials and thus enables the authentication against the consumer 
locally. The first one is more secure since the creds are not stored on 
consumers that might be more easily corrupted.
>>
>>>     - if the authentication is successful and proper policy is set for
>>> him, the
>>>       user will be added into 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.
>> Why should this depend on authentication ??
>> Keep in mind that changing filters will not cause any replication to
>> occur, replication would occur only when a change happens. Therefore
>> placing a user in one group should happen before the kerberos keys are
>> created.
>> Also in order to move a user from one group to another, which would
>> theoretically cause deletion of credentials from a group of servers and
>> distribution to another we will probably need a plugin.
>> This plugin would take care of intercepting this special membership
>> change.
>> On servers that loos membership this plugin would go and delete locally
>> stored keys from the user(s) that lost membership.
>> On servers that gained membership they would have to go to one of the
>> master and fetch the keys and store them locally, this would need to be
>> in a way that prevent replication and retain the master modification
>> time so that later replication events will not conflict in any way.
>> There i also the problem of rekeying and having different master keys on
>> hubs/consumers, not an easy problem, and would require quite some custom
>> changes to the replication protocol for these special entries.
>>
I agree, seems like a good idea
>>>     - The groups will be created and modified on the master, so they 
>>> will get
>>>       replicated to all Hubs and Consumers. Hubs make it more 
>>> complicated
>>> as they
>>>       must know which groups are relevant for them. Because of that I
>>> suppose that
>>>       every Hub will have to know about all its 'subordinates' - this
>>> information
>>>       will have to be generated dynamically - probably on every 
>>> change to the
>>>       replication topology (adding/removing replicas is usually not 
>>> a very
>>>       frequent operation)
>> Hubs will simply be made members of these groups just like consumers.
>> All members of a group are authorized to do something with that group
>> membership. The grouping part doesn't seem complicated to me, but I may
>> have missed a detail, care to elaborate what you see as difficult ?
>>
>>>     - The policy must also specify the credentials expiration time. If
>>> user tries to
>>>       authenticate with expired credential, he will be refused and
>>> redirected to Master
>>>       server for authentication.
>> How is this different from current status ? All accounts already have
>> password expiration times and account expiration times. What am I
>> missing ?
Sorry, I wrote it unclear. I meant that the credentials, we store on 
Consumer should be there available only for a specified period of time. 
After that time they should be flushed away (means they are still valid, 
just not stored on the Consumer), no matter what is their expiration 
time. This is mainly for the scenario when someone authenticates against 
our Consumer on some occasion and then he never gets back - it's 
worthless storing his credentials any more, so I think that the it 
should be possible to define some limit for storing credentials.
>>
>>> ISSUE: How to deal with creds. expiration in replication? The 
>>> replication of
>>>       credential to the Consumer could be stopped by removing the user
>>> from the
>>>       Consumer specific user group (mentioned above). The easiest way
>>> would be to
>>>       delete him when he tries to auth.
>> See above, we need a plugin IMO.
>>
>>>   with expired credentials or do a
>>> regular
>>>       check (intervals specified in policy) and delete all expired 
>>> creds.
>> It's not clear to me what we mean by expired creds, what am I missing ?
see above
>>
>>> Because
>>>       of the removal of expired creds. we will have to grant the 
>>> Consumer the
>>>       permission to delete users from the Consumer specific user group
>>> (but only
>>>       deleting, adding users will be possible on Masters only).
>> I do not understand this.
When user hasn't authenticated against Consumer for a long time and his 
credentials were flushed from Consumer, his credentials should be also 
omitted from being replicated to the Consumer. This might be solved by 
the proposed plugin as well.
>>
>>> Offline authentication:
>>>
>>> * Consumer (and Hub) must allow write operations just for a small 
>>> set of
>>>     attributes: last login date and time, count of unsuccessful logins
>>> and the
>>>             lockup of account
>> This shouldn't be a problem, we already do that with masters, the trick
>> is in non replicating those attributes so that they never conflict.
>>
>>>     - to be able to do that, both Consumers and Hubs must be 
>>> Masters(from
>>>     389-DS point of view).
>> This doesn't sound right at all. All server can always write locally,
>> what prevents them from doing so are referrals/configuration. Consumers
>> and hubs do not and cannot be masters.
But what about the information of account getting locked? We need to 
lock the account locally immediately and also tell the master (and thus 
every other node) that the specific account is locked.
>>
>>>   When the Master<->Consumer connection is
>>> broken, the
>>>     lockup information is saved only locally and will be pushed to 
>>> Master
>>>     on connection restoration. I suppose that only the lockup 
>>> information
>>> should
>>>     be replicated. In case of lockup the user will have to authenticate
>>> against
>>>     Master server only.
>> What is the lookup information ? What connection is broken ? There
>> aren't persistent connections between masters and consumers (esp. when
>> hubs are in between there are none).
typo there probably - by lock up information I mean reporting the 
situation, when the account gets locked due to too many failed logins. 
Broken connection - when it is not possible to tell the master, that the 
account got locked.
>>
>>
>>> Transfer of Krb keys:
>>>
>>> * Consumer server will have to have realm krbtgt.
>> I guess you mean "a krbtgt usuable in the realm", not 'the' realm
>> krbtgt, right ?
right
>>
>>>   This means that we
>>> will have
>>>     to distribute every Consumer's krbtgt to the Master servers.
>> It's the other way around. All keys are generated on the masters just
>> like with any other principal key, and then replicated to consumers.
>>
>>>   The
>>> Masters will
>>>     need to have a logic for using those keys instead of the normal 
>>> krbtgt to
>>>     perform operations when user's krbtgt are presented to a different
>>> server.
>> Yes, we will need potentially quite invasive changes to the KDC when the
>> 'krbtgt' is involved. We will need to plan this ahead with MIT to
>> validate our idea or see if they have different ideas on how to solve
>> this problem.
>>
>> Simo.
>>
>


-- 
Regards,

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