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