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