<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> On 03/12/2012 03:38 PM, Ondrej Hamada wrote: <blockquote cite="mid:4F5E50AF.5090701@redhat.com" type="cite"> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> On 03/08/2012 04:54 PM, Dmitri Pal wrote: <blockquote cite="mid:4F58D620.90107@redhat.com" type="cite"> <pre wrap="">On 03/06/2012 01:30 PM, Ondrej Hamada wrote: </pre> <blockquote type="cite"> <pre wrap="">On 03/06/2012 05:47 PM, Dmitri Pal wrote: </pre> <blockquote type="cite"> <pre wrap="">On 03/06/2012 10:59 AM, Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">On Tue, 2012-03-06 at 10:56 -0500, Dmitri Pal wrote: </pre> <blockquote type="cite"> <pre wrap="">[...] </pre> <blockquote type="cite"> <pre wrap="">For a read-only KDC we need to investigate what's the better </pre> </blockquote> <pre wrap="">solution. </pre> <blockquote type="cite"> <pre wrap="">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 </pre> </blockquote> <pre wrap="">operation </pre> <blockquote type="cite"> <pre wrap="">against a full R/W server to get the user keys to sign, </pre> </blockquote> <pre wrap="">authenticating </pre> <blockquote type="cite"> <pre wrap="">with a special R/O KDC principal. We can also investigate how MS </pre> </blockquote> <pre wrap="">does </pre> <blockquote type="cite"> <pre wrap="">internal forwarding and do something similar as I suspect that's something samba4-RODC will want to implement too, so we could share </pre> </blockquote> <pre wrap="">some </pre> <blockquote type="cite"> <pre wrap="">of the development burden there. Simo. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">Then may be Ondrej should start with formulating use cases and requirements based on this discussion. </pre> </blockquote> <pre wrap="">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. </pre> </blockquote> <pre wrap="">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? </pre> </blockquote> I'll start with usage scenario for 3), it's shorter: All write operations and authentication requests are forwarded to the master <meta http-equiv="CONTENT-TYPE" content="text/html; charset=ISO-8859-1"> 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): <meta http-equiv="CONTENT-TYPE" content="text/html; charset=ISO-8859-1"> <title></title> <meta name="GENERATOR" content="LibreOffice 3.3 (Unix)"> <style type="text/css">  </style> 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 </blockquote> 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. <blockquote cite="mid:4F5E50AF.5090701@redhat.com" type="cite"> -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 </blockquote> 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. <blockquote cite="mid:4F5E50AF.5090701@redhat.com" type="cite"> -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 </blockquote> 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. <blockquote cite="mid:4F5E50AF.5090701@redhat.com" type="cite"> <pre class="moz-signature" cols="72">-- Regards, Ondrej Hamada FreeIPA team jabber: <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:ohama@jabbim.cz">ohama@jabbim.cz</a> IRC: ohamada</pre> </blockquote> <pre class="moz-signature" cols="72">-- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. ------------------------------- Looking to carve out IT costs? <a class="moz-txt-link-abbreviated" href="http://www.redhat.com/carveoutcosts/">www.redhat.com/carveoutcosts/</a> </pre> </body> </html>