On 05/27/2014 08:18 PM, Simo Sorce wrote: > On Tue, 2014-05-27 at 21:14 +0300, Alexander Bokovoy wrote: >> On Tue, 27 May 2014, Simo Sorce wrote: >>> On Tue, 2014-05-27 at 19:59 +0200, thierry bordaz wrote: >>>> On 05/27/2014 06:56 PM, Simo Sorce wrote: >>>>> On Tue, 2014-05-27 at 18:39 +0200, thierry bordaz wrote: >>>>>> On 05/27/2014 06:06 PM, Simo Sorce wrote: >>>>>>> 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. >>>>>> 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. >>>>> 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. >>>>> >>>>>>> Sounds like a lot of complexity for a problem we do not really have, all >>>>>>> we need is to not enforce uniqueness in staging. >>>>>> This proposal was also to limit the operator privilege to do MODRDN from >>>>>> 'pre-active' to 'active', instead ADD on 'active'. >>>>> It is not useful, the operator still needs to be able to create in >>>>> pre-active ... so it can still create what it wants. >>>> >>>> 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' ? >>> >>> 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. >> 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. > > 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.
Ok, thanks guys, I see an agreement. Thierry, we should now update all the information here: http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP (you can even link this thread in the archives) Martin _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel