[Freeipa-devel] Supported Staged entries
Simo Sorce
ssorce at redhat.com
Tue May 27 12:16:24 UTC 2014
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: 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?
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.
More information about the Freeipa-devel
mailing list