[Freeipa-devel] Supported Staged entries
Jan Cholasta
jcholast at redhat.com
Tue May 27 12:32:06 UTC 2014
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.
>
> Simo.
--
Jan Cholasta
More information about the Freeipa-devel
mailing list