RE: When to not deref aliases

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 12:39 PM 1/17/01 +1100, Ramsay, Ron wrote:
>I believe that dereferencing is the default for X.500.

>I say this because I
>believe the option dontDereferenceAliases was added to allow management of
>the alias entry itself.

I believe it the option was added when support for deferencing
alias in update operations was added (in the 2nd edition).  Note
that the option was not added to bind, hence I don't believe
aliases are to be dereferenced during bind operations.

>If the default were never to dereference, I would
>have expected the option to be dereferenceAliases.

Additional alias functionality was added to the second addition,
along with statements noting were the behavior could not be
expected by older DSAs.  Note that the bind operation, unlike
update operations, does not contain such a note.

>As regards the bind, we always dereference aliases.

Do you dereference aliases for add, compare, modify, moddn, or delete?
For bind, if you have an alias problem or dereferencing problem,
what result code do you return?

>You gain the ability to
>allow multiple logins (for access control) for the one user, though we
>haven't used this feature in practice.

You also incur numerous security risks.  I note that if the
consensus is to allow/require bind to dereference aliases, the
security considerations would have to be documented.

>If you don't take the default as being dereference, it seems you are saying
>that alias entries are second-class entries.

I thought they were.  :-)  They certainly were in LDAPv2 and
the first edition of X.500.

Note that X.511(93) says:
  If simple is used, it consists of a name (always the distinguished name of an object),
  an optional validity, and an optional password.

IMO, X.511 nor LDAP allows binding to an alias name.

Kurt