[Freeipa-devel] Supported Staged entries

[Martin Kosek]

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: tb17 at idm.lab.bos.redhat.com
>>         krbPrincipalName: tb17 at 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: tb20 at idm.lab.bos.redhat.com
>>         krbPrincipalName: tb20 at 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?

Thanks,
Martin