[Freeipa-devel] More types of replica in FreeIPA

Ondrej Hamada ohamada at redhat.com
Tue Mar 6 18:30:16 UTC 2012


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.

-- 
Regards,

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




More information about the Freeipa-devel mailing list