Project

General

Profile

Actions

Bug #2909

closed

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

Added by akschu1 about 6 years ago. Updated almost 6 years ago.

Status:
Invalid
Priority:
Normal
Category:
mod_auth
Target version:
ASK QUESTIONS IN Forums:

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.

Actions #1

Updated by gstrauss about 6 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 about 6 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.

Actions #3

Updated by gstrauss about 6 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 about 6 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 almost 6 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)?

Actions #6

Updated by gstrauss almost 6 years ago

  • Status changed from Reopened to Need Feedback
Actions #7

Updated by gstrauss almost 6 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.

Actions

Also available in: Atom