[nssldap] netbsd nss_ldap & pam_ldap issues

[Aaron Turner <synfinatic [at] gmail.com>]

NetBSD 5.0.1, building nss_ldap 260 & pam_ldap 184 from source via packages.

here's my ldap.conf for reference:
uri ldaps://netauth.sv2.corp.company.com/
base dc=company,dc=com
ldap_version 3
rootbinddn cn=Manager,dc=company,dc=com
scope sub
timelimit 15
bind_timelimit 15
pam_filter objectClass=posixAccount
pam_groupdn cn=netsvn.sv2,ou=Machines,dc=company,dc=com
pam_member_attribute member
pam_password exop
nss_base_passwd     ou=Users,dc=company,dc=com?one
nss_base_shadow     ou=Users,dc=company,dc=com?one
nss_base_group      ou=Groups,dc=company,dc=com?one
nss_initgroups_ignoreusers
root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd,gdm
ssl on
tls_checkpeer yes
tls_cacertfile  /etc/pki/companyca.pem

This config is the same for my Linux boxes (other then timeouts).  I'm
having two issues:

1) For one of the nss_ldap queries (I believe it to be the second
group query... not sure why there are two, but there are two when I
turn off SSL) the server rejects the query and shuts down the
connection because the SSL Record MAC is invalid.  Wireshark confirms
this.  The odd thing is that all the other messages are fine and it
appears to always be the same LDAP query which has the problem.  This
results in the following messages:

 nss_ldap: could not get LDAP result - Timed out
 nss_ldap: could not get LDAP result - Can't contact LDAP server

This also has the nasty side-effect of delaying logins, hence me
lowering the timelimit to 15sec.

2) pam_ldap recognizes the pam_groupd and pam_member_attribute options
and even tells users they must be in said group to login via ssh, but
then lets them in anyways.  Here's my /etc/pam.d/sshd for reference:

# auth
auth            required        pam_nologin.so  no_warn
auth            sufficient      pam_ldap.so     try_first_pass
auth            sufficient      pam_skey.so     no_warn try_first_pass
auth            sufficient      pam_krb5.so     no_warn try_first_pass
auth            optional        pam_afslog.so   no_warn try_first_pass
# pam_ssh has potential security risks.  See pam_ssh(8).
#auth           sufficient      pam_ssh.so      no_warn try_first_pass
auth            required        pam_unix.so     no_warn try_first_pass

# account
account         required        pam_krb5.so
account         sufficient      pam_ldap.so
account         required        pam_login_access.so
account         required        pam_unix.so

# session
# pam_ssh has potential security risks.  See pam_ssh(8).
#session        optional        pam_ssh.so
session         sufficient      pam_ldap.so
session         required        pam_permit.so

# password
password        sufficient      pam_krb5.so     no_warn try_first_pass
password        sufficient      pam_ldap.so     try_first_pass
password        required        pam_unix.so     no_warn try_first_pass

Neither has any problems under Linux, so I'm fairly certain my
OpenLDAP server is behaving.  The ldap.conf is basically exactly the
same on my Linux boxes, but I had to tweak the pam.d/sshd file because
NetBSD's PAM doesn't work exactly like Linux.

Anyways, I looked in bugzilla and didn't find any tickets related to
either issue and the list archives seem to be down?
http://www.netsys.com/nssldap/

-- 
Aaron Turner
http://synfin.net/         Twitter: @synfinatic
http://tcpreplay.synfin.net/ - Pcap editing and replay tools for Unix & Windows
Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety.
    -- Benjamin Franklin
"carpe diem quam minimum credula postero"