Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

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-ldap	Assignee:	Alon Bar-Lev <alonbl>
Status:	CLOSED ERRATA	QA Contact:	Ondra Machacek <omachace>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.3.0	CC:	alonbl, bazulay, 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:
Embargoed:
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