[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
RE: anonymous binds
In our implementation we allow a bind with DN>0 and an empty password
and I will not change this because there are some applications
which does this kind of bind (e.g. for statistics).
We assign (like x.500) for every bind a AuthenticationLevel
which is "NONE" if you send no password (independant whether the DN
is empty or not and which is SIMPLE when you give a name and Password.
I agree with Mark that there is no real difference between
an "unauthenticated bind" and an "anonymous bind."
Especially for AccessControl it is the same.
Helmut
> -----Original Message-----
> From: mcs@netscape.com [mailto:mcs@netscape.com]
> Sent: Mittwoch, 15. November 2000 21:46
> To: Jim Sermersheim
> Cc: Kurt@OpenLDAP.org; Richard Ellis; ietf-ldapbis@OpenLDAP.org
> Subject: Re: anonymous binds
>
>
> I am not convinced that there is any real difference between an
> "unauthenticated bind" and an "anonymous bind." Certainly in
> terms of
> access control and so on, they are likely equivalent.
>
> Can someone provide a useful definition?
>
> -Mark Smith
> Netscape
>
>
> Jim Sermersheim wrote:
> >
>
> > I wonder how many implementations will be broken by stating that
> > non-empty DN + empty PW != anonymous.
> >
> > >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 11/14/00 7:15:32 PM >>>
> > At 04:26 PM 11/14/00 -0500, Mark C Smith wrote:
> > >No. I am saying that I believe a > 0 length DN with an
> empty password
> > should be accepted as an anonymous bind. I think Kurt was
> suggesting
> > that servers should return invalidCredentials instead if
> the DN is of
> > non-zero length..
> >
> > RFC 1777 makes a distinction between unauthenticated and anonymous
> > bind. That is, they are NOT synonymous.
> >
> > I see the following four usages:
> >
> > DN Password Usage
> > ------------------------------------------------------------
> > empty empty anonymous
> > non-empty empty unauthenticated
> > non-empty non-empty authentication
> > empty non-empty authentication *
> >
> > We should not disallow any of these usages in the revised
> specification.
> > However, we might want to clarify each usage and any usage-specific
> > security consideration.
> >
> > Note that latter usage can be left unspecified as to what entity
> > is implied by the empty DN. This could be a "self" authentication
> > (DSA authenticating to itself... some servers talk LDAP
> with themselves)
> > or some special admin entity. Leaving it unspecified allows for
> > such experimentation and, if ever desired, standard track extension
> > or update of such.
> >
> > Kurt
>