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 | [log in to unmask]
Lawrence Berkeley National Laboratory |
Office: 50A-5104E | Mailstop 50A-5101
Phone: 510 486-4208 | Fax: 510 486-6808
|
