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@xxxxxxxxxxxxxxxxxxx>
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@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@xxxxxxxxxxx
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@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@xxxxxxxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxxxxx>
> > 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@xxxxxxxxxxxxxxxxxxx>
> > > 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@xxxxxxxxxxxxxxxxxxx>
> > > > 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
> > > >
> > > >
