[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: Difficulty searching by groupOfNames member



Well, things are improving slightly.  I started playing around with the
spaces and commas separating elements of the member attribute dn and filter
dn.  I am able to get a match on my search iff the member dn is stored with
NO spaces.  Here's my example (with my comments in parentheses):
----------------------------------------------------------------------
Directory entries:
==================
# TestGroup, Reseller1, netiq, com
dn: cn=TestGroup, o=Reseller1, dc=netiq, dc=com
objectClass: top
objectClass: groupOfNames
cn: TestGroup
member: uid=00001
member: uid=00002
member: cn=Robert Vieira,o=Reseller1,dc=netiq,dc=com                  (<--
note, no spaces)
description: TestGroup

# TestGroup1, Reseller1, netiq, com
dn: cn=TestGroup1, o=Reseller1, dc=netiq, dc=com
objectClass: top
objectClass: groupOfNames
cn: cn=TestGroup1
member: uid=00001
member: uid=00011
member: cn=Robert Vieira, o=Reseller1, dc=netiq, dc=com               (<--
note, some spaces)
member: cn=Davey Crocket o=Reseller1 dc=netiq dc=com
description: TestGroup1

Search command:
===============
ldapsearch -x -b "dc=netiq,dc=com" -D "cn=Manager,dc=netiq,dc=com" -w secret
"(member=cn=Robert Vieira, o=Reseller1, dc=netiq, dc=com)"

(Notice that I included spaces between the elements of the dn in the
filter.)

Search results:
===============
# TestGroup, Reseller1, netiq, com
dn: cn=TestGroup, o=Reseller1, dc=netiq, dc=com
objectClass: top
objectClass: groupOfNames
cn: TestGroup
member: uid=00001
member: uid=00002
member: cn=Robert Vieira,o=Reseller1,dc=netiq,dc=com
description: TestGroup

------------------------------------------------------------------------
The search also finds the same single record when the filter is
"(member=cn=Robert Vieira,o=Reseller1,dc=netiq,dc=com)".  I.e., NO spaces in
the dn.

It strikes me as odd that my filter matched the group which had no spaces in
the member's dn and failed to match the group where the member dn and my
filter matched PERFECTLY.  I know spaces are somewhat optional, but why
didn't OpenLDAP ignore them such that TestGroup1 would match?  I realize
that, inspite of the documentation, LDAP doesn't really treat member
attributes as DNs.  Bruno, are you storing your member attributes with
spaces in the DN?

At least I'm getting somewhere slowly.  Thanks everyone.  If I get any more
insight into what's going on, I'll post it.  Thanks everyone in advance for
doing the same.

Kristin

-----Original Message-----
From: Bruno Eteve [mailto:bruno.eteve@atempo.com] 
Sent: Wednesday, July 31, 2002 6:13 AM
To: Kristin Engstrom
Subject: Re: Difficulty searching by groupOfNames member


Kristin Engstrom wrote:
> 
> I have some small measure of success to report.
> 
> First the bad new:  I downloaded the latest version -- 2.0.25 (20020618)
--
> and rebuilt it (a half-day affair since I'm using MS Visual C++).  

I'm using a Linux box to run my test platform, it took only one hour
to upgrade openldap. 5 minutes of my time and 55' for the CPU (not that
powerful ;)

If it's possible for you, I advise to switch from Windows to Linux.
It's so simple to compile under this OS.

> No change, so I also upgraded from Berkeley DB 3.2.9 to 4.0.14 and rebuilt
> everything again.  I double-checked my index configuration and built my
> directory database anew.  Still no improvement in searching by member dn.

This is the DB version I use.

I used the loglevel entry in the slapd.conf file to find out what was
going on.

I set "loglevel 36" and could read the filter requests in the
/var/log/syslog
file. I don't know where openldap logs are stored under Windows, maybe
arround
the Event Viewer... 
If you could have a look, maybe you'll see if something's misspelled or
whatever's going wrong.

> Now, the good news: I created a new group in my directory

> Since I can't be sure my users will store group memberships by UID, I
still
> need to figure out why I can't get a match with a filter like
"dn=cn=Jessica
> Coffin, ...".  I've tried removing spaces between commas, but that makes
no
> difference.  I've checked to make sure there are no hidden characters in
> either my directory entry or my filter.  Is there something else wrong
with
> my syntax?

Be sure to enter the full DN.
I've tried to use wildcards (like *) in the request. But I got the
"bad filter" message in the log file.

-- 
Bruno Eteve -*- 01 64 86 83 00 -*- http://www.atempo.com
E = MC ** 2 +- 3db