RE: When to not deref aliases

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

The operation will only return invalid credentials if an alias is provided
AND the implementation doesn't dereference aliases on binds AND the bind is
simple.

If aliases are dereferenced, or the bind is SASL, there would seem to be
little reason for returning invalidCredentials.

Does one really need a reason?

What if you are using SASL external but the name in the certificate doesn't
map into your user space?

What if you didn't want to declare your DIT?

Frankly I don't understand why people are getting their knickers in a knot
over aliases.

Ron.

-----Original Message-----
From: rvh@qsun.mt.att.com [mailto:rvh@qsun.mt.att.com]
Sent: Thursday, 25 January 2001 5:50
To: Kurt@OpenLDAP.org; ietf-ldapbis@OpenLDAP.org
Subject: RE: When to not deref aliases


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