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

[Simo Sorce]

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.

-- 
Simo Sorce * Red Hat, Inc * New York