nss_ldap SSL/TLS problems..
Locked
 
|
|
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.. 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 |
attachment0 (851 bytes) |
|
|
On 02/10/2009 10:08 PM, Arjun Singh wrote:
> 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 It appears to be a bug when using nss_ldap with RELENG_7, as I have been unable to reproduce the issue on machines running 6.2-RELEASE and 6.3-RELEASE, regardless of the version of OpenLDAP. In my environment, the machines use pam_krb5 for authentication, so the problem is definitely not related to pam_ldap. Have you filed a problem report? -- Benjamin Lee http://www.b1c1l1.com/ |
|
|
On 02/11/2009 04:20 PM, Benjamin Lee wrote:
> On 02/10/2009 10:08 PM, Arjun Singh wrote: >> 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 > [...] > > It appears to be a bug when using nss_ldap with RELENG_7, as I have been > unable to reproduce the issue on machines running 6.2-RELEASE and > 6.3-RELEASE, regardless of the version of OpenLDAP. In my environment, > the machines use pam_krb5 for authentication, so the problem is > definitely not related to pam_ldap. Have you filed a problem report? I was able to work around the issue by removing pthread_atfork detection from the configure script. Specifically: blee@dot /usr/ports/net/nss_ldap/work/nss_ldap-264 $ diff -u configure.in{.orig,} --- configure.in.orig 2009-02-13 01:56:31.000000000 -0800 +++ configure.in 2009-02-13 01:56:58.000000000 -0800 @@ -230,7 +230,6 @@ AC_CHECK_FUNCS(gethostbyname) AC_CHECK_FUNCS(nsdispatch) AC_CHECK_LIB(pthread_nonshared, main) -AC_CHECK_FUNCS(pthread_atfork) AC_CHECK_FUNCS(pthread_once) AC_CHECK_FUNCS(ether_aton) AC_CHECK_FUNCS(ether_ntoa) I assume, then, that the defect is related to the change from libkse to libthr in RELENG_7. Does anybody have any further insight into this issue? -- Benjamin Lee http://www.b1c1l1.com/ |
Loading...
| Powered by Nabble | Edit this page |