RE: When to not deref aliases

["Volpers, Helmut" <helmut.volpers@icn.siemens.de>]

I think "should not " is the best solution.

> -----Original Message-----
> From: Ramsay, Ron [mailto:Ron.Ramsay@ca.com]
> Sent: Donnerstag, 25. Januar 2001 02:06
> To: rvh@qsun.mt.att.com; Kurt@OpenLDAP.org; ietf-ldapbis@OpenLDAP.org
> Subject: RE: When to not deref aliases
> 
> 
> 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?

Why should the name in the certificate map into my namespace.
If I have a directory tree which begins with DC=Siemens/...
and Kurt logs in my server with the name DC=OpenLdap/...
He can authenticate agauinst my Server (If I trust his CA)
and I can give him AccessRights or why shouldn't this work ?

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