Feature changed by: Jiří Suchomel (jsuchome)
Feature #308902, revision 23
Title: Configure SSSD via Yast
openSUSE-11.3: Rejected by Andreas Jaeger (a_jaeger)
reject date: 2010-07-20 09:29:40
reject reason: not done in time.
Priority
Requester: Important
openSUSE-11.4: Implementation
Priority
Requester: Mandatory
Info Provider: (Novell)
Requested by: David Alston (dalston)
Product Manager: (Novell)
Product Manager: (Novell)
Project Manager: (Novell)
Engineering Manager: (Novell)
Developer: (Novell)
Technical Contact: (Novell)
Partner organization: openSUSE.org
Description:
It would be great if we could configure the SSSD package (
http://fedoraproject.org/wiki/Features/SSSD (http://fedoraproject.org/wiki/Features/SSSD)
) for local user/password sync with either LDAP or Kerberos for offline
authentication with Yast.
This is related to https://features.opensuse.org/308900 (../308900)
This is important if openSUSE is interested in being a significant
presence in Enterprise environments.
SSSD configuration
sssd's main config file is /etc/sssd/sssd.conf. It is in .ini Format
and documented in the sssd.conf(5) man page. It made up of the multiple
sections.
[sssd] section: The "domains" setting should be un-commented and set to
the special domain "default" for now. The "services" setting should
have the value "nss, pam". Everything else can be left untouched here
for now.
The "[nss]" and "[pam]" sections can be taken as shipped in the
package. Make sure that "filter_groups" and "filter_users" in the
"[nss]" section contains "root".
The rest of the settings are done in the "[domain/default]" section
(create one if it does not exist yet). For a plain LDAP setup the
section should have the following settings:
ldap_uri =
ldap_search_base = <LDAP Base DN>
ldap_schema = rfc2307bis
id_provider = ldap
chpass_provider = ldap
auth_provider = ldap
ldap_user_uuid = entryuuid
ldap_group_uuid = entryuuid
ldap_id_use_start_tls =
cache_credentials =
This flag is used to enable/disable offline authentication. I guess we
need to add a checkbox in the yast2 module for that. Similar to what
the samba-client module has.
ldap_tls_cacertdir =
or
ldap_tls_cacert =
Note, that sssd requires to use SSL/TLS when it is configureed to do
LDAP authentication. The "ldap_id_use_start_tls" setting is only meant
for the NSS part of sssd.
In a mixed Kerberos/LDAP setup the following changes are needed in the
[domain/default] section:
* Set "auth_provider" and "chpass_provider" to "krb5"
* Set "krb5_kdcip" to the hostname of the kerberos kdc
* Set "krb5_realm" to kerberos realm
Additionally to the above settings, the YaST module needs to:
1) Install sssd and it's dependencies
2) Add "sss" to the passwd and group databases in nsswitch.conf
3) Run pam_config to enable the sss PAM module
4) enable the sssd daemon to be started at bootup
5) start sssd
6) invalidate the nscd caches
Note: The /etc/ldap.conf and /etc/openldap/ldap.conf files still need
to written when sssd is used. As things like autofs or sudo still read
their configuration from there.
Relations:
- original request to include sssd (feature/id: 308900)
- related Feature (feature/id: 310176)
- More info about sssd (url: )
- related bugreport (novell/bugzilla/id: 662734)
https://bugzilla.novell.com/show_bug.cgi?id=662734
Discussion:
#1: Bidossessi SODONON (bidossessi) (2010-02-04 16:19:02)
I discovered the existence of this package through the hermes feed, and
i must say this is a MAJOR feature that should be included as soon as
it is declared stable.
I use Gonicus' Gosa for my users' accounts, and i had to fallback to
local because our network is a bit flaky and users would be locked out
of their machines time and time again (mandated wireless and lots of
power outages).
SSSD (or any equivalent) would mean the end of my remote user-
management nightmares in a multi-site all-openSUSE network.
I would strongly recommend it be reviewed.
#6: Ralf Haferkamp (rhafer) (2010-11-10 14:17:51)
One remaining question here is whether we want YaST to support both
types of setup or if to switch to sssd completely. I just checked how
this is handled in Fedora 14 currently. And it seems that they support
both types of setups in their GUI tools, depending on what packages are
installed in the system.
* If the sssd package is installed in the system (it seems to be in
their default installation), sssd is configured.
* If nss-pam-ldapd (which is kind of a successor to nss_ldap/pam_ldap,
we also have packages for that) is installed they configure that.
* If none of the above packages is installed (e.g. you choose a minimal
installation) they suggest to install nss-pam-ldapd. (Which is kind of
strange)
(IMO leaving support for nss_ldap/pam_ldap inplace in the yast2-ldap-
client module for now is a good idea. Provided that is doesn't create
too much effort. I'll add some details about what the sssd setup looks
like here next.)
Setting needinfo to aj@novell.com to give his point of view here.
#7: Andreas Jaeger (a_jaeger) (2010-11-10 14:34:54) (reply to #6)
We currently have some hacks in glibc due to nss_ldap usage. I would
prefer to remove those hacks but you have to tell me whether it makes
sense to support both or not. So, I'm in favor of moving to sssd
completely but you have to tell us whether we really need
nss_ldap/pam_ldap.
#8: Ralf Haferkamp (rhafer) (2010-11-22 14:26:57) (reply to #7)
I think we should support both types as sssd is not a complete 1:1
replacement for nss_ldap/pam_ldap it misses some of nss_ldap/pam_ldaps
flexiblity (like support for other databases than passwd and group).
Additionally sssd pulls in quite some dependencies, people not using
this advance features of sssd (like offline caching and kerberos
support) might not be too happy about that.
Ideally we should to what Fedora did. Use the nss-pam-ldapd suite as an
complete replacement for nss_ldap/pam_ldap (This would help us to get
rid of the glibc hacks we have for nss_ldap). But default to sssd
because of its broader feature set. I just think we don't have the
resources to do that (as nss-pam-ldapd is not a complete drop in
replacement for nss_ldap and pam_ldap as well, though it comes close)
#9: Ralf Haferkamp (rhafer) (2010-11-22 14:49:00)
Grmbl, I somehow messed up the formatting of the feature's description.
Hopefully that's fixed now again.
#10: Jiří Suchomel (jsuchome) (2010-12-17 11:07:12)
yast2-ldap-client-2.20.1 package, with sssd switched on by default, is
ready for testing in Factory repository.
#11: Ralf Haferkamp (rhafer) (2011-01-18 13:43:53) (reply to #10)
Update: I did some testing recently and reported some bugs. After those
were fixed yast2-ldap-client (currently 2.20.6) seems to work
reasonable well for pure LDAP setups.
I didn't however find any option to enable kerberos authentication with
sssd. Is that one still missing or didn't I look hard enough?
#12: Jiří Suchomel (jsuchome) (2011-01-18 15:39:17) (reply to #11)
If kerberos authentication is configured via yast2-kerberos-client,
yast2-ldap-client should take it into account while saving.
Is that wrong?
#13: Ralf Haferkamp (rhafer) (2011-01-18 16:14:33) (reply to #12)
Yes, there are some issues with that. sssd can act as a kerberos client
itself, i.e. it doesn't need pam_krb5 to be configured. The
configuration changes I mention in the description of this feature
should be enough to make sssd use kerberos (instead of LDAP) for
authentication. Even though the combined sssd/pam_krb5 setup that is
currently created seems to work, it is very awkward and some essential
features (e.g. offline authentication) are lost.
We should really have an option to setup sssd's builtin kerberos
authentication (inside yast-ldap-client).
+ #14: Jiří Suchomel (jsuchome) (2011-01-19 08:07:33) (reply to #13)
+ So you mean that 1. ldap-client should ask for those kerberos specific
+ data (realm, kdc) for sssd? Isn't it creating little too much
+ confusion? I did not realize you mean this, otherwise I'd probably
+ stick to the idea of having extra module for sssd (extra UI, using the
+ inner parts of ldap and kerberos)...
+ 2. Kerberos options still need to be written to /etc/krb5.conf, right?
+ Only the pam module is different...
--
openSUSE Feature:
https://features.opensuse.org/308902