Re: Problem with libnss-ldap/libpam-ldap and TLS client-/server-verification (Ubuntu 10.04)
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
Re: Problem with libnss-ldap/libpam-ldap and TLS client-/server-verification (Ubuntu 10.04)
- From: Martin Wegner <public [at] mroot.net>
- To: nss-pam-ldapd-users [at] lists.arthurdejong.org
- Subject: Re: Problem with libnss-ldap/libpam-ldap and TLS client-/server-verification (Ubuntu 10.04)
- Date: Wed, 04 May 2011 19:04:23 +0200
Hello.
First of all, thank you for your answer.
On 04/19/11 21:44, Arthur de Jong wrote:
> [...]
> This is the mailing list for nss-pam-ldapd, a derivative of nss_ldap
> (and probably small bits of pam_ldap). For more information on this
> issue you can probably be better served at one of the PADL mailing
> lists:
> http://www.padl.com/Contents/OpenSourceSoftware.html
I confused that, I'm sorry about that. Somewhere in the process of
searching for reasons of (and solutions to) our problem, I must have
confused those packages so that I ended up here.
> [...]
> Since you've reached a nss-pam-ldapd mailing list, you might as well
> have a look at it. ;) It's security model is simpler and should fit
> quite nicely for your kind of environment because all LDAP queries are
> performed by a single process as a dedicated user. The packages in
> Ubuntu lucid (libnss-ldapd, libpam-ldapd and nslcd) are quite outdated
> (0.7.2) and contain some known issues that are fixed in later releases.
We as well like the idea of one local daemon and dedicated user querying
the LDAP server. So, first we installed the Ubuntu (10.04) versions of
the packages and configured everything so that nslcd was
used.
So, basically this is our config of nslcd (/etc/nslcd.conf):
uid nslcd
gid nslcd
uri ldaps://134.169.81.19/
base dc=irmb,dc=bau,dc=tu-bs,dc=de
ssl on
tls_cacertfile /etc/ssl/certs/caelrond.pem
tls_cert /etc/ssl/certs/lurtzldap.crt
tls_key /etc/ssl/private/lurtzldap.key
tls_reqcert demand
bind_timelimit 60
We changed the ownership of the certificates of the machine accordingly,
so that they are owned and therefore readable by nslcd.
openssl s_client and gnutls-cli respectively tell us that the
certificates can be validated as well as they can validate the server's
certificate as trusted.
But unfortunately, nslcd is not able to query the server with the above
config.
We were able to trace this down to one option - namely tls_reqcert. If
we set it to 'never', the querying of the LDAP server via nslcd and the
according pam and nss modules work.
We also tried newer versions of nslcd - 0.7.13 and 0.8.2 - but they gave
the same results.
A $ getent passwd fails with tls_reqcert set to demand. As soon as we
change that option to never, LDAP querying works fine.
I pasted a log of a running nslcd v. 0.7.13 with the -d flag while it
fails to query the LDAP server under [1].
I'd be glad if you could tell us how we can investigate this further or
what we are doing wrong.
Thanks again and best regards,
Martin Wegner
[1] http://hpaste.org/46362/nslcdlog
--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users