Bug 846029 - ldap change passwd failed to be propagated to master in chain-update configuration
ldap change passwd failed to be propagated to master in chain-update configur...
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
x86_64 Linux
unspecified Severity high
: rc
: ---
Assigned To: Stephen Gallagher
Depends On:
  Show dependency treegraph
Reported: 2012-08-06 11:09 EDT by Dawei Wang
Modified: 2012-08-06 13:12 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2012-08-06 11:23:08 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Dawei Wang 2012-08-06 11:09:57 EDT
Description of problem:
We have redhat/centos directory server in chaining-update configuration. The sssd client is on the slave. When change password in os, the password change is reflected in the slave but failed to propagate to the master.

We tested the password change on RHEL5, and it was properly propagated to the master.

Version-Release number of selected component (if applicable):

How reproducible:
password change with sssd-ldap configuration, the sssd-ldap is pointed to the slave of ldap server(centos ds configured as chaining-update configuration).

Steps to Reproduce:
1. login as a non-root user
2. try to change password with change passwd
3. verify the new password in both slave and master ldap server, and the password is changed in slave but not in master
Actual results:

Expected results:
Password changed in both master and slave directory 

Additional info: 
Directory server version

we have server side password policy enabled with ssd ldap related configuration like:

auth_provider = ldap
chpass_provider= ldap
ldap_id_use_start_tls = true
cache_credentials = false
entry_cache_timeout = 5400
ldap_search_base = dc=example,dc=com
ldap_uri = ldap://ldapserver.stg.example.com
ldap_chpass_uri = ldap://ldapserver.stg.example.com
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_tls_reqcert = allow

ldap_default_bind_dn = cn=proxyagent,ou=profile,dc=example,dc=com
ldap_default_authtok_type = password
ldap_default_authtok = secret

#timeout default to 30 when enumerate is true, 5 when enumerate is false
#default to 6 seconds
#default to 5 seconds, when no ldap response recevied

ldap_user_search_base= ou=people,dc=example,dc=com
ldap_group_search_base = ou=groups, dc=example,dc=com
ldap_netgroup_search_base = ou=netgroup, dc=example,dc=com
ldap_sudo_search_base = ou=SUDoers, dc=example,dc=com
#none is using server side policy
ldap_pwd_policy =none

ldap_access_order =  expire
Comment 2 Stephen Gallagher 2012-08-06 11:23:08 EDT
Bugs against CentOS packages should not be submitted to the Red Hat Bugzilla. Please file them at http://bugs.centos.org

Furthermore, this bug is irrelevant to SSSD. If the password-change succeeded against the slave LDAP server (and can be viewed there), then the issue can only be with replication. The client cannot impact this in any way.

Closing this bug as WONTFIX because the issue is in centos-ds, which is not a Red Hat Enterprise Linux package.
Comment 3 Dawei Wang 2012-08-06 11:41:59 EDT
If you think, it's not the client os problem, then why RHEL5 works perfectly.
Comment 4 Stephen Gallagher 2012-08-06 12:15:12 EDT
(In reply to comment #3)
> If you think, it's not the client os problem, then why RHEL5 works perfectly.

At a guess, I'd say you're probably using pam_ldap on RHEL 5 using the less-secure method of writing the password attribute directly on a password-change. SSSD requires the use of the (more secure) password-change extended-operation, which you may not have configured properly with replication.
Comment 5 Dawei Wang 2012-08-06 13:12:38 EDT
yes, that seems the case i guess chain-on-update cannot chain password extended operation.

Note You need to log in before you can comment on or make changes to this bug.