Ugh, some people are going to read this wrong ... On Tue, Jul 29, 2014 at 2:41 PM, Bryan J Smith <[email protected]> wrote:
> Why no cover the more _practical_ experience if configuring System > Security Services Daemon (SSSD)? > Why not cover the more _practical_ *CLIENT* support experience ... SSSD replaces a lot of legacy (sometimes broken or very non-compliant with > various programs these days) PAM, NSS and other services. In fact, it uses > newer OpenLDAP libraries than older pam_ldap and related modules > ... > SSSD replaces a lot of legacy *MODULES* (sometimes broken or very non-compliant with various programs these days) *FOR* NSS, NSS and other services ... With that said, I should have provided a link as well. [1] Understand the sssd.conf syntax is very krb5.conf, ldap.conf, etc... like. And when it comes to PAM and NSS, it becomes a matter of just inserting "sss" in NSS, and "pam_sss" in PAM files. As I mentioned, anyone on any distro that uses SSSD seriously questions how they ever survived setting up network client authentication and directory access without it. This includes not only its very, very deterministic caching support, but some of its more unique features that are well outside of anything else, especially the direct AD support for IETF RFC2307 (IdM for UNIX, if installed/populated), and multi-domain and far better caching support than Winbindd in more recent releases (1.10+). I only wish there was a standard solution like "authconfig" in most distros when it comes to setting up all of the PAM details, whether using SSSD or not (while NSS is much easier). -- bjs [1] https://fedorahosted.org/sssd/wiki/HOWTO_Configure_1_0_2
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
