RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 846029 - ldap change passwd failed to be propagated to master in chain-update configuration
Summary: ldap change passwd failed to be propagated to master in chain-update configur...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.3
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Stephen Gallagher
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-08-06 15:09 UTC by Dawei Wang
Modified: 2012-08-06 17:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-08-06 15:23:08 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

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.
Note You need to log in before you can comment on or make changes to this bug.