[Freeipa-devel] Supported Staged entries
thierry bordaz
tbordaz at redhat.com
Tue May 27 12:59:02 UTC 2014
On 05/27/2014 02:19 PM, 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.
>
> Martin
In short, a large kind of entries should be supported in staging and we
can not assum that provisioning in staging was done through FreeIPA CLI.
Now if an entry was not created by FreeIPA CLI ('ipa user-add --stage')
it could be impossible to update/unstage the entry with FreeIPA CLI .
For example with those two entries. 'ipa user-mod TestUser --stage' or
'ipa user-unstage TestUser' are unable to select the correct entry
# Created from provisioning system
dn: cn=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
objectClass: top
objectClass: organizationalperson
objectClass: posixAccount
cn: Test User
sn: User
uid: xxx
ipaUniqueID: autogenerate
uidNumber: -1
gidNumber: -1
nsAccountLock: True
# Created from the FreeIPA CLI
dn: uid=TestUser,cn=staged users,cn=accounts,cn=provisioning,dc=example,dc=com
objectClass: top
objectClass: organizationalperson
objectClass: posixAccount
cn: Test User
sn: User
uid: Test User
ipaUniqueID: autogenerate
uidNumber: -1
gidNumber: -1
nsAccountLock: True
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140527/23903aa4/attachment.htm>
More information about the Freeipa-devel
mailing list