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(a)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@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(a)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(a)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(a)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(a)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
> > >
> > >
> > > --
> > > John A. Sullivan III
> > > Open Source Development
Corporation
> > > +1 207-985-7880
> > > jsullivan(a)opensourcedevel.com
> > >
> > >
http://www.spiritualoutreach.com
> > > Making Christianity intelligible
to
> secular society
> > >
> > > --
> > > Fedora-directory-users mailing
list
> > >
Fedora-directory-users(a)redhat.com
> > >
> >
>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
> > >
> > > --
> > > Fedora-directory-users mailing list
> > > Fedora-directory-users(a)redhat.com
> > >
> >
>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> > --
> >
> > John A. Sullivan III
> > Open Source Development Corporation
> > +1 207-985-7880
> > jsullivan(a)opensourcedevel.com
> >
> >
http://www.spiritualoutreach.com
> > Making Christianity intelligible to
secular society
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users(a)redhat.com
> >
>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users(a)redhat.com
> >
>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
> --
> John A. Sullivan III
> Open Source Development Corporation
> +1 207-985-7880
> jsullivan(a)opensourcedevel.com
>
>
http://www.spiritualoutreach.com
> Making Christianity intelligible to secular society
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users(a)redhat.com
>
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan(a)opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
--
Fedora-directory-users mailing list
Fedora-directory-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users
--
Fedora-directory-users mailing list
Fedora-directory-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users --
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan(a)opensourcedevel.com