[Freeipa-devel] Supported Staged entries
Martin Kosek
mkosek at redhat.com
Tue May 27 12:19:32 UTC 2014
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.
Martin
More information about the Freeipa-devel
mailing list