<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 06/16/2014 03:04 PM, Rob Crittenden wrote: </div> <blockquote cite="mid:539EEB47.3030901@redhat.com" type="cite"> <pre wrap="">thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">Hello, When a stage user is activate (ipa stageuse-activate), UUID plugin (DS) checks that the ipaUniqueID value of the new active user is 'autogenerate'. This is useful to prevent a provisioning systems to create Active user with invalid ipaUniqueID. Now one of the workflow step is to move a Delete user into the Stage container. In that case the Stage entry contains a ipaUniqueID and can not activate. A possibility is to 'reset' the ipaUniqueID value to 'autogenerate' during that step but I wonder it it is valid to reset it. Also, is it valid to reset it and keep others values like uidNumber/gidNumber ? </pre> </blockquote> <pre wrap=""> I guess to walk through the logic, the unique id is there so we can uniquely address an entry without worrying about the value changing (like uid, name, etc). So if it is a brand new entry from the provisioning system, yeah, we want to always set it to autogenerate. If a user is deleted I think we agreed that all links to that user would be broken (memberships, hbac rules, etc) which means that it doesn't matter if the unique id is changed I suppose. IMHO uidnumber/gidnumber should always be maintained. rob </pre> </blockquote> Hello Rob, <blockquote>Thanks for your precise feedback and sorry for my late answer. So if I try to consolidate my understandings, the workflow would be: <ol> <li>Staging (container: cn=staged users,cn=accounts,cn=provisioning,SUFFIX) </li> <ul> <li>ipa stageuser-add <login> It creates a stage entry with</li> </ul> </ol> <blockquote> <blockquote> <blockquote><tt>uidNumber: -1</tt> <tt>gidNumber: -1</tt> <tt>ipaUniqueID: autogenerate</tt> <tt>description: __no_upg__ manager: checks that the DN is an active user nsAccountLock: True</tt> </blockquote> </blockquote> </blockquote> <ol> <ul> <li>ipa stageuser-add <login> --from-delete</li> </ul> </ol> <blockquote> <blockquote>It moves a deleted entry to staging container where <blockquote><tt>uidNumber: <unchanged, so it is preserved from the prevous active account></tt> <tt>gidNumber: <unchanged</tt><tt><tt>, so it is preserved from the prevous active account</tt>></tt> <tt>ipaUniqueID: autogenerate (reset to autogenerate)</tt> <tt>description: __no_upg__ (to show there is no managed group) nsAccountLock: True </tt></blockquote> </blockquote> </blockquote> <ol> <ul> <li>ipa stageuser-activate <login> It adds in the active container, a destination copy of a stage entry where <blockquote><tt>uidNumber: <unchanged, so a provisioning system can force a uidNumber></tt> <tt>gidNumber: <unchanged</tt><tt><tt>, so a provisioning system can force a gidNumber</tt>></tt> <tt>ipaUniqueID: autogenerate (reset to autogenerate)</tt> <tt>description: value __no_upg__ is removed nsAccountLock: False</tt> <tt>DN syntax attributes are cleared (but kept for schema checking) except: manager, managedby and secretary (those values must be active DN entries) </tt></blockquote> Then remove the source entry from the 'Staging' container. </li> <li>ipa stageuser-find <login></li> <li>ipa stageuser-show <login></li> <li>ipa stageuser-mod <login> <blockquote>nsAccountLock: can not be modify DN syntax attributes: checks that the DN is an active user </blockquote> </li> <li>ipa stageuser-del <login> </li> </ul> <li>Active (container: cn=users,cn=accounts,SUFFIX) A new entry (user-add or stageuser-activate) is updated by DS plugins (UUID, memberof, managed entries and DNA plugins) </li> </ol> <blockquote> <ul> <li>ipa user-add <login> <blockquote><tt>nsAccountLock:</tt><tt> False</tt> </blockquote> </li> <li>ipa user-find <login></li> <li>ipa user-show <login></li> <li>ipa user-mod <login> <blockquote><tt>nsAccountLock: can not be modify DN syntax attributes: checks that DN is an active user</tt> </blockquote> </li> <li>ipa user-delete <login> moves (modrdn) the entry under 'Delete' container but first do the following upates <blockquote><tt>nsAccountLock: true all memberships attributes updated by plugins (managed entries/memberof) description: __no_upg__ DN syntax attributes are cleared (but kept for schema checking) except: manager, managedby and secretary)</tt> </blockquote> </li> <li>ipa user-undelete <login> moves (modrdn) the entry under 'Active' containers. DS plugins will update the membership attributes. Before the modrdn, the updates are done: <blockquote><tt><tt>nsAccountLock: False</tt> description: value __no_upg__ is removed </tt><tt>DN syntax attributes are cleared (but kept for schema checking) except: manager, managedby and secretary (those values must be active DN entries)</tt> </blockquote> </li> </ul> </blockquote> <ol> <li>Delete (container is cn=deleted users,cn=accounts,SUFFIX) This container has no specific plugin, only user and stageuser are implemented. </li> </ol> I would have an additional question. 'stageuser-add' is used both to create a stage entry or to recover a Delete entry into Staging container. In case of recover 'stageuser-add <login> --from-delete', the options '--first' and '--last' are optional because the entry already exists. But these options are mandatory to create a new stage entry. Currently I made them optional (in take_param), and in case of creation of a stage entry, it displays an error message requesting these options. In short, if a flag is (--from-delete) I need options to be optional else to be mandatory. Does anyone know if it exists examples how to handle such situation ? thanks thierry </blockquote> </body> </html>