This seems like the least harmful path then:
- name: The name of the directory object that the client wishes to bind as. This field may take on a null value (a zero length string) under the following scenarios:
(a) When the AuthenticationChoice is simple, and a zero-length password is specified, signifying an anonymous bind,
(b) When authenticating as the root DSE,
(c) When authentication has been performed at a lower layer,
(d) When using SASL credentials with a mechanism that includes the identity in the credentials.
If no authentication (anonymous bind) is to be performed, then the simple authentication option MUST be chosen, and the password be of zero length. (This is often done by LDAPv2 clients.) The name field SHOULD also be zero length and, if provided, MUST be ignored as an authentication identity by the server.
>>> Mark C Smith <email@example.com> 11/14/00 2:26:15 PM >>>
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
Netscape Directory Product Development
Jim Sermersheim wrote:
> Are you saying that you believe a name paired with an simple empty
> password is *not* an anonymous bind? Rather, some kind of
> unauthenticated connection?
> >>> Mark C Smith <firstname.lastname@example.org> 11/14/00 1:32:39 PM >>>
> Kurt D. Zeilenga wrote:
> >> 2) Which signifies an anonymous bind, an empty name or empty
> simple password?
> > A simple bind with an empty password. By my reading of 2251,
> > the DN should be empty and ignored if present. However, for
> > security reasons, I believe this is bad. I believe it appropriate
> > to say that the DN shall be empty and if not, invalidCredentials
> > returned.
> I disagree. I am not sure what the X.500 specifications say about this,
> but it has been a long standing practice for LDAP clients to use simple
> bind with a DN of length > 0 with no password to allow the LDAP server
> to log an identity for the informational purposes such as usage
> statistics (of course the name is not authenticated in any way). I do
> not think we should introduce this kind of incompatible change at
> this time.