<html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 05/28/2014 08:22 AM, Martin Kosek wrote: </div> <blockquote cite="mid:538580A2.60508@redhat.com" type="cite"> <pre wrap="">On 05/27/2014 08:18 PM, Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: </pre> <blockquote type="cite"> <pre wrap="">On Tue, 27 May 2014, Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/27/2014 06:56 PM, Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/27/2014 06:06 PM, Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">We just need to care about the 'uid' attribute in the staged entry, and pick that to generate the RDN of the user in the active tree. If there are conflicts the 'unstage' will fail cleanly, as the 'add' operation will just fail (due to non unique RDN) and the admin will have to take care of the situation. </pre> </blockquote> <pre wrap="">In that case the provisioning system created a staging entry ou=TestUser,$STAGING, it will get an active entry uid=xxx,$ACTIVE It could be an issue for the provisioning system to retrieve the entry it created. </pre> </blockquote> <pre wrap="">Too bad for the provisioning system, we are not going to allow users to have a form that does not use uid in the RDN in IPA. </pre> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">Sounds like a lot of complexity for a problem we do not really have, all we need is to not enforce uniqueness in staging. </pre> </blockquote> <pre wrap="">This proposal was also to limit the operator privilege to do MODRDN from 'pre-active' to 'active', instead ADD on 'active'. </pre> </blockquote> <pre wrap="">It is not useful, the operator still needs to be able to create in pre-active ... so it can still create what it wants. </pre> </blockquote> <pre wrap=""> yes that is correct. Does it address the security concern, if the operator that is allowed to add in 'staging'/'pre-active' is different from the one allowed to move the entry in 'active' ? </pre> </blockquote> <pre wrap=""> Well it really depends on 'who' the operator is. We would like to be able to allow a 'junior admin/helpdesk person' to just press a button to activate a user, but that shouldn't drive our design if it makes other things clumsy or suboptimal. The less privileged operator problem can always be solved by a middle-man script that has higher privileges. So we nee to give priority to getting the workflow right in terms of the way it works. I think re-creating the user object gives us better chances at handling the overall workflow and fixing up entries accordingly to the management framework view of what a user needs to look like, so in the end I prefer that route. </pre> </blockquote> <pre wrap="">I agree. It also opens us a way to handle import of any foreign schema person if staged object uses extensibleObject object class where we are in control of what exactly will get into the actual tree. </pre> </blockquote> <pre wrap=""> Right it allows us to do things like filter out objectclass or attributes the provisioning system adds but that the admin does not want in the final entry. This is not something we may want to build into the solution from day zero, but it gives us the option to build it more easily, as a framework filter on the 'unstage' operation. (We so need to be able to copy additional objectclasses and their attributes from day 0 though). Simo. </pre> </blockquote> <pre wrap=""> Ok, thanks guys, I see an agreement. Thierry, we should now update all the information here: <a class="moz-txt-link-freetext" href="http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP">http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP</a> (you can even link this thread in the archives) Martin </pre> </blockquote> Yes I will do that. Regarding workflow, it looks a priority that active entries are valid (regarding FreeIPA). Currently CLI offers: <ul> <li>ipa user-add (in active)</li> <li>ipa user-add --stage (in stage).</li> </ul> In order to prevent admin to add a corrupted entry in active and force any entry to go through the filter of objectclass/attribute, we could make 'ipa user-add' to create entry in staging and 'ipa user-add --active' to create entry in active. Even more, should we support to add entry directly in 'active' or rather only support 'user-add' to go only in staging ? thanks thierry </body> </html>