Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 1104074

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-ldapAssignee: Alon Bar-Lev <alonbl>
Status: CLOSED ERRATA QA Contact: Ondra Machacek <omachace>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.3.0CC: alonbl, bazulay, gklein, iheim, lpeer, oourfali, pagupta, rbalakri, Rhev-m-bugs, sherold, yeylon, yzaslavs
Target Milestone: ---   
Target Release: 3.5.0   
Hardware: x86_64   
OS: Linux   
Whiteboard: infra
Fixed In Version: ovirt-engine-3.5.0_rc1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-11 18:12:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
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