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.
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.
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
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.
(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.
(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.
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.