Description of problem: Users from an LDAP server are allowed to update their password in the web UI but the password change does not take effect. Old password remains. Version-Release number of selected component (if applicable): [root@qeblade41 ~]# rpm -qa |grep aeolus aeolus-conductor-0.13.8-1.el6cf.noarch aeolus-all-0.13.8-1.el6cf.noarch aeolus-conductor-doc-0.13.8-1.el6cf.noarch rubygem-aeolus-cli-0.7.1-1.el6cf.noarch aeolus-conductor-daemons-0.13.8-1.el6cf.noarch aeolus-configure-2.8.6-1.el6cf.noarch rubygem-aeolus-image-0.3.0-12.el6.noarch aeolus-configserver-0.4.10-2.el6cf.noarch How reproducible: 100% Steps to Reproduce: 1. config with LDAP server 2. login as LDAP user 3. Edit user, update password 4. logout and attempt login with new password Actual results: new password invalid. old password remains valid Expected results: new password should be valid. old password should be invalid Additional info:
Kicking this to 2.0 for design review.
This seems to be a sizeable limitation in LDAP integration. While I'm not a security expert, this may also have security impact given users cannot effectively change their passwords. I'm not sure we should move this out to 2.0. What is the feature statement with regards to LDAP support? Does it say read-only? Are we clear that LDAP data updates via conductor are not supported?
I believe we are clear that updates aren't supported. In the design discussion as far, we've been envisaging a situation where organisations are configuring CE to authenticate against an LDAP server which is a shared resource, providing authentication for multiple services, rather than something which is dedicated to CE. In that scenario, where changing the password in CE would also change the user's password to access email, shared network directories etc. etc., we don't want to be responsible for password management. Putting it another way, how many customers are likely to set up a new LDAP instance, specifically for CE, rather than configure CE to access an existing, shared LDAP server?
I confirmed with ruby gem ldap_fluff author jomara that support is read-only. We must disable password updates from CloudEngine when in LDAP mode. I understand this has been done in SystemEngine [aweiteka confirming]. We do indeed expect CE to use a shared LDAP server but I understand customers will assume each client can update user passwords. One edge case of note is that when password policy requires a password change CE authentication will fail until another client updates the LDAP user password. This limitation should be documented to ensure customer help desk support is aware.
(In reply to comment #5) > This limitation should be documented to ensure customer help desk support is > aware. Agreed, whether it's a unintentional limitation, or by design ... it would be nice to remove the temptation for changing the user password if configured to authenticate using LDAP. At the very least, updating the documentation to denote this behavior is advised. I don't see any mention of read-only in the current DRAFT 1.1 docs [1]. Angus, what's your opinion? Should the user password dialog be available if conductor is configured to authenticate using LDAP? [1] http://documentation-devel.engineering.redhat.com/docs/en-US/CloudForms/1.1/html/Installation_Guide/Configuring_LDAP_for_CloudForms_Cloud_Engine.html
Note, it appears that the password and email fields are hidden in System Engine when LDAP is enabled (refer to bug#820626). I believe we have precedence for the same behavior in Cloud Engine.
*** This bug has been marked as a duplicate of bug 859998 ***