LDAP authentication confusion

[Jan Bramkamp]

On 15.07.2013 21:25, Mark Felder wrote:> On Mon, Jul 15, 2013, at 14:19,
Jan Bramkamp wrote:
>>
>> More than that. In my opinion it should be updated by replacing nss_ldap
>> and pam_ldap with nss-pam-ldapd which splits the job of both into a
>> shared daemon talking to the LDAP server and small stubs linked into the
>> NSS / PAM using process talking to the local daemon. This allows useable
>> timeout handling and client certificates with save permissions.
>>
>
> And if the daemon ever crashes, we can't login to our customer servers
> (assuming they nuked our local account because they have root access).
>
> That's the one issue I have with that daemon and why we haven't migrated
> to it. We should re-evaluate it, though.

In that case run nslcd in foreground with some kind of watchdog. Their
are several examples of this in the ports tree e.g. daemontools. So far
i never ran into this problem because nslcd on any of my production
systems. I prefer nss-pam-ldapd over nss_ldap + pam_ldap because:
- It doesn't link libldap, liblber, libsasl, libssl etc. into nearly
every process.
- It keeps the LDAP connection open reducing the latency (important with
DHE-RSA ciphersuites).
- It handles timeouts in one place instead of timing out in every process.

This doesn't change the fact that the nslcd daemon is a single point of
failure for all LDAP accesses over NSS and PAM.