Date: Tue, 10 Feb 2009 22:08:00 -0800 From: Arjun Singh <arjun810@gmail.com> To: freebsd-questions@freebsd.org Subject: Re: nss_ldap SSL/TLS problems.. Message-ID: <35a7e0160902102208g423b8506q1038bdbbaed8a254@mail.gmail.com> In-Reply-To: <20090210210034.GD10513@hal.rescomp.berkeley.edu> References: <35a7e0160902100435h273627e7g4037b8af5c7bcd80@mail.gmail.com> <20090210210034.GD10513@hal.rescomp.berkeley.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Thanks for the advice. I tried to see if I could get nscd to solve anything, but it seems to just hide the problem, and not completely. With nscd enabled, the first login fails. After that, it's fine.. I get the following in auth.log corresponding with the failed first login (with the correct pw): Feb 10 22:03:23 new-hkn sshd[59371]: nss_ldap: could not search LDAP server - Server is unavailable Feb 10 22:03:23 new-hkn sshd[59371]: fatal: login_get_lastlog: Cannot find account for uid 10000 Feb 10 22:03:23 new-hkn sshd[59371]: syslogin_perform_logout: logout() returned an error On Tue, Feb 10, 2009 at 1:00 PM, Chris Cowart <ccowart@rescomp.berkeley.edu>wrote: > Arjun Singh wrote: > > I'm trying to set up an ldap server on FreeBSD 7.1-RELEASE. > > > > I installed all of the latest versions of openldap24-server, > > openldap24-client, nss_ldap, and pam_ldap. > > > > When I do any sort of ldapsearch or 'getent passwd' or anything, > everything > > works perfectly. The only time I have trouble is when I'm logging in via > > SSH..then it gets really weird. > > > > 1.) When I log in as a user in LDAP only and give the incorrect password > > first and then supply the correct password, everything works fine. If the > > user is in wheel, I can sudo. > > 2.) When I log in as the same user and give only the correct password the > > first time, it hangs for roughly 45 seconds and then lets me in. Even > though > > this user is in wheel, it says that the user is not in the sudoers file. > > > > Here are the log messages I get in auth.log that correspond to the events > > above: > > > > sshd[54031]: pam_ldap: error trying to bind as user "uid=user..(cut)..." > > (Invalid credentials) # This is the incorrect pw > > sshd[54029]: error: PAM: authentication error for user from localhost > > #Incorrect pw > > sshd[54032]: nss_ldap: could not search LDAP server - Server is > unavailable > > # correct pw > > sshd[54029]: Accepted keyboard-interactive/pam for user from localhost > port > > 32935 ssh2 #correct pw > > > > When I enter just the right password, the first time, I get this in the > log: > > > > sshd[54047]: Accepted keyboard-interactive/pam for user from localhost > port > > 51972 ssh2 > > sshd[54050]: nss_ldap: could not get LDAP result - Can't contact LDAP > server > > > > Again, when SSL/TLS are disabled, I get normal log output and none of the > > weird stuff above.. > > > > I turned on debugging in nss_ldap.conf and found that each time I gave > only > > the correct password (corresponding with the 45 second hang) I found this > in > > the debug output: > > > > ...bunch of normal looking output... > > ldap_chkResponseList ld 0x801b31480 msgid 5 all 0 > > ldap_chkResponseList returns ld 0x801b31480 NULL > > ldap_int_select > > read1msg: ld 0x801b31480 msgid 5 all 0 > > ber_get_next > > TLS trace: SSL3 alert write:fatal:bad record mac <--- what is the cause > of > > this? > > ldap_free_connection 1 0 > > ldap_free_connection: actually freed > > ldap_err2string > > ldap_result ld 0x801b31480 msgid 5 > > wait4msg ld 0x801b31480 msgid 5 (timeout 30000000 usec) > > wait4msg continue ld 0x801b31480 msgid 5 all 0 > > ** ld 0x801b31480 Connections: > > ** ld 0x801b31480 Outstanding Requests: > > Empty > > ld 0x801b31480 request count 0 (abandoned 0) > > ** ld 0x801b31480 Response Queue: > > Empty > > > > I get the above regardless of whether I'm using start_tls or ssl. > > > > If you have any insight, it'd be really useful. I've spent tons of time > > scouring lists for help and haven't found anything yet.. > > I don't have any more insight into the problem other than to say we've > had some similar issues in our environment. Initial password-based > logins do not have groups initialized, but SSH key logins and /bin/login > logins have groups initialized successfully. > > We were piloting nscd on some of our 7.0 boxes. It turns out that > enabling nscd was a successful workaround. We have since enabled it on > the rest of our 7.0 installations. > > Anyone out there have ideas? > > -- > Chris Cowart > Network Technical Lead > Network & Infrastructure Services, RSSP-IT > UC Berkeley >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?35a7e0160902102208g423b8506q1038bdbbaed8a254>