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

(ITS#4030) BDB: Alias resolving in base dn incomplete



Full_Name: Michael Reiher
Version: 2.3.7
OS: Linux (Debian Sarge)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (213.54.219.18)


Resolving of base dns, which contain aliases, in searches doesn't work as
expected in the BDB backend.

Suppose you have a tree like:

dc=de
  |
  |-- ou=entry1
  |     |
  |     '-- ou=alias -> ou=entry3,dc=de
  |
  '-- ou=entry3
        |
        '-- ou=entry2

Now if you use the folling dns as base for a search (with deref == finding)

Example 1: dn: ou=alias,ou=entry1,dc=de

Resolving of this dn works as expected, as the alias is the last part of the dn.
This is the only place where aliases are resoved currently, at the moment.


Example 2: dn: ou=entry2,ou=alias,ou=entry1,dc=de

#> ldapsearch ... -a always -b "ou=entry2,ou=alias,ou=entry1,dc=de"

Gives:

No such object (32)
Matched DN: ou=alias,ou=entry1,dc=de

It just looks up the full dn in the DB, which fails of course. But no action is
taken from there. i.e. resolve the matching part, retry, and so on...

_All_ aliases appearing anywhere in the base dn should be dereferenced, and I
guess also aliases in dns resolved from the initial aliases, and so on...until a
completly alias free dn is reached.

The relevant part of the models draft someone quoted on the list would be:

      "The conversion of an alias name to an object name is termed
      (alias) dereferencing and comprises the systematic replacement of
      alias names, where found within a purported name, by the value of
      the corresponding 'aliasedObjectName' attribute.  The process may
      require the examination of more than one alias entry."