[Freeipa-devel] More types of replica in FreeIPA

[Dmitri Pal]

On 04/19/2012 09:03 AM, Simo Sorce wrote:
> On Thu, 2012-04-19 at 14:18 +0200, Ondrej Hamada wrote:
>> On 04/18/2012 08:30 PM, Rich Megginson wrote:
>>>>> * 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).
> This should be determined through group membership or similar mechanism,
> talking about 'expiration' seem wrong and confusing, perhaps just a
> language problem ?
>
>>> 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.
> I am not sure we can achieve this, with just a fractional replication
> filter, not easily anyway. A search filter singles out entire entries.
> In order to have different sets of attributes replicated we need an
> additional, per-filter attribute exclusion list.
>
>>>>>      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.
> Neither, we have the list of masters in LDAP in the cn=etc subtree for
> these uses, it's a simple search, and it is the authoritative list.
> Remember we may not always control the DNS, so relying on a manually
> maintained DNS would be bad.
>
>>>>> * 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?
> Currently SSSD can handle referrals, although it does so poorly due to
> issues with the openldap libraries. Stephen tells me there are plans to
> handle referrals in the SSSD code directly instead of deferring to
> openldap libs. When that is done we should have no more issues.
> However, for authentication purposes I am not sure referrals are the way
> to go.
> For the Kerberos case referrals won't work, because we will not let a
> consumer have read access to keys in a master (besides the consumer will
> not have the same master key so will not be able to decrypt them), so we
> will need to handle the Krb case differently.
> For ldap binds, we might do referrals, or we could chain binds and avoid
> that issue entirely. If we chain binds we can also temporarily cache
> credentials in the same way we do in SSSD so that if the server get cut
> off the network it can keep serving requests. I am not thrilled about
> caching users passwords this way and should probably not enabled by
> default, but we'd have the option.
>
>>>>> * 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.
> Ok, makes sense, but I would handle this transparently to the clients,
> as noted above. Trying to build knowledge in clients or rely on
> referrals is going to work poorly with a lot of clients, making the
> solution not really useful in real deployments where a mix of machines
> that do not use SSSD is present.
>
>>>>>     - 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. 
> Why ?
>
>> 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.
> I do not see what's the point. If we are replicating the keys to a
> consumer why would it try to delete them after a while ?
>
>> 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.
> Ok so we are mixing things here.
>
> I guess the scenario you are referring to here, is the one where we do
> not replicate any key to the consumer, and some user does an ldap bind
> against with chained-binds and we do decide to cache the password as a
> hash if auth is successful. This is a rare corner case in my mind.
>
> Note that we cannot do this with Kerberos. we can't "cache" kerberos
> keys, we either have a copy permanently (or until the policy/group
> membership of the consumer is changed) or never have them.
>
>
>>>>> 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.
> Either the user is marked as part of the location server by this
> consumer, and therefore we replicate keys or we do not. We cannot delete
> keys, as nothing would replicate them back to us until a password change
> occurs. Also, you have no way to tell the master what it should
> replicate, dynamically.
> I would remove this point, it is not something we need or want, I think.
>
>>>>>     - 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.
> For account lockouts we will need to do an explicit write to a master.
> (probably yet another plugin or an option to the password plugin). We
> cannot use replication to forward this information, as consumers do not
> have a replication agreement that go from consumer to master.
>
>>>>>   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. 
> This will be hard indeed.
>
>> Broken connection - when it is not possible to tell the master, that the 
>> account got locked.
> Ok replace with "when the masters are unreachable".
>
> Simo.
>
>
There is one aspect that is missing in this discussion. If we are
talking about a remote office and about a Consumer that serves this
office we need to understand not only the flow of the initial
authentication but are there other authentications happening. I mean are
we just talking about logging into the machines in the remote office
then LDAP auth with pass-through and caching would be sufficient on the
consumer (I will explain how it could be done below) or there is an eSSO
involved and expected?

I guess if the eSSO is required for example to access NFS shares there
should be a local IPA server with KDC in the remote office. In this case
it probably makes sense to make it just a normal replica but with
limited modification capabilities and potentially with a subset of users
and other entries replicated to that location.

If the eSSO is not required and we talk about the initial login only we
can have a DS instance as a consumer do not need to have the whole IPA
becuase KDC, CA and management frameworks are not needed. This DS can
replicate a subset of the users, groups and other data using fractional
replication for the identity lookups can and use PAM pass-through
feature with SSSD configured to go to the real master for authentication. 

So effectively there are two different use cases:
1) eSSO server in the remote office
2) Login server in the remote office

The solutions seem completely different so I suggest starting with one
or another.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/