Having done the same mistake myself a couple of years ago:
Most protocols/software will return an error code if you try to login with a valid username (other than "anonymous") and an empty password. That is even true for most systems that allow some kind of anonymous usage without being logged in at all.
For LDAP, however, the common case is that the server allows logins with any username and an empty password. The user will end up as being anonymous. But the login returns a status code indicating success.
RFC2829 says:
An LDAP client MAY also choose to explicitly bind anonymously. A client that wishes to do so MUST choose the simple authentication option in the Bind Request (see section 4.1) and set the password to be of zero length. (This is often done by LDAPv2 clients.) Typically the name is also of zero length.
So, now imagine that the login is not done by the user directly. But the user logs into some other software, and this software takes the username and password and does an LDAP login behind the scenes.
If this software blindly trust the "success" result from the LDAP server without having a special case handling for empty passwords, boom.
That software might even try to read some information about the current user such as the email address. But if LDAP is used as an directory of people, this information may be accessible for anonymous users. LDAP servers are often only reachable from within the company network and not from the Internet.
I said at the beginning, that I did this mistake myself. Our software supports many different kinds of authentication front and backends. LDAP was the only effected system of all the ones we support.
To ensure that this will never happen again, we now globally reject empty passwords for all authentication systems, unless the system is passwordless such as single-sign-on services and smart-cards. And we added an additional test case to our documentation (test good case, test wrong password, test empty password).
