Bug 846029

Summary:	ldap change passwd failed to be propagated to master in chain-update configuration
Product:	Red Hat Enterprise Linux 6	Reporter:	Dawei Wang <daweiwang>
Component:	sssd	Assignee:	Stephen Gallagher <sgallagh>
Status:	CLOSED WONTFIX	QA Contact:	IDM QE LIST <seceng-idm-qe-list>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.3	CC:	grajaiya, jgalipea
Target Milestone:	rc
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-08-06 15:23:08 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Dawei Wang 2012-08-06 15:09:57 UTC

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

Comment 2 Stephen Gallagher 2012-08-06 15:23:08 UTC

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 15:41:59 UTC

If you think, it's not the client os problem, then why RHEL5 works perfectly.

Comment 4 Stephen Gallagher 2012-08-06 16:15:12 UTC

(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 17:12:38 UTC

yes, that seems the case i guess chain-on-update cannot chain password extended operation.