Sumit, please make a determination for SSSD 1.0

component: SSSD => PAM
description: If there is only an LDAP provider specified in the sssd.conf and no chpass_directive sssd fails with an obscure pam system error when a user tries to change the password.

A config like this seems reasonable enough:

[domain/LDAP]

id_provider = ldap
auth_provider = ldap
cache_credentials = true
ldap_tls_reqcert = never
ldap_user_search_base = dc=company,dc=com
ldap_group_search_base = ou=Groups,dc=company,dc=com
ldap_user_search_base = dc=company,dc=com
ldap_uri = ldap://ldap1.company.com ldap://ldap2.company.com ldap://ldap3.company.com

debug_level = 10

If LDAP is used without kerberos the chpass_provider should be implicit unless specified otherwise. If the IPA team disagrees and thinks it should stay explicit for the kerberos use case can the error be cleaned up or at very least the daemon throw a warning on startup?

I've updated the wiki (thanks simo) here:
https://fedorahosted.org/sssd/wiki/HOWTO_Configure?action=diff&version=24 => If there is only an LDAP provider specified in the sssd.conf and no chpass_directive sssd fails with an obscure pam system error when a user tries to change the password.

A config like this seems reasonable enough:
{{{
[domain/LDAP]

id_provider = ldap
auth_provider = ldap
cache_credentials = true
ldap_tls_reqcert = never
ldap_user_search_base = dc=company,dc=com
ldap_group_search_base = ou=Groups,dc=company,dc=com
ldap_user_search_base = dc=company,dc=com
ldap_uri = ldap://ldap1.company.com ldap://ldap2.company.com ldap://ldap3.company.com

debug_level = 10

}}}

If LDAP is used without kerberos the chpass_provider should be implicit unless specified otherwise. If the IPA team disagrees and thinks it should stay explicit for the kerberos use case can the error be cleaned up or at very least the daemon throw a warning on startup?

I've updated the wiki (thanks simo) here:
https://fedorahosted.org/sssd/wiki/HOWTO_Configure?action=diff&version=24
owner: somebody => sbose

Ok, I agree this behavior will surprise most users. I will add the following rule to the backend:

if auth_provider is given and chpass_provider not and the auth_provider also offers a chpass_provider this will be used.

I agree with this approach. Setting milestone to 1.0 RC

milestone: SSSD Deferred => SSSD 1.0 RC

Fields changed

tests: 0 => 1

A new patch allows to set auth_provider and access_provider implicitly, too. Details can be found in the man page changes in the second patch from https://fedorahosted.org/pipermail/sssd-devel/2009-October/000959.html.

If these patches are committed it would be nice if tests can cover the implicit setting of auth_provider and access_provider, too.

Fixed in:

dc71ede

740a925

fixedin: => 0.7.0
resolution: => fixed
status: new => closed

Fields changed

proposed: =>
tests: 1 => 0
testsupdated: 0 => 1

Fields changed

rhbz: => 0

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1262

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.