[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Difficulty searching by groupOfNames member
I think the issue involved here is DN normalization. OpenLDAP will
normalize (remove spaces and cruft) under many circumstances before using
the value. It's possible that your search is using the normalized DN
against the database, and therefore matching the member attribute you've
manually normalized (removed spaces), and not the unnormalized value.
I've learned that using unnormalized values always seems to get me in
trouble. I'd try not to store unnormalized values if at all possible.
Hope that helps. Hope that's right, too. :-)
-Alan
Kristin Engstrom said:
> 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
===========
Alan Sparks, UNIX/Linux Systems Administrator
<asparks@doublesparks.net>