RE: When to not deref aliases

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

Helmut,

If your question was directed to me, my answer would be: Why have any users
in the directory. If you can validate their login without reference to a
user entry then you don't need to store users in the directory.

Conversely, if you use user entries to validate binds, then you presumably
will require entries for 'external' users.

Ron.

-----Original Message-----
From: Volpers, Helmut [mailto:helmut.volpers@icn.siemens.de]
Sent: Friday, 26 January 2001 19:59
To: Ramsay, Ron; rvh@qsun.mt.att.com; Kurt@OpenLDAP.org;
ietf-ldapbis@OpenLDAP.org
Subject: RE: When to not deref aliases


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