[Freeipa-devel] More types of replica in FreeIPA

Mon Mar 12 19:51:40 UTC 2012

On 03/12/2012 01:51 PM, Dmitri Pal wrote:
> On 03/12/2012 03:38 PM, Ondrej Hamada wrote:
>> On 03/08/2012 04:54 PM, Dmitri Pal wrote:
>>> On 03/06/2012 01:30 PM, Ondrej Hamada wrote:
>>>> On 03/06/2012 05:47 PM, Dmitri Pal wrote:
>>>>> On 03/06/2012 10:59 AM, Simo Sorce wrote:
>>>>>> On Tue, 2012-03-06 at 10:56 -0500, Dmitri Pal wrote:
>>>>>>> [...]
>>>>>>>> For a read-only KDC we need to investigate what's the better
>>>>>>> solution.
>>>>>>>> There are many ways we can handle the issue, one of the simplest is
>>>>>>>> probably to allow the RO KDC to use a special LDAP Extended
>>>>>>> operation
>>>>>>>> against a full R/W server to get the user keys to sign,
>>>>>>> authenticating
>>>>>>>> with a special R/O KDC principal. We can also investigate how MS
>>>>>>> does
>>>>>>>> internal forwarding and do something similar as I suspect that's
>>>>>>>> something samba4-RODC will want to implement too, so we could share
>>>>>>> some
>>>>>>>> of the development burden there.
>>>>>>>>
>>>>>>>> Simo.
>>>>>>>>
>>>>>>> I do not think it is a good idea for the remote RO KDC to go back to
>>>>>>> the main datacenter on every authentication without some sort of
>>>>>>> caching. This is why I think that some kind of SSSD integration might
>>>>>>> be due. If RO KDC would just pass the authentication to SSSD in some
>>>>>>> way and SSSD would do the caching in case the office gets offline. I
>>>>>>> understand that authhub as is will not work as the client sends time
>>>>>>> stamp encrypted with password and SSSD needs plain text password as
>>>>>>> credential. I do not know if there is a way to solve this without
>>>>>>> actually sending the password in the tunnel. IMO it is more important
>>>>>>> to make sure that remote office can have uninterrupted operation than
>>>>>>> to worry about the password being sent inside the encrypted tunnel. It
>>>>>>> is something that deployment should decide and weight risks against
>>>>>>> convenience.
>>>>>> This is why MS does partial replication, ie allows the RODC to have
>>>>>> data
>>>>>> about the office users. It's complex and there are many ways to handle
>>>>>> it. We need to look at various options and see how they would work
>>>>>> against uses cases we want to support.
>>>>>> Simo.
>>>>>>
>>>>> Then may be Ondrej should start with formulating use cases and
>>>>> requirements based on this discussion.
>>>>>
>>>> I see three possible use cases here, but only two should be considered
>>>> when speaking about consumer node:
>>>>
>>>> 1) The office that should rely on that replica is quite a big one
>>>> (hundreds of employees) or many different users are authenticating
>>>> against its replica or there are located admins, who need to do a lot
>>>> of write-operations. -->  In this case I suppose the best solution is
>>>> to deploy master replica there.
>>>>
>>>>
>>>> 2) Office that doesn't fulfil the conditions in 1) - not a desperate
>>>> need for write-operations on ipa-server, but the priority is to allow
>>>> (some) clients to authenticate and use available services even when
>>>> the network is down. -->  We need a consumer with credentials caching,
>>>> authentication requests for non-cached users or write operations must
>>>> be forwarded to master.
>>>>
>>>> 3) Office that doesn't fulfil the conditions in 1), but the priority
>>>> is security, so that the consumer is not allowed to store or cache any
>>>> confidential data. -->  We need a consumer, authentications and write
>>>> operations must be forwarded to master.
>>>>
>>>> If we choose the second use case, both the caching and request
>>>> forwarding must be implemented. I suppose that there shouldn't be big
>>>> problem to decide during the installation to turn the caching off by
>>>> some option like '-no-chaching' so that the consumer could be used for
>>>> the third use case as well.
>>>>
>>> Can you please now create a set usage scenarios for the 2) and 3).
>>> User logs in and he is in cache, he is not in cache, he is redirected
>>> and data is cached, he failed and account lockout data is updated
>>> locally or on the other server? Admin tries to perform and IPA command
>>> or ldapmodify command - what happens?
>>>
>>> Can those work flows be spelled out in details for caching and non use
>>> cases?
>>>
>>>
>>
>> I'll start with usage scenario for 3), it's shorter:
>> All write operations and authentication requests are forwarded to the 
>> master
>>
>> Operations when connection is OK:
>> ----------------------------------------------
>> read -- local
>> write-forwarding to master
>> authentication-forwarding to master
>>
>> Operations when connection is BROKEN:
>> -----------------------------------------------------
>> read-local (only until ticket expires)
>> write-not available
>> authentication-not available
>>
>>
>> Usage scenario for 2):
>>
>> 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
>>
>
> I am not sure is this is always right. IMO we should make it 
> configurable and allow the admin to decide if in this case the 
> authentication should be performed against central server and then 
> cached credentials rather than always going to the cache first.
>
>> -credentials not cached -- forward request to master, on success 
>> cache the credentials
>>
>> USER'S operations when connection is BROKEN:
>> --------------------------------------------------------------
>> read data -> local
>> write data -> not available
>> authentication:
>> -credentials cached -- authenticate against credentials in local cache
>>                             -on failure: log failure locally, on 
>> lock-down lock account locally and update information to master when 
>> the connection is back on
>>
>
> I am not sure we propagate the failures and account lockout. I think 
> it is per server and not replicated so when the connection is restored 
> we should just switch to authenticating against a central server.
>
>> -credentials not cached -- deny access -- not possible to 
>> authenticate user
>>
>> ad ADMIN'S -- I suppose that admin's credentials should not be cached 
>> -- it doesn't make much sense because all the operations, he's 
>> permitted to do, could be executed on master server only
>>
>> ADMIN'S operations when connection is OK:
>> ---------------------------------------------------------
>> read - local
>> write - forwarding to master
>> authentication - forwarding to master
>>
>> ADMIN'S operations when connection is BROKEN:
>> ----------------------------------------------------------------
>> read-only operations until valid ticket expires
>> write - not available
>> authentication - not available
>>
>
> Now when we know the scenarios (assuming we agree on those after some 
> review) next would be to specify how you plan to implement the 
> forwarding and caching. Is auth forwarding would be implemented using 
> KDC or there will be some kind of referral/redirect issued to the 
> client. No you plan to implement write forwarding> I assume some kind 
> of the DS plugin? It might already be there but might require some 
> tweaks and custom configuration.
http://port389.org/wiki/Howto:ChainOnUpdate
>
>> -- 
>> Regards,
>>
>> Ondrej Hamada
>> FreeIPA team
>> jabber:ohama at jabbim.cz
>> IRC: ohamada
>
>
> -- 
> Thank you,
> Dmitri Pal
>
> Sr. Engineering Manager IPA project,
> Red Hat Inc.
>
>
> -------------------------------
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
>
>
>
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20120312/d5bd95c5/attachment.htm>