vmware's (closed-source) products are linked against the very old 0.9.7-OpenSSL library products. I just emerged vmware-server-1.0.4 some hours ago. Authentication against LDAP-Server running under "modern Distributions" (using /etc/pam.d/vmware-authd using pam_ldap.so and/or nss_ldap) fails completely, because the ldap-libraries are compiled against OpenSSL 0.9.8, while vmware needs OpenSSL-0.9.7 and they don't like to talk to each other. Although the problem was discoverd already in the year 2006, vmware do not offer a solution for modern linux distributions (e.g. Gentoo). A detailed problem description is available from the VMware-Community-Forum: http://www.vmware.com/community/message.jspa?messageID=424898 As long as VMware Inc. is not willing/able to upgrade there products to use openssl version 0.9.8 the only possible currently "best" solution from customers' point of view is probably available here: http://darkness.codefu.org/wordpress/2007/07/28/283#comments I haven't tested the above solution myself (lack of time) But I will test it the next days. My Gentoo-based LDAP-Server and Services are running completely fine here. I'm using (Open)LDAP within apache, cyrus-imapd, sendmail, tomcat, suqid, sasl, clamav, spamass, nss_ldap/pam_ldap for shell access and so on, with no problem at all. If you do not have an ldap-infrastructure available, please let me know if I should test a bugfixed ebuild within my environment... Thanks a lot for the current ebuilds! Cheers Daniel Reproducible: Always Actual Results: Oct 21 22:12:14 tony slapd[21032]: conn=702 op=0 STARTTLS Oct 21 22:12:14 tony slapd[21032]: conn=702 op=0 RESULT oid= err=0 text= Oct 21 22:12:14 tony slapd[21032]: conn=702 fd=16 closed (TLS negotiation failure) Expected Results: Authentication vmware-authd using /etc/pam/vmware-authd using pam_ldap.so or even system-auth Portage 2.1.3.9 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.6.1-r0, 2.6.22-gentoo-r5 i686) ================================================================= System uname: 2.6.22-gentoo-r5 i686 Intel(R) Pentium(R) M processor 1.80GHz Timestamp of tree: Sun, 21 Oct 2007 00:50:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 3.2_p17 dev-java/java-config: 1.3.7, 2.0.33-r1 dev-lang/python: 2.3.5-r3, 2.4.4-r5 dev-python/pycrypto: 2.0.1-r6 dev-util/ccache: 2.4-r7 sys-apps/baselayout: 1.12.9-r2 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.24 virtual/os-headers: 2.6.22-r2 ACCEPT_KEYWORDS="x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium4 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" . .. ... .... .....
Sorry Daniel, I realize it's a bug, but you seem quite aware that it's an upstream bug. How would you like us to help? We can possibly add a note at the end of the ebuild, but I'm not sure there's a very clean way of ensuring that openldap is compiled against the old openssl and that it's only done when you need ldap support through pam (and not just that you happen to have openldap, openssl and vmware installed on the same box). If you can think of a solution, we'd welcome it, but I don't really see what we can do? I'm going to mark this bug as UPSTREAM because we've really got our hands tied here, but if you disagree, please reply here and we'll reopen it...
Created attachment 134144 [details] Build instructions bundled in a shell script, used to compile a special libldap.so liblber.so to support vmware-authd against pam_ldap I got vmware-server's vmware-authd (using gentoo's standard shipped pam_ldap) finally running. Therefore I adepted the idea and instructions behind the above mentioned blog posting. My changes: 1.) ssl config options are wrong, "--" should not be used (gentoo additionally uses "threads") 2.) CPPFLAGS are useless; used CFLAGS=... instead 3.) ln -s install command's are a little bit "reversed" or I didn't understood the paths ;-) I build the latest (openldap 2.3.38) libldap.so and liblber.so which are compiled using openssl 0.9.7m header files. Testing this build client-binaries explicitly using the openssl-0.9.7-libs starting the also compiled ldapsearch command line tool: LD_LIBRARY_PATH="PATH/TO/BUILD/LDAPLIBS" ldapsearch -x-Z -h "..." -D "..." -W worked like a charm! ;-) Attached to this message you'll find the shell script I used to compile libldap 2.3.38 against openssl and install the lib under vmware-server's library directory. After the script has been run I manually extended the vmware-authd's xinetd-configuration file "/etc/xinetd.d/vmware-authd" by this line: "env = LD_LIBRARY_PATH=/.../vmware/server/lib/lib/libldap-2.3.so.0:/.../vmware/server/lib/lib/liblber-2.3.so.0" Opend a console, entered login and password ----> BINGO! ;-) cat /etc/xinetd.d/vmware-authd # default: on # description: The VMware remote access authentification daemon, using # custom openldap libs compiled against openssl 0.9.7 to allow usage of # gentoo's ebuild-shipped "pam_ldap/nss_ldap" to authenticate/authorize # against ldap directories: service vmware-authd { disable = no port = 902 socket_type = stream protocol = tcp wait = no user = root server = /opt/vmware/server/sbin/vmware-authd env = LD_LIBRARY_PATH=/opt/vmware/server/lib/lib/libldap-2.3.so.0:/opt/vmware/server/lib/lib/liblber-2.3.so.0 type = unlisted } Open question: How can (should?!) this workaraound be integrated into vmware-server ebuild (perhaps by (miss)using "USE=ldap")??? Or should this bug report including this tested workaround and the shell-script, be linked in a message that the ebuild prints after emerge has been run? I leave this decision completely up to you. ;-) Best regards Daniel
Ok thanks. I think at best we're going to mention that people looking for LDAP/pam support should see this bug. I hope that's ok with you, thanks for contributing your work back to the community... 5:) I've reOPENed this until I add it into the overlay or portage itself.
Hey Daniel, Nice work. I've been on a similar crusade to get this fixed speaking with various product managers and such. I've been approaching it from another standpoint to attempt to get them to change the way they build their product. They need to prevent symbols from being exported for libraries that are being linked in as helper libs because when openssl 0.9.9 is released and vmware switches to 0.9.8, we'll have the same problem. Additionally, simply compiling openldap against Gentoo's latest 0.9.7 version (only one without security issues) didn't fix the problem for me. I had to actually compile it against the openssl libraries they provided. I'll check out the work you've done on this bug and report back. There was another similar bug to this about nss_ldap that was resolved but I can't remember what fixed it. (It could have been unrelated too.)
This is probably obsolete by now?
Actually, when Gentoo switches to 1.0.0 of OpenSSL, this issue will crop up again.
(In reply to comment #6) > Actually, when Gentoo switches to 1.0.0 of OpenSSL, this issue will crop up > again. > Yes. I'm reading gentoo-dev too... :| Bug 328355 should handle the slotting, so I'm resolving this one here (slightly unconventinally) as its duplicate... *** This bug has been marked as a duplicate of bug 328355 ***