Re: TLS/SSL altNames [was: SSL certificates, kerberos keytabs, and load balancing]

["Medievalist" <ldap@HBCS.Org>]

It depends on which "nss_ldap" you're talking about, Tony.

[root@burner root]# rpm -ql nss_ldap
/etc/ldap.conf
/lib/libnss_ldap-2.3.2.so
/lib/security/pam_ldap.so    <--- see this
/usr/lib/libnss_ldap.so
..etc...

[root@burner root]# rpm -ql openldap
/etc/openldap
/etc/openldap/ldap.conf
/usr/lib/liblber.so.2        <---and this
/usr/lib/liblber.so.2.0.124
/usr/lib/libldap.so.2        <---and this
/usr/lib/libldap.so.2.0.124
/usr/lib/libldap_r.so.2
/usr/lib/libldap_r.so.2.0.124
...etc...

[root@burner root]# ldd /lib/security/pam_ldap.so
        libresolv.so.2 => /lib/libresolv.so.2 (0xb75d6000)
see ->  libldap.so.2 => /usr/lib/libldap.so.2 (0xb75a4000)
see ->  liblber.so.2 => /usr/lib/liblber.so.2 (0xb7598000)
        libnsl.so.1 => /lib/libnsl.so.1 (0xb7583000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0xb7556000)
        libpam.so.0 => /lib/libpam.so.0 (0xb754e000)
        libdl.so.2 => /lib/libdl.so.2 (0xb754a000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7412000)
        libsasl2.so.2 => /usr/lib/libsasl2.so.2 (0xb73fc000)
        libssl.so.4 => /lib/libssl.so.4 (0xb73c8000)
        libcrypto.so.4 => /lib/libcrypto.so.4 (0xb72d7000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)
        libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 (0xb72c3000)
        libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0xb7265000)
        libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0xb7263000)
        libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0xb7253000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb7245000)

As you can see (if our mailers haven't munged my message to bits) Red Hat's 
nss_ldap *package* includes pam_ldap, which uses two OL libs.

Granted, the nss_ldap *module* doesn't.  Or at least not directly.

What prompted my comment/question was the observation in Bugzilla that this bug 
occurs in the OpenLDAP 2.0.27 ldapsearch command shipped with Red Hat EL v3.  
Upgrading the OpenLDAP installation reportedly fixed ldapsearch, but not the 
related pam_unix + nss_ldap problem, which is described here:

http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=85728

One person said that rebuilding the nss_ldap package (therefore recompiling 
pam_ldap) fixes the problem once you've got OpenLDAP upgraded.  Since Red Hat 
(and I) statically link these sorts of things, I theorize that OpenLDAP 2.0.27 
is the culprit.

--Charlie



On 13 Apr 2004 at 21:35, Tony Earnshaw wrote:

Subject:        	Re: TLS/SSL altNames [was: SSL certificates, kerberos keytabs, and
	load balancing]
From:           	Tony Earnshaw <tonye@billy.demon.nl>
To:             	Openldap list <openldap-software@OpenLDAP.org>
Organization:   	Billy
Date sent:      	Tue, 13 Apr 2004 21:35:45 +0200
Priority:       	non-urgent

> tir, 13.04.2004 kl. 21.00 skrev Medievalist:
> 
> > Hmmm... looking at the bug reports, isn't this another side effect of Red Hat 
> > shipping an obsolete, known-to-be-buggy OpenLDAP package?
> 
> I'd not consider Openldap 2.0.27 to be buggy, just a bit old-fashioned
> ;) RHEL3 comes with BDB 4.1.(15?) as standard and RedHat's OL 2.0.27
> uses it.
> 
> >   P'raps nss_ldap is 
> > using the OpenLDAP libraries and inheriting the bug?
> 
> nss_ldap doesn't use OL libs. There was a new RHEL3 up2date nss/pam_dap
> package in January last. up2people to keep their systems up2date.
> 
> --Tonni
>