You may be running into a problem we identified with UMich 3.2 slapd
yesterday, and which we are fixing today (how's that for just in time
patching?): expressed simply, slapd is not indexing attributes specified
only in the DN.
Why, you ask? Short answer: oversight at UMich. Long answer: the
oversight is quite understandable, if you forget slapd and focus on ldapd
and X.500 for a moment....
When you create an entry in X.500, the DSA creates the entry with the
attributes and values you have specified in the entry's RDN (the
distinguished values) and those that you specified as arguments to the Add
operation (the entryInformation argument).
X.500 is ambiguous as to whether distinguished values should or can be
specified in both places (the RDN and the entryInformation); it just says
(and I'm paraphrasing for purposes of exposition) that the complete set of
attributes and values is the union of the set of distinguished values and
the set of attributes and values in entryInformation.
As a result, many DUA libraries, ISODE included, ensure that the
distiguished attributes are also present in entryInformation, and many
DSAs (most if not all on the market) are quite flexible, allowing both
cases (distingsuished values included in or not included in
entryInformation).
As a result of this, LDAP programmers don't need to worry about it: they
specify a DN and a set of attributes and values (and, since they are good
lazy logical programmers, they avoid redundancy and specify the
distinguished values once and only once), and send this off to an LDAP
proxy, which is almost always UMich's ldapd, and which almost always talks
to QUIPU.
So the right thing happens: the entry is created with all desired
attributes.
Now UMich begins working on slapd, and, I suppose, they look at slapd as
if they were looking at a DSA. Since almost all DSAs in the world see all
attributes and values in entryInformation, the slapd coders expect to see
all attributes and values in the list of arguments to the LDAP Add
operation, and they ignore the possibility that attributes and values are
being specified once and only once.
The good news is that we discovered this yesterday. The better news is
that we have a working patch this morning. The not so better news is that
it is a bandaid, not a fix: for purposes of advancing our port to NT,
we've defaulted to "everything before the first comma is the entry's RDN",
ignoring RDN's with multiple distinguished attributes, and ignoring values
with embedded commas. Once we've got the multi-threaded,
high-performance, kick-butt port working, we'll clean up DN handling.
pww
Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] X.500 Specialist
pww@entrust.com [ http://www.entrust.com ] Nortel Secure Networks
Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C
FAX:+1 613 765 3520 [__________________________] Ottawa, Canada, K1Y 4H7