On 05/27/2014 02:32 PM, Jan Cholasta wrote:
On 27.5.2014 14:22, Simo Sorce wrote:
On Tue, 2014-05-27 at 14:19 +0200, Martin Kosek wrote:
On 05/27/2014 02:16 PM, Simo Sorce wrote:
On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote:
On 05/27/2014 11:53 AM, Jan Cholasta wrote:
On 27.5.2014 11:14, thierry bordaz wrote:
Hello,

     Me again !!!

Thanks to all your inputs, the discussion about User_life_cycle
     clarified a lot workflow/command verbs.

     Now I have a doubt about what would be an entry in staging
(objectclass/attribute). Also I wonder if ipa CLI (ipa user-add
     --stage), would be the only support way to create stage entry.

     An active entry is looking like (with krb* attributes if the
     userpassword is defined):

         dn:
uid=tb17,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
         displayName: tb15 tb15
         cn: tb15 tb15
         objectClass: top
         objectClass: person
         objectClass: organizationalperson
         objectClass: inetorgperson
         objectClass: inetuser
         objectClass: posixaccount
         objectClass: krbprincipalaux
         objectClass: krbticketpolicyaux
         objectClass: ipaobject
         objectClass: ipasshuser
         objectClass: ipaSshGroupOfPubKeys
         objectClass: mepOriginEntry
         loginShell: /bin/sh
         gecos: tb15 tb15
         sn: tb15
         homeDirectory: /home/tb17
         uid: tb17
         mail: t...@idm.lab.bos.redhat.com
         krbPrincipalName: t...@idm.lab.bos.redhat.com
         givenName: tb15
         initials: tt
         ipaUniqueID: 3f1b5cce-e1b8-11e3-86fe-001a4a104ecd
         uidNumber: 646400009
         gidNumber: 646400009
         mepManagedEntry:
cn=tb17,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,
           dc=com
         memberOf:
cn=ipausers,cn=groups,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=
           com
         nsAccountLock: False


A staged entry created by 'ipa user-add --stage' may look like the following. This kind of entry is easy to activate 'ipa user-unstage'

         dn: uid=tb20,cn=staged
users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,
           dc=redhat,dc=com
         displayName: tb20 tb20
         cn: tb20 tb20
         objectClass: top
         objectClass: person
         objectClass: organizationalperson
         objectClass: inetorgperson
         objectClass: inetuser
         objectClass: posixaccount
         objectClass: krbprincipalaux
         objectClass: krbticketpolicyaux
         objectClass: ipaobject
         objectClass: ipasshuser
         objectClass: ipaSshGroupOfPubKeys
         loginShell: /bin/sh
         uidNumber: -1
         ipaUniqueID: autogenerate
         gidNumber: -1
         gecos: tb20 tb20
         sn: tb20
         homeDirectory: /home/tb20
         uid: tb20
         mail: t...@idm.lab.bos.redhat.com
         krbPrincipalName: t...@idm.lab.bos.redhat.com
         givenName: tb20
         initials: tt
         nsAccountLock: True

Now are we going to support the following entries for 'ipa user-unstage'

         dn: cn=tb20,cn=staged
users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,
           dc=redhat,dc=com
         objectClass: top
         objectClass: person
         sn: tb20
         cn: tb20
         nsAccountLock: True

     or

         dn: uid=tb20,cn=staged
users,cn=accounts,cn=provisioning,dc=idm,dc=lab,dc=bos,
           dc=redhat,dc=com
         objectClass: top
         objectClass: person
         objectClass: posixAccount
         sn: tb20
         cn: tb20 tb20
         uid: tb20
         uidNumber: -1
         gidNumber: -1
         homeDirectory: /home/tb20
         nsAccountLock: True


     thanks
     thierry

IIUC unstaging a user will do something like this:

     staged_user = ldap.get_entry(staged_dn, ['*'])
     api.Command.user_add(**staged_user)

So IMO virtually any kind of entry should be supported in the staging tree.

The workflow will be different from what Jan suggested, but yes, we should support wide range of entries. I suspect some provisioning systems may even
write entries with different RDN - i.e. with CN for example.

About the unstaging - we already spoke about it, we will need to consolidate current operations in user-add and user-mod in common functions that will be
called by those commands and user-unstage command.

I imagine user-unstage command would then do:

1) MODRDN from staged users to active users
2) Update user with the same default as user-add, if RDN is different than UID,
it should be converted to UID

I wonder how should be the step 2) authorized LDAP-wise. The easiest way to
make it happen is to give the operator making unstage operator write
permission/ACI to active users, but it may not be the ideal way - we would want to limit the write permission only to the actual unstage operation of the
particular user... Simo, what is your take on this?

My take is that users need to be created with uid=<name> as the RDN or
the operation should be refused. We have still some rules for what our
users need to look like.

Simo.

Hm, I was more relaxed in my original RFE and allowed records like:

dn: cn=Test User,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
objectClass: top
objectClass: organizationalperson
cn: Test User
sn: User
nsAccountLock: True

RDN is just part of the problem though - note that the user-unstage command would also need to generate the default attributes for the user (including kerberos principal ones) - and we need to somehow authorize that LDAP modify
operation.

My idea was that we read the entry and create a new on in the user area,
and once the operation is completed we delete the entry from the staging
area. This way creating a user has always the same workflow from the
framework pov, the staging are entry just "fills up the initial user
creation form".

+1, exactly what I thought it should do in my original comment.

If we use staging entry as a template for a new active entry could be difficult with uniqueness plugin (uid, ipaUniqueid,...). If we want those plugin to have both containers in their scope, we need to delete the stage entry before creating the active one.


Simo.



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

Reply via email to