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

[Dmitri Pal]

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.

-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IdM portfolio
Red Hat, Inc.