Ubuntu
sssd package

Cannot change LDAP password when ldap_pwd_policy=shadow

Bug #1415545 reported by lohapuk
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
sssd (Debian)
New
Unknown
sssd (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Package: sssd
Version: 1.8.6-0ubuntu0.3
Severity: Critical

Sssd refuses to change user's password when ldap_pwd_policy is set to shadow
and LDAP server has disabled password policies support.

Changing ldap_pwd_policy to none in sssd.conf fixes the problem but disables password expiration.

Enabling ppolicy module and configuring ppolicy overlay in slapd also fixes the problem.

Conditions:

- sssd.conf settings:

id_provider = ldap
access_provider = ldap
auth_provider = ldap
chpass_provider = ldap
ldap_pwd_policy = shadow

- user has shadowAccount attributes,
- slapd has ppolicy module disabled,
- slapd has ppolicy overlay disabled.

sssd debug output

(Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [sdap_pam_chpass_handler] (0x0040): starting password change request for user [srj].
(Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'LDAP_CHPASS'
(Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [be_resolve_server_done] (0x0200): Found address for server xxxx: [192.168.0.32] TTL 7200
(Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [fo_set_port_status] (0x0100): Marking port 636 of server 'xxxx' as 'working'
(Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [set_server_common_status] (0x0100): Marking server xxxx' as 'working'
(Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [simple_bind_send] (0x0100): Executing simple bind as: uid=srj,ou=People,dc=xx,dc=xx
(Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [simple_bind_done] (0x0200): Server returned no controls.
(Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [simple_bind_done] (0x0080): Bind result: Success(0), no errmsg set
(Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [sdap_auth4chpass_done] (0x0020): Changing shadow password attributes not implemented.
(Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 28, <NULL>) [Internal Error (Module is unknown)]
(Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [be_pam_handler_callback] (0x0100): Sending result [28][default]

slapd debug output:
> slap_access_allowed: read access granted by read(=rscxd)
=> access_allowed: read access granted by read(=rscxd)
=> access_allowed: result was in cache (memberUid)
=> access_allowed: result was in cache (memberUid)
=> access_allowed: result was in cache (memberUid)
=> access_allowed: result was in cache (memberUid)
=> access_allowed: result was in cache (memberUid)
=> access_allowed: result was in cache (memberUid)
=> access_allowed: result was in cache (memberUid)
=> access_allowed: result was in cache (memberUid)
=> access_allowed: result was in cache (memberUid)
=> access_allowed: result was in cache (memberUid)
=> access_allowed: result was in cache (memberUid)
=> access_allowed: result not in cache (modifyTimestamp)
=> access_allowed: read access to "cn=hamiltonbh,ou=Group,dc=thermeon,dc=eu" "modifyTimestamp" requested
=> dn: [3]
=> acl_get: [4] attr modifyTimestamp
=> acl_mask: access to entry "cn=hamiltonbh,ou=Group,dc=xxx,dc=eu", attr "modifyTimestamp" requested
=> acl_mask: to value by "cn=view,dc=xxx,dc=eu", (=0)
<= check a_dn_pat: cn=admin,dc=xxx,dc=eu
<= check a_dn_pat: cn=root,dc=xxx,dc=eu
<= check a_dn_pat: cn=root2,dc=xxx,dc=eu
<= check a_dn_pat: cn=view,dc=xxx,dc=eu
<= acl_mask: [4] applying read(=rscxd) (stop)
<= acl_mask: [4] mask: read(=rscxd)
=> slap_access_allowed: read access granted by read(=rscxd)
=> access_allowed: read access granted by read(=rscxd)
slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1
=> access_allowed: result not in cache (userPassword)
=> access_allowed: auth access to "uid=srj,ou=People,dc=xxx,dc=eu" "userPassword" requested
=> acl_get: [2] attr userPassword
=> acl_mask: access to entry "uid=srj,ou=People,dc=xxx,dc=eu", attr "userPassword" requested
=> acl_mask: to value by "", (=0)
<= check a_dn_pat: cn=admin,dc=xxx,dc=eu
<= check a_dn_pat: cn=root,dc=xxx,dc=eu
<= check a_dn_pat: cn=root2,dc=xxx,dc=eu
<= check a_dn_pat: uid=nobody,ou=people,dc=xxx,dc=eu
<= check a_dn_pat: anonymous
<= acl_mask: [5] applying auth(=xd) (stop)
<= acl_mask: [5] mask: auth(=xd)
=> slap_access_allowed: auth access granted by auth(=xd)
=> access_allowed: auth access granted by auth(=xd)
=> access_allowed: result not in cache (userPassword)
=> access_allowed: auth access to "cn=root2,dc=xxx,dc=eu" "userPassword" requested
=> acl_get: [2] attr userPassword
=> acl_mask: access to entry "cn=root2,dc=xxx,dc=eu", attr "userPassword" requested
=> acl_mask: to value by "", (=0)
<= check a_dn_pat: cn=admin,dc=xxx,dc=eu
<= check a_dn_pat: cn=root,dc=xxx,dc=eu
<= check a_dn_pat: cn=root2,dc=xxx,dc=eu
<= check a_dn_pat: uid=nobody,ou=people,dc=xxx,dc=eu
<= check a_dn_pat: anonymous
<= acl_mask: [5] applying auth(=xd) (stop)
<= acl_mask: [5] mask: auth(=xd)
=> slap_access_allowed: auth access granted by auth(=xd)
=> access_allowed: auth access granted by auth(=xd)
=> access_allowed: search access to "dc=xxx,dc=eu" "entry" requested

Tags: precise
Bug Watch Updater (bug-watch-updater)
Changed in sssd (Debian):
status: Unknown → New
Revision history for this message
Jakub Hrozek (jakub-hrozek) wrote :

Here is the most important part of the log:
(Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [sdap_auth4chpass_done] (0x0020): Changing shadow password attributes not implemented.

The functionality you request is simply not implemented. Because shadow attributes are inherently insecure and obsolete, I don't see us implementing this functionality ourselves. Patches welcome, though!

Revision history for this message
Stephen Gallagher (stephen-gallagherhome) wrote : Re: [Bug 1415545] Re: Cannot change LDAP password when ldap_pwd_policy=shadow

On Wed, 2015-01-28 at 19:19 +0000, Jakub Hrozek wrote:
> Here is the most important part of the log:
> (Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [sdap_auth4chpass_done] (0x0020): Changing shadow password attributes not implemented.
>
> The functionality you request is simply not implemented. Because shadow
> attributes are inherently insecure and obsolete, I don't see us
> implementing this functionality ourselves. Patches welcome, though!
>

To clarify, the reason this isn't implemented is that it means that the
password hashes have to be made available to the LDAP user from which
SSSD connects. This means that anyone with root access on an SSSD client
system would have access to all the password hashes on the server. This
is a serious security hole.

The password-policy extended operation is designed to solve this problem
by requiring users to use their own credentials to change the password
(through a mechanism that is also capable of applying security policy
such as minimum password length).

Revision history for this message
lohapuk (lohapuk) wrote :

The reason I believe it's a bug is remove

ldap_pwd_policy = shadow

and add ldap_chpass_update_last_change = true

Then the user can change their pass and it even updates the ShadowLastChange but you don't get password lock out on ShadowExpire etc.

Sasa Paporovic (melchiaros)
tags: added: precise
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in sssd (Ubuntu):
status: New → Confirmed
Revision history for this message
martin (martin-andersen) wrote :

I find this issue a bit curious. I certainly understand the reason not to make the pw hashes available to any and all SSSD clients – providing one has root access – as that is obviously inherently insecure.

However; since regular users are indeed able to change their passwords once logged in via 'passwd', as well as update their shadowLastChange value provided 'ldap_chpass_update_last_change = true' is set in sssd.conf, the question becomes how to trigger the password-change warning during login without reverting to actually setting 'ldap_pwd_policy = shadow' (unless that option is simply there for compatibility purposes, i.e, show the warning, then call a regular passwd change exec operation without involving passwd:chauthtok)

Or perhaps a slightly different approach; how to activate this behaviour using password-policy extended operation via sssd.conf? (the equivalent of setting 'pam_password exop' in ldap.conf)

There has to be a way to trigger just a password warning without making the whole hash available, provided shadowLastChange & shadowMax are available to be read on the client (which they are; at least in our setup, without exposing the hashes). There are undoubtedly many organizations with existing shadowLastChange values for all their users who would rather not perform intrusive changes to their ldap server setups to accomplish this.

Would certainly be interested in knowing whether anyone has made any progress getting this to work.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.