[Freeipa-devel] Supported Staged entries

[Martin Kosek]

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