On 23/01/16 00:23, Dr. Nikolaus Klepp wrote:
Does anybody know what sssd is good for? I was a bit surprised to see a whole
bunch of these sssd-something packages in debian, while I was searching for
sss. It's homepage says:
"SSSD is a system daemon. Its primary function is to provide access to identity
and authentication remote resource through a common framework that can provide
caching and offline support to the system. It provides PAM and NSS modules, and in
the future will D-BUS based interfaces for extended user information. It provides
also a better database to store local users as well as extended user data.
Documentation on configuring SSSD in Fedora or Red Hat Enterprise Linux is available
from the RHEL deployment guide. We also have a dedicated Documentation section
[...]"
Any idea?
a quick google suggests it is a Red Hat replacement for authentication using
ldap, maybe from 2012 or so, replacing PADL ...
here is a guide, loaded with aggression and with a mugshot to match:
http://www.couyon.net/blog/enabling-ldap-usergroup-support-and-authentication-in-centos-6
"Fedora/RedHat realized how terrible PADL software is, so they wrote their own
stuff; it’s called SSSD. It’s a terrible name, but overall it works pretty well.
Use SSSD, don’t use nslcd or anything that has pam_ldap or ldapd in the name.
Just use SSSD."
and so on, down to Step 7 ...
"That's it. Don't mess with nslcd.conf. Don't install any nss-pam-ldapd packages
or ldapd or anything. Just don't do it. Use the RedHat/Fedora stuff and tell
PADL to kiss your ass."
http://www.padl.com/Contents/OpenSourceSoftware.html
a comment on that post:
"NSLCD and SSSD both work. I disagree with the author about sudo with nslcd.
sudo will work fine with nslcd. It works fine with sssd also. There IS one
reason to use nslcd over sssd, if it applies to you. If you have any
applications that use the getent calls for user authentication, sssd will not
work. Period. Red Hat decided that it knows better than any other software
author, and dropped suooprt for getent shadow (from LDAP users) with sssd. A
plus for sssd is that is supports credential caching, however this is only good
is a user actually logged into the server while it was connected to LDAP, and we
actually turn this caching setting off for security reasons. We are actually
working with Red Hat to get some RADIUS support into sssd, and in a way that is
not completely retarded.
Other than the author's bias against nss_ldap, anyone else have any reason to go
with one other than the other? Both are actually pretty darn easy to get setup
and working correctly. Neither have very good documentation."
None of the above sound encouraging ... but that was 4 years ago, I have no idea
how well it works, how much it is better or worse than any other methods, how
deeply it is tied into everything else to do with the "red-hat way". I am
interested to hear reports, I am setting up something which will use ldap for
web authentication, and to maintain a directory of various bits and pieces
scattered around.
Simon
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
