[ovirt-users] Re: LDAP Authentication issues

Dear All,
Process of database "fixing" is required because adding system permissions to
the "Everyone" group is a one-way process that causes many problems and there is
no way to rescue from the GUI, only options are to restore from backup or rebuild the
permissions database.
The next issue, is that CPU Profiles are locked out to even the SuperUser - so creating a
VM with the SuperUser account with reset permissions is denied:
User doesn't have permissions to assign the cpu profile Default with id
58ca604e-01a7-003f-01de-000000000250 to VMs.
I consider that to be a bug, personally, as a SuperUser should have access to everything
by definition.
To solve this in the mean time, i need to know the object_type_id of a cpu profile to
manually reassign permissions to it (you can't control CPU profile permissions in the
GUI either, only view).
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. callum@well.ox.ac.uk<mailto:callum@well.ox.ac.uk>
On 12 Jun 2018, at 06:44, Roy Golan
<rgolan@redhat.com<mailto:rgolan@redhat.com>> wrote:
On Tue, 12 Jun 2018 at 02:24 Donny Davis
<donny@fortnebula.com<mailto:donny@fortnebula.com>> wrote:
I am happy to help where I can. I would also not recommend tinkering around in the
database, but I am happy to hear you have it all running. :)
Everything you should every be doing in the engine is available via the API/UI. Just some
general advice.
On Mon, Jun 11, 2018 at 9:31 AM, Callum Smith
<callum@well.ox.ac.uk<mailto:callum@well.ox.ac.uk>> wrote:
Dear All & Donny,
Thank you for the clarifications, very useful indeed.
A note for future users who go down this path and dont want to restore or reinstall:
Cleaning out the `permissions` table in the database and restoring the defaults will solve
the issue, but you need to restore the SuperUser permission on the admin@internal
account:
Learning from here:
https://www.ovirt.org/develop/developer-guide/action-permissions-overview/
Clean out your `roles_groups` and `permissions`
DELETE FROM `permissions`;
DELETE FROM `roles_groups`;
Restore the defaults:
https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/dat...https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/dat...
Re-assign the SuperUser role to the admin@internal user:
Either:
https://github.com/oVirt/ovirt-engine/blob/master/packaging/bin/ovirt-eng...
Or just go straight into your localhost psql on your engine, replacing information as
appropriate:
Get your external_id from the users table and use it in the function:
SELECT external_id FROM `users` WHERE `name` = 'admin' AND `domain` =
'internal-authz';
select
attach_user_to_role('admin','internal-authz','*','#external_id#','SuperUser');
Regards,
Callum
I think the root cause here is that you are trying to login to the webadmin and not the vm
portal. User are authorized to login to the web admin
only if they have a role of type 'admin'. And UserRole is a 'user' type.
So the solution is not the give SuperUser for all those users, this is just a workaround.
If you want to know for sure, go to Administration - Configure - Roles.
So ask yourself why users need access to the webadmin at all. If they need admin
permission assign them an appropriate role on the DC or the cluster.
If not, they use the VM portal.
Having said all that, if nothing helps and the db needs 'fixing' (I doubt it
though) then this is a bug.
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. callum@well.ox.ac.uk<mailto:callum@well.ox.ac.uk>
On 11 Jun 2018, at 11:57, Donny Davis
<donny@fortnebula.com<mailto:donny@fortnebula.com>> wrote:
https://lists.ovirt.org/pipermail/users/2015-January/030981.html
This is the thread where I discussed a bit of the permissions thing. I am sure things have
changed since 3.5.1, but should get you down the right path.
On Mon, Jun 11, 2018 at 6:54 AM, Callum Smith
<callum@well.ox.ac.uk<mailto:callum@well.ox.ac.uk>> wrote:
Yes, in process of trying to fix/identify things - need to undo this.
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. callum@well.ox.ac.uk<mailto:callum@well.ox.ac.uk>
On 11 Jun 2018, at 11:48, Donny Davis
<donny@fortnebula.com<mailto:donny@fortnebula.com>> wrote:
did you add system permissions to the everyone group?
On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith
<callum@well.ox.ac.uk<mailto:callum@well.ox.ac.uk>> wrote:
Happy for you to link me a guide, googlefu is failing me.
How do i get around this "It's not allowed to remove system permissions assigned
to built-in Everyone group" - to remove permissions erroneously added.
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. callum@well.ox.ac.uk<mailto:callum@well.ox.ac.uk>
On 11 Jun 2018, at 11:38, Donny Davis
<donny@fortnebula.com<mailto:donny@fortnebula.com>> wrote:
You can create a profile that has the proper permissions to allow what you are looking
for, and then assign that profile to the groups you wish.
I wrote a post on this quite a while back on how to setup oVirt to appear to be
multi-tenant.
Happy to see you don't have an ldap issue :)

This will be a problem for us to now create group permissions for all
100+ groups since Everyone === No-one. -sigh-

On Mon, Jun 11, 2018 at 6:34 AM, Callum Smith
<callum@well.ox.ac.uk<mailto:callum@well.ox.ac.uk>> wrote:
Ah, this appears to be an issue with the proxy - setting up the spice proxy as indicated
in the guides is causing this issue, and likely will need support.
https://www.ovirt.org/documentation/admin-guide/chap-Proxies/
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. callum@well.ox.ac.uk<mailto:callum@well.ox.ac.uk>
On 11 Jun 2018, at 11:29, Callum Smith
<callum@well.ox.ac.uk<mailto:callum@well.ox.ac.uk>> wrote:
Ok, the user now logs in! This will be a problem for us to now create group permissions
for all 100+ groups since Everyone === No-one. -sigh-
A new issue, when in the VM portal as the LDAP user, i get HTTP basic auth login prompts,
and a "Authorization expired" error, then a page reload. Nothing in the logs
seem to indicate an issue.
Regards,
Callum
--
Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. callum@well.ox.ac.uk<mailto:callum@well.ox.ac.uk>
On 11 Jun 2018, at 11:26, Donny Davis
<donny@fortnebula.com<mailto:donny@fortnebula.com>> wrote:
Try giving your user system permissions as a superuser and see if it goes away.
I wouldn't leave it like that, but it will help isolate your issue. I don't think
you have an ldap issue... the log entry is telling you that user has no permissions