<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 05/27/2014 04:35 PM, Martin Kosek wrote: </div> <blockquote cite="mid:5384A2C0.1050500@redhat.com" type="cite"> <pre wrap="">On 05/27/2014 04:27 PM, Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">On Tue, 2014-05-27 at 15:21 +0200, Martin Kosek wrote: </pre> <blockquote type="cite"> <pre wrap="">This topic was already discussed in the past, see following part of the design: <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> 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: <a class="moz-txt-link-freetext" href="https://fedorahosted.org/389/ticket/47553">https://fedorahosted.org/389/ticket/47553</a> </pre> </blockquote> <pre wrap=""> 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.</pre> </blockquote> </blockquote> Both approach looks possible: <ul> <li>adding required structural OC+AT in the existing entry</li> <li>creating a new entry with all structural OC+AT and update the AT values with what exists in the stage entry</li> </ul> but I think the second one would be simpler to implement. 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. <blockquote cite="mid:5384A2C0.1050500@redhat.com" type="cite"> <blockquote type="cite"> <pre wrap=""> 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.</pre> </blockquote> </blockquote> I am not sure: if some provisioning systems created the two entries <pre wrap=""># 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. </pre> <blockquote cite="mid:5384A2C0.1050500@redhat.com" type="cite"> <blockquote type="cite"> <pre wrap=""> I understand it gives operators a higher privilege, but I think we'll have to think harder how to properly handle the issue.</pre> </blockquote> </blockquote> 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'. <blockquote cite="mid:5384A2C0.1050500@redhat.com" type="cite"> <blockquote type="cite"> <pre wrap=""> Perhaps the best way is to create a new "proxy-API" to "promote" users from a staging area. This service will have the privilege to create users using its own credentials instead of those of the operator. This can be done later, meanwhile we will have to accept operators need the privilege to create users. Simo. </pre> </blockquote> <pre wrap=""> Ok, the point about structural objectclasses is a strong one. Thierry, you what to do - this should be noted in the design page... Martin </pre> </blockquote> </body> </html>