lists.arthurdejong.org
RSS feed

[nssldap] Looking for support on nss_ldap issue

[Date Prev][Date Next] [Thread Prev][Thread Next]

[nssldap] Looking for support on nss_ldap issue



Hello,

I use 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.

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.

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.

The host acting as test case is using nss_ldap-253-5.el5 provided with CentOS 5.x.

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!