Re: Add/Delete failures?

peter (
Wed, 19 Jun 1996 09:09:19 -0400

On Tue, 18 Jun 1996 wrote:
> -Description
> 1. DN Add/Delete operations are not visible via ldapsearch although
> ldap_add/ldap_delete
> return codes indicate successfull operation (neither ldap_search API nor
> ldapsearch
> utility).

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

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

So the right thing happens: the entry is created with all desired

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.


Peter Whittaker [~~~~~~~~~~~~~~~~~~~~~~~~~~] X.500 Specialist [ ] Nortel Secure Networks
Ph: +1 613 765 2064 [ ] P.O. Box 3511, Station C
FAX:+1 613 765 3520 [__________________________] Ottawa, Canada, K1Y 4H7