Bug 1095416

Summary:	Authentication fails when AdUserPassword is wrong
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Juan Hernández <juan.hernandez>
Component:	ovirt-engine	Assignee:	Yair Zaslavsky <yzaslavs>
Status:	CLOSED NOTABUG	QA Contact:	Pavel Stehlik <pstehlik>
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	3.4.0	CC:	acathrow, alonbl, bazulay, gklein, iheim, lpeer, oourfali, Rhev-m-bugs, yeylon, yzaslavs
Target Milestone:	---
Target Release:	3.4.1
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	infra
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-05-08 12:19:48 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:	1057368

Description Juan Hernández 2014-05-07 16:15:31 UTC

Before version 3.4 when a user tried to log in to webadmin, user portal or RESTAPI, the backend performed a search to find it in the LDAP directory, then it performed the actual authentication. For both the search and the authentication the backend used the a Kerberos ticket obtained using the password provided by the user.

Starting with version 3.4 the backend doesn't use the password provided by the user for the search, instead it uses the user and password stored in the configuration options AdUserName and AdUserPassword stored in the database. The password provided for the user is only used later, after the search, to perform a bind, and thus authenticate the user.

As a result of this change, if the password of the user stored in AdAdminPassword has changed (in the Kerberos server) but hasn't bee updated in the engine database, authentication of any user will fail with 3.4 where it succeeded with 3.3.

To workaround this just update the password in the engine database:

  # engine-manage-domains edit --domain=WHATEVER
  Password: ******

  # service ovirt-engine restart

This should be done whenever the password is changed in the Kerberos server.

Comment 1 Juan Hernández 2014-05-07 16:16:48 UTC

In my opinion we shouldn't change this behavior, but it may be worth to publish a release note explaining users that they should keep the AdUserPassword option up to date.

Comment 2 Barak 2014-05-07 21:25:36 UTC

This is indeed a change in behaviour, however doesn't look critical (as AdUserPassword should be updated in DB once changed  in Kerberos server)
Hence this is not a blocker, moving to 3.4.1

Comment 3 Alon Bar-Lev 2014-05-07 21:29:21 UTC

The new behavior is correct, user's credentials should not be used for ldap search, this is long standing issue in the legacy implementation.

The user/password provided within engine for the search are application user, which should be set as "password never expired", or modified when it is. It is quite obvious that if you provide a user for application use it should be handled this way.

The major issue is the order, the directory search should be done after user credentials check, this will be the case within the generic ldap provider.

I hope this is why need-info was set for me.

Comment 4 Alon Bar-Lev 2014-05-07 21:30:09 UTC

(In reply to Barak from comment #2)
> Hence this is not a blocker, moving to 3.4.1

Per my comment#3, I do not think there is anything to fix.

Comment 5 Yair Zaslavsky 2014-05-08 00:54:49 UTC

(In reply to Alon Bar-Lev from comment #3)
> The new behavior is correct, user's credentials should not be used for ldap
> search, this is long standing issue in the legacy implementation.
> 
> The user/password provided within engine for the search are application
> user, which should be set as "password never expired", or modified when it
> is. It is quite obvious that if you provide a user for application use it
> should be handled this way.
> 
> The major issue is the order, the directory search should be done after user
> credentials check, this will be the case within the generic ldap provider.
> 
> I hope this is why need-info was set for me.

I agree with Alon, and would like to add -
the current implementation of the ldap broker code mixes authentication and authorization.
As a result - authentication stage is done with the user+password provided by the user that has logged in.
After that stage -the authorization part is done with the user+password provided for the domain.
However, due to the mix I mentioned, the implementation of the authorization also performs an authentication (kerberos authentication) using the the user+password provided for the domain (AdUserName and AddUserPassword in vdc_options).
Fixing this and using the credentials of the user that tried to login will be wrong.

Comment 8 Yair Zaslavsky 2014-05-08 12:10:53 UTC

Gil, why did you mark it as regression? 3.4 actually fixed a wrong behavior here.
This is the correct way to work with the system, the fact you had a user that had an expired password for the domain is the wrong behavior.