thr3ads.net - samba - [Samba] Samba-LDAP TLS problems with inofficial Debian OpenLDAP 2.2 packages [Mar 2005]

If this information is useful, please help other people find it:
Share via:

Paul Coray

2005-Mar-23 10:31 UTC

[Samba] Samba-LDAP TLS problems with inofficial Debian OpenLDAP 2.2 packages

Dear Torsten, dear samba list reader

Three days ago I switched our domain from a NT 4 domaincontroller to 
Samba-OpenLDAP, controlled by a Debian Sarge system. I installed the 
following inofficial Debian OpenLDAP 2.2 packages (I know these are not 
supported, but TLS with OpenSSL is essential to us...):

Package: slapd
Version: 2.2.20-1.hrz.1

Package: libldap2.2
Version: 2.2.20-1.hrz.1

Package: ldap-utils
Version: 2.2.20-1.hrz.1

In order to keep apt from lamenting over missing dependencies, i left 
the official libldap2 package on the system, but I made sure, libldap 
and liblber are linked to version 2.2:

Package: libldap2
Version: 2.1.30-3

Samba domain control (PDC) is running on the same system:

Package: samba
Version: 3.0.10-1

This LDAP master does replication with slurpd to a slave (Solaris 9, 
SunSparc, with blastwave.org OpenLDAP 2.1.27, linked to OpenSSL, 
pam-ldap and nss-ldap from PADL). This system also is hosting samba 
backup domain control (blastwave.org Samba 3.0.10).

As soon as the LDAP-replication is active, my windows users are 
experiencing problems logging on to the domain, often they only manage 
to log in with locally cached credentials/profiles. I suspect there are 
problems with TLS, as I see a lot of messages like this in the Samba 
machine logs:


[2005/03/23 08:18:44, 0] lib/fault.c:fault_report(36)
   ==============================================================[2005/03/23
08:18:44, 0] lib/fault.c:fault_report(37)
   INTERNAL ERROR: Signal 6 in pid 15289 (3.0.10-Debian)
   Please read the appendix Bugs of the Samba HOWTO collection
[2005/03/23 08:18:44, 0] lib/fault.c:fault_report(39)
   ==============================================================[2005/03/23
08:18:44, 0] lib/util.c:smb_panic2(1482)
   PANIC: internal error
[2005/03/23 08:18:44, 0] lib/util.c:smb_panic2(1490)
   BACKTRACE: 34 stack frames:
    #0 /usr/sbin/smbd(smb_panic2+0x111) [0x81e05e1]
    #1 /usr/sbin/smbd(smb_panic+0x1a) [0x81e04ca]
    #2 /usr/sbin/smbd [0x81cc8e8]
    #3 [0xffffe420]
    #4 /lib/tls/libc.so.6(abort+0x1d2) [0x401b5f12]
    #5 /lib/tls/libc.so.6(__assert_fail+0x10f) [0x401ae26f]
    #6 /usr/lib/libldap.so.2 [0x4002b12d]
    #7 /usr/lib/libldap.so.2(ldap_int_open_connection+0x11e) [0x400257ee]
    #8 /usr/lib/libldap.so.2(ldap_new_connection+0x89) [0x400374c9]
    #9 /usr/lib/libldap.so.2(ldap_open_defconn+0x41) [0x400252a1]
    #10 /usr/lib/libldap.so.2(ldap_send_initial_request+0x8f) [0x4003703f]
    #11 /usr/lib/libldap.so.2(ldap_sasl_bind+0x177) [0x4002d387]
    #12 /usr/lib/libldap.so.2(ldap_simple_bind+0x80) [0x4002dd80]
    #13 /lib/libnss_ldap.so.2 [0x409ad423]
    #14 /lib/libnss_ldap.so.2 [0x409acefc]
    #15 /lib/libnss_ldap.so.2 [0x409ae24a]
    #16 /lib/libnss_ldap.so.2 [0x409ae81b]
    #17 /lib/libnss_ldap.so.2(_nss_ldap_getpwnam_r+0x69) [0x409af9e9]
    #18 /lib/tls/libc.so.6(getpwnam_r+0xfc) [0x4023475c]
    #19 /lib/tls/libc.so.6(getpwnam+0x91) [0x40234081]
    #20 /usr/sbin/smbd(getpwnam_alloc+0x11) [0x81d3d21]
    #21 /usr/sbin/smbd(make_server_info_sam+0x59) [0x821e779]
    #22 /usr/sbin/smbd(make_server_info_guest+0xbb) [0x821eaab]
    #23 /usr/sbin/smbd [0x821c882]
    #24 /usr/sbin/smbd [0x821705f]
    #25 /usr/sbin/smbd [0x80ad98e]
    #26 /usr/sbin/smbd(reply_sesssetup_and_X+0x788) [0x80af5b8]
    #27 /usr/sbin/smbd [0x80d3306]
    #28 /usr/sbin/smbd [0x80d3590]
    #29 /usr/sbin/smbd(process_smb+0x8c) [0x80d379c]
    #30 /usr/sbin/smbd(smbd_process+0x168) [0x80d44d8]
    #31 /usr/sbin/smbd(main+0x4ea) [0x82579ba]
    #32 /lib/tls/libc.so.6(__libc_start_main+0xf4) [0x401a1904]
    #33 /usr/sbin/smbd [0x8078b41]
smbd: 
/home/roland/debian/openldap/build/2.1.30/openldap2-2.1.30/libraries/libldap/cyrus.c:468:
ldap_int_sasl_open: Assertio
n `lc->lconn_sasl_ctx == ((void *)0)' failed.


Is samba using the 'original' OpenLDAP 2.1.30 TLS libraries, even if I 
have the ldap libraries linked to 2.2?


# ll /usr/lib/liblber*
lrwxrwxrwx  1 root root    21 2005-01-19 15:20 /usr/lib/liblber-2.2.so.7 
-> liblber-2.2.so.7.0.13
-rw-r--r--  1 root root 49712 2005-01-07 14:07 
/usr/lib/liblber-2.2.so.7.0.13
-rw-r--r--  1 root root 62152 2004-07-27 08:07 /usr/lib/liblber.a
lrwxrwxrwx  1 root root    21 2005-03-22 20:28 /usr/lib/liblber.so -> 
liblber-2.2.so.7.0.13
lrwxrwxrwx  1 root root    21 2005-03-22 20:28 /usr/lib/liblber.so.2 -> 
liblber-2.2.so.7.0.13
-rw-r--r--  1 root root 47312 2004-07-27 08:07 /usr/lib/liblber.so.2.0.130

# ll /usr/lib/libldap*
lrwxrwxrwx  1 root root     21 2005-01-19 15:20 
/usr/lib/libldap-2.2.so.7 -> libldap-2.2.so.7.0.13
-rw-r--r--  1 root root 209212 2005-01-07 14:07 
/usr/lib/libldap-2.2.so.7.0.13
-rw-r--r--  1 root root 290604 2004-07-27 08:07 /usr/lib/libldap.a
lrwxrwxrwx  1 root root     23 2005-01-19 15:20 
/usr/lib/libldap_r-2.2.so.7 -> libldap_r-2.2.so.7.0.13
-rw-r--r--  1 root root 220944 2005-01-07 14:07 
/usr/lib/libldap_r-2.2.so.7.0.13
-rw-r--r--  1 root root 309850 2004-07-27 08:07 /usr/lib/libldap_r.a
lrwxrwxrwx  1 root root     23 2005-03-22 20:22 /usr/lib/libldap_r.so -> 
libldap_r-2.2.so.7.0.13
lrwxrwxrwx  1 root root     23 2005-03-22 20:23 /usr/lib/libldap_r.so.2 
-> libldap_r-2.2.so.7.0.13
-rw-r--r--  1 root root 221844 2004-07-27 08:07 
/usr/lib/libldap_r.so.2.0.130
lrwxrwxrwx  1 root root     21 2005-03-22 20:24 /usr/lib/libldap.so -> 
libldap-2.2.so.7.0.13
lrwxrwxrwx  1 root root     21 2005-03-22 20:24 /usr/lib/libldap.so.2 -> 
libldap-2.2.so.7.0.13
-rw-r--r--  1 root root 209400 2004-07-27 08:07 /usr/lib/libldap.so.2.0.130

And, why does this go away as soon as I stop slurpd on the master and 
slapd on the slave?

This is critical to us, as this is the first major step migrating ~200 
users away from NT-desktops to Linux thin clients, and I don't want to 
give them something to argue against OSS...

Please put my e-mail on cc, as don't read the list on a regular basis.

Thanks
Paul





-- 
Paul Coray
Administrator Server und Netzwerk

Oeffentliche Bibliothek der Universitaet Basel
EDV-Abteilung
Schoenbeinstrasse 18-20
CH-4056 Basel

Tel: +41 61 267 05 13
Fax: +41 61 267 31 03

mailto:paul.coray@unibas.ch
http://www.ub.unibas.ch

Torsten Landschoff

2005-Mar-23 12:06 UTC

head link

[Samba] Re: Samba-LDAP TLS problems with inofficial Debian OpenLDAP 2.2 packages

Hi Paul, 

On Wed, Mar 23, 2005 at 11:30:35AM +0100, Paul Coray
wrote:> Three days ago I switched our domain from a NT 4 domaincontroller to 
> Samba-OpenLDAP, controlled by a Debian Sarge system. I installed the 
> following inofficial Debian OpenLDAP 2.2 packages (I know these are not 
> supported, but TLS with OpenSSL is essential to us...):
> 
> Package: slapd
> Version: 2.2.20-1.hrz.1
> 
> Package: libldap2.2
> Version: 2.2.20-1.hrz.1
> 
> Package: ldap-utils
> Version: 2.2.20-1.hrz.1
Where are those available? I did not know about that fork and perhaps I
can share some work with the maintainer.
> As soon as the LDAP-replication is active, my windows users are 
> experiencing problems logging on to the domain, often they only manage 
> to log in with locally cached credentials/profiles. I suspect there are 
> problems with TLS, as I see a lot of messages like this in the Samba 
> machine logs:
> 
> 
> [2005/03/23 08:18:44, 0] lib/fault.c:fault_report(36)
>   ==============================================================>
[2005/03/23 08:18:44, 0] lib/fault.c:fault_report(37)
>   INTERNAL ERROR: Signal 6 in pid 15289 (3.0.10-Debian)
>   Please read the appendix Bugs of the Samba HOWTO collection
> [2005/03/23 08:18:44, 0] lib/fault.c:fault_report(39)
>   ==============================================================>
[2005/03/23 08:18:44, 0] lib/util.c:smb_panic2(1482)
>   PANIC: internal error
> [2005/03/23 08:18:44, 0] lib/util.c:smb_panic2(1490)
>   BACKTRACE: 34 stack frames:
>    #0 /usr/sbin/smbd(smb_panic2+0x111) [0x81e05e1]
>    #1 /usr/sbin/smbd(smb_panic+0x1a) [0x81e04ca]
>    #2 /usr/sbin/smbd [0x81cc8e8]
>    #3 [0xffffe420]
>    #4 /lib/tls/libc.so.6(abort+0x1d2) [0x401b5f12]
>    #5 /lib/tls/libc.so.6(__assert_fail+0x10f) [0x401ae26f]
>    #6 /usr/lib/libldap.so.2 [0x4002b12d]
>    #7 /usr/lib/libldap.so.2(ldap_int_open_connection+0x11e) [0x400257ee]
>    #8 /usr/lib/libldap.so.2(ldap_new_connection+0x89) [0x400374c9]
>    #9 /usr/lib/libldap.so.2(ldap_open_defconn+0x41) [0x400252a1]
>    #10 /usr/lib/libldap.so.2(ldap_send_initial_request+0x8f) [0x4003703f]
>    #11 /usr/lib/libldap.so.2(ldap_sasl_bind+0x177) [0x4002d387]
>    #12 /usr/lib/libldap.so.2(ldap_simple_bind+0x80) [0x4002dd80]
>    #13 /lib/libnss_ldap.so.2 [0x409ad423]
>    #14 /lib/libnss_ldap.so.2 [0x409acefc]
>    #15 /lib/libnss_ldap.so.2 [0x409ae24a]
>    #16 /lib/libnss_ldap.so.2 [0x409ae81b]
>    #17 /lib/libnss_ldap.so.2(_nss_ldap_getpwnam_r+0x69) [0x409af9e9]
>    #18 /lib/tls/libc.so.6(getpwnam_r+0xfc) [0x4023475c]
>    #19 /lib/tls/libc.so.6(getpwnam+0x91) [0x40234081]
>    #20 /usr/sbin/smbd(getpwnam_alloc+0x11) [0x81d3d21]
>    #21 /usr/sbin/smbd(make_server_info_sam+0x59) [0x821e779]
>    #22 /usr/sbin/smbd(make_server_info_guest+0xbb) [0x821eaab]
>    #23 /usr/sbin/smbd [0x821c882]
>    #24 /usr/sbin/smbd [0x821705f]
>    #25 /usr/sbin/smbd [0x80ad98e]
>    #26 /usr/sbin/smbd(reply_sesssetup_and_X+0x788) [0x80af5b8]
>    #27 /usr/sbin/smbd [0x80d3306]
>    #28 /usr/sbin/smbd [0x80d3590]
>    #29 /usr/sbin/smbd(process_smb+0x8c) [0x80d379c]
>    #30 /usr/sbin/smbd(smbd_process+0x168) [0x80d44d8]
>    #31 /usr/sbin/smbd(main+0x4ea) [0x82579ba]
>    #32 /lib/tls/libc.so.6(__libc_start_main+0xf4) [0x401a1904]
>    #33 /usr/sbin/smbd [0x8078b41]
> smbd: 
>
/home/roland/debian/openldap/build/2.1.30/openldap2-2.1.30/libraries/libldap/cyrus.c:468:
> ldap_int_sasl_open: Assertio
> n `lc->lconn_sasl_ctx == ((void *)0)' failed.
This is a known bug in the Debian packages. Have a look at

	http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=273620

If you can reproduce it we might be able to track it down finally.
> Is samba using the 'original' OpenLDAP 2.1.30 TLS libraries, even
if I
> have the ldap libraries linked to 2.2?
Yes. It will use the 2.1.30 libraries as they are incompatible with
2.2.x
> And, why does this go away as soon as I stop slurpd on the master and 
> slapd on the slave?
No idea.
> This is critical to us, as this is the first major step migrating ~200 
> users away from NT-desktops to Linux thin clients, and I don't want to 
> give them something to argue against OSS...
My guess how to fix this: Get the openldap2 sources from the Debian
package and build it against OpenSSL. I can make packages available if
you can't build them. 

You should change debian/changelog so that apt can differentiate between
the official and your packages and debian/configure.options so it uses
OpenSSL. Ah, and remove gnutls from Build-Depends in debian/control and
add libssl-dev. Make sure no gnutls dev package is installed as the
configure script had a bug to use it even if you'd rather use OpenSSL. 

Thanks

	Torsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url :
http://lists.samba.org/archive/samba/attachments/20050323/90bb0270/attachment.bin

Paul Coray

2005-Mar-23 14:29 UTC

head link

[Samba] Re: Samba-LDAP TLS problems with inofficial Debian OpenLDAP 2.2 packages

Torsten,

Thanks for your quick response!
>  >
>  > Package: slapd
>  > Version: 2.2.20-1.hrz.1
>  >
>  > Package: libldap2.2
>  > Version: 2.2.20-1.hrz.1
>  >
>  > Package: ldap-utils
>  > Version: 2.2.20-1.hrz.1
> 
> Where are those available? I did not know about that fork and perhaps I
> can share some work with the maintainer.
Sorry, as the Packages file at ftp://ftp.uni-marburg.de/linux/debian 
mentions your name as maintainer, I thought you made those, but I'm glad 
you are willing to deal with them anyway :-)

>  > smbd:
>  > 
>
/home/roland/debian/openldap/build/2.1.30/openldap2-2.1.30/libraries/libldap/cyrus.c:468:
> 
>  > ldap_int_sasl_open: Assertio
>  > n `lc->lconn_sasl_ctx == ((void *)0)' failed.
> 
> This is a known bug in the Debian packages. Have a look at
> 
>     http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=273620
> 
> If you can reproduce it we might be able to track it down finally.
Not so easy, as this happened only twice in the morning when the load 
from user authenticating, maybe also changing attributes (passwords) was 
high. Difficult to simulate this in a testing environment...
> 
>  > Is samba using the 'original' OpenLDAP 2.1.30 TLS libraries,
even if I
>  > have the ldap libraries linked to 2.2?
> 
> Yes. It will use the 2.1.30 libraries as they are incompatible with
> 2.2.x
> 
>  > And, why does this go away as soon as I stop slurpd on the master and
>  > slapd on the slave?
> 
> No idea.
> 
>  > This is critical to us, as this is the first major step migrating
~200
>  > users away from NT-desktops to Linux thin clients, and I don't
want to
>  > give them something to argue against OSS...
> 
> My guess how to fix this: Get the openldap2 sources from the Debian
> package and build it against OpenSSL. I can make packages available if
> you can't build them.
> 
> You should change debian/changelog so that apt can differentiate between
> the official and your packages and debian/configure.options so it uses
> OpenSSL. Ah, and remove gnutls from Build-Depends in debian/control and
> add libssl-dev. Make sure no gnutls dev package is installed as the
> configure script had a bug to use it even if you'd rather use OpenSSL.
Hmm... Ok, I'll give it a shot. Problem though is, this is a productive 
server as from last monday. In my testing environment, the mentioned 
packages worked flawlessly, so this HAS to work, once I use it in 
production, or my users might get upset, if you know what I mean... ;-)

Anyway, if you have those packages from the Debian openldap2 sources 
handy, I would gladly test them.


Cheers
Paul

-- 
Paul Coray
Administrator Server und Netzwerk

Oeffentliche Bibliothek der Universitaet Basel
EDV-Abteilung
Schoenbeinstrasse 18-20
CH-4056 Basel

Tel: +41 61 267 05 13
Fax: +41 61 267 31 03

mailto:paul.coray@unibas.ch
http://www.ub.unibas.ch

Paul Coray

2005-Mar-23 15:49 UTC

head link

[Samba] Re: Samba-LDAP TLS problems with inofficial Debian OpenLDAP 2.2 packages

> 
>  > Anyway, if you have those packages from the Debian openldap2 sources
>  > handy, I would gladly test them.
> 
> I just built them. I don't think it will help though. Looking at the
> source I wonder why it doesn't fail consistently. So I have to ask you
> another question: Are you using that SASL stuff? (I never used it...)
> I could switch it off which would completely eliminate the errorneous
> code path.
No, I never used SASL, since I want TLS for LDAP transport ;-).

Cheers
Paul

-- 
Paul Coray
Administrator Server und Netzwerk

Oeffentliche Bibliothek der Universitaet Basel
EDV-Abteilung
Schoenbeinstrasse 18-20
CH-4056 Basel

Tel: +41 61 267 05 13
Fax: +41 61 267 31 03

mailto:paul.coray@unibas.ch
http://www.ub.unibas.ch

Tony Earnshaw

2005-Mar-23 16:38 UTC

head link

[Samba] Samba-LDAP TLS problems with inofficial Debian OpenLDAP 2.2 packages

Paul Coray:
> Three days ago I switched our domain from a NT 4 domaincontroller to
> Samba-OpenLDAP, controlled by a Debian Sarge system. I installed the
> following inofficial Debian OpenLDAP 2.2 packages (I know these are not
> supported, but TLS with OpenSSL is essential to us...):
>
> Package: slapd
> Version: 2.2.20-1.hrz.1
>
>
> Package: libldap2.2
> Version: 2.2.20-1.hrz.1
>
>
> Package: ldap-utils
> Version: 2.2.20-1.hrz.1
I'm a Red Hat person don't know Debian at all ... However:

To use OL 2.2 you'll have to have Sleepycat BDB 4.2.52 + patches ,too.
> In order to keep apt from lamenting over missing dependencies, i left
> the official libldap2 package on the system, but I made sure, libldap and
> liblber are linked to version 2.2:
[...]
> This LDAP master does replication with slurpd to a slave (Solaris 9,
> SunSparc, with blastwave.org OpenLDAP 2.1.27, linked to OpenSSL,
> pam-ldap and nss-ldap from PADL). This system also is hosting samba backup
> domain control (blastwave.org Samba 3.0.10).
>
> As soon as the LDAP-replication is active, my windows users are
> experiencing problems logging on to the domain, often they only manage to
> log in with locally cached credentials/profiles. I suspect there are
> problems with TLS, as I see a lot of messages like this in the Samba
> machine logs:
[...]
> And, why does this go away as soon as I stop slurpd on the master and
> slapd on the slave?
IIRC OL 2.2 won't replicate (slurpd) to a 2.1 slave and the slave can't
update a 2.2 server.

2.2 compiles fine on Solaris 7/8/9, so the gurus on the OL list say (I've
no experience), as long as one uses GNU gcc and tools. Try to go that way
- and don't forget BDB 4.2.52 (Cyrus SASL if you need it).

--Tonni

--
mail: tonye@billy.demon.nl
http://www.billy.demon.nl

Possibly Parallel Threads

Search for more seemingly similar threads

samba - Mar 2005 - Samba-LDAP TLS problems with inofficial Debian OpenLDAP 2.2 packages

[Samba] Samba-LDAP TLS problems with inofficial Debian OpenLDAP 2.2 packages

[Samba] Re: Samba-LDAP TLS problems with inofficial Debian OpenLDAP 2.2 packages

[Samba] Re: Samba-LDAP TLS problems with inofficial Debian OpenLDAP 2.2 packages

[Samba] Re: Samba-LDAP TLS problems with inofficial Debian OpenLDAP 2.2 packages

[Samba] Samba-LDAP TLS problems with inofficial Debian OpenLDAP 2.2 packages

Possibly Parallel Threads