On 06/17/2014 07:35 PM, Rob Crittenden wrote:
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?

Hi,
my first intention was to do this in the plugin.
It does not protect from a ldapmodify. ACI would be a better protection but it has overhead.


           * 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?
Well, I was thinking to have 'nsAccountLock: False' only in Active container. And the value is set at the transition when the entry becomes active (stageuser-activate and user-undelete)

           * 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?
Here I mention membership managed by the scoping of managed entries plugin and memberof plugin.
So the 'user plugin' will not wipe the memberships attributes.
Now if it remains membership attributes 'user plugin' will remove them when all DN syntax attributes will be cleared (except manager/managedby/secretary).

                 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.

Great !! thanks a lot I will have a look

thanks
thierry

rob


_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to