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

[Rob Crittenden]

thierry bordaz wrote:
> 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

So your plugin is going to manage restriction access to nsAccountLock or
is this going to be via an ACI?

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

Why can't nsAccountLock be modified, or was this a cut-n-paste error?

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

Just to be clear, your plugin is going to remove all of these?

>                 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 ?

There is a module-level set of options in takes_params and a
command-specific set in takes_options. I think you'll need to add these
into takes_options on a per-command basis. If there is a set of
identical options used in several places you can define them at the top
level and add them in. See _trust_type_option in trust.py for an example.

rob