[Freeipa-devel] User life cycle: plugins scope for staged users

[Dmitri Pal]

On 05/29/2014 02:24 PM, Simo Sorce wrote:
> On Thu, 2014-05-29 at 14:08 -0400, Dmitri Pal wrote:
>> On 05/29/2014 02:17 AM, Martin Kosek wrote:
>>> On 05/29/2014 04:09 AM, Dmitri Pal wrote:
>>>> On 05/22/2014 10:33 AM, thierry bordaz wrote:
>>>>> Hello,
>>>>>
>>>>>       In order to provision staged users (account inactivated) with
>>>>>       there initial values:
>>>>>
>>>>>           /usr/bin/ipa user-add tb20 --to-stage --first=tb20 --last=tb20
>>>>>           -----------------
>>>>>           Added user "tb20"
>>>>>           -----------------
>>>>>             User login: tb20
>>>>>             First name: tb20
>>>>>             Last name: tb20
>>>>>             Full name: tb20 tb20
>>>>>             Display name: tb20 tb20
>>>>>             Initials: tt
>>>>>             Home directory: /home/tb20
>>>>>             GECOS: tb20 tb20
>>>>>             Login shell: /bin/sh
>>>>>             Kerberos principal: tb20 at IDM.LAB.BOS.REDHAT.COM
>>>>>             Email address: tb20 at idm.lab.bos.redhat.com
>>>>>             UID: -1
>>>>>             GID: -1
>>>>>             Account disabled: true
>>>>>             Password: False
>>>>>             Kerberos keys available: False
>>>>>
>>>>>           ldapsearch -LLL -h localhost -p 389 -D "cn=directory manager"
>>>>>           -w Secret123 -b "dc=idm,dc=lab,dc=bos,dc=redhat,dc=com" uid=tb20
>>>>>           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
>>>>>
>>>>>       I needed to resctrict the scope of the following plugins:
>>>>>
>>>>>           dn: cn=ipaUniqueID uniqueness,cn=plugins,cn=config
>>>>>           nsslapd-pluginarg1:
>>>>>           cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
>>>>>
>>>>>           dn: cn=IPA Unique IDs,cn=IPA UUID,cn=plugins,cn=confi
>>>>>           ipauuidscope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
>>>>>
>>>>>           dn: cn=Posix IDs,cn=Distributed Numeric Assignment
>>>>>           Plugin,cn=plugins,cn=config
>>>>>           dnaScope: cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
>>>>>
>>>>>           dn: cn=MemberOf Plugin,cn=plugins,cn=config
>>>>>           memberofentryscope:
>>>>>           cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com
>>>>>
>>>>>       In fact I need them to not modify the added entry when it is added
>>>>>       under "cn=staged users,cn=accounts,cn=provisioning,$SUFFIX".
>>>>>       Now is it possible to limit those plugins scope to the
>>>>>       'cn=accounts' part of the tree ? I guess not.
>>>>>       If it is not possible, a solution is to make the scope
>>>>>       multi-valued attributes or to introduce a new config attribute
>>>>>       '*notInScope' also multi-valued.
>>>>>       A problem is the 'cn=ipaUniqueID uniqueness' that rely on the
>>>>>       'attribute uniqueness' plugin with a argv[ ], not really
>>>>>       convenient to pass 2 multivalued attributes.
>>>>>
>>>>>       If anyone is having others solutions it would help me a lot :-)
>>>>>
>>>>>       thanks
>>>>>       thierry
>>>>>
>>>>>
>>>> The easiest solution IMO is to not treat staging area as an account area, i.e
>>>> instead of cn=staging, cn=accounts, dc=... I suggest saving users in cn=users,
>>>> cn=staging, dc=...
>>> Actually, this almost exactly the DN I wrote in the RFE:
>>>
>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management#User_status
>>>
>>> Proposed containers are:
>>>
>>> cn=staged users,cn=accounts,cn=provisioning,$SUFFIX
>>> cn=deleted users,cn=accounts,cn=provisioning,$SUFFIX
>>>
>>>> This way if in future we will have some staging for other objects (for whatever
>>>> reason) we will create containers under common "staging" area.
>>>> I would also argue that "deleted" should not be under accounts.
>>> Agreed. This will also make the plugin configuration (tree exclusion) easier.
>>>
>>> Martin
>>>
>> I do not think so. My proposal is not to have staging under cn=accounts
>> because most of the plugins enforce uniqueness and other consistency
>> like DNA in the cn=account sub tree. Moving it out would move the
>> staging out of the scope of the plugins and plugin configuration would
>> not need to change.
> Dmitri, I think you need to pay attention to the whole suffix :-)
>
> Simo.
>
@#$%^.
Mia Culpa. Missed the cn=provisioning part.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.