systemd-resolved and nss_ldap

[vovan@xxxxxxxx (Vlad)]

Mantas,

I'm aware of all the software you mentioned, but there's a few things to
consider:
- nslcd is quite old and personally I don't think it's the way to go
- the glibc's nscd wouldn't help in this case and will bring just
troubles (based as well on my experiences). More and more admins (since
at least a few years ago) are avoiding using nscd in complex network
environments, particularly because of problems with DNS caching in case
of failover, etc..

I thought about sssd as a replacement, but haven't had time to test this
combination yet (although I have quite a lot experiences with sssd). If
somebody has any experiences in this area, please share ;-)

Regards,
Vlad.

On 04/07/18 13:50, Mantas MikulÄ?nas wrote:
> On Wed, Jul 4, 2018 at 2:03 PM Lennart Poettering
> <lennart at poettering.net <mailto:lennart at poettering.net>> wrote:
>
>     I am pretty sure it's not the best design today that nss-ldap inserts
>     a complex, network facing piece of code into all kinds of system
>     processes the way it does, even the most benign ones such as
>     "ls". This is security sensitive stuff after all...
>
>
> There actually exist two modules both named 'libnss_ldap': the
> original one from PADL loads a LDAP client directly in-process, while
> the one from 'nslcd' (aka nss-pam-ldapd) uses a Unix socket connection
> to its own daemon (so it works the same way as nss-resolve). And yes,
> the one in nslcd should be used whenever possible.
>
> (I think glibc's nscd should also not be forgotten, since it offloads
> *all* modules into a single caching daemon. Would have protected
> against last year's glibc libnss_dns CVE, I'm sure.)
>
> -- 
> Mantas MikulÄ?nas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20180704/3fbfb871/attachment.html>