|Summary:||[AAA] RHEVM does not sync automatically IPA user password incase of password change|
|Product:||Red Hat Enterprise Virtualization Manager||Reporter:||pagupta|
|Component:||ovirt-engine-extension-aaa-ldap||Assignee:||Alon Bar-Lev <alonbl>|
|Status:||CLOSED ERRATA||QA Contact:||Ondra Machacek <omachace>|
|Version:||3.3.0||CC:||alonbl, bazulay, gklein, iheim, lpeer, oourfali, pagupta, rbalakri, Rhev-m-bugs, sherold, yeylon, yzaslavs|
|Fixed In Version:||ovirt-engine-3.5.0_rc1||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2015-02-11 18:12:47 UTC||Type:||Bug|
|oVirt Team:||Infra||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
|Bug Depends On:|
|Bug Blocks:||1063095, 1142923, 1156165|
Description pagupta 2014-06-03 08:52:16 UTC
Description of problem: When Customer is changing domain user password in IPA. Password change does not sync automatically to RHEVM. We get below errors in log: Error: exception message: Integrity check on decrypted field failed (31) - PREAUTH_FAILED Version-Release number of selected component (if applicable): RHEVM 3.3 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: We get error in logs(engine.log): Error: exception message: Integrity check on decrypted field failed (31) - PREAUTH_FAILED Expected results: RHEVM should be able to sync the changes password automatically without doing 'service ovirt-engine restart' Additional info:
Comment 4 Yair Zaslavsky 2014-06-05 07:10:48 UTC
in 3.4 you can set using manage-domains a URL to change the password in case expired but i understand this is not exactly the case here. In addition we currently don't support that, Alon - what are your thoughts here?
Comment 5 Alon Bar-Lev 2014-06-05 08:35:40 UTC
The new LDAP provider will encourage not using kerberos as authentication phase, hence this problem will not exist.
Comment 8 Alon Bar-Lev 2014-06-22 10:02:07 UTC
This bug will not happen if we use ldap bind in order to authenticate, I am closing this as part of the new ldap implementation.
Comment 10 Ondra Machacek 2014-09-01 17:40:43 UTC
(In reply to Alon Bar-Lev from comment #8) > This bug will not happen if we use ldap bind in order to authenticate, I am > closing this as part of the new ldap implementation. if I understand this bz correctly, it's about changing password in runtime, without engine restart. When using ldap bind, the old password from config is still used. How can ldap bind help here? User still have to change password and restart engine.
Comment 11 Alon Bar-Lev 2014-09-01 17:44:23 UTC
(In reply to Ondra Machacek from comment #10) > (In reply to Alon Bar-Lev from comment #8) > > This bug will not happen if we use ldap bind in order to authenticate, I am > > closing this as part of the new ldap implementation. > > if I understand this bz correctly, it's about changing password in runtime, > without engine restart. > > When using ldap bind, the old password from config is still used. > How can ldap bind help here? User still have to change password and restart > engine. as far as I understand the bug is about the end-user password, not the search user.
Comment 12 Ondra Machacek 2014-09-01 19:53:44 UTC
But for such use case is sign-out / sign-in with new password enough.
Comment 13 Alon Bar-Lev 2014-09-01 19:56:51 UTC
(In reply to Ondra Machacek from comment #12) > But for such use case is sign-out / sign-in with new password enough. right. in the past (3.3) the user that used for search was the user that used for login, so I suspect something was wrong in this regard. in >=3.4 and especially with the new ldap provider (as it does not use kerberos at all) this will not happen.
Comment 14 Ondra Machacek 2014-09-02 08:05:50 UTC
Hi Pankaj, is this bugzilla about search user or end user? Thanks.
Comment 18 errata-xmlrpc 2015-02-11 18:12:47 UTC
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2015-0174.html