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: t...@idm.lab.bos.redhat.com
            Email address: t...@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: t...@idm.lab.bos.redhat.com
          krbPrincipalName: t...@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.

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to