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 - [AAA] RHEVM does not sync automatically IPA user password incase of password change
Summary: [AAA] RHEVM does not sync automatically IPA user password incase of password ...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-extension-aaa-ldap
Version: 3.3.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
: 3.5.0
Assignee: Alon Bar-Lev
QA Contact: Ondra Machacek
URL:
Whiteboard: infra
Depends On:
Blocks: oVirt-AAA-LDAP rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2014-06-03 08:52 UTC by pagupta
Modified: 2019-03-22 07:16 UTC (History)
12 users (show)

Fixed In Version: ovirt-engine-3.5.0_rc1
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-02-11 18:12:47 UTC
oVirt Team: Infra
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2015:0174 normal SHIPPED_LIVE new package: ovirt-engine-extension-aaa-ldap 2015-02-11 22:40:02 UTC

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


Note You need to log in before you can comment on or make changes to this bug.