[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: When to not deref aliases



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