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. _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel