Bug 434735

The x86_64 server should not be attempting to load /usr/lib/sasl2 - it should be
using /usr/lib64/sasl2.  Can you confirm that you have installed the
fedora-ds-base.x86_64 package?

Yes, it's the x86_64 package (fedora-ds-base-1.1.0-3.fc6) on CentOS-5.1.

# file /usr/sbin/ns-slapd
/usr/sbin/ns-slapd: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for
GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9,
stripped

# ldd /usr/sbin/ns-slapd
        libslapd.so.0 => /usr/lib64/dirsrv/libslapd.so.0 (0x00002aaaaaaad000)
        libssldap60.so => /usr/lib64/libssldap60.so (0x00002aaaaad9c000)
        libprldap60.so => /usr/lib64/libprldap60.so (0x0000003b9d000000)
        libldap60.so => /usr/lib64/libldap60.so (0x0000003b9d400000)
        libldif60.so => /usr/lib64/libldif60.so (0x0000003b9d800000)
        libssl3.so => /usr/lib64/libssl3.so (0x000000364bc00000)
        libnss3.so => /usr/lib64/libnss3.so (0x000000364b800000)
        libsoftokn3.so => /usr/lib64/libsoftokn3.so (0x00002aaaaafaa000)
        libplc4.so => /usr/lib64/libplc4.so (0x000000364a400000)
        libplds4.so => /usr/lib64/libplds4.so (0x000000364a800000)
        libnspr4.so => /usr/lib64/libnspr4.so (0x000000364a000000)
        libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003b9cc00000)
        libsvrcore.so.0 => /usr/lib64/libsvrcore.so.0 (0x0000003b9e000000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003637a00000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003638600000)
        libsmime3.so => /usr/lib64/libsmime3.so (0x000000364b000000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003638200000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x000000363fc00000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003648800000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003636a00000)

rpm -qa --queryformat '%{name}.%{arch}\n' | grep sasl

On my RHEL5 x86_64 system I have these:
cyrus-sasl-gssapi.i386
cyrus-sasl-lib.i386
cyrus-sasl.x86_64
cyrus-sasl-plain.x86_64
cyrus-sasl.i386
cyrus-sasl-md5.x86_64
cyrus-sasl-plain.i386
cyrus-sasl-ntlm.i386
cyrus-sasl-devel.x86_64
cyrus-sasl-lib.x86_64
cyrus-sasl-md5.i386

I have these on my system:

rpm -qa --queryformat '%{name}.%{arch}\n' | grep sasl
cyrus-sasl-lib.x86_64
cyrus-sasl-plain.i386
cyrus-sasl-plain.x86_64
cyrus-sasl-md5.x86_64
cyrus-sasl-lib.i386
cyrus-sasl.i386
cyrus-sasl-devel.x86_64
cyrus-sasl.x86_64
cyrus-sasl-gssapi.x86_64

env | grep -i sasl
grep -i sasl_path /etc/rc.d/init.d/dirsrv /etc/sysconfig/dirsrv
/etc/dirsrv/slapd-*/dse.ldif

No, nothing. So then I:
gdb program `pgrep ns-slapd`
...
> Reading symbols from /usr/lib64/sasl2/libsasldb.so.2...(no debugging symbols
found)...done.
> Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2
> Reading symbols from /usr/lib64/sasl2/libdigestmd5.so.2...
> (no debugging symbols found)...done.
> Loaded symbols for /usr/lib64/sasl2/libdigestmd5.so.2
> Reading symbols from /lib64/libcrypto.so.6...(no debugging symbols found)...done.
> Loaded symbols for /lib64/libcrypto.so.6
> Reading symbols from /usr/lib64/libz.so.1...
> (no debugging symbols found)...done.
> Loaded symbols for /usr/lib64/libz.so.1
> Reading symbols from /usr/lib64/sasl2/libcrammd5.so.2...(no debugging symbols
found)...done.
> Loaded symbols for /usr/lib64/sasl2/libcrammd5.so.2
> Reading symbols from /usr/lib64/sasl2/libgssapiv2.so.2...
> (no debugging symbols found)...done.
> Loaded symbols for /usr/lib64/sasl2/libgssapiv2.so.2
> Reading symbols from /usr/lib64/libgssapi_krb5.so.2...(no debugging symbols
found)...done.
> Loaded symbols for /usr/lib64/libgssapi_krb5.so.2
> Reading symbols from /usr/lib64/libkrb5.so.3...
> (no debugging symbols found)...done.
> Loaded symbols for /usr/lib64/libkrb5.so.3
> Reading symbols from /usr/lib64/libk5crypto.so.3...(no debugging symbols
found)...done.
> Loaded symbols for /usr/lib64/libk5crypto.so.3
> Reading symbols from /lib64/libcom_err.so.2...
> (no debugging symbols found)...done.
> Loaded symbols for /lib64/libcom_err.so.2
> Reading symbols from /usr/lib64/libkrb5support.so.0...(no debugging symbols
found)...done.
> Loaded symbols for /usr/lib64/libkrb5support.so.0
> Reading symbols from /lib64/libkeyutils.so.1...
> (no debugging symbols found)...done.
> Loaded symbols for /lib64/libkeyutils.so.1
> Reading symbols from /lib64/libselinux.so.1...(no debugging symbols found)...done.
> Loaded symbols for /lib64/libselinux.so.1
> Reading symbols from /lib64/libsepol.so.1...
> (no debugging symbols found)...done.
> Loaded symbols for /lib64/libsepol.so.1
> Reading symbols from /usr/lib64/sasl2/libanonymous.so.2...(no debugging
symbols found)...done.
> Loaded symbols for /usr/lib64/sasl2/libanonymous.so.2
> Reading symbols from /usr/lib64/sasl2/liblogin.so.2...
> (no debugging symbols found)...done.
> Loaded symbols for /usr/lib64/sasl2/liblogin.so.2
> Reading symbols from /usr/lib64/sasl2/libplain.so.2...(no debugging symbols
found)...done.
> Loaded symbols for /usr/lib64/sasl2/libplain.so.2

It seems to be finding the /usr/lib64/sasl2 shared libraries.

What prompted this bug report was that I have a working fds 1.0.4
installation that has autofs authenticating via a proxy user. autofs
can only authenticate using SASL mechanisms. With fds 1.1 the server
always returns LDAP_INVALID_CREDENTIALS (49):

[24/Feb/2008:14:11:24 -0800] conn=352 fd=69 slot=69 connection from
132.239.23.78 to 132.239.92.137
[24/Feb/2008:14:11:24 -0800] conn=352 op=0 EXT oid="1.3.6.1.4.1.1466.20037"
name="startTLS"
[24/Feb/2008:14:11:24 -0800] conn=352 op=0 RESULT err=0 tag=120 nentries=0 etime=0
[24/Feb/2008:14:11:24 -0800] conn=352 SSL 256-bit AES
[24/Feb/2008:14:11:24 -0800] conn=352 op=1 BIND dn="" method=sasl version=3
mech=ANONYMOUS
[24/Feb/2008:14:11:24 -0800] conn=352 op=1 RESULT err=49 tag=97 nentries=0 etime=0
[24/Feb/2008:14:11:24 -0800] conn=352 op=2 UNBIND

Are you using mech=ANONYMOUS with 1.0.4?

Yes I am. I didn't find an alternative SASL mechanism compatible with
both autofs and fds. I'm not particularly happy about the security implications.

So the bug is that SASL ANONYMOUS works with Fedora DS 1.0.4 but is broken with
Fedora DS 1.1?

That is apparently tha case. Sorry for the red-herrings.

The SASL code didn't really change much with 1.1.  The SASL mapping code did - I
wonder if that has something to do with this problem?  Are you really attempting
to bind as anonymous (dn="") or is that just what the log reports?  Have you
tried another mechanism such as LOGIN or PLAIN?  Does autofs really require
SASL?  Is there no way to use LDAP simple bind?

We had a SASL mapping set up for a proxy user. autofs was supplying the sasl
authcid matching that mapping. Today we got autofs working with ssl certificates,
so as far as I'm concerned this bug report can be closed. Thanks for your
help and prompt responses. -frank

Thanks.  I'm going to leave it open - you probably won't be the last person to
run into this.  Thanks for all of the info, btw.

I also have the following messages on my 64 bit Red Hat directory server:
# grep lib /var/log/messages
Aug 12 13:11:45 rhds ns-slapd: unable to dlopen /usr/lib/sasl2/liblogin.so.2: /usr/lib/sasl2/liblogin.so.2: wrong ELF class: ELFCLASS32
Aug 12 13:11:45 rhds ns-slapd: unable to dlopen /usr/lib/sasl2/libanonymous.so.2: /usr/lib/sasl2/libanonymous.so.2: wrong ELF class: ELFCLASS32
Aug 12 13:11:45 rhds ns-slapd: unable to dlopen /usr/lib/sasl2/libplain.so.2: /usr/lib/sasl2/libplain.so.2: wrong ELF class: ELFCLASS32

My problem is that SSL does not seem to work when setting up a LDAP synchronization to an active directory machine. Without SSL it works ok.
If anyone has pointers how to resolve this, that would be very welcome.

More info:
Installed base: Red Hat Enterprise Linux (v. 5 for 64-bit x86_64)

# file /usr/sbin/ns-slapd
/usr/sbin/ns-slapd: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped

# ldd /usr/sbin/ns-slapd
        libslapd.so.0 => /usr/lib64/dirsrv/libslapd.so.0 (0x00002af86dc7d000)
        libssldap60.so => /usr/lib64/libssldap60.so (0x00002af86df65000)
        libprldap60.so => /usr/lib64/libprldap60.so (0x0000003f48400000)
        libldap60.so => /usr/lib64/libldap60.so (0x0000003f47800000)
        libldif60.so => /usr/lib64/libldif60.so (0x0000003f48000000)
        libssl3.so => /usr/lib64/libssl3.so (0x00002af86e172000)
        libnss3.so => /usr/lib64/libnss3.so (0x00002af86e3a5000)
        libsoftokn3.so => /usr/lib64/libsoftokn3.so (0x00002af86e6e8000)
        libplc4.so => /usr/lib64/libplc4.so (0x00002af86e942000)
        libplds4.so => /usr/lib64/libplds4.so (0x00002af86eb46000)
        libnspr4.so => /usr/lib64/libnspr4.so (0x00002af86ed4a000)
        libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003f3b600000)
        libsvrcore.so.0 => /usr/lib64/libsvrcore.so.0 (0x0000003f46c00000)
        libc.so.6 => /lib64/libc.so.6 (0x0000003f28400000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003f29000000)
        libsmime3.so => /usr/lib64/libsmime3.so (0x00002af86ef85000)
        libdl.so.2 => /lib64/libdl.so.2 (0x0000003f28c00000)
        libnssutil3.so => /usr/lib64/libnssutil3.so (0x00002af86f1b0000)
        libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003f31a00000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003f3ae00000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003f28000000)

# rpm -qa --queryformat '%{name}.%{arch}\n' | grep sasl
cyrus-sasl-lib.x86_64
cyrus-sasl-gssapi.x86_64
cyrus-sasl-lib.i386
cyrus-sasl-plain.x86_64
cyrus-sasl.x86_64
cyrus-sasl-md5.x86_64
cyrus-sasl-plain.i386

# env | grep -i sasl
# grep -i sasl_path /etc/rc.d/init.d/dirsrv /etc/sysconfig/dirsrv /etc/dirsrv/slapd-*/dse.ldif
#

(In reply to comment #14)
> I also have the following messages on my 64 bit Red Hat directory server:
> # grep lib /var/log/messages
> Aug 12 13:11:45 rhds ns-slapd: unable to dlopen /usr/lib/sasl2/liblogin.so.2:
> /usr/lib/sasl2/liblogin.so.2: wrong ELF class: ELFCLASS32
> Aug 12 13:11:45 rhds ns-slapd: unable to dlopen
> /usr/lib/sasl2/libanonymous.so.2: /usr/lib/sasl2/libanonymous.so.2: wrong ELF
> class: ELFCLASS32
> Aug 12 13:11:45 rhds ns-slapd: unable to dlopen /usr/lib/sasl2/libplain.so.2:
> /usr/lib/sasl2/libplain.so.2: wrong ELF class: ELFCLASS32
> 
> My problem is that SSL does not seem to work when setting up a LDAP
> synchronization to an active directory machine. Without SSL it works ok.
> If anyone has pointers how to resolve this, that would be very welcome.
>

Those sasl messages are just annoying and should be ignored.  We are working on a way to remove them from the logs.  In addition, they have nothing to do with SSL, so they are not related to any problems you might be having with SSL.

http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Windows_Sync.html
http://directory.fedoraproject.org/wiki/Howto:WindowsSync
general ssl information
http://directory.fedoraproject.org/wiki/Howto:SSL

> More info:
> Installed base: Red Hat Enterprise Linux (v. 5 for 64-bit x86_64)
> 
> # file /usr/sbin/ns-slapd
> /usr/sbin/ns-slapd: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV),
> for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux
> 2.6.9, stripped
> 
> # ldd /usr/sbin/ns-slapd
>         libslapd.so.0 => /usr/lib64/dirsrv/libslapd.so.0 (0x00002af86dc7d000)
>         libssldap60.so => /usr/lib64/libssldap60.so (0x00002af86df65000)
>         libprldap60.so => /usr/lib64/libprldap60.so (0x0000003f48400000)
>         libldap60.so => /usr/lib64/libldap60.so (0x0000003f47800000)
>         libldif60.so => /usr/lib64/libldif60.so (0x0000003f48000000)
>         libssl3.so => /usr/lib64/libssl3.so (0x00002af86e172000)
>         libnss3.so => /usr/lib64/libnss3.so (0x00002af86e3a5000)
>         libsoftokn3.so => /usr/lib64/libsoftokn3.so (0x00002af86e6e8000)
>         libplc4.so => /usr/lib64/libplc4.so (0x00002af86e942000)
>         libplds4.so => /usr/lib64/libplds4.so (0x00002af86eb46000)
>         libnspr4.so => /usr/lib64/libnspr4.so (0x00002af86ed4a000)
>         libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003f3b600000)
>         libsvrcore.so.0 => /usr/lib64/libsvrcore.so.0 (0x0000003f46c00000)
>         libc.so.6 => /lib64/libc.so.6 (0x0000003f28400000)
>         libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003f29000000)
>         libsmime3.so => /usr/lib64/libsmime3.so (0x00002af86ef85000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x0000003f28c00000)
>         libnssutil3.so => /usr/lib64/libnssutil3.so (0x00002af86f1b0000)
>         libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003f31a00000)
>         libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003f3ae00000)
>         /lib64/ld-linux-x86-64.so.2 (0x0000003f28000000)
> 
> # rpm -qa --queryformat '%{name}.%{arch}\n' | grep sasl
> cyrus-sasl-lib.x86_64
> cyrus-sasl-gssapi.x86_64
> cyrus-sasl-lib.i386
> cyrus-sasl-plain.x86_64
> cyrus-sasl.x86_64
> cyrus-sasl-md5.x86_64
> cyrus-sasl-plain.i386
> 
> # env | grep -i sasl
> # grep -i sasl_path /etc/rc.d/init.d/dirsrv /etc/sysconfig/dirsrv
> /etc/dirsrv/slapd-*/dse.ldif
> #

I am unable to even get either MozLDAP or OpenLDAP ldapsearch to see ANONYMOUS as a valid SASL mechanism on my Fedora 11 system.  I have confirmed that libanonymous.so exists in the SASL plugin directory and set SASL_PATH manually to ensure that the proper location is being used.

I ran MozLDAP ldapsearch in a debugger and can see that sasl_client_start() returns an errror that there is no worthy mechanism found when trying to use the ANONYMOUS mechanism.  I'm not sure what exactly is required to make this work, but it's not even getting to the point where the server receives the bind attempt.

After some debugging through the SASL library code, I found that the default secprops set by the libraries disable anonymous and plaintext authentication.  I am now able to get to the same point as this bug report with an error 49 in the access log by setting the secprops to none with mozLDAP ldapsearch:

  ldapsearch -h localhost.localdomain -p 389 -o "mech=ANONYMOUS" -o "secprop=none" -b "" -s base "objectclass=*"

I'll continue to look into this on the server side.

The problem is that the bind attempt goes into the normal SASL mapping code.  This causes it to do a search for a real entry to map the SASL authid to using a filter of "uid=anonymous".  It seems that we need some special handing for the anonymous SASL mechanism prior to calling the mapping code.

We will also need to perform a check in the normal bind code to reject binds using the SASL anonymous mechanism if anonymous access is disabled on the server.

Created attachment 394796 [details]
Patch

The SASL ANONYMOUS mechanism was broken since the SASL mapping code
was invoked to map anonymous to a real user entry.  This adds a
special case to the canonify user callback that sets the bind DN
to "" if the ANONYMOUS mechanism is being used.

I also added a check to see if anonymous access is disabled when
we set up the SASL secprops for a connection.  If anonymous access
is disabled, we set a SASL security flag to disallow mechanisms
that would allow anonymous access.

Thanks for the review!  Pushed to master.

Counting objects: 11, done.
Delta compression using 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (6/6), 1.27 KiB, done.
Total 6 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
   a7d0c3d..363be33  master -> master