Bug #2909
closedauth.backend.ldap.starttls encrypts authenticating user password, but not auth.backend.ldap.bind-pw
Description
Just setup lighttpd with the following:
auth.backend = "ldap"
auth.backend.ldap.hostname = "junewts.domain.net"
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.
Updated by gstrauss over 5 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().
Updated by akschu1 over 5 years ago
Hello,
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)
bindRequest
version: 3
name: CN=lookupuser,CN=Users,DC=domain,DC=net
authentication: simple (0)
simple: THEACTUALPASSWORD
then a few searches, then unbindRequest then....
72 0.017358 172.24.0.211 172.24.0.237 TLSv1 371 Client Hello
76 0.023452 172.24.0.237 172.24.0.211 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 \
--build=$ARCH-slackware-linux
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.
Updated by gstrauss over 5 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.
Updated by akschu1 over 5 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.
Updated by gstrauss about 5 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 127.0.0.1).
For a simple testing environment, I followed:
https://www.itzgeek.com/how-tos/linux/centos-how-tos/step-step-openldap-server-configuration-centos-7-rhel-7.html
https://www.itzgeek.com/how-tos/linux/centos-how-tos/configure-openldap-with-ssl-on-centos-7-rhel-7.html
including setting TLS_REQCERT allow in /etc/openldap/ldap.conf for use with my self-signed cert.
auth.backend.ldap.hostname = "ldap://127.0.0.1/" auth.backend.ldap.starttls = "enable"
or
auth.backend.ldap.hostname = "ldaps://127.0.0.1/" auth.backend.ldap.starttls = "disable"
My test system is running lighttpd 1.4.52 on RedHat Fedora 29 with:
openldap-2.4.46-9.fc29.x86_64
openldap-clients-2.4.46-9.fc29.x86_64
openldap-servers-2.4.46-9.fc29.x86_64
(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)?
Updated by gstrauss about 5 years ago
- Status changed from Reopened to Need Feedback
Updated by gstrauss about 5 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