[Freeipa-devel] Supported Staged entries

[thierry bordaz]

On 05/27/2014 06:06 PM, Simo Sorce wrote:
> On Tue, 2014-05-27 at 17:55 +0200, thierry bordaz wrote:
>> On 05/27/2014 04:35 PM, Martin Kosek wrote:
>>> On 05/27/2014 04:27 PM, Simo Sorce wrote:
>>>> On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote:
>>>>> This topic was already discussed in the past, see following part of
>>>>> the design:
>>>>>
>>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#Renaming_vs._Moving_Users_in_LDAP
>>>>>
>>>>> One of the biggest concern was that to allow operator unstage a user,
>>>>> he would
>>>>> need to have a delete ACI in staging container AND add ACI in the
>>>>> active users
>>>>> area - which would also allow him to create any user he wishes in the
>>>>> users area.
>>>>>
>>>>> This is the reason why we preferred to do and control it via MODRDN
>>>>> and the
>>>>> reason why Thierry implemented the new ACI for controlling MODRDN
>>>>> operation:
>>>>>
>>>>> https://fedorahosted.org/389/ticket/47553
>>>>>
>>>> I know that's why we did it, but I had a hard look since then, and I
>>>> believe we cannot really use that method.
>>>>
>>>> The reason is simply that we do not control who adds the user object and
>>>> our reason to do the staging is to make it simple for an external
>>>> provisioning system to create a basic user entry the way it knows how
>>>> to, with only the attributes the provisioning system cares about.
>>>>
>>>> But this means we have no guarantee of what objectclasses are available
>>>> on the object, so we have no guarantees all the necessary structureal
>>>> objectclasses have been added in the staging object.
>>>>
>>>> We have to recreate the user object in order to be able to add all the
>>>> right structural objectclasses as those can only be added at object
>>>> creation time in an LDAPv3 compliant LDAP server.
>> Both approach looks possible:
>>
>>    * adding required structural OC+AT in the existing entry
>>    * creating a new entry with all structural OC+AT and update the AT
>>      values with what exists in the stage entry
>>
>> but I think the second one would be simpler to implement.
> My assessment too.
>
>> Here again uid uniqueness is a difficulty: if 'uid' exists in stage
>> entry we need to delete the stage entry before adding the active one.
>> There is a risk to loose the entry if the add fails. Also it is
>> important to apply DEL/ADD on the same replica so that DEL csn < ADD csn.
> I think the solution is to not have the uid uniqueness plugin look into
> the staging tree. I think it is fair to put the burden of not creatoing
> conflicting uids in the provisioning system the drives creating the
> staged entries.
>
> If a staged entry has a conflicting uid then at unstaging time we will
> throw an error and the admin will have to fix the staged entry (either
> remove it and ask the provisioning people to re-provision, or modifying
> it).

Ok great.
>
>>>> Recreating the object will also allow you to deal with the other case
>>>> you brought forward where the provisioning system used CN as the RDN,
>>>> but we want uid.
>> I am not sure: if some provisioning systems created the two entries
>>
>> # entry 1
>> dn: ou=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
>> objectClass: top
>> objectClass: account
>> uid: xxx
>> ou: TestUser
>>
>> # entry 2
>> dn: uid=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
>> objectClass: top
>> objectClass: posixAccount
>> cn: TestUser
>> uid: TestUser
>> ipaUniqueID: autogenerate
>> uidNumber: -1
>> gidNumber: -1
>>
>>
>> If we activate both entries. we will create a new entry with all the required objectclass but at the end we will need to pick up a 'uid' value.
>> Entry 2 will keep its 'uid'. Entry 1 we have two solutions, 'xxx' but then it changes the RDN value or 'TestUser' (the former RDN value) that is in collision with entry 2.
>>
>> I think it would simplify the problem if we enforce that staged entries have 'uid' RDN.
> To be honest I do not see the problem.
>
> 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.

>
>>>> I understand it gives operators a higher privilege, but I think we'll
>>>> have to think harder how to properly handle the issue.
>> A possibility is to create a "pre-active" status, between 'stage' and
>> 'active'.
>> The 'stage' container contains raw provisioned entries. 'pre-active' a
>> copy of the 'stage' entry with all the structural objectclasses.
>>
>> If 'pre-active' is out of the scope of uid uniqueness, we can add the
>> 'pre-active' entry before removing the 'stage' entry (and rollback in
>> case of failure). Then do a MODRDN (with appropriate aci) 'pre-active'
>> -> 'active'.
> 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'.
>
> Simo.
>