RE: When to not deref aliases

[rvh@qsun.mt.att.com (Richard V Huber)]

If the operation will always return invalidCredentials, aren't we
really saying that an alias MUST (or SHOULD) NOT be used as the target
of a BIND?

If that is the behavior we want, fine.  As I said before, access
control issues may well make this the right answer.

But if there is anyone out there who feels they have a real need to
BIND using an alias as the dn, now would be a good time to speak up.

Rick Huber

: To: ietf-ldapbis@OpenLDAP.org
: From: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
: Subject: RE: When to not deref aliases
: Cc: rvh@qsun.mt.att.com (Richard V Huber), JIMSE@novell.com, Ron.Ramsay@ca.com
: 
: A few corrections to my last post...
: 
: At 10:29 PM 1/23/01 -0800, Kurt D. Zeilenga wrote:
: >At 12:53 AM 1/24/01 -0500, Richard V Huber wrote:
: >>If aliases are not dereferenced for BINDs, what is the expected
: >>behavior when the dn of an alias is used as the argument to BIND?
: >
: >invalidCredentials.  The provided DN/password pair, which
: >together are the credentials, is invalid.
: >
: >>As Thomas Salter noted in a previous posting, an alias entry will
: >>typically not have the UserPassword attribute needed for a simple BIND,
: >>nor would it have any other attributes that might be used as part of
: >>authentication.
: >
: >I actually believe aliasing dereferencing in bind should be
: >disallowed as there bind cannot return aliasProblem or
: 
: s/as there/as/
: 
: >aliasDereferencingProblem per RFC 2251.  But "SHOULD NOT" is
: >enough.
: >
: >>It seems to me that saying BIND SHOULD NOT or MUST NOT dereference
: >>aliases is pretty much the same as saying that BIND should never be
: >>used with an alias as its target dn.
: >
: >Imperitives are to should be applied and interpreted as detailed
: >in RFC 2119.
: 
: s/are to should/should/
: 
: 
: >>If this is our intent, let's say
: >>so explicitly (this would avoid some really messy access control
: >>issues).  But let's not do it as a side effect.
: >
: >I believe there are sufficient security considerations to
: >require a "SHOULD NOT".