Re: [nssldap] Looking for support on nss_ldap issue

[nssldap [at] evilbrain.com]

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!