Learn more about these different git repos.
Other Git URLs
While moving from ldap_client with pam_ldap to ldap_client with sssd I did setup sssd in a configuration where sssd runs in proxy mode and proxy requests via sssd to pam_ldap. This does work but fails as soon as password policy settings in ldap are active.
Example:
via policy settings the password is expired and the user must change his password. when using normal pam_ldap this does work and during login the user is asked to change his password or gets a warning of remaining grace logins.
When using sssd_proxy with pam_ldap the policy is ignored. Even if the password is expired the user is able to login without any notification that the password is expired. Even if all grace logins are exhausted the user still can login.
I have reviewed this in more details and think i found the issue.
When the normal pam_stack is used the auth,account and session stages are called within one pam "incarnation". The pam_ldap module looks like to receive the policy settings during the "auth" phase and does store them into pam variables. Later when the "account" phase does run it receives the policy settings via the pam_stack that was stored earlier via the "auth" stage. (This is IMHO what does happen)
With sssd_proxy things are litte bit different. sssd_proxy does spawn a "proxy_child" process for each pam stage.
If the child terminates with success
As the "pam session" does terminate in between there no stored data available for the account stage to read the policy settings. So the pam_ldap does assume there no policy settings at all and grant access.
/etc/sssd/sssd.conf:[[BR]]
[sssd][[BR]] config_file_version = 2[[BR]] services = nss,pam[[BR]] domains = proxy[[BR]] [nss][[BR]] [pam][[BR]] [domain/proxy][[BR]] debug_level = 10[[BR]] auth_provider = proxy[[BR]] id_provider = proxy[[BR]] proxy_lib_name = ldap[[BR]] proxy_pam_target = sssdproxyldap[[BR]] enumerate = true[[BR]] cache_credentials = false[[BR]] id_provider = proxy[[BR]] access_provider = proxy[[BR]] chpass_provider = proxy[[BR]] sudo_provider = none[[BR]] selinux_provider = none[[BR]] subdomains_provider = none[[BR]] autofs_provider = none[[BR]] hostid_provider = none[[BR]]
/etc/pam.d/sssdproxyldap:[[BR]]
auth required pam_ldap.so[[BR]] account required pam_ldap.so[[BR]] session required pam_ldap.so[[BR]] password required pam_ldap.so[[BR]]
With this settings even if the password is expired login is possible on the client without any issues.
Is this a supportable scenario at all ?
Is this fixable or broken by design ?
Which PAM module are you using?
Do you know what PAM variables does the module set?
I've searched the pam_ldap source code and I don't see any pam_getenv or pam_putenv variables honestly.
A more important question is -- why are you using the proxy provider at all? The proxy provider is not our primary focus, it's not something we test too extensively or something we wish to spend much time on..
I would strongly recommend to use the native LDAP provider instead.
Of course, I'll be glad to review patches. In the meantime, I'm filing this bug report into the "Deferred" bucket.
milestone: NEEDS_TRIAGE => SSSD Deferred
I'm not using myself the proxy module. It is a support question of one of our customer. I only want to now if it is was ever planned to support such a functionality. I have suggested our customer to use the nativ LDAP provider.
Fields changed
rhbz: => todo
Metadata Update from @varkoly: - Issue set to the milestone: SSSD Patches welcome
Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfill this request I am closing the issue as wontfix.
If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.
Thank you for understanding.
Metadata Update from @pbrezina: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
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/3482
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.