[389-users] memberOf task problem
Nathan Kinder
nkinder at redhat.com
Tue May 26 17:15:56 UTC 2009
John A. Sullivan III wrote:
> Very interesting. The shipping dse.ldif which the instructions say to
> use as a template to edit the 8.0 dse.ldif has memberofgroupattr: member
>
> dn: cn=MemberOf Plugin,cn=plugins,cn=config
> objectClass: top
> objectClass: nsSlapdPlugin
> objectClass: extensibleObject
> cn: MemberOf Plugin
> nsslapd-pluginpath: libmemberof-plugin
> nsslapd-plugininitfunc: memberof_postop_init
> nsslapd-plugintype: postoperation
> nsslapd-pluginenabled: off
> nsslapd-plugin-depends-on-type: database
> memberOfGroupAttr: member
> memberOfAttr: memberOf
>
> When I changed it to uniqueMember, it worked!
>
> So it looks like there are several issues/errors/bugs in the
> instructions and procedures for upgrading from 8.0 to 8.1
>
> 1. The memberOf plugin is enabled by default and needs to be
> manually enabled (not really a bug but it is mentioned nowhere
> in the docs that I saw)
> 2. One must manually add the inetuser to each object with which one
> wishes to use the plugin. This does not appear to be a default
> objectClass for user creation - at least in 8.0
>
It all depends on how you provision your users, and what attributes you
are using (they don't have to be "member" and
"memberOf"). It is up to the administrator to use the proper
objectclass that allows the attribute defined as the "memberOfAttr"
config value in the member entries.
> 3. One must change the default memberofgroupattr from member to
> uniqueMember
>
This is going to depend on the attribute you use to define grouping.
Some use the "groupOfNames" objectclass for a group
entry, which uses the "member" attribute to define members. It appears
that you are using "groupOfUniqueNames", which
uses "uniqueMember". The memberOf plug-in allows you to use whatever
attributes you want for both the grouping attribute
as well as the membership attribute. In fact, the plug-in could be used
for things completely unrelated to membership.
> 4. The fixup-memberof.pl script is not generated from the template.
>
Yes, this appears to be a bug related to in-place upgrades. Please file
a bug on this.
> Thanks very much for your help - John
>
> On Tue, 2009-05-26 at 09:38 +0200, Andrey Ivanov wrote:
>
>> If it still doesn't work, it's a matter of the plug-in configuration
>> and presence. Verify your dse.ldif. You shoud have something like
>>
>> dn: cn=MemberOf Plugin,cn=plugins,cn=config
>> objectClass: top
>> objectClass: nsSlapdPlugin
>> objectClass: extensibleObject
>> cn: MemberOf Plugin
>> nsslapd-pluginPath: libmemberof-plugin
>> nsslapd-pluginInitfunc: memberof_postop_init
>> nsslapd-pluginType: postoperation
>> nsslapd-pluginEnabled: on
>> nsslapd-plugin-depends-on-type: database
>> memberofgroupattr: uniqueMember
>> memberofattr: memberOf
>> nsslapd-pluginId: memberof
>> nsslapd-pluginVersion: 1.2.0
>> nsslapd-pluginVendor: Fedora Project
>> nsslapd-pluginDescription: memberof plugin
>>
>>
>> The importnant parameters are :
>> nsslapd-pluginEnabled: on
>> memberofgroupattr: uniqueMember
>> memberofattr: memberOf
>>
>> Other than that you may have the plug-in binaries missing...
>>
>> 2009/5/25 John A. Sullivan III <jsullivan at opensourcedevel.com>
>> Hmm . . . this made perfect sense and I thought it would be
>> the end of
>> my problems for sure. However, I added inetUser, ran
>> fixup_memberof.pl
>> and still see no memberOf populated attribute even if I ask
>> for it
>> explicitly:
>>
>> [root at ldap01 ~]# /usr/lib64/mozldap/ldapsearch -b
>> "ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz" -D
>> "cn=Directory Manager" -w - -h ldap01 uid=jasiii
>> Enter bind password:
>> version: 1
>> dn:
>> uid=jasiii,ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz
>>
>> objectClass: top
>> objectClass: person
>> objectClass: organizationalPerson
>> objectClass: inetOrgPerson
>> objectClass: posixAccount
>> objectClass: account
>> objectClass: posixgroup
>> objectClass: shadowaccount
>>
>> objectClass: inetuser
>> physicalDeliveryOfficeName: Kennebunk
>> telephoneNumber: +1 (207) xxx-xxxx
>> mail: jsullivan at example.com
>> sn: Sullivan III
>> givenName: John A.
>> loginShell: /bin/bash
>> homeDirectory: /home/jasiii
>> gidNumber: 100001
>> uidNumber: 100001
>> cn: jasiii
>> uid: jasiii
>> userPassword: {SSHA}p5K8zhxQYqkjCXmu617H2DtnDKDgnom3qTgQAg==
>> shadowLastChange: 14366
>> l: Kennebunk
>> postalCode: 04043-XXXX
>> postOfficeBox: PO Box XXX
>> st: ME
>> [root at ldap01 ~]# /usr/lib64/mozldap/ldapsearch -b
>> "ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz" -D
>> "cn=Directory Manager" -w - -h ldap01 uid=jasiii memberOf
>> Enter bind password:
>> version: 1
>> dn:
>> uid=jasiii,ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz
>>
>>
>> I then explicitly added the memberOf attribute to a user,
>> created a
>> bogus group and added the user to the group. Still no
>> memberOf. What
>> am I doing wrong? Thanks - John
>>
>>
>>
>> On Fri, 2009-05-22 at 22:59 +0200, Andrey Ivanov wrote:
>> >
>> >
>> > 2009/5/22 John A. Sullivan III
>> <jsullivan at opensourcedevel.com>
>> > Ah, I did not do that as I thought the filter would
>> make the
>> > change to
>> > users with objectClass inetOrgPerson.
>> > No. The filter just searches what you have in your directory
>> >
>> >
>> > I am virtually certain the users
>> > do not explicitly have inetUser as an object class.
>> Are they
>> > supposed
>> > to?
>> > Yes. The set of the attributes that your entry can hold is
>> defined by
>> > the classes listed in "objectClass". And the attribute
>> memberOf is
>> > part of the "inetUser" objectClass.
>> >
>> > Is this done by default or is the need to add this
>> object
>> > class to
>> > all users in order to use memberOf missing from the
>> > documentation (or
>> > overlooked by me!).
>> > No. It is not done by default, you need to add the
>> "objectClass:
>> > inetUser" (or any other objectClass containing the memberOf
>> attribute)
>> > to each user entry. You can make a small perl script that
>> does for all
>> > your users something like
>> >
>> > -------------
>> > dn:
>> uid=jasiii,ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz
>> > changetype: add
>> > objectclass: inetUser
>> > -------------
>> >
>> >
>> > You can test it with the GUI of the console for one or two
>> user
>> > entries just to be sure the attribute memberOf works as you
>> wish...
>> >
>> >
>> >
>> >
>> > objectClass: top
>> > objectClass: person
>> > objectClass: organizationalPerson
>> > objectClass: inetOrgPerson
>> > objectClass: posixAccount
>> > objectClass: account
>> > objectClass: posixgroup
>> > objectClass: shadowaccount
>> > The origin of your problem is the absence of "objectClass:
>> inetUser"
>> > necessary to add memberOf attribute to the entry...
>> >
>> >
>> >
>> > Thanks - John
>> >
>> >
>> > On Fri, 2009-05-22 at 08:31 +0200, Andrey Ivanov
>> wrote:
>> > > Can you show me the result of
>> > > /usr/lib64/mozldap/ldapsearch -b
>> > > "ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz"
>> -D
>> > "cn=Directory
>> > > Manager" -w - -h ldap uid=jasiii objectClass
>> > >
>> > > It will list all the objectClasses of your entry.
>> If
>> > "objectClass:
>> > > inetUser" is not present in the result of this
>> search you
>> > should, as i
>> > > said in the previous message, add this objectClass
>> to all
>> > the entries
>> > > you're going to manage with memberOf plug-in, smth
>> like:
>> > >
>> > > dn:
>> >
>> uid=jasiii,ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz
>> > > changetype: add
>> > > objectclass: inetUser
>> > >
>> > >
>> > > Hope it helps .
>> > >
>> > >
>> > >
>> > > 2009/5/22 John A. Sullivan III
>> > <jsullivan at opensourcedevel.com>
>> > > I'm starting to feel really stupid here -
>> still not
>> > working.
>> > >
>> > > I thought the filter must be the problem
>> for sure.
>> > I assumed
>> > > from the
>> > > documentation that no filter meant the
>> task would
>> > add the
>> > > attribute for
>> > > everything that could take a memberOf
>> attribute. I
>> > did not
>> > > realize it
>> > > defaulted to inetuser. So I recreated the
>> task with
>> > a filter
>> > > of
>> > > (objectClass=inetOrgPerson) but it still
>> did not
>> > seem to work.
>> > >
>> > > I thought perhaps I was doing ldapmodify
>> wrong
>> > (enter the
>> > > parameters,
>> > > double enter, then CTL D) so I edited the
>> > fixup-memberof.pl
>> > > script
>> > > according to Rich's instructions. It ran
>> without
>> > error (by
>> > > the way, it
>> > > reflects the admin password when using -w
>> - !!!).
>> > But still
>> > > no success.
>> > >
>> > > Perhaps I am checking incorrectly. I did
>> not expect
>> > to see
>> > > memberOf
>> > > listed as an attribute in the advanced
>> console
>> > screen for the
>> > > user since
>> > > it is a managed attribute. But I did try
>> to view it
>> > with an
>> > > ldapsearch:
>> > > It should be visible as an attribute you can add
>> (provided
>> > your entry
>> > > has "objectClass: inetUser")
>> > >
>> > >
>> > >
>> > >
>> > > /usr/lib64/mozldap/ldapsearch -b
>> > >
>> > >
>> "ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz"
>> > -D
>> > > "cn=Directory
>> > > Manager" -w - -h ldap uid=jasiii memberOf
>> > >
>> > > Is this how I would check for success?
>> > >
>> > > There is nothing suspicious in the error
>> log. I do
>> > have the
>> > > audit log
>> > > enabled. I see the creation and automatic
>> deletion
>> > of the
>> > > task but I do
>> > > not see any changes to objects to add and
>> populate
>> > the
>> > > memberOf
>> > > attribute. I'll paste in some excerpts
>> below.
>> > >
>> > > What next? Thanks - John
>> > >
>> > > time: 20090520221132
>> > > dn: cn=fixMemberOf,cn=memberof
>> > task,cn=tasks,cn=config
>> > > changetype: add
>> > >
>> > > objectClass: top
>> > > objectClass: extensibleObject
>> > > cn: fixMemberOf
>> > > basedn: o=Internal,dc=ssiservices,dc=biz
>> > >
>> > > creatorsName: cn=xxxx
>> > > modifiersName: cn=xxx
>> > > createTimestamp: 20090521021132Z
>> > > modifyTimestamp: 20090521021132Z
>> > >
>> > > time: 20090520221333
>> > > dn: cn=fixmemberof,cn=memberof
>> > task,cn=tasks,cn=config
>> > > changetype: delete
>> > > modifiersname:
>> cn=server,cn=plugins,cn=config
>> > >
>> > > time: 20090520222242
>> > > dn: cn=fixMemberOf,cn=memberof
>> > task,cn=tasks,cn=config
>> > > changetype: add
>> > >
>> > > objectClass: top
>> > > objectClass: extensibleObject
>> > > cn: fixMemberOf
>> > > basedn:
>> > ou=Desks,o=a100,o=Internal,dc=ssiservices,dc=biz
>> > > creatorsName: cn=xxxx
>> > > modifiersName: cn=xxxx
>> > > createTimestamp: 20090521022242Z
>> > > modifyTimestamp: 20090521022242Z
>> > >
>> > > time: 20090520222442
>> > > dn: cn=fixmemberof,cn=memberof
>> > task,cn=tasks,cn=config
>> > > changetype: delete
>> > > modifiersname:
>> cn=server,cn=plugins,cn=config
>> > >
>> > > .
>> > > .
>> > > .
>> > > time: 20090521183523
>> > > dn: cn=memberOf_fixup_2009_5_21_18_35_23,
>> > cn=memberOf task,
>> > > cn=tasks,
>> > > cn=config
>> > > changetype: add
>> > > objectClass: top
>> > > objectClass: extensibleObject
>> > > cn: memberOf_fixup_2009_5_21_18_35_23
>> > > basedn: o=Internal,dc=ssiservices,dc=biz
>> > >
>> > > filter: (objectClass=inetOrgPerson)
>> > > creatorsName: cn=xxxx
>> > > modifiersName: cn=xxxx
>> > > createTimestamp: 20090521223523Z
>> > > modifyTimestamp: 20090521223523Z
>> > >
>> > > time: 20090521183724
>> > > dn:
>> cn=memberof_fixup_2009_5_21_18_35_23,cn=memberof
>> > > task,cn=tasks,cn=config
>> > >
>> > > changetype: delete
>> > > modifiersname:
>> cn=server,cn=plugins,cn=config
>> > >
>> > > time: 20090521185804
>> > > dn:
>> > >
>> >
>> cn=general,ou=1.1,ou=console,ou=cn=xxxxx,ou=userpreferences,ou=ssiservices.biz,o=netscaperoot
>> > > changetype: modify
>> > > replace: nsPreference
>> > > nsPreference::
>> > >
>> >
>> IwojVGh1IE1heSAyMSAxODo1ODowNSBFRFQgMjAwOQpXaWR0aD0xMjgwClNob3
>> > >
>> > >
>> >
>> dTdGF0dXNCYXI9dHJ1ZQpTaG93QmFubmVyQmFyPXRydWUKWT0wCkhlaWdodD03NjkKWD0wCg==
>> > > -
>> > > replace: modifiersname
>> > > modifiersname: cn=xxxxx
>> > > -
>> > > replace: modifytimestamp
>> > > modifytimestamp: 20090521225804Z
>> > > -
>> > >
>> > >
>> > > On Thu, 2009-05-21 at 15:59 +0200, Andrey
>> Ivanov
>> > wrote:
>> > > >
>> > > >
>> > > > 2009/5/21 John A. Sullivan III
>> > > <jsullivan at opensourcedevel.com>
>> > > > Thank you, Andrey. I did do an
>> updatedb
>> > and then
>> > > locate - no
>> > > > fixup-member0f.pl - just
>> > > template.fixup-memberOf.pl :-(
>> > > > It is very strange. Normally during the
>> server
>> > installation
>> > > the
>> > > > template should be converted to the
>> "normal" perl
>> > script.
>> > > >
>> > > > Have you verified the configuration of
>> the
>> > memberOf plugin,
>> > > especially
>> > > > the arguments/attributes
>> "memberofgroupattr" and
>> > > "memberofattr" ?
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > Unless I'm missing something,
>> you're
>> > ldapmodify
>> > > looks just
>> > > > like mine
>> > > > except for the cn (I believe the
>> > documentation says
>> > > it can be
>> > > > called
>> > > > anything) and I did not use a
>> filter
>> > (again, I
>> > > believe the
>> > > > documentation
>> > > > says it is optional and our dit
>> is still
>> > rather
>> > > small).
>> > > > If you do not put the filter into the
>> ldif then
>> > the default
>> > > filter is
>> > > > used : "(objectClass=inetuser)". Do all
>> your user
>> > entries
>> > > include this
>> > > > objectClass (inetuser)? If not, you
>> should add
>> > this
>> > > objectClass to all
>> > > > the entries where you want the memberOf
>> attribute
>> > to appear.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > I did create a new group and add
>> myself to
>> > it as you
>> > > suggested
>> > > > (thank
>> > > > you). Surprisingly, it did not
>> appear to
>> > work. I
>> > > did not see
>> > > > a
>> > > > memberOf attribute populated for
>> me. I
>> > then thought
>> > > I would
>> > > > see if I
>> > > > need to manually add that
>> attribute to
>> > each user (I
>> > > hope not!)
>> > > > and I did
>> > > > not see memberOf as an attribute
>> I could
>> > add to my
>> > > user
>> > > > object.
>> > > >
>> > > > No. You should not add it manually, the
>> memberOf
>> > attribute
>> > > is
>> > > > maintained automatically based on the
>> group
>> > membership.
>> > > >
>> > > > Do you see any message in error log?
>> There should
>> > be
>> > > something about
>> > > > the impossibility to write the memberof
>> attribute
>> > i think.
>> > > > If you cannot add this attribute
>> manually to your
>> > entry it
>> > > means that
>> > > > your entry does not containe
>> "objectClass:
>> > inetuser". Add
>> > > this
>> > > > objectClass to all the entries that
>> should be
>> > "managed" by
>> > > the plug-in
>> > > > to allow the attribute memberOf to be
>> written to
>> > that
>> > > entries.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > I have verified that the plugin
>> is defined
>> > in
>> > > dse.ldif and it
>> > > > is
>> > > > enabled. I also see memberOf
>> defined in
>> > > 20subscriber.ldif and
>> > > > did not
>> > > > see anything in the
>> documentation about
>> > needing to
>> > > extend the
>> > > > schema.
>> > > > No, you don't need to extend the schema
>> but you
>> > need to make
>> > > sure that
>> > > > your entries include the objectClass
>> "inetuser":
>> > > >
>> > > > objectClasses:
>> ( 2.16.840.1.113730.3.2.130 NAME
>> > 'inetUser'
>> > > DESC
>> > > > 'Auxiliary class which must be present
>> in an entry
>> > for
>> > > delivery of
>> > > > subscriber services' SUP top AUXILIARY
>> MAY ( uid $
>> > > inetUserStatus $
>> > > > inetUserHTTPURL $ userPassword $
>> memberOf )
>> > X-ORIGIN
>> > > 'Netscape
>> > > > subscriber interoperability' )
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > So, at this point, I am still at
>> a loss
>> > for what I
>> > > did wrong.
>> > > > What do I
>> > > > check next? Thanks - John
>> > > > Try to add the "objectClass: inetuser"
>> to the
>> > entries
>> > > concerned and
>> > > > take a closer look to the "errors" log
>> file.
>> > > >
>> > > > @+
>> > > >
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Thu, 2009-05-21 at 12:59
>> +0200, Andrey
>> > Ivanov
>> > > wrote:
>> > > > > Hi,
>> > > > >
>> > > > > there are two things to be
>> verified
>> > and/or taken
>> > > into
>> > > > account:
>> > > > > * the pair of the attributes
>> that is
>> > maintained
>> > > (the
>> > > > arguments
>> > > > > "memberofgroupattr" and
>> "memberofattr"
>> > of the
>> > > plug-in)
>> > > > > * presence of these two
>> attributes in
>> > the classes
>> > > of your
>> > > > users and
>> > > > > groups
>> > > > >
>> > > > > To find fixup-memberof.pl try
>> "locate
>> > > fixup-memberof.pl".
>> > > > >
>> > > > > To launch it manually you
>> need to add
>> > something
>> > > like that
>> > > > to the
>> > > > > server (with ldapmodify) :
>> > > > > dn:
>> > cn=memberOf_fixup_2009_5_21_12_39_21,
>> > > cn=memberOf task,
>> > > > cn=tasks,
>> > > > > cn=config
>> > > > > changetype: add
>> > > > > objectclass: top
>> > > > > objectclass: extensibleObject
>> > > > > cn:
>> memberOf_fixup_2009_5_21_12_39_21
>> > > > > basedn: dc=example,dc=com
>> > > > > filter:
>> (objectClass=inetOrgPerson)
>> > > > >
>> > > > >
>> > > > > As for your account, you may
>> remove/add
>> > yourself
>> > > from a
>> > > > group to see
>> > > > > if it changes the memberof
>> attribute.
>> > Verify the
>> > > objectClass
>> > > > of your
>> > > > > entry and make sure the
>> attribute
>> > memberOf is an
>> > > optional
>> > > > attribute of
>> > > > > at least one of these
>> objectClasses...
>> > > > >
>> > > > >
>> > > > >
>> > > > > 2009/5/21 John A. Sullivan III
>> > > > <jsullivan at opensourcedevel.com>
>> > > > > Hello, all. We are in
>> the
>> > process of
>> > > upgrading from
>> > > > 8.0 to
>> > > > > 8.1. We've
>> > > > > hit a few glitches
>> along the way
>> > but most
>> > > has gone
>> > > > well.
>> > > > > However, we
>> > > > > wanted to implement
>> the new
>> > memberOf
>> > > functionality.
>> > > > We
>> > > > > successfully
>> > > > > added the plugin by
>> editing
>> > dse.ldif and
>> > > enabled it
>> > > > from the
>> > > > > console.
>> > > > > However, we've been
>> unsuccessful
>> > in having
>> > > existing
>> > > > group
>> > > > > membership
>> > > > > assigned to the
>> memberOf
>> > attribute.
>> > > > >
>> > > > > We first tried to run
>> > fixup-memberOf.pl
>> > > but the
>> > > > script does
>> > > > > not exist.
>> > > > > There is a
>> > template.fixup-memberOf.pl but
>> > > this does
>> > > > not seem
>> > > > > to have
>> > > > > been built into a
>> final script.
>> > > > >
>> > > > > We then thought we
>> would use the
>> > new task
>> > > feature of
>> > > > the
>> > > > > console. We
>> > > > > went to cn=memberof
>> > > task,cn=tasks,cn=config and
>> > > > tried to
>> > > > > create the task
>> > > > > object. There was no
>> > > nsDirectoryServerTask
>> > > > objectclass. We
>> > > > > added an
>> > > > > nstask but then found
>> there was
>> > no basedn
>> > > attribute
>> > > > we could
>> > > > > add. We
>> > > > > then created an
>> extensibleobject
>> > instead
>> > > but still
>> > > > not basedn
>> > > > > attribute.
>> > > > >
>> > > > > Finally, we resorted
>> to
>> > ldapmodify (we
>> > > hesitated
>> > > > just because
>> > > > > we are not
>> > > > > very familiar with the
>> command
>> > line
>> > > tools). First,
>> > > > we did:
>> > > > >
>> > > > > dn:
>> cn=fixMemberOf,cn=memberof
>> > > > task,cn=tasks,cn=config
>> > > > > changetype: add
>> > > > > objectclass: top
>> > > > > objectclass:
>> extensibleObject
>> > > > > cn: fixMemberOf
>> > > > > basedn:
>> > o=Internal,dc=ssiservices,dc=biz
>> > > > >
>> > > > > The Internal
>> Organization has
>> > several
>> > > organizations
>> > > > under it
>> > > > > (for
>> > > > > various clients) and
>> then user
>> > > organizational units
>> > > > under
>> > > > > those
>> > > > > organizations.
>> Although it
>> > generated no
>> > > errors, it
>> > > > did not
>> > > > > seem to
>> > > > > work. Perhaps I just
>> don't know
>> > how to
>> > > test it.
>> > > > However, the
>> > > > > following
>> > > > > did not return an
>> memberOf data:
>> > > > >
>> > > > >
>> /usr/lib64/mozldap/ldapsearch -b
>> > > > >
>> > > >
>> > >
>> >
>> "ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz" -D
>> > > > > "cn=Directory
>> > > > > Manager" -w - -h ldap
>> uid=myid
>> > memberOf
>> > > > >
>> > > > >
>> > Doing /usr/lib64/mozldap/ldapsearch -b
>> > > > >
>> > > >
>> > >
>> >
>> "ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz" -D
>> > > > > "cn=Directory
>> > > > > Manager" -w - -h ldap
>> uid=myid
>> > > > > showed me plenty of
>> attributes
>> > but nothing
>> > > for
>> > > > memberOf
>> > > > >
>> > > > > I also tried creating
>> the task
>> > with a
>> > > basedn of
>> > > > >
>> > >
>> ou=Users,o=client1,o=Internal,dc=ssiservices,dc=biz
>> > > > in case it
>> > > > > did not
>> > > > > change objects lower
>> in the
>> > tree. Still
>> > > no success.
>> > > > >
>> > > > > Finally I tried:
>> > > > >
>> > > > > dn:
>> cn=fixMemberOf,cn=memberof
>> > > > task,cn=tasks,cn=config
>> > > > > changetype: add
>> > > > > objectclass: top
>> > > > > objectclass:
>> > nsDirectoryServerTask
>> > > > > cn: fixMemberOf
>> > > > > basedn:
>> > o=Internal,dc=ssiservices,dc=biz
>> > > > >
>> > > > > adding new entry
>> > > cn=fixMemberOf,cn=memberof
>> > > > >
>> task,cn=tasks,cn=config
>> > > > > ldap_add: Object class
>> violation
>> > > > > ldap_add: additional
>> info:
>> > unknown object
>> > > class
>> > > > >
>> "nsDirectoryServerTask"
>> > > > >
>> > > > > And received the
>> expected
>> > unknown object
>> > > class
>> > > > error.
>> > > > >
>> > > > > What are we doing
>> wrong? Are
>> > these
>> > > documentation
>> > > > bugs? Are
>> > > > > there
>> > > > > application bugs or do
>> we simply
>> > not know
>> > > what we
>> > > > are doing
>> > > > > with tasks
>> > > > > and memberOf? How do
>> we get the
>> > memberOf
>> > > information
>> > > > into our
>> > > > > existing
>> > > > > user objects? Thanks -
>> John
>> > > > >
>> > > > >
>>
> <snip>
>
More information about the Fedora-directory-users
mailing list