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:
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?
The new LDAP provider will encourage not using kerberos as authentication phase, hence this problem will not exist.
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.
(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.
(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.
But for such use case is sign-out / sign-in with new password enough.
(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.
Hi Pankaj, is this bugzilla about search user or end user? Thanks.
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