Hardy slapd server is not supporting sasl/external authentication

[Dragomir Minkovski]

On our dapper machines, we use the sasl external mechanism for authentication on slapd, the ldap server.
On hardy this doesn't work any more. Running an ldapsearch for example produces errors messages.

hardy ldapsearch against hardy slapd:
$ ldapsearch -H ldaps://ldap
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)

and slapd (-d 256) says
conn=6 fd=16 ACCEPT from IP=100.9.0.234:45017 (IP=0.0.0.0:636)
conn=6 fd=16 TLS established tls_ssf=16 ssf=16
conn=6 fd=16 closed (connection lost)

Here, the client fails

fedora core 3 ldapsearch (ldap utils are linked against openssl) against hardy slapd:
$ ldapsearch -H ldaps://ldap
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Authentication method not supported (7)
additional info: SASL(-4): no mechanism available:

and slapd (-d 256) says
conn=5 fd=16 ACCEPT from IP=100.9.11.1:38962 (IP=0.0.0.0:636)
conn=5 fd=16 TLS established tls_ssf=16 ssf=16
conn=5 op=0 BIND dn="" method=163
conn=5 op=0 RESULT tag=97 err=7 text=SASL(-4): no mechanism available:
conn=5 fd=16 closed (connection lost)

This shows that the server actually doesn't support the mechanism.

Installed packages:
root@system:~# dpkg -l '*slapd*' '*ldap*' '*gnutls*' '*openssl*' '*sasl*' | grep ^ii | awk '{print $2"_"$3}'
gnutls-bin_2.0.4-1ubuntu2.1
gnutls-doc_2.0.4-1ubuntu2.1
ldap-auth-client_0.5
ldap-auth-config_0.5
ldap-utils_2.4.7-6ubuntu4.2
libcurl3-gnutls_7.18.0-1ubuntu2
libgnutls13_2.0.4-1ubuntu2.1
libldap-2.4-2_2.4.7-6ubuntu4.2
libnss-ldap_258-1ubuntu3
libpam-ldap_184-2ubuntu2
libsasl2_2.1.22.dfsg1-18ubuntu2
libsasl2-2_2.1.22.dfsg1-18ubuntu2
libsasl2-modules_2.1.22.dfsg1-18ubuntu2
openssl_0.9.8g-4ubuntu3.1
openssl-blacklist_0.1-0ubuntu0.8.04.4
php5-ldap_5.2.4-2ubuntu5.1
postfix-ldap_2.5.1-2ubuntu1
sasl2-bin_2.1.22.dfsg1-18ubuntu2
slapd_2.4.7-6ubuntu4.2

Configuration:
/etc/default/slapd

# Default location of the slapd.conf file
SLAPD_CONF=/etc/openldap/slapd.conf

# System account to run the slapd server under. If empty the server
# will run as root.
SLAPD_USER=openldap

# System group to run the slapd server under. If empty the server will
# run in the primary group of its user.
SLAPD_GROUP=openldap

# Path to the pid file of the slapd server. If not set the init.d script
# will try to figure it out from $SLAPD_CONF (/etc/ldap/slapd.conf)
SLAPD_PIDFILE=

# Configure if db_recover should be called before starting slapd
TRY_BDB_RECOVERY=yes

# Configure if the slurpd daemon should be started. Possible values:
# - yes: Always start slurpd
# - no: Never start slurpd
# - auto: Start slurpd if a replica option is found in slapd.conf (default)
SLURPD_START=auto

# slapd normally serves ldap only on all TCP-ports 389. slapd can also
# service requests on TCP-port 636 (ldaps) and requests via unix
# sockets.
# Example usage:
SLAPD_SERVICES="ldap:/// ldaps:/// ldapi:///"

# Additional options to pass to slapd and slurpd
SLAPD_OPTIONS=""
SLURPD_OPTIONS=""

/etc/openldap/slapd.conf (relevant lines only)
TLSCACertificateFile /etc/ssl/cacert.pem
TLSCertificateFile /etc/ssl/ldap/ldap-CERT.pem
TLSCertificateKeyFile /etc/ssl/ldap/ldap-KEY.pem
TLSVerifyClient try

example .ldaprc
TLS_CACERT /home/max/.ssl/cacert.pem
TLS_CERT /home/max/.ssl/usercert.pem
TLS_KEY /home/max/.ssl/user.key
SASL_MECH EXTERNAL

First it was suspected gnutls might not like certificates/keys generated with openssl. But playing around with gnutls-serv and gnutls-cli using the same files shows that gnutls works.

The search shows external is not supported by server:
$ ldapsearch -x -H ldaps://ldap -b "" -LLL -s base supportedSASLMechanisms
dn:
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: LOGIN

apparmor is not running on the server.

The authentication is not working with neither when openldap user is a member of ssl-cert group or not, i.e. has read permission on /etc/ssl/private

[Steve Langasek (vorlon)]

Confirming as a regression in hardy.

Strangely, I see EXTERNAL as an option if I connect using ldapi:///, but not when using ldap://; I'm not sure why that would be, but it may have to do with the use of gnutls vs. openssl.

[Mathias Gug (mathiaz)]

Section 15.2.1.8 of the openldap admin guide states the following :

Note: The server must request a client certificate in order to use the SASL EXTERNAL authentication mechanism with a TLS session. As such, a non-default TLSVerifyClient setting must be configured before SASL EXTERNAL authentication may be attempted, and the SASL EXTERNAL mechanism will only be offered to the client if a valid client certificate was received.

According to your slapd.conf file, you're using:

TLSVerifyClient try

which means that if your client doesn't send its certificate, the connection proceeds anyway. And thus the EXTERNAL mechanism will not be available.

Try setting TLSVerifyClient to demand, so that the connection won't proceed if the client doesn't send a certificate. That may be your actual problem.

[Mathias Gug (mathiaz)]

Also, could you try with the latest version available in hardy-updates (2.4.9) ?

[JCBailey (jbailey-co)]

Confirmed with 2.4.9 from hardy-updates.

[Mathias Gug (mathiaz)]

What do you confirm ?

If you don't see EXTERNAL as a supportedSASLMechanisms, make sure that the client is sending a valid ssl certificate. With a proper ssl setup, I was able to get EXTERNAL listed as a supportedSASLMechanisms with 2.4.9.

[JCBailey (jbailey-co)]

I confirmed that the issue as reported exists in 2.4.9. Also, I installed 2.4.11 from source - using the defaults provided by the configure script (probably bound to OpenSSL vs GNUTLS), and it works just fine with the exact same configuration and certificates. I'll have to try to build 2.4.11 with GNUTLS and see if it makes a difference. I used the latest libsasl2-dev and openssl-dev packages available in the repos.

[Mathias Gug (mathiaz)]

I was able to get the EXTERNAL mechanism listed:

mathiaz@t-sasl:~$ ldapsearch -x -H ldaps:/// -b "" -LLL -s base supportedSASLMechanisms
dn:
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: EXTERNAL

I've used the following options in slapd.conf:

TLSCACertificateFile /etc/ssl/certs/cacert.pem
TLSCertificateFile /etc/ssl/certs/t-sasl.vmnet.pem
TLSCertificateKeyFile /etc/ssl/private/t-sasl.vmnet.key
TLSVerifyClient demand

and the following options in .ldaprc:

TLS_CACERT /etc/ssl/certs/cacert.pem
TLS_CERT /home/mathiaz/t-client.vmnet.pem
TLS_KEY /home/mathiaz/t-client.vmnet.key

I've use a properly PKI to create the certificates:

cacert.pem is a self-signed certifcate. t-sasl.vmnet.pem and t-client.vmnet.pem are certificate signed by cacert.pem.

Using a self-signed certificate on the client won't work (ldapsearch doesn't send self-signed certificates).

[Dragomir Minkovski (dejuren)]

I got the problem again:

# Creating self-signed sertificate
openssl genrsa -out ca.key 2048
openssl req -new -x509 -days 365 -key ca.key -out ca.crt

# Create server key and request
openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr

# Sign server request
openssl x509 -req -days 365 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

# Create client key and request
openssl genrsa -out client.key 2048
openssl req -new -key client.key -out client.csr

# Sign client key
openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -set_serial 02 -out client.crt

# The files:
-rw-r--r-- 1 root root 1700 2008-09-04 19:44 ca.crt
-rw-r--r-- 1 root root 1679 2008-09-04 19:42 ca.key
-rw-r--r-- 1 root root 1342 2008-09-04 21:52 client.crt
-rw-r--r-- 1 root root 1086 2008-09-04 21:52 client.csr
-rw-r--r-- 1 root root 1675 2008-09-04 19:52 client.key
-rw-r--r-- 1 root root 1342 2008-09-04 21:51 server.crt
-rw-r--r-- 1 root root 1086 2008-09-04 21:51 server.csr
-rw-r--r-- 1 root root 1675 2008-09-04 19:46 server.key

# Configuration files:

# /home/ubuntu/.ldaprc

TLS_CACERT /root/ca.crt
TLS_CERT /home/ubuntu/client.crt
TLS_KEY /home/ubuntu/client.key

# /etc/ldap/slapd.conf

TLSCACertificateFile /root/ca.crt
TLSCertificateFile /root/server.crt
TLSCertificateKeyFile /root/server.key

TLSVerifyClient demand

# Search
ldapsearch -x -H ldaps:/// -b -LLL -s base supportedSASLMechanisms

# Result

dn:
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: PLAIN

[Mathias Gug (mathiaz)]

Hi,

I've followed the steps you've followed to generate the certificates and
was unable to reproduce your problem:

mathiaz@t-slapd-h:~$ ldapsearch -x -H ldaps:/// -b "" -LLL -s base supportedSASLMechanisms
dn:
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: EXTERNAL

On Fri, Sep 05, 2008 at 02:33:03AM -0000, Dragomir Minkovski wrote:
> # Configuration files:
>
> # /home/ubuntu/.ldaprc
>
> TLS_CACERT /root/ca.crt
> TLS_CERT /home/ubuntu/client.crt
> TLS_KEY /home/ubuntu/client.key
>
> # /etc/ldap/slapd.conf
>
> TLSCACertificateFile /root/ca.crt
> TLSCertificateFile /root/server.crt
> TLSCertificateKeyFile /root/server.key

Could you use /etc/ssl/certs/ for ca.crt and server.crt and /etc/ssl/private/ for server.key instead ?

Also make sure that the permission are set correctly on the files:

mathiaz@t-slapd-h:~$ ls -l /etc/ssl/certs/*crt
-rw-r--r-- 1 root root 1424 2008-09-05 17:16 /etc/ssl/certs/ca.crt
-rw-r--r-- 1 root root 1159 2008-09-05 17:16 /etc/ssl/certs/server.crt

mathiaz@t-slapd-h:~$ sudo ls -l /etc/ssl/private/
total 8
-rw-r----- 1 root ssl-cert 1675 2008-09-05 17:16 server.key

Don't forget to add the openldap user to the ssl-cert group.

Could you also update the .ldaprc file to reference
/etc/ssl/certs/ca.crt rather than /root/ca.crt ?

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com

[Dragomir Minkovski (dejuren)]

Same result here. I copied the files to /etc/ssl/certs and /etc/ssl/private, modified /etc/ldap/slapd.conf to show the new places of the files, /home/ubuntu/.ldaprc was also modified to point to /etc/ssl/certs/ca.cert. There wasn't group ssl-certs, so I created it, (vigr, vigr -s, GID 114) and added user openldap to the group. The directory /etc/ssl/private was 700 root:root, so I changed it to 750 root:ssl-cert, otherwise slapd cannot start. Running slapd by "/etc/init.d/slapd start" doesn't show EXTERNAL. slapd in that case is started with group and user openldap. Even when slapd was run manually with group ssl-cert there wasn't EXTERNAL protocol listed as supported. id for user openldap shows groups openldap and ssl-cert.

[Dragomir Minkovski (dejuren)]

Attaching certificates I'm using. The new_client.crt is the last one created with same country/city/firm/OU etc., no e-mail address.

[Dragomir Minkovski (dejuren)]

Got it working:

ldapsearch -x -H ldaps:/// -b "" -LLL -s base supportedSASLMechanisms

dn:
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: NTLM
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: PLAIN
supportedSASLMechanisms: EXTERNAL

Tks Mathias