Re: [nssldap] Looking for support on nss_ldap issue

["Douglas E. Engert" <deengert [at] anl.gov>]

nssldap@evilbrain.com wrote:
> Sorry for the repost, but I really would like to find out how to fix 
> this as soon as possible.
>
> If I'm missing something or I'm wrong in the framing of this question in 
> any way, or if I'm asking in the wrong place, I welcome any feedback 
> about that as well.
>
> Hello,
>
>  I use pam_ldap+nss_ldap with CentOS 5.x, and the problem that I'm seeing
>  is that nss_ldap doesn't handle a failure of a server to handshake after
>  STARTTLS properly.  As such, it just hangs, causing an inability to
>  authenticate with and gain access to the host using any user in the LDAP
>  base.  I have not run tcpdump or strace to verify this, but that
>  description of the problem seems to be just as good as any I know of at
>  this point.  If there's any advice to determine the steps in more detail,
>  it would be appreciated.
>
>  This is the ldap.conf file that I have now:
>  uri                     ldap://ldaphost1 ldap://ldaphost2
>  base                    dc=example,dc=com
>  pam_filter              objectclass=posixAccount
>  pam_login_attribute     uid
>  pam_member_attribute    memberUid
>  pam_password            md5
>  ssl                     start_tls
>  tls_cacertdir           /etc/openldap/cacerts
>  tls_cacertfile          /etc/openldap/cacerts/cacert.pem
>  tls_reqcert             demand
>  bind_timelimit          5
>  nss_initgroups_ignoreusers root,ldap,named
>  bind_policy  soft
>
>  If slapd on ldaphost1 has "kill -SIGSTOP" invoked against it, a condition
>  that simulates other possible conditions where the server opens a TCP
>  connection but then doesn't have a conversation, the client hangs.
>  Again, if I'm wrong here, please chime in.
>
>  I have modified a perl script that someone else has written to handle a
>  similar failure condition to handle this condition that may also directly
>  relate to how LDAP over TLS works , but it is most definitely a kludgy
>  workaround and something that I don't want to deploy across hundreds of
>  servers.  It's just an alarm stanza wrapped around the logic to check
>  whether the LDAP server is alive to cause it to be skipped if it doesn't
>  respond in a few seconds.
>
>  The host acting as test case is using nss_ldap-253-5.el5 provided with 
> CentOS
>  5.x. (I have hosts that are 5.0-5.3 and have tried them on all versions)
>
>  I already looked this issue up and found that someone was having a similar
>  problem with CentOS 4.x and they resolved it by using host and port
>  parameters instead of uri.  There are two problems with that.
>
>  1. I believe that host and port are deprecated parameters, please 
> correct me
>  if I'm wrong.
>
>  2. I actually tried that and found that I had a similar problem where 
> there
>  was something of a conversation, but it dropped somewhere because sshd
>  dropped right after password entry, as if the conversation was disrupted
>  somehow.
>
>  Any advice would be greatly appreciated, thanks!

I don't have a CentOS system but we ran into issues with lost connections
and TLS. This sounds a lot like:

BUG #392: call do_close() if ldap_result() or ldap_parse_result()
          fails (before returning NSS_UNAVAIL)

and not having a timelimit set.

Fixes for these are in nss_ldap-265 announced on 11/6/2009

You may want to try using this newer version, if only to see if it fixes
your problem even if CentOS does not have this version yet.

Since this looks like issues with timeouts
You may also want to set:

idle_timelimit 20
timelimit 30

Good luck.

>

--

 Douglas E. Engert  <DEEngert@anl.gov>
 Argonne National Laboratory
 9700 South Cass Avenue
 Argonne, Illinois  60439
 (630) 252-5444