RE: When to not deref aliases

["Ramsay, Ron" <Ron.Ramsay@ca.com>]

Kurt,

I may be going out on a limb here, but I think dontDereferenceAliases was in
ServiceControls.options in the 1988 version.

I note that bind is ambiguous.

No, we don't dereference aliases on update operations. There is a note in
the standard (from the 1988 standard, I think) that aliases should not be
dereferenced on update operations. (Apparently the latest standard has a
flag for overruling this behaviour.)

If you have a problem dereferencing an alias on a bind, I would think the
error should be securityError:invalidCredentials.

Does 'the distinguished name of an object' mean 'the distinguished name of
an entry'? An alias is an entry. I don't know if it is an object, but I
thought objects were phased out in favour of entries (aliasedObjectName?).

As regards LDAPv2, I was replying to your request regarding X.511. I know
LDAP is different (aliases, distribution, replication, read, list, ...). If
LDAP doesn't want to dereference on bind I won't cry. (I think vendors will
continue to do what they think is appropriate, anyway.)

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:Kurt@OpenLDAP.org]
Sent: Wednesday, 17 January 2001 14:43
To: Ramsay, Ron
Cc: Jim Sermersheim; ietf-ldapbis@OpenLDAP.org
Subject: RE: When to not deref aliases


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