Re: Alias dereferencing

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

(Reintroducing and rearranging snipped text somewhat.
To summarize, I disagree with many specific points made to Michael,
but for other reasons I agree that it's probably best to find some
other solution than aliases.  Aliases are a pain.)

Michael Reiher wrote:
> What it apparently doesn't do is transparently resolving base DNs,
> which contain aliases at other places, like dn:
> ou=entry2,ou=alias,ou=entry1,dc=de.
>
> Am I just missing something,

Pierangelo Masarati wrote:

> Apparently, yes:
> <draft-ietf-ldapbis-models, section 2.6>
>       An alias entry shall have no subordinates, so that an alias entry
>       is always a leaf entry.
> </draft-ietf-ldapbis-models, section 2.6>

No, that text is about the alias entry, not the entry which the alias
points at.

This sounds like an OpenLDAP bug.  Look a few paragraphs above in the
models draft:

      "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."

Note that replacement is not just done when the name itself is an alias,
but also with aliases within the name.

> The other issue is, that it also doesn't seem possible to resolve
> aliases pointing at entries in a different backend

...and that's an old limitation in OpenLDAP, which if I understand
correctly it would be quite a bit of work to fix.  It should be
documented somewhere though, along with other LDAP model/protocol
details of OpenLDAP.  The doc could use some work - and volunteers to
write it...

However, aliases will be fairly broken anyway unless a lot more work is
done than just fixing these two issues.  Unless a lot has happened since
our site exorcised aliases from our LDAP directory, anyway:

If you have just a few aliases, that may be OK.  But if you have a lot
of them, they defeat any indexes a search might have used since the
server would have to follow each alias in the search scope and examine
the entry or subtree the alias points at.

I haven't investigated what server implementors have done to deal with
the problem, but the "simple" fix I can think of is for OpenLDAP to
index values "through" aliases: An index which maintained not only which
entries contained a given attribute/value, but also which alias entries
pointed to entries with such values.  Also subtree indexes for aliases
pointing to subtrees that contain entries with such values.  And reverse
indexes to keep track of where the aliases are that point a which
entries.  For cross-database aliases, these would be cross-database
indexes (whatever that means in practice) and we'd have fun like keeping
transactions and any database recovery of the two databases consistent.
Off my head I can think of some heuristics to reduce this problem for a
number of cases, but no general solution.

>> Now, if I'd want to implement this, i.e. to a) transparently handle
>> aliases
>
> It would be a mistake to implement (a) since you'll have no way to
> specify when you want to Modify the alias entry itself, vs what the
> alias points to.

No need, since "subordinates of aliases" are not needed, just aliases
pointing at non-leaf entries.

>> and b) support references to other backends.
>
> It would be a mistake to implement (b); that is already the purpose of
> referrals.

It might be a mistake because of the mess I described above, but as far
as I can tell not because of referrals.
draft-ietf-ldapbis-protocol-xx.txt defines referrals to be for
references to _other_ servers.  A server referring to itself seems to
be abuse of referrals, at least as far as the standard is concerned.
Though most LDAP implementations twist the standard in various ways
anyway, e.g. allowing encryption of the userPassword attribute.

-- 
Hallvard