[Freeipa-devel] Supported Staged entries
thierry bordaz
tbordaz at redhat.com
Tue May 27 12:40:28 UTC 2014
On 05/27/2014 02:32 PM, Jan Cholasta wrote:
> On 27.5.2014 14:22, Simo Sorce wrote:
>> 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".
>
> +1, exactly what I thought it should do in my original comment.
If we use staging entry as a template for a new active entry could be
difficult with uniqueness plugin (uid, ipaUniqueid,...).
If we want those plugin to have both containers in their scope, we need
to delete the stage entry before creating the active one.
>
>>
>> Simo.
>
>
More information about the Freeipa-devel
mailing list