Feature changed by: Bidossessi SODONON (bidossessi) Feature #308902, revision 2 Title: Configure SSSD via Yast openSUSE-11.3: Unconfirmed Priority Requester: Important Requested by: David Alston (dalston) Description: It would be great if we could configure the SSSD package (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 This is important if OpenSUSE is interested in being a significant presence in Enterprise environments. + 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. -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Andreas Jaeger (a_jaeger) Feature #308902, revision 4 Title: Configure SSSD via Yast - openSUSE-11.3: Unconfirmed + openSUSE-11.3: Rejected by (a_jaeger) + reject date: 2010-07-20 09:29:40 + reject reason: not done in time. Priority Requester: Important - openSUSE-11.4: Unconfirmed + openSUSE-11.4: Evaluation Priority Requester: Mandatory + Info Provider: (Novell) Requested by: David Alston (dalston) Description: It would be great if we could configure the SSSD package (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 - This is important if OpenSUSE is interested in being a significant + This is important if openSUSE is interested in being a significant presence in Enterprise environments. 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. -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Klaus Kämpf (kwk) Feature #308902, revision 7 Title: Configure SSSD via Yast openSUSE-11.3: Rejected by Federico Lucifredi (a_jaeger) reject date: 2010-07-20 09:29:40 reject reason: not done in time. Priority Requester: Important openSUSE-11.4: Evaluation Priority Requester: Mandatory - Info Provider: (Novell) Requested by: David Alston (dalston) Description: It would be great if we could configure the SSSD package (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 This is important if openSUSE is interested in being a significant presence in Enterprise environments. 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. -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Ralf Haferkamp (rhafer) Feature #308902, revision 11 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: Evaluation Priority Requester: Mandatory + Info Provider: (Novell) Requested by: David Alston (dalston) Description: It would be great if we could configure the SSSD package (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 This is important if openSUSE is interested in being a significant presence in Enterprise environments. + Relations: + - original request to include sssd (feature/id: 308900) + - related Feature (feature/id: 310176) + - More info about sssd (url: ) 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. -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Ralf Haferkamp (rhafer) Feature #308902, revision 13 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: Evaluation by project manager Priority Requester: Mandatory Requested by: David Alston (dalston) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (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) for local user/password - sync with either LDAP or Kerberos for offline authentication with Yast. - This is related to https://features.opensuse.org/308900 + 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 = <uri to LDAP server: ldap://ldap.server> + ldap_search_base = <LDAP Base DN> + l dap_schema = rfc2307bis + id_provider = ldap + chpass_provider = ldap + auth_provider = ldap + ldap_user_uuid = entryuuid + ldap_group_uuid = entryuuid + ldap_id_use_start_tls = <True|False> + cache_credentials = <True|False> + 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 = </path/to/hashed/cacerts/dir> + or + ldap_tls_cacert = </path/to/cacert/file> + 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 Relations: - original request to include sssd (feature/id: 308900) - related Feature (feature/id: 310176) - More info about sssd (url: ) 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) -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Ralf Haferkamp (rhafer) Feature #308902, revision 15 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: Evaluation by project manager Priority Requester: Mandatory Requested by: David Alston (dalston) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (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 ". + [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 = <uri to LDAP server: ldap://ldap.server> 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 = <True|False> cache_credentials = <True|False> 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 = </path/to/hashed/cacerts/dir> or ldap_tls_cacert = </path/to/cacert/file> 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 Relations: - original request to include sssd (feature/id: 308900) - related Feature (feature/id: 310176) - More info about sssd (url: ) 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) -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Ralf Haferkamp (rhafer) Feature #308902, revision 17 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: Evaluation by project manager Priority Requester: Mandatory Requested by: David Alston (dalston) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (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 = <uri to LDAP server: ldap://ldap.server> 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 = <True|False> cache_credentials = <True|False> 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 = </path/to/hashed/cacerts/dir> or ldap_tls_cacert = </path/to/cacert/file> 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: ) 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. -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Ralf Haferkamp (rhafer) Feature #308902, revision 19 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: Evaluation by project manager Priority Requester: Mandatory Requested by: David Alston (dalston) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering Manager: (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 = <uri to LDAP server: ldap://ldap.server> 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 = <True|False> cache_credentials = <True|False> 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 = </path/to/hashed/cacerts/dir> or ldap_tls_cacert = </path/to/cacert/file> 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. -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Jiří­ Suchomel (jsuchome) Feature #308902, revision 21 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 = <uri to LDAP server: ldap://ldap.server> 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 = <True|False> cache_credentials = <True|False> 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 = </path/to/hashed/cacerts/dir> or ldap_tls_cacert = </path/to/cacert/file> 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? -- openSUSE Feature: https://features.opensuse.org/308902

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 = <uri to LDAP server: ldap://ldap.server> 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 = <True|False> cache_credentials = <True|False> 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 = </path/to/hashed/cacerts/dir> or ldap_tls_cacert = </path/to/cacert/file> 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

Feature changed by: Jiří­ Suchomel (jsuchome) Feature #308902, revision 25 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 + openSUSE-11.4: Done 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 = <uri to LDAP server: ldap://ldap.server> 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 = <True|False> cache_credentials = <True|False> 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 = </path/to/hashed/cacerts/dir> or ldap_tls_cacert = </path/to/cacert/file> 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... #15: Ralf Haferkamp (rhafer) (2011-01-19 10:14:18) (reply to #14) 1. I agree that ldap-client in it's current form is already somewhat bloated. I only think, that if we create a separate sssd module nobody will find/use it. I am open to suggestions here. A short term fix could e.g. be to add a 4th Radio Button "LDAP + KRB5" to the RadioButtonGroup and turn the dialog into a multistep wizard, asking for the krb5 details after clicking "Ok" (resp. "Next" then). In the long run (for openSUSEn+1) we'd need a cleanup of the whole module I guess. E.g. by splitting out settings that are unrelated to NSS and PAM, like the parts that write settings for yast2-users' LDAP User Management. And by removing support for nss_ldap/pam_ldap (it's still to early for that) 2. sssd itself doesn't need /etc/krb5.conf, but it still makes sense to write /etc/krb5.conf (and install krb5-client) IMO. + #16: Jiří­ Suchomel (jsuchome) (2011-02-07 09:56:09) + So, the YaST support is done for 11.4. It is expected the users will + use yast2 ldap-client, where the SSSD is the default option. YaST + kerberos-client was also adapted, so that when sssd is already used, it + will not add krb5 configuration. + During development we've met some problems related to UI presentation + of this feature, but the clear solution would require deeper + redesigning of current YaST modules. So we should rethink it again for + SLE12 and next openSUSE version. -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Jiří­ Suchomel (jsuchome) Feature #308902, revision 27 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: Done 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 = <uri to LDAP server: ldap://ldap.server> 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 = <True|False> cache_credentials = <True|False> 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 = </path/to/hashed/cacerts/dir> or ldap_tls_cacert = </path/to/cacert/file> 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) - related bugreport (novell/bugzilla/id: 662734) https://bugzilla.novell.com/show_bug.cgi?id=662734 - More info about sssd (url: ) 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... #15: Ralf Haferkamp (rhafer) (2011-01-19 10:14:18) (reply to #14) 1. I agree that ldap-client in it's current form is already somewhat bloated. I only think, that if we create a separate sssd module nobody will find/use it. I am open to suggestions here. A short term fix could e.g. be to add a 4th Radio Button "LDAP + KRB5" to the RadioButtonGroup and turn the dialog into a multistep wizard, asking for the krb5 details after clicking "Ok" (resp. "Next" then). In the long run (for openSUSEn+1) we'd need a cleanup of the whole module I guess. E.g. by splitting out settings that are unrelated to NSS and PAM, like the parts that write settings for yast2-users' LDAP User Management. And by removing support for nss_ldap/pam_ldap (it's still to early for that) 2. sssd itself doesn't need /etc/krb5.conf, but it still makes sense to write /etc/krb5.conf (and install krb5-client) IMO. #16: Jiří­ Suchomel (jsuchome) (2011-02-07 09:56:09) So, the YaST support is done for 11.4. It is expected the users will use yast2 ldap-client, where the SSSD is the default option. YaST kerberos-client was also adapted, so that when sssd is already used, it will not add krb5 configuration. During development we've met some problems related to UI presentation of this feature, but the clear solution would require deeper redesigning of current YaST modules. So we should rethink it again for SLE12 and next openSUSE version. + #17: Jiří­ Suchomel (jsuchome) (2011-03-02 14:16:04) + Please, describe what would be needed for SLE11SP2. We could just use + the same solution which is already implemented for 11.4 (see comment + 16) which means, yast2-ldap-client configures sssd by default. + But we were also thinking about making some better approach in terms of + UI; currently all (including extra Kerberos setting) is placed into + yast2-ldap-client, and the module is quite crowded. The question is, if + UI redesign should be done for SP2 or we should save it for future. -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Jiří­ Suchomel (jsuchome) Feature #308902, revision 33 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: Done Priority Requester: Mandatory Info Provider: (Novell) Requested by: David Alston (dalston) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering 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 = <uri to LDAP server: ldap://ldap.server> 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 = <True|False> cache_credentials = <True|False> 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 = </path/to/hashed/cacerts/dir> or ldap_tls_cacert = </path/to/cacert/file> 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) - related bugreport (novell/bugzilla/id: 662734) https://bugzilla.novell.com/show_bug.cgi?id=662734 - More info about sssd (url: ) 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... #15: Ralf Haferkamp (rhafer) (2011-01-19 10:14:18) (reply to #14) 1. I agree that ldap-client in it's current form is already somewhat bloated. I only think, that if we create a separate sssd module nobody will find/use it. I am open to suggestions here. A short term fix could e.g. be to add a 4th Radio Button "LDAP + KRB5" to the RadioButtonGroup and turn the dialog into a multistep wizard, asking for the krb5 details after clicking "Ok" (resp. "Next" then). In the long run (for openSUSEn+1) we'd need a cleanup of the whole module I guess. E.g. by splitting out settings that are unrelated to NSS and PAM, like the parts that write settings for yast2-users' LDAP User Management. And by removing support for nss_ldap/pam_ldap (it's still to early for that) 2. sssd itself doesn't need /etc/krb5.conf, but it still makes sense to write /etc/krb5.conf (and install krb5-client) IMO. #16: Jiří­ Suchomel (jsuchome) (2011-02-07 09:56:09) So, the YaST support is done for 11.4. It is expected the users will use yast2 ldap-client, where the SSSD is the default option. YaST kerberos-client was also adapted, so that when sssd is already used, it will not add krb5 configuration. During development we've met some problems related to UI presentation of this feature, but the clear solution would require deeper redesigning of current YaST modules. So we should rethink it again for SLE12 and next openSUSE version. #17: Jiří­ Suchomel (jsuchome) (2011-03-02 14:16:04) Please, describe what would be needed for SLE11SP2. We could just use the same solution which is already implemented for 11.4 (see comment 16) which means, yast2-ldap-client configures sssd by default. But we were also thinking about making some better approach in terms of UI; currently all (including extra Kerberos setting) is placed into yast2-ldap-client, and the module is quite crowded. The question is, if UI redesign should be done for SP2 or we should save it for future. #18: Jiri Srain (jsrain) (2011-03-15 16:43:45) (reply to #17) Let's keep it as it is now, with one exception: Add information that SSSD is enabled to the Kerberos module to avoid confusion. + #19: Jiří­ Suchomel (jsuchome) (2011-03-18 11:34:34) (reply to #18) + Please note that important questions regarding SLE11SP2 were raised in + feature 310820 -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Lukas Ocilka (locilka) Feature #308902, revision 36 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: Done Priority Requester: Mandatory Requested by: David Alston (dalston) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering 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 = <uri to LDAP server: ldap://ldap.server> 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 = <True|False> cache_credentials = <True|False> 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 = </path/to/hashed/cacerts/dir> or ldap_tls_cacert = </path/to/cacert/file> 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. + References: + packages: yast2-ldap-client Relations: - original request to include sssd (feature/id: 308900) - related Feature (feature/id: 310176) - related bugreport (novell/bugzilla/id: 662734) https://bugzilla.novell.com/show_bug.cgi?id=662734 - More info about sssd (url: ) 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... #15: Ralf Haferkamp (rhafer) (2011-01-19 10:14:18) (reply to #14) 1. I agree that ldap-client in it's current form is already somewhat bloated. I only think, that if we create a separate sssd module nobody will find/use it. I am open to suggestions here. A short term fix could e.g. be to add a 4th Radio Button "LDAP + KRB5" to the RadioButtonGroup and turn the dialog into a multistep wizard, asking for the krb5 details after clicking "Ok" (resp. "Next" then). In the long run (for openSUSEn+1) we'd need a cleanup of the whole module I guess. E.g. by splitting out settings that are unrelated to NSS and PAM, like the parts that write settings for yast2-users' LDAP User Management. And by removing support for nss_ldap/pam_ldap (it's still to early for that) 2. sssd itself doesn't need /etc/krb5.conf, but it still makes sense to write /etc/krb5.conf (and install krb5-client) IMO. #16: Jiří­ Suchomel (jsuchome) (2011-02-07 09:56:09) So, the YaST support is done for 11.4. It is expected the users will use yast2 ldap-client, where the SSSD is the default option. YaST kerberos-client was also adapted, so that when sssd is already used, it will not add krb5 configuration. During development we've met some problems related to UI presentation of this feature, but the clear solution would require deeper redesigning of current YaST modules. So we should rethink it again for SLE12 and next openSUSE version. #17: Jiří­ Suchomel (jsuchome) (2011-03-02 14:16:04) Please, describe what would be needed for SLE11SP2. We could just use the same solution which is already implemented for 11.4 (see comment 16) which means, yast2-ldap-client configures sssd by default. But we were also thinking about making some better approach in terms of UI; currently all (including extra Kerberos setting) is placed into yast2-ldap-client, and the module is quite crowded. The question is, if UI redesign should be done for SP2 or we should save it for future. #18: Jiri Srain (jsrain) (2011-03-15 16:43:45) (reply to #17) Let's keep it as it is now, with one exception: Add information that SSSD is enabled to the Kerberos module to avoid confusion. #19: Jiří­ Suchomel (jsuchome) (2011-03-18 11:34:34) (reply to #18) Please note that important questions regarding SLE11SP2 were raised in feature 310820 -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Ralf Haferkamp (rhafer) Feature #308902, revision 39 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: Done Priority Requester: Mandatory Requested by: David Alston (dalston) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Engineering 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 = <uri to LDAP server: ldap://ldap.server> 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 = <True|False> cache_credentials = <True|False> 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 = </path/to/hashed/cacerts/dir> or ldap_tls_cacert = </path/to/cacert/file> 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. References: packages: yast2-ldap-client Relations: - original request to include sssd (feature/id: 308900) - related Feature (feature/id: 310176) - related bugreport (novell/bugzilla/id: 662734) https://bugzilla.novell.com/show_bug.cgi?id=662734 - More info about sssd (url: ) 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... #15: Ralf Haferkamp (rhafer) (2011-01-19 10:14:18) (reply to #14) 1. I agree that ldap-client in it's current form is already somewhat bloated. I only think, that if we create a separate sssd module nobody will find/use it. I am open to suggestions here. A short term fix could e.g. be to add a 4th Radio Button "LDAP + KRB5" to the RadioButtonGroup and turn the dialog into a multistep wizard, asking for the krb5 details after clicking "Ok" (resp. "Next" then). In the long run (for openSUSEn+1) we'd need a cleanup of the whole module I guess. E.g. by splitting out settings that are unrelated to NSS and PAM, like the parts that write settings for yast2-users' LDAP User Management. And by removing support for nss_ldap/pam_ldap (it's still to early for that) 2. sssd itself doesn't need /etc/krb5.conf, but it still makes sense to write /etc/krb5.conf (and install krb5-client) IMO. #16: Jiří­ Suchomel (jsuchome) (2011-02-07 09:56:09) So, the YaST support is done for 11.4. It is expected the users will use yast2 ldap-client, where the SSSD is the default option. YaST kerberos-client was also adapted, so that when sssd is already used, it will not add krb5 configuration. During development we've met some problems related to UI presentation of this feature, but the clear solution would require deeper redesigning of current YaST modules. So we should rethink it again for SLE12 and next openSUSE version. #17: Jiří­ Suchomel (jsuchome) (2011-03-02 14:16:04) Please, describe what would be needed for SLE11SP2. We could just use the same solution which is already implemented for 11.4 (see comment 16) which means, yast2-ldap-client configures sssd by default. But we were also thinking about making some better approach in terms of UI; currently all (including extra Kerberos setting) is placed into yast2-ldap-client, and the module is quite crowded. The question is, if UI redesign should be done for SP2 or we should save it for future. #18: Jiri Srain (jsrain) (2011-03-15 16:43:45) (reply to #17) Let's keep it as it is now, with one exception: Add information that SSSD is enabled to the Kerberos module to avoid confusion. #19: Jiří­ Suchomel (jsuchome) (2011-03-18 11:34:34) (reply to #18) Please note that important questions regarding SLE11SP2 were raised in feature 310820 #21: Jiří­ Suchomel (jsuchome) (2011-06-07 15:52:29) YaST part implemented in yast2-ldap-client-2.17.27 and submitted to SUSE:SLE-11-SP2:GA + #22: Ralf Haferkamp (rhafer) (2011-06-17 10:29:36) + sssd package submitted to SUSE:SLE-11-SP2:GA -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Ihno Krumreich (ihno) Feature #308902, revision 41 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: Done Priority Requester: Mandatory Requested by: David Alston (dalston) Product Manager: Federico Lucifredi (flucifredi) 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. + It would be great if we could configure the System Security Services + Daemon (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 = <uri to LDAP server: ldap://ldap.server> 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 = <True|False> cache_credentials = <True|False> 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 = </path/to/hashed/cacerts/dir> or ldap_tls_cacert = </path/to/cacert/file> 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. References: packages: yast2-ldap-client sssd Relations: - original request to include sssd (feature/id: 308900) - related Feature (feature/id: 310176) - related bugreport (novell/bugzilla/id: 662734) https://bugzilla.novell.com/show_bug.cgi?id=662734 - More info about sssd (url: ) 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... #15: Ralf Haferkamp (rhafer) (2011-01-19 10:14:18) (reply to #14) 1. I agree that ldap-client in it's current form is already somewhat bloated. I only think, that if we create a separate sssd module nobody will find/use it. I am open to suggestions here. A short term fix could e.g. be to add a 4th Radio Button "LDAP + KRB5" to the RadioButtonGroup and turn the dialog into a multistep wizard, asking for the krb5 details after clicking "Ok" (resp. "Next" then). In the long run (for openSUSEn+1) we'd need a cleanup of the whole module I guess. E.g. by splitting out settings that are unrelated to NSS and PAM, like the parts that write settings for yast2-users' LDAP User Management. And by removing support for nss_ldap/pam_ldap (it's still to early for that) 2. sssd itself doesn't need /etc/krb5.conf, but it still makes sense to write /etc/krb5.conf (and install krb5-client) IMO. #16: Jiří­ Suchomel (jsuchome) (2011-02-07 09:56:09) So, the YaST support is done for 11.4. It is expected the users will use yast2 ldap-client, where the SSSD is the default option. YaST kerberos-client was also adapted, so that when sssd is already used, it will not add krb5 configuration. During development we've met some problems related to UI presentation of this feature, but the clear solution would require deeper redesigning of current YaST modules. So we should rethink it again for SLE12 and next openSUSE version. #17: Jiří­ Suchomel (jsuchome) (2011-03-02 14:16:04) Please, describe what would be needed for SLE11SP2. We could just use the same solution which is already implemented for 11.4 (see comment 16) which means, yast2-ldap-client configures sssd by default. But we were also thinking about making some better approach in terms of UI; currently all (including extra Kerberos setting) is placed into yast2-ldap-client, and the module is quite crowded. The question is, if UI redesign should be done for SP2 or we should save it for future. #18: Jiri Srain (jsrain) (2011-03-15 16:43:45) (reply to #17) Let's keep it as it is now, with one exception: Add information that SSSD is enabled to the Kerberos module to avoid confusion. #19: Jiří­ Suchomel (jsuchome) (2011-03-18 11:34:34) (reply to #18) Please note that important questions regarding SLE11SP2 were raised in feature 310820 #21: Jiří­ Suchomel (jsuchome) (2011-06-07 15:52:29) YaST part implemented in yast2-ldap-client-2.17.27 and submitted to SUSE:SLE-11-SP2:GA #22: Ralf Haferkamp (rhafer) (2011-06-17 10:29:36) sssd package submitted to SUSE:SLE-11-SP2:GA -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Antoine Ginies (aginies) Feature #308902, revision 45 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: Done Priority Requester: Mandatory Requested by: David Alston (dalston) Product Manager: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: It would be great if we could configure the System Security Services Daemon (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 = <uri to LDAP server: ldap://ldap.server> 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 = <True|False> cache_credentials = <True|False> 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 = </path/to/hashed/cacerts/dir> or ldap_tls_cacert = </path/to/cacert/file> 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. References: packages: yast2-ldap-client sssd Relations: - original request to include sssd (feature/id: 308900) - related Feature (feature/id: 310176) - related bugreport (novell/bugzilla/id: 662734) https://bugzilla.novell.com/show_bug.cgi?id=662734 - More info about sssd (url: ) + Documentation Impact: + Security Guide, RN 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... #15: Ralf Haferkamp (rhafer) (2011-01-19 10:14:18) (reply to #14) 1. I agree that ldap-client in it's current form is already somewhat bloated. I only think, that if we create a separate sssd module nobody will find/use it. I am open to suggestions here. A short term fix could e.g. be to add a 4th Radio Button "LDAP + KRB5" to the RadioButtonGroup and turn the dialog into a multistep wizard, asking for the krb5 details after clicking "Ok" (resp. "Next" then). In the long run (for openSUSEn+1) we'd need a cleanup of the whole module I guess. E.g. by splitting out settings that are unrelated to NSS and PAM, like the parts that write settings for yast2-users' LDAP User Management. And by removing support for nss_ldap/pam_ldap (it's still to early for that) 2. sssd itself doesn't need /etc/krb5.conf, but it still makes sense to write /etc/krb5.conf (and install krb5-client) IMO. #16: Jiří­ Suchomel (jsuchome) (2011-02-07 09:56:09) So, the YaST support is done for 11.4. It is expected the users will use yast2 ldap-client, where the SSSD is the default option. YaST kerberos-client was also adapted, so that when sssd is already used, it will not add krb5 configuration. During development we've met some problems related to UI presentation of this feature, but the clear solution would require deeper redesigning of current YaST modules. So we should rethink it again for SLE12 and next openSUSE version. #17: Jiří­ Suchomel (jsuchome) (2011-03-02 14:16:04) Please, describe what would be needed for SLE11SP2. We could just use the same solution which is already implemented for 11.4 (see comment 16) which means, yast2-ldap-client configures sssd by default. But we were also thinking about making some better approach in terms of UI; currently all (including extra Kerberos setting) is placed into yast2-ldap-client, and the module is quite crowded. The question is, if UI redesign should be done for SP2 or we should save it for future. #18: Jiri Srain (jsrain) (2011-03-15 16:43:45) (reply to #17) Let's keep it as it is now, with one exception: Add information that SSSD is enabled to the Kerberos module to avoid confusion. #19: Jiří­ Suchomel (jsuchome) (2011-03-18 11:34:34) (reply to #18) Please note that important questions regarding SLE11SP2 were raised in feature 310820 #21: Jiří­ Suchomel (jsuchome) (2011-06-07 15:52:29) YaST part implemented in yast2-ldap-client-2.17.27 and submitted to SUSE:SLE-11-SP2:GA #22: Ralf Haferkamp (rhafer) (2011-06-17 10:29:36) sssd package submitted to SUSE:SLE-11-SP2:GA #23: Duncan Mac-Vicar (dmacvicar) (2013-03-05 17:46:24) Can this be marked as done for SLE12 already? -- openSUSE Feature: https://features.opensuse.org/308902

Feature changed by: Antoine Ginies (aginies) Feature #308902, revision 50 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: Done Priority Requester: Mandatory Requested by: David Alston (dalston) Product Manager: Federico Lucifredi (flucifredi) Partner organization: openSUSE.org Description: It would be great if we could configure the System Security Services Daemon (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 = <uri to LDAP server: ldap://ldap.server> 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 = <True|False> cache_credentials = <True|False> 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 = </path/to/hashed/cacerts/dir> or ldap_tls_cacert = </path/to/cacert/file> 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. References: packages: yast2-ldap-client sssd Relations: - original request to include sssd (feature/id: 308900) - related Feature (feature/id: 310176) - related bugreport (novell/bugzilla/id: 662734) https://bugzilla.novell.com/show_bug.cgi?id=662734 - More info about sssd (url: ) - ldap-client > auth-client (feature/id: 316349) Documentation Impact: Security Guide - concerning RN, see c#25. 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... #15: Ralf Haferkamp (rhafer) (2011-01-19 10:14:18) (reply to #14) 1. I agree that ldap-client in it's current form is already somewhat bloated. I only think, that if we create a separate sssd module nobody will find/use it. I am open to suggestions here. A short term fix could e.g. be to add a 4th Radio Button "LDAP + KRB5" to the RadioButtonGroup and turn the dialog into a multistep wizard, asking for the krb5 details after clicking "Ok" (resp. "Next" then). In the long run (for openSUSEn+1) we'd need a cleanup of the whole module I guess. E.g. by splitting out settings that are unrelated to NSS and PAM, like the parts that write settings for yast2-users' LDAP User Management. And by removing support for nss_ldap/pam_ldap (it's still to early for that) 2. sssd itself doesn't need /etc/krb5.conf, but it still makes sense to write /etc/krb5.conf (and install krb5-client) IMO. #16: Jiří­ Suchomel (jsuchome) (2011-02-07 09:56:09) So, the YaST support is done for 11.4. It is expected the users will use yast2 ldap-client, where the SSSD is the default option. YaST kerberos-client was also adapted, so that when sssd is already used, it will not add krb5 configuration. During development we've met some problems related to UI presentation of this feature, but the clear solution would require deeper redesigning of current YaST modules. So we should rethink it again for SLE12 and next openSUSE version. #17: Jiří­ Suchomel (jsuchome) (2011-03-02 14:16:04) Please, describe what would be needed for SLE11SP2. We could just use the same solution which is already implemented for 11.4 (see comment 16) which means, yast2-ldap-client configures sssd by default. But we were also thinking about making some better approach in terms of UI; currently all (including extra Kerberos setting) is placed into yast2-ldap-client, and the module is quite crowded. The question is, if UI redesign should be done for SP2 or we should save it for future. #18: Jiri Srain (jsrain) (2011-03-15 16:43:45) (reply to #17) Let's keep it as it is now, with one exception: Add information that SSSD is enabled to the Kerberos module to avoid confusion. #19: Jiří­ Suchomel (jsuchome) (2011-03-18 11:34:34) (reply to #18) Please note that important questions regarding SLE11SP2 were raised in feature 310820 #21: Jiří­ Suchomel (jsuchome) (2011-06-07 15:52:29) YaST part implemented in yast2-ldap-client-2.17.27 and submitted to SUSE:SLE-11-SP2:GA #22: Ralf Haferkamp (rhafer) (2011-06-17 10:29:36) sssd package submitted to SUSE:SLE-11-SP2:GA #23: Duncan Mac-Vicar (dmacvicar) (2013-03-05 17:46:24) Can this be marked as done for SLE12 already? #25: Karl Eichwalder (keichwa) (2014-08-28 10:28:09) AFAICS, yast support is redesigned for SLE 12 (ldap-client > auth- client; fate#316349?). This means you'd better do not add a release notes snippet here because it could appear in the RN 11 _and_ RN 12 documents, because both products are set to "done" here. -- openSUSE Feature: https://features.opensuse.org/308902