Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have installed many Active Directory (AD) based networks and have applied various standard security templates based on best practices, however I have never really looked at LDAP on a deeper level and after reading recently about the OSX Lion LDAP issues (The Register and Slashdot), I am rather concerned and quite worried.

I have spent a while reading up on this, but, I keep seeing conflicting reports. Is there any solid information on what actually the problem is with?

In addition, I was always under the impression that with security, you treat everything as worst case scenario/infected/whatever... guilty until proven innocent! If this is even possible, surely it is the LDAP server that is responsible rather than just the client?

share|improve this question
add comment

2 Answers

The simple BIND request takes one of four forms depending on the data transmitted with the request:

  • null name, null password: anonymous, this is also the authorization state of all initial LDAP sessions, that is, where the LDAP client has yet to issue a BIND request or a BIND request has failed or been rejected. Server administrators should consider configuring to reject anonymous authentication attempts and set the result code of the BIND response to unwilling to perform since no authentication has occurred.
  • non-null name, null password: unauthenticated. Server administrators should consider configuring to reject anonymous authentication attempts and set the result code of the BIND response to unwilling to perform since no authentication has occurred
  • non-null name, non-null password: authenticated. Server administrators should consider configuring the server to reject these requests if those requests are transmitted on a non-secure connection, that is, a connection without confidentiality
  • null name, non-null password: undefined. Server behavior is not defined by the LDAP standards in this case, therefore, server administrators should consider configuring to reject anonymous authentication attempts and set the result code of the BIND response to unwilling to perform since no authentication has occurred.

see also

LDAP: Authentication Methods and Security Mechanisms

share|improve this answer
add comment

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

share|improve this answer
1  
This behavior in LDAP is the cause of a large number of authentication bypasses (in fact this is the second I've come across this calendar year). In my mind it comes down to not understanding and/or not checking your return values. –  Scott Pack Sep 2 '11 at 1:13
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.