[Freeipa-devel] User Life Cycle: enforce ipaUniqueID generation by the server

[thierry bordaz]

On 06/16/2014 03:04 PM, Rob Crittenden wrote:
> thierry bordaz wrote:
>> 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 ?
> 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
Hello Rob,

    Thanks for your precise feedback and sorry for my late answer.
    So if I try to consolidate my understandings, the workflow would be:

     1. Staging (container: cn=staged
        users,cn=accounts,cn=provisioning,SUFFIX)
          * ipa stageuser-add <login>
            It creates a stage entry with

                uidNumber: -1
                gidNumber: -1
                ipaUniqueID: autogenerate
                description: __no_upg__
                manager: checks that the DN is an active user
                nsAccountLock: True

          * ipa stageuser-add <login> --from-delete

            It moves a deleted entry to staging container where

                uidNumber: <unchanged, so it is preserved from the
                prevous active account>
                gidNumber: <unchanged, so it is preserved from the
                prevous active account>
                ipaUniqueID: autogenerate (reset to autogenerate)
                description: __no_upg__ (to show there is no managed group)
                nsAccountLock: True

          * ipa stageuser-activate <login>
            It adds in the active container, a destination copy of a
            stage entry where

                uidNumber: <unchanged, so a provisioning system can
                force a uidNumber>
                gidNumber: <unchanged, so a provisioning system can
                force a gidNumber>
                ipaUniqueID: autogenerate (reset to autogenerate)
                description: value __no_upg__ is removed
                nsAccountLock: False
                DN syntax attributes are cleared (but kept for schema
                checking) except: manager, managedby and secretary
                (those values must be active DN entries)

            Then remove the source entry from the 'Staging' container.
          * ipa stageuser-find <login>
          * ipa stageuser-show <login>
          * ipa stageuser-mod <login>

                nsAccountLock: can not be modify
                DN syntax attributes: checks that the DN is an active user

          * ipa stageuser-del <login>
     1. 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)

          * ipa user-add <login>

                nsAccountLock:False

          * ipa user-find <login>
          * ipa user-show <login>
          * ipa user-mod <login>

                nsAccountLock: can not be modify
                DN syntax attributes: checks that DN is an active user

          * ipa user-delete <login>
            moves (modrdn) the entry under 'Delete' container but first
            do the following upates

                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)


          * 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:

                nsAccountLock: False
                description: value __no_upg__ is removed
                DN syntax attributes are cleared (but kept for schema
                checking) except: manager, managedby and secretary
                (those values must be active DN entries)

     1. Delete (container is cn=deleted users,cn=accounts,SUFFIX)
        This container has no specific plugin, only user and stageuser
        are implemented.



    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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140617/3e6ecb3d/attachment.htm>