<html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#FFFFFF" text="#000000"> <div class="moz-cite-prefix">On 05/27/2014 02:19 PM, Martin Kosek wrote: </div> <blockquote cite="mid:538482D4.1040503@redhat.com" type="cite"> <pre wrap="">On 05/27/2014 02:16 PM, Simo Sorce wrote: </pre> <blockquote type="cite"> <pre wrap="">On Tue, 2014-05-27 at 13:01 +0200, Martin Kosek wrote: </pre> <blockquote type="cite"> <pre wrap="">On 05/27/2014 11:53 AM, Jan Cholasta wrote: </pre> <blockquote type="cite"> <pre wrap="">On 27.5.2014 11:14, thierry bordaz wrote: </pre> <blockquote type="cite"> <pre wrap="">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: <a class="moz-txt-link-abbreviated" href="mailto:tb17@idm.lab.bos.redhat.com">tb17@idm.lab.bos.redhat.com</a> krbPrincipalName: <a class="moz-txt-link-abbreviated" href="mailto:tb17@IDM.LAB.BOS.REDHAT.COM">tb17@IDM.LAB.BOS.REDHAT.COM</a> 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: <a class="moz-txt-link-abbreviated" href="mailto:tb20@idm.lab.bos.redhat.com">tb20@idm.lab.bos.redhat.com</a> krbPrincipalName: <a class="moz-txt-link-abbreviated" href="mailto:tb20@IDM.LAB.BOS.REDHAT.COM">tb20@IDM.LAB.BOS.REDHAT.COM</a> 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 </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> 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? </pre> </blockquote> <pre wrap=""> 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. </pre> </blockquote> <pre wrap=""> 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. Martin </pre> </blockquote> In short, a large kind of entries should be supported in staging and we can not assum that provisioning in staging was done through FreeIPA CLI. Now if an entry was not created by FreeIPA CLI ('ipa user-add --stage') it could be impossible to update/unstage the entry with FreeIPA CLI . For example with those two entries. 'ipa user-mod TestUser --stage' or 'ipa user-unstage TestUser' are unable to select the correct entry <pre wrap=""># Created from provisioning system dn: cn=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: organizationalperson objectClass: posixAccount cn: Test User sn: User uid: xxx ipaUniqueID: autogenerate uidNumber: -1 gidNumber: -1 nsAccountLock: True</pre> <pre wrap=""># Created from the FreeIPA CLI dn: uid=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com objectClass: top objectClass: organizationalperson objectClass: posixAccount cn: Test User sn: User uid: Test User ipaUniqueID: autogenerate uidNumber: -1 gidNumber: -1 nsAccountLock: True</pre> <pre wrap=""> </pre> </body> </html>