I have four Gentoo systems that I administer. Three of them are 64-bit one is 32-bit All have the same USE flags for nss_ldap (USE=kerberos sasl -debug) /etc/ldap.conf is identical on all systems (and symlinks to /etc/openldap/ldap.conf) All systems are correctly querying the LDAP server when using 'getent passwd' or any of the GUI tools for LDAP administration. The 64-bit Gentoo systems are unable to authenticate using LDAP. (nsswitch.conf does have the proper "passwd/group/shadow: files ldap" options) After turning up the verbosity of the debug log, and using wireshark to monitor the LDAP server's interfaces/ports, it appears that no connection attempt is being made by the 64-bit client machines. The LDAP server is not seeing any packets coming in from the 64 bit Gentoo machines when an authentication attempt is made. I have no issues with authenticating with the LDAP server with SLES 9, SLES 10, RHEL 5, Ubuntu 7.10, or OS X 10.5 (all 64-bit), or from the 32-bit gentoo system. A side note (that may or may not be at all related) is that ldapsearch -v -x -H ldap://ldap.foo.com -b "dc=foo,dc=com" on the 64-bit gentoo systems will exit with error 4: Size limit exceeded.
Additional note: I looked at bug #214750, and tried various combinations of USE flags and whether or not kerberos is installed - it didn't seem to make a difference in my case.
Ok, /etc/ldap.conf is NOT the same as /etc/openldap/ldap.conf They share some lines, but the /etc/ldap.conf has a lot more stuff in it. Put the original /etc/ldap.conf back, and then set it up properly. If the problem persists after that, reopen this bug.
I've fixed (I believe) the ldap.conf issue(s), and am still able to replicate most of the issue; I am now able to get ldapsearch working properly. Authentication, however, is still not working properly. My /etc/ldap.conf (sans comments,etc) is: uri ldap://ldap.foo.bar.com ldaps://ldap.foo.bar.com ldap_version 3 scope sub nss_base_passwd ou=People,dc=foo,dc=bar,dc=com?one nss_base_shadow ou=People,dc=foo,dc=bar,dc=com?one nss_base_group ou=Group,dc=foo,dc=bar,dc=com?one ssl start_tls tls_checkpeer no nss_reconnect_tries 4 nss_reconnect_sleeptime 1 nss_reconnect_maxsleeptime 16 nss_reconnect_maxconntries 2 My /etc/openldap/ldap.conf is: BASE dc=foo,dc=bar,dc=com URI ldap://ldap.foo.bar.com ldaps://ldap.foo.bar.com TLS_REQCERT allow I'm able to get full functionality with this configuration (ie. /etc/ldap.conf & /etc/openldap/ldap conf) on other distros; however on 64-bit Gentoo, if I try to login as user 'ldaptestuser', the OS returns "Unknown id: ldaptestuser" No attempt is made to contact the LDAP server (according to wireshark, listening to ports 389 & 636; I verified that the LDAP server was listening on these ports using `netstat -p -l --numeric-ports | grep slapd` 32-bit gentoo knows about the LDAP users, however it is unable to authenticate, claiming the password is bad. On both systems, getent returns the LDAP usernames, and an ldapsearch -ZZ -v -x -H ldap://ldap.foo.bar.com -b "dc=foo,dc=bar,dc=com" works as expected.
I've also just tried automounts. I've set up both the 'old' and 'new' styles of automountmaps, and nsswitch.conf is set up for "automount: ldap files" - and automount isn't getting its maps on 64-bit. It is getting its maps on 32-bit, however. Again, /etc/ldap.conf matches on the two systems, and /etc/openldap/ldap.conf matches on the two systems (but /etc/ldap.conf != /etc/openldap/ldap.conf as per comment #2.)
Go back some versions of nss_ldap to test. I can't reproduce this. Do you have any firewall stuff maybe?
No firewall at all between the client & the server. I've tried the following version(s) with no luck: 239-r1 249 253 258 259 My use flags are: USE="7zip X accessibility acl alsa apache2 async audiofile authfile bash-completion bzip2 cairo caps cdr curl dba dvd dvdr ecc eds emacs emul-linux-x86 encode esd exif expat ffmpeg fpx ftp gd gif glib gmp gnome graphviz gs gtk idn imagemagick imlib java jbig jpeg jpeg2k json kde kerberos lcms mad maildir math mhash mmap mng motif mozilla mp3 mpeg mysql nis odbc opengl pdf php png postgres qt3 qt3support quicktime samba sasl sdl sendfile server shaper sharedmem slang soap sockets socks5 softquota spell svg sysvipc tcl tcltk tiff tk truetype usb vhosts vim vim-pager vim-with-x webdav xfs xinerama xinetd xml xml2 xpm xv"
You mentioned using tcpdump on the server. I'd like you to do this: 1. ensure no other traffic is flowing client -> LDAP server on the LDAP port. 2. # tcpdump -i $INTERFACE -s 65535 -xX port ldap and host $SERVER 2>&1 | tee log.$BOX.tcp 3. (in parallel) # strace -ff getent -s ldap passwd 2>&1 | tee log.$BOX.strace Run it on both x86 and amd64 clients please, there shouldn't be any private password details in it, but if you're concerned thereof, you can email me the dumps instead. Tar+bz2 them first if you do. I'm at a conference this coming week, so sorry in advance about the delay.
Created attachment 149713 [details] Requested Captures getent has always worked fine (see 1st post); which makes the fact that it's not working with nss_ldap confusing. The first attachment is the 64-bit case. I've attached the traces for getent & tcpdump. Two things you should know: 1.) I've sanitized the DNS names (ie. changed something.com -> foo.bar) 2.) There are two sets of logs; one is when TLS is enabled, one with it disabled. TLS works fine - getent returns the expected values when using TLS. I turned it off for the dump as encrypted data isn't overly useful in this case. Now when I leave TCPdump running, and then try to log in as an LDAP user, there is zero communication happening with the server. /etc/nsswitch.conf is pretty boring: passwd: files ldap shadow: files ldap group: files ldap hosts: files dns services: db files networks: files dns protocols: db files rpc: db files ethers: db files netmasks: files netgroup: files bootparams: files automount: ldap files aliases: files netgroup: ldap [NOTFOUND=return] files (I've also tried copying the default nsswitch.ldap to nsswitch.conf; there's no difference in behavior)
Created attachment 149750 [details] Requested Captures The 32-bit case is... well, broken. 'getent -s ldap passwd' does one of two things: 1.) when nscd is running (on the 32 bit client), it segfaults, exiting with status 139 2.) when nscd is not running, getent runs for a while, then effectively halts without exiting. To add strangeness to the brew, running 'getent passwd' works fine - returning the info from /etc/passwd first, and then information from LDAP; the server is contacted, etc. And when I try to authenticate as an LDAP user, I am getting traffic captured by tcpdump; something that doesn't happen with 64-bit. If you'd like, I'll email that one to you.
Changing to INVALID - it turns out that nscd was running and caching the older config where there were no users to authenticate. Restarting nscd fixed the issue. (One disadvantage of very long uptimes, I imagine)
