Jeffrey D Anderson wrote: > 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,
I was overly optimistic, after I modified /etc/ldap.conf from ldap to ldaps with the latest nss_ldap-253-12, something/some machine would work but not the others unless you downgrade to nss_ldap-253-5. Oh, well! -- Zhi-Wei Lu Institute for Data Analysis and Visualization University of California, Davis (530) 752-0494
