[Freeipa-devel] Supported Staged entries
thierry bordaz
tbordaz at redhat.com
Tue May 27 13:38:10 UTC 2014
On 05/27/2014 03:08 PM, Simo Sorce wrote:
> On Tue, 2014-05-27 at 14:40 +0200, thierry bordaz wrote:
>> 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,...).
> ipaUniqueid will not be a problem, staging entries should not get one at
> all, or if they get one, we just ignore it in unstaging, and the new
> user gets a new one.
Yes I agree, scope of ipaUniqueId uniqueness should not look at 'stage'.
Having ipaUniqueId depends on the entry objectclass. But I think 'uid'
should be a mandatory RDN and if it is inherited from 'ipaObject' the
entry will have 'ipaUniqueId'.
>
> uid uniqueness would be a problem if we enforce uniqueness in staging
> too.
It was the use case of 'John Doe' (uid=jdoe) being active/delete and a
new stage user 'Jenny Doe' should be forced to pick up a different uid.
So yes in my mind, uid scope should cover the full suffix.
>
>> If we want those plugin to have both containers in their scope, we need
>> to delete the stage entry before creating the active one.
> The issue with deleting in advance is that we risk to lose entries if we
> have a framework issue after we delete the entry but before we create a
> new one.
>
> I am thinking we may not want to enforce uniqueness over staging, though
> that could cause issues too, as the entry will have to be checked
> explicitly in advance, OTOH if you are using a staging process, then
> probably the provisioning system already have a way to create and
> enforce name uniqueness, so maybe it is not such a big deal ?
>
>
> Or alternatively that we create the new user with a RDN we rename after
> the staging entry is deleted; like:
>
> add uid=thierry-from-staging,cn=users,cn=accounts
> del uid=thierry,cn=users,cn=staging
> modrdn uid=thierry-from-staging -> uid=thierry
>
> I am not sure what is the best method, perhaps we should make a list of
> pros/cons an then decide.
>
> Simo.
>
More information about the Freeipa-devel
mailing list