Bug #2909


auth.backend.ldap.starttls encrypts authenticating user password, but not auth.backend.ldap.bind-pw

Added by akschu1 over 4 years ago. Updated over 4 years ago.

Target version:


Just setup lighttpd with the following:

auth.backend = "ldap"
auth.backend.ldap.hostname = ""
auth.backend.ldap.base-dn = "dc=domain,dc=net"
auth.backend.ldap.filter = "(&(objectClass=user)(sAMAccountName=$)(memberOf=CN=Allowed,CN=Users,DC=domain,DC=net))"
auth.backend.ldap.starttls = "enable"
auth.backend.ldap.bind-dn = "CN=lookupuser,CN=Users,DC=domain,DC=net"
auth.backend.ldap.bind-pw = "password"
auth.backend.ldap.allow-empty-pw = "disable"

When sniffing the packets with tcpdump, I see it bind as lookupuser without starting tls, then it starts TLS and tries to bind as the user it found in the filter.

When selecting starttls ligttpd should encrypt both the bind to lookup the user, as well as the bind as the user.

Actions #1

Updated by gstrauss over 4 years ago

What version of lighttpd are you using? Which package and what version of LDAP libraries?

When configured with auth.backend.ldap.starttls = "enable", lighttpd calls ldap_start_tls_s() prior to ldap_sasl_bind_s().

Actions #2

Updated by akschu1 over 4 years ago


I can't confirm this. According to my packet capture I get this:

LDAPMessage bindRequest(16) "CN=lookupusr,CN=Users,DC=domain,DC=net" simple
messageID: 16
protocolOp: bindRequest (0)
version: 3
name: CN=lookupuser,CN=Users,DC=domain,DC=net
authentication: simple (0)

then a few searches, then unbindRequest then....

72 0.017358 TLSv1 371 Client Hello
76 0.023452 TLSv1 4664 Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done

So it's pretty clearly only doing TLS for the user part, not the bind-dn part.

I'm using lighttpd-1.4.50.tar.xz compiled like this on slackware:

./configure \
--prefix=/usr \
--libdir=/usr/lib64/lighttpd \
--sysconfdir=/etc \
--localstatedir=/var \
--mandir=/usr/man \
--with-pcre \
--with-attr \
--with-openssl \
--with-ldap \

openldap is openldap-client-2.4.42-x86_64-1 from slackware.

If you want I can send you the packet capture, but don't want to post it here, as it's has private information.

Actions #3

Updated by gstrauss over 4 years ago

Thanks for the update. I'll have to set up a test environment to reproduce this, which may take me some time with $dayjob demands.

Actions #4

Updated by akschu1 over 4 years ago

Yea, my C is terrible, but I might be able to figure it out and supply a patch... depends on my workload too.

Oh, and thanks for working on lighttpd, I needed something small for an embedded project, but I really like what I see, and I'm not impressed easily.

Actions #5

Updated by gstrauss over 4 years ago

  • Status changed from New to Reopened

I finally got around to setting up a full environment and I could not replicate the behavior that you have reported. I am using a self-signed certificate, and tried both ldaps and starttls (separately; not at the same time). strace and tcpdump show lighttpd sending encrypted traffic to the ldap server (which I ran on

For a simple testing environment, I followed:

including setting TLS_REQCERT allow in /etc/openldap/ldap.conf for use with my self-signed cert.

auth.backend.ldap.hostname = "ldap://" 
auth.backend.ldap.starttls = "enable" 

auth.backend.ldap.hostname = "ldaps://" 
auth.backend.ldap.starttls = "disable" 

My test system is running lighttpd 1.4.52 on RedHat Fedora 29 with:

(You reported Slackware, lighttpd 1.4.50, and openldap-client 2.4.42)

The last substantive change to mod_authn_ldap was d5f37803 in lighttpd 1.4.49. I do not think what you have reported is an issue with lighttpd. Would you please test with a later version of openldap-client? Outside of lighttpd, would you try a packet capture when testing with ldapsearch -ZZ ... (which forces starttls)?

Actions #6

Updated by gstrauss over 4 years ago

  • Status changed from Reopened to Need Feedback
Actions #7

Updated by gstrauss over 4 years ago

  • Status changed from Need Feedback to Invalid

Unable to reproduce

If you can reproduce this with current versions of lighttpd and openldap-client, please post and I will look further.


BTW, if your auth.backend.ldap.filter begins with ",", then it is treated as an explicit DN and there is no bind performed to search for the DN for the username. Instead, the only bind performed is to authenticate the user "uid=<username><auth.backend.ldap.filter>" with the provided password.


Also available in: Atom