Red Hat Bugzilla – Bug 846029
ldap change passwd failed to be propagated to master in chain-update configuration
Last modified: 2012-08-06 13:12:38 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): sssd-client-1.8.0-32.el6.x86_64 sssd-1.8.0-32.el6.x86_64 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 centos-ds-admin-8.1.0-9.el5.centos.1.x86_64 centos-admin-console-8.1.0-2.el5.centos.2.noarch centos-ds-8.1.0-1.el5.centos.2.x86_64 centos-idm-console-1.0.1-1.el5.centos.2.x86_64 centos-ds-base-8.1.0-0.14.el5.centos.2.x86_64 idm-console-framework-1.1.3-9.el5.centos.2.noarch we have server side password policy enabled with ssd ldap related configuration like: id_provider=ldap auth_provider = ldap chpass_provider= ldap ldap_id_use_start_tls = true cache_credentials = false entry_cache_timeout = 5400 enumerate=FALSE 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 ldap_search_timeout=30 #default to 6 seconds ldap_network_timeout=6 #default to 5 seconds, when no ldap response recevied ldap_opt_timeout=10 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_account_expire_policy=rhds ldap_access_order = expire
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.
If you think, it's not the client os problem, then why RHEL5 works perfectly.
(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.
yes, that seems the case i guess chain-on-update cannot chain password extended operation.