[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: Difficulty searching by groupOfNames member - RESOLVED
Well, Alan, I believe you've hit the nail on the head.
I rebuilt my directory such that all member attributes have a "normalized"
dn (i.e., no spaces between the comma and following elements). Now, my
search returns precisely the entries I'm expecting. Evidently, after
working with hundreds of thousands of entries for performance testing, I
must have reloaded with a new simpler set of data and somehow just happened
to include spaces between the dn elements in the member attributes. Hence,
the search command that worked for me a month or two ago, appeared to
suddenly stop working.
I still haven't found anything definitive on dn normalization, so I'm
assuming it's specific to each LDAP implementation.
Thanks to everyone who helped me sort this one out.
Kristin
-----Original Message-----
From: Alan Sparks [mailto:asparks@doublesparks.net]
Sent: Wednesday, July 31, 2002 5:24 PM
To: Kristin.Engstrom@netiq.com
Cc: bruno.eteve@atempo.com; tpalmer@cyntergyllc.com;
openldap-software@OpenLDAP.org
Subject: 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>