On Thursday 22 May 2008 3:45:44 pm you wrote: > Jeffrey D Anderson wrote: > > On Thursday 22 May 2008 11:47:28 am Jeffrey D Anderson wrote: > >> On Thursday 22 May 2008 8:20:22 am you wrote: > >>> On Thu, May 22, 2008 at 03:28:11PM +0100, Faye Gibbins wrote: > >>>> Hi, > >>>> > >>>> Has anything relating to how ldap uses ssl changed in the last couple > >>>> of days? > >>>> > >>>> In the last day or so our ldap servers (that are queried though SSL > >>>> and the nss_ldap libs) have stopped working properly. > >>>> > >>>> They do part of the job then die with broken pipe signals (as seen by > >>>> running strace on for example "su"). > >>>> > >>>> This has shown up on both 32 and 64 bit SL5.0 boxes. > >>> > >>> We're getting this as well since the update this mornig to > >>> nss_ldap-253-12.el5.x86_64. > >>> > >>> It looks like libnss_ldap.so.2 is now linked again SElinux. Is that > >>> part of the problem? > >>> > >>> -jkl > >> > >> I am getting this on SL5.0 and SL5.1. > >> > >> We use LDAP with TLS for authentication for dozens of workstations, and > >> it is totally broken at the moment. > >> > >> I've done a 'yum clean && yum update' to see if Troy's fixed packages > >> from this morning rectify the situation, but still nothing. > >> > >> The symptoms are that users cannot login. They type their password at > >> KDM or at a text VT, the password apparently is authenticated, but the > >> screen flashes and they are returned to the login screen. > >> Also, I cannot 'su' to any users. If I try, as root for example, > >> 'su SOMEUSER' I am just brought back to the root bash prompt. 'whoami' > >> verifies that I am still root, not su'd to SOMEUSER. > >> > >> finger and id both successfully lookup the user information, but for > >> some reason su, login, KDM, do not successfully log people in. I've > >> verified this on a number of different boxes. I've also rebooted the > >> LDAP server without solving the problem. > > > > Bad for to reply to myself, but I wanted to add that reverting to > > nss_ldap-253-5.el5.i386.rpm cleared up the problem for me, so there is > > definitely some kind of critical bug in the updated nss_ldap. > > Jeffrey, > > My thread is directly related to this bug, I have to change > ldaps://ldapserver in /etc/ldap.conf file to > > ldap://ldapserver > ssl start_tls > tls_checkpeer yes > > then, ldap query via nss_ldap is working again. > > Regards,
Hi: Thanks for the input, but unfortunately this does not address my problem. I'm already using TLS rather than ldaps:// Even if that were not the case, nss_ldap should support both methods, as long as the server is properly configured. In my case I believe that the ldap queries are succeeding, since finger and id both work. Since there are so many different ways a login can fail through X, I tried to simplify the situation. With the new nss_ldap installed: `rpm -q nss_ldap` -> nss_ldap-253-12.el5 A user attempts to login at a text console on a workstation that authenticates via LDAP with TLS. He enters his username and password. The screen flashes and the login prompt is redrawn. Here is the snippet from /var/log/secure relevant to this session: May 23 09:54:28 theorytest login: pam_unix(login:auth): authentication failure; logname= uid=0 euid=0 tty=tty1 ruser= rhost= user=anderson May 23 09:54:28 theorytest login: pam_unix(login:session): session opened for user anderson by (uid=0) May 23 09:54:28 theorytest login: pam_console(login:session): handler '/sbin/pam_console_apply' caught a signal 13 May 23 09:54:28 theorytest -- anderson: LOGIN ON tty1 BY anderson Here is /etc/ldap.conf on this box: host ldapserver.mydomain base dc=ldap-auth,dc=gov scope one ldap_version 3 pam_filter objectclass=posixaccount pam_login_attribute uid pam_member_attribute member pam_password md5 nss_base_passwd ou=People,dc=ldap-auth,dc=gov nss_base_shadow ou=People,dc=ldap-auth,dc=gov?one nss_base_group ou=Group,dc=ldap-auth,dc=gov pam_groupdn cn=theoryaccess,ou=Group,dc=ldap-auth,dc=gov ssl start_tls TLS_REQCERT allow TLS_CHECKPEER no nss_initgroups_ignoreusers root,ldap With nss_ldap-253-5.el everything works fine. The "pam_console_apply" signal 13 (broken pipe) is obviously at the core of the bug, but I don't know enough about pam to really understand what is going wrong. Just in case it is relevant, SELinux is turned off on all of these boxes. -- -------------------------------------------------------------- Jeffrey Anderson | [EMAIL PROTECTED] Lawrence Berkeley National Laboratory | Office: 50A-5104E | Mailstop 50A-5101 Phone: 510 486-4208 | Fax: 510 486-6808
