[ovirt-users] Re: LDAP Authentication issues

2018-06-12 Thread Callum Smith
Dear All,

Seems the required element for the CPU Profile to work is in roles_groups table:

insert into roles_groups (role_id, action_group_id) VALUES 
('def00017----def00017', '1668');

Whether the action_group_id is install-specific or not is unclear, but the role 
UUID for "CPUOperator" should be standard.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 12 Jun 2018, at 09:47, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

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-0250 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. cal...@well.ox.ac.uk

On 12 Jun 2018, at 06:44, Roy Golan 
mailto:rgo...@redhat.com>> wrote:



On Tue, 12 Jun 2018 at 02:24 Donny Davis 
mailto:do...@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 
mailto:cal...@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/data/00600_insert_permissions.sql
https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/data/00700_insert_roles_groups.sql

Re-assign the SuperUser role to the admin@internal user:
Either: 
https://github.com/oVirt/ovirt-engine/blob/master/packaging/bin/ovirt-engine-role.sh
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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:57, Donny Davis 
mailto:do...@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 
mailto:cal...@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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:48, Donny Davis 
mailto:do...@fortnebula.com>> wrote:

did you add system permissions to the everyone group?


[ovirt-users] Re: LDAP Authentication issues

2018-06-12 Thread Callum Smith
Yes indeed

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 12 Jun 2018, at 10:18, Roy Golan 
mailto:rgo...@redhat.com>> wrote:



On Tue, 12 Jun 2018 at 11:48 Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
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-0250 to VMs.


I consider that to be a bug, personally, as a SuperUser should have access to 
everything by definition.

Is that user is admin@internal?

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. cal...@well.ox.ac.uk

On 12 Jun 2018, at 06:44, Roy Golan 
mailto:rgo...@redhat.com>> wrote:



On Tue, 12 Jun 2018 at 02:24 Donny Davis 
mailto:do...@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 
mailto:cal...@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/data/00600_insert_permissions.sql
https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/data/00700_insert_roles_groups.sql

Re-assign the SuperUser role to the admin@internal user:
Either: 
https://github.com/oVirt/ovirt-engine/blob/master/packaging/bin/ovirt-engine-role.sh
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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:57, Donny Davis 
mailto:do...@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 
mailto:cal...@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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:48, Donny Davis 
mailto:do...@fortnebula.com>> wrote:

did you add system permissions to the everyone group?

On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith 
mailto:cal...@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 

[ovirt-users] Re: LDAP Authentication issues

2018-06-12 Thread Roy Golan
On Tue, 12 Jun 2018 at 11:48 Callum Smith  wrote:

> 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-0250 to VMs.
>
>

> I consider that to be a bug, personally, as a SuperUser should have access
> to everything by definition.
>
> Is that user is admin@internal?

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. cal...@well.ox.ac.uk
>
> On 12 Jun 2018, at 06:44, Roy Golan  wrote:
>
>
>
> On Tue, 12 Jun 2018 at 02:24 Donny Davis  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 
>> 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/data/00600_insert_permissions.sql
>>>
>>> https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/data/00700_insert_roles_groups.sql
>>>
>>> Re-assign the SuperUser role to the admin@internal user:
>>> Either:
>>> https://github.com/oVirt/ovirt-engine/blob/master/packaging/bin/ovirt-engine-role.sh
>>> 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. cal...@well.ox.ac.uk
>>>
>>> On 11 Jun 2018, at 11:57, Donny Davis  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 
>>> 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. cal...@well.ox.ac.uk

 On 11 Jun 2018, at 11:48, Donny Davis  wrote:

 did you add system permissions to the everyone group?

 On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith 
 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
>

[ovirt-users] Re: LDAP Authentication issues

2018-06-12 Thread Callum Smith
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-0250 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. cal...@well.ox.ac.uk

On 12 Jun 2018, at 06:44, Roy Golan 
mailto:rgo...@redhat.com>> wrote:



On Tue, 12 Jun 2018 at 02:24 Donny Davis 
mailto:do...@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 
mailto:cal...@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/data/00600_insert_permissions.sql
https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/data/00700_insert_roles_groups.sql

Re-assign the SuperUser role to the admin@internal user:
Either: 
https://github.com/oVirt/ovirt-engine/blob/master/packaging/bin/ovirt-engine-role.sh
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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:57, Donny Davis 
mailto:do...@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 
mailto:cal...@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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:48, Donny Davis 
mailto:do...@fortnebula.com>> wrote:

did you add system permissions to the everyone group?

On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith 
mailto:cal...@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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:38, Donny Davis 
mailto:do...@fortnebula.com>> wrote:

You can create a profile that has 

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Roy Golan
On Tue, 12 Jun 2018 at 02:24 Donny Davis  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 
> 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/data/00600_insert_permissions.sql
>>
>> https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/data/00700_insert_roles_groups.sql
>>
>> Re-assign the SuperUser role to the admin@internal user:
>> Either:
>> https://github.com/oVirt/ovirt-engine/blob/master/packaging/bin/ovirt-engine-role.sh
>> 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. cal...@well.ox.ac.uk
>>
>> On 11 Jun 2018, at 11:57, Donny Davis  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 
>> 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. cal...@well.ox.ac.uk
>>>
>>> On 11 Jun 2018, at 11:48, Donny Davis  wrote:
>>>
>>> did you add system permissions to the everyone group?
>>>
>>> On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith 
>>> 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. cal...@well.ox.ac.uk

 On 11 Jun 2018, at 11:38, Donny Davis  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 
 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. cal...@well.ox.ac.uk
>
> On 11 Jun 2018, at 11:29, Callum Smith  wrote:
>
> Ok, the user now logs in! This will be a problem for us to 

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Donny Davis
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  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/data/00600_insert_permissions.sql
> https://github.com/oVirt/ovirt-engine/blob/master/
> packaging/dbscripts/data/00700_insert_roles_groups.sql
>
> Re-assign the SuperUser role to the admin@internal user:
> Either: https://github.com/oVirt/ovirt-engine/blob/
> master/packaging/bin/ovirt-engine-role.sh
> 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
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
> On 11 Jun 2018, at 11:57, Donny Davis  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 
> 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. cal...@well.ox.ac.uk
>>
>> On 11 Jun 2018, at 11:48, Donny Davis  wrote:
>>
>> did you add system permissions to the everyone group?
>>
>> On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith 
>> 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. cal...@well.ox.ac.uk
>>>
>>> On 11 Jun 2018, at 11:38, Donny Davis  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 
>>> 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. cal...@well.ox.ac.uk

 On 11 Jun 2018, at 11:29, Callum Smith  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. cal...@well.ox.ac.uk

 On 11 Jun 2018, at 11:26, Donny Davis  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
 >The user callum@Biomedical 

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Callum Smith
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/data/00600_insert_permissions.sql
https://github.com/oVirt/ovirt-engine/blob/master/packaging/dbscripts/data/00700_insert_roles_groups.sql

Re-assign the SuperUser role to the admin@internal user:
Either: 
https://github.com/oVirt/ovirt-engine/blob/master/packaging/bin/ovirt-engine-role.sh
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

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:57, Donny Davis 
mailto:do...@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 
mailto:cal...@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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:48, Donny Davis 
mailto:do...@fortnebula.com>> wrote:

did you add system permissions to the everyone group?

On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith 
mailto:cal...@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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:38, Donny Davis 
mailto:do...@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 
mailto:cal...@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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:29, Callum Smith 
mailto:cal...@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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:26, Donny Davis 
mailto:do...@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
>The user callum@Biomedical Research Computing is not authorized to perform 
>login

On Mon, Jun 11, 2018 at 6:23 AM, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear Donny,

No, though the user shows the permissions inherited from the Everyone group:

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk


[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Donny Davis
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  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. cal...@well.ox.ac.uk
>
> On 11 Jun 2018, at 11:48, Donny Davis  wrote:
>
> did you add system permissions to the everyone group?
>
> On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith 
> 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. cal...@well.ox.ac.uk
>>
>> On 11 Jun 2018, at 11:38, Donny Davis  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 
>> 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. cal...@well.ox.ac.uk
>>>
>>> On 11 Jun 2018, at 11:29, Callum Smith  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. cal...@well.ox.ac.uk
>>>
>>> On 11 Jun 2018, at 11:26, Donny Davis  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
>>> >The user callum@Biomedical Research Computing is not authorized to
>>> perform login
>>>
>>> On Mon, Jun 11, 2018 at 6:23 AM, Callum Smith 
>>> wrote:
>>>
 Dear Donny,

 No, though the user shows the permissions inherited from the Everyone
 group:
 
 Regards,
 Callum

 --

 Callum Smith
 Research Computing Core
 Wellcome Trust Centre for Human Genetics
 University of Oxford
 e. cal...@well.ox.ac.uk

 On 11 Jun 2018, at 11:21, Donny Davis  wrote:

 Just a shot in the dark, but after you setup ldap did you go in as the
 default admin and give an ldap account permissions?

 On Mon, Jun 11, 2018 at 6:04 AM, Callum Smith 
 wrote:

> Dear All,
>
> Could this be as our LDAP is fairly short on attributes?
>
> 2018-06-11 11:00:52,856+01 INFO  
> [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand]
> (default task-5) [5dff9eb0] Running command: CreateUserSessionCommand
> internal: false.
> 2018-06-11 11:00:52,884+01 ERROR [org.ovirt.engine.core.dal.dbb
> roker.auditloghandling.AuditLogDirector] (default task-5) [5dff9eb0]
> EVENT_ID: USER_VDC_LOGIN_FAILED(114), User callum@Biomedical Research
> Computing connecting from '--ipaddr--' failed to log in.
> 2018-06-11 11:00:52,884+01 ERROR 
> [org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet]
> (default task-5) [] The user callum@Biomedical Research Computing is
> not authorized to perform login
>
> I note that a number of variables are included in this action, but
> which are required and which are optional is the question:
>
> https://github.com/oVirt/ovirt-engine/blob/master/backend/ma
> nager/modules/aaa/src/main/java/org/ovirt/engine/core/aaa/se
> rvlet/SsoPostLoginServlet.java#L88
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> 

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Callum Smith
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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:48, Donny Davis 
mailto:do...@fortnebula.com>> wrote:

did you add system permissions to the everyone group?

On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith 
mailto:cal...@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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:38, Donny Davis 
mailto:do...@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 
mailto:cal...@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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:29, Callum Smith 
mailto:cal...@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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:26, Donny Davis 
mailto:do...@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
>The user callum@Biomedical Research Computing is not authorized to perform 
>login

On Mon, Jun 11, 2018 at 6:23 AM, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear Donny,

No, though the user shows the permissions inherited from the Everyone group:

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:21, Donny Davis 
mailto:do...@fortnebula.com>> wrote:

Just a shot in the dark, but after you setup ldap did you go in as the default 
admin and give an ldap account permissions?

On Mon, Jun 11, 2018 at 6:04 AM, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear All,

Could this be as our LDAP is fairly short on attributes?

2018-06-11 11:00:52,856+01 INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-5) 
[5dff9eb0] Running command: CreateUserSessionCommand internal: false.
2018-06-11 11:00:52,884+01 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-5) [5dff9eb0] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User callum@Biomedical 
Research Computing connecting from '--ipaddr--' failed to log in.
2018-06-11 11:00:52,884+01 ERROR 
[org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-5) [] The 
user callum@Biomedical Research Computing is not authorized to perform login

I note that a number of variables are included in this action, but which are 
required and which are optional is the question:

https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/aaa/src/main/java/org/ovirt/engine/core/aaa/servlet/SsoPostLoginServlet.java#L88

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 09:35, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

What would be the next step to help solve this issue? All users authenticating 
through LDAP get "This user is not authorised to perform authentication".

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. 

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Donny Davis
did you add system permissions to the everyone group?

On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith  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. cal...@well.ox.ac.uk
>
> On 11 Jun 2018, at 11:38, Donny Davis  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 
> 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. cal...@well.ox.ac.uk
>>
>> On 11 Jun 2018, at 11:29, Callum Smith  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. cal...@well.ox.ac.uk
>>
>> On 11 Jun 2018, at 11:26, Donny Davis  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
>> >The user callum@Biomedical Research Computing is not authorized to
>> perform login
>>
>> On Mon, Jun 11, 2018 at 6:23 AM, Callum Smith 
>> wrote:
>>
>>> Dear Donny,
>>>
>>> No, though the user shows the permissions inherited from the Everyone
>>> group:
>>> 
>>> Regards,
>>> Callum
>>>
>>> --
>>>
>>> Callum Smith
>>> Research Computing Core
>>> Wellcome Trust Centre for Human Genetics
>>> University of Oxford
>>> e. cal...@well.ox.ac.uk
>>>
>>> On 11 Jun 2018, at 11:21, Donny Davis  wrote:
>>>
>>> Just a shot in the dark, but after you setup ldap did you go in as the
>>> default admin and give an ldap account permissions?
>>>
>>> On Mon, Jun 11, 2018 at 6:04 AM, Callum Smith 
>>> wrote:
>>>
 Dear All,

 Could this be as our LDAP is fairly short on attributes?

 2018-06-11 11:00:52,856+01 INFO  
 [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand]
 (default task-5) [5dff9eb0] Running command: CreateUserSessionCommand
 internal: false.
 2018-06-11 11:00:52,884+01 ERROR [org.ovirt.engine.core.dal.dbb
 roker.auditloghandling.AuditLogDirector] (default task-5) [5dff9eb0]
 EVENT_ID: USER_VDC_LOGIN_FAILED(114), User callum@Biomedical Research
 Computing connecting from '--ipaddr--' failed to log in.
 2018-06-11 11:00:52,884+01 ERROR 
 [org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet]
 (default task-5) [] The user callum@Biomedical Research Computing is
 not authorized to perform login

 I note that a number of variables are included in this action, but
 which are required and which are optional is the question:

 https://github.com/oVirt/ovirt-engine/blob/master/backend/ma
 nager/modules/aaa/src/main/java/org/ovirt/engine/core/aaa/se
 rvlet/SsoPostLoginServlet.java#L88

 Regards,
 Callum

 --

 Callum Smith
 Research Computing Core
 Wellcome Trust Centre for Human Genetics
 University of Oxford
 e. cal...@well.ox.ac.uk

 On 11 Jun 2018, at 09:35, Callum Smith  wrote:

 What would be the next step to help solve this issue? All users
 authenticating through LDAP get "This user is not authorised to perform
 authentication".

 Regards,
 Callum

 --

 Callum Smith
 Research Computing Core
 Wellcome Trust Centre for Human Genetics
 University of Oxford
 e. cal...@well.ox.ac.uk

 On 5 Jun 2018, at 11:42, Callum Smith  wrote:

 Ok I spoke too soon, I have resolved the groups, but authentication
 still isn't working for LDAP users, same error as before (114).

 Regards,
 Callum

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Callum Smith
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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:38, Donny Davis 
mailto:do...@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 
mailto:cal...@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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:29, Callum Smith 
mailto:cal...@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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:26, Donny Davis 
mailto:do...@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
>The user callum@Biomedical Research Computing is not authorized to perform 
>login

On Mon, Jun 11, 2018 at 6:23 AM, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear Donny,

No, though the user shows the permissions inherited from the Everyone group:

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:21, Donny Davis 
mailto:do...@fortnebula.com>> wrote:

Just a shot in the dark, but after you setup ldap did you go in as the default 
admin and give an ldap account permissions?

On Mon, Jun 11, 2018 at 6:04 AM, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear All,

Could this be as our LDAP is fairly short on attributes?

2018-06-11 11:00:52,856+01 INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-5) 
[5dff9eb0] Running command: CreateUserSessionCommand internal: false.
2018-06-11 11:00:52,884+01 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-5) [5dff9eb0] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User callum@Biomedical 
Research Computing connecting from '--ipaddr--' failed to log in.
2018-06-11 11:00:52,884+01 ERROR 
[org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-5) [] The 
user callum@Biomedical Research Computing is not authorized to perform login

I note that a number of variables are included in this action, but which are 
required and which are optional is the question:

https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/aaa/src/main/java/org/ovirt/engine/core/aaa/servlet/SsoPostLoginServlet.java#L88

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 09:35, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

What would be the next step to help solve this issue? All users authenticating 
through LDAP get "This user is not authorised to perform authentication".

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 5 Jun 2018, at 11:42, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Ok I spoke too soon, I have resolved the groups, but authentication still isn't 
working for LDAP users, same error as before (114).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 5 Jun 2018, at 10:14, Callum Smith 

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Donny Davis
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  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. cal...@well.ox.ac.uk
>
> On 11 Jun 2018, at 11:29, Callum Smith  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. cal...@well.ox.ac.uk
>
> On 11 Jun 2018, at 11:26, Donny Davis  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
> >The user callum@Biomedical Research Computing is not authorized to
> perform login
>
> On Mon, Jun 11, 2018 at 6:23 AM, Callum Smith 
> wrote:
>
>> Dear Donny,
>>
>> No, though the user shows the permissions inherited from the Everyone
>> group:
>> 
>> Regards,
>> Callum
>>
>> --
>>
>> Callum Smith
>> Research Computing Core
>> Wellcome Trust Centre for Human Genetics
>> University of Oxford
>> e. cal...@well.ox.ac.uk
>>
>> On 11 Jun 2018, at 11:21, Donny Davis  wrote:
>>
>> Just a shot in the dark, but after you setup ldap did you go in as the
>> default admin and give an ldap account permissions?
>>
>> On Mon, Jun 11, 2018 at 6:04 AM, Callum Smith 
>> wrote:
>>
>>> Dear All,
>>>
>>> Could this be as our LDAP is fairly short on attributes?
>>>
>>> 2018-06-11 11:00:52,856+01 INFO  
>>> [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand]
>>> (default task-5) [5dff9eb0] Running command: CreateUserSessionCommand
>>> internal: false.
>>> 2018-06-11 11:00:52,884+01 ERROR [org.ovirt.engine.core.dal.dbb
>>> roker.auditloghandling.AuditLogDirector] (default task-5) [5dff9eb0]
>>> EVENT_ID: USER_VDC_LOGIN_FAILED(114), User callum@Biomedical Research
>>> Computing connecting from '--ipaddr--' failed to log in.
>>> 2018-06-11 11:00:52,884+01 ERROR 
>>> [org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet]
>>> (default task-5) [] The user callum@Biomedical Research Computing is
>>> not authorized to perform login
>>>
>>> I note that a number of variables are included in this action, but which
>>> are required and which are optional is the question:
>>>
>>> https://github.com/oVirt/ovirt-engine/blob/master/backend/ma
>>> nager/modules/aaa/src/main/java/org/ovirt/engine/core/aaa/
>>> servlet/SsoPostLoginServlet.java#L88
>>>
>>> Regards,
>>> Callum
>>>
>>> --
>>>
>>> Callum Smith
>>> Research Computing Core
>>> Wellcome Trust Centre for Human Genetics
>>> University of Oxford
>>> e. cal...@well.ox.ac.uk
>>>
>>> On 11 Jun 2018, at 09:35, Callum Smith  wrote:
>>>
>>> What would be the next step to help solve this issue? All users
>>> authenticating through LDAP get "This user is not authorised to perform
>>> authentication".
>>>
>>> Regards,
>>> Callum
>>>
>>> --
>>>
>>> Callum Smith
>>> Research Computing Core
>>> Wellcome Trust Centre for Human Genetics
>>> University of Oxford
>>> e. cal...@well.ox.ac.uk
>>>
>>> On 5 Jun 2018, at 11:42, Callum Smith  wrote:
>>>
>>> Ok I spoke too soon, I have resolved the groups, but authentication
>>> still isn't working for LDAP users, same error as before (114).
>>>
>>> Regards,
>>> Callum
>>>
>>> --
>>>
>>> Callum Smith
>>> Research Computing Core
>>> Wellcome Trust Centre for Human Genetics
>>> University of Oxford
>>> e. cal...@well.ox.ac.uk
>>>
>>> On 5 Jun 2018, at 10:14, Callum Smith  wrote:
>>>
>>> Dear Ondra, all,
>>>
>>> Managed to solve this once i got my head around the properties file.
>>> Conceptually the problem is that users are typically not a member of their
>>> primary group in a POSIX scenario, and their primary group is set by the
>>> gidNumber of the user's record, with additional group memberships specified
>>> by memberUid entries against a posixGroup entry.
>>>
>>> search.rfc2307-resolve-groups-memberUid.search-request.filter =
>>> 

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Callum Smith
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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:29, Callum Smith  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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:26, Donny Davis 
mailto:do...@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
>The user callum@Biomedical Research Computing is not authorized to perform 
>login

On Mon, Jun 11, 2018 at 6:23 AM, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear Donny,

No, though the user shows the permissions inherited from the Everyone group:

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:21, Donny Davis 
mailto:do...@fortnebula.com>> wrote:

Just a shot in the dark, but after you setup ldap did you go in as the default 
admin and give an ldap account permissions?

On Mon, Jun 11, 2018 at 6:04 AM, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear All,

Could this be as our LDAP is fairly short on attributes?

2018-06-11 11:00:52,856+01 INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-5) 
[5dff9eb0] Running command: CreateUserSessionCommand internal: false.
2018-06-11 11:00:52,884+01 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-5) [5dff9eb0] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User callum@Biomedical 
Research Computing connecting from '--ipaddr--' failed to log in.
2018-06-11 11:00:52,884+01 ERROR 
[org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-5) [] The 
user callum@Biomedical Research Computing is not authorized to perform login

I note that a number of variables are included in this action, but which are 
required and which are optional is the question:

https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/aaa/src/main/java/org/ovirt/engine/core/aaa/servlet/SsoPostLoginServlet.java#L88

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 09:35, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

What would be the next step to help solve this issue? All users authenticating 
through LDAP get "This user is not authorised to perform authentication".

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 5 Jun 2018, at 11:42, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Ok I spoke too soon, I have resolved the groups, but authentication still isn't 
working for LDAP users, same error as before (114).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 5 Jun 2018, at 10:14, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Dear Ondra, all,

Managed to solve this once i got my head around the properties file. 
Conceptually the problem is that users are typically not a member of their 
primary group in a POSIX scenario, and their primary group is set by the 
gidNumber of the user's record, with additional group memberships specified by 
memberUid entries against a posixGroup entry.

search.rfc2307-resolve-groups-memberUid.search-request.filter = 
&(objectClass=posixGroup)(|(memberUid=${seq:_rfc2307_uid_encoded})(gidNumber=${seq:_rfc2307_gid_encoded}))

search.rfc2307-resolve-principal-uid.search-request.attributes = uid, gidNumber

sequence.bmrc-resolve-groups.010.description = set dn
sequence.bmrc-resolve-groups.010.type = var-set
sequence.bmrc-resolve-groups.010.var-set.variable = _rfc2307_dn
sequence.bmrc-resolve-groups.010.var-set.value = ${seq:dn}
sequence.bmrc-resolve-groups.010.description = resolve uid
sequence.bmrc-resolve-groups.020.type = fetch-record

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Callum Smith
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. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:26, Donny Davis 
mailto:do...@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
>The user callum@Biomedical Research Computing is not authorized to perform 
>login

On Mon, Jun 11, 2018 at 6:23 AM, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear Donny,

No, though the user shows the permissions inherited from the Everyone group:

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:21, Donny Davis 
mailto:do...@fortnebula.com>> wrote:

Just a shot in the dark, but after you setup ldap did you go in as the default 
admin and give an ldap account permissions?

On Mon, Jun 11, 2018 at 6:04 AM, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear All,

Could this be as our LDAP is fairly short on attributes?

2018-06-11 11:00:52,856+01 INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-5) 
[5dff9eb0] Running command: CreateUserSessionCommand internal: false.
2018-06-11 11:00:52,884+01 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-5) [5dff9eb0] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User callum@Biomedical 
Research Computing connecting from '--ipaddr--' failed to log in.
2018-06-11 11:00:52,884+01 ERROR 
[org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-5) [] The 
user callum@Biomedical Research Computing is not authorized to perform login

I note that a number of variables are included in this action, but which are 
required and which are optional is the question:

https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/aaa/src/main/java/org/ovirt/engine/core/aaa/servlet/SsoPostLoginServlet.java#L88

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 09:35, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

What would be the next step to help solve this issue? All users authenticating 
through LDAP get "This user is not authorised to perform authentication".

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 5 Jun 2018, at 11:42, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Ok I spoke too soon, I have resolved the groups, but authentication still isn't 
working for LDAP users, same error as before (114).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 5 Jun 2018, at 10:14, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Dear Ondra, all,

Managed to solve this once i got my head around the properties file. 
Conceptually the problem is that users are typically not a member of their 
primary group in a POSIX scenario, and their primary group is set by the 
gidNumber of the user's record, with additional group memberships specified by 
memberUid entries against a posixGroup entry.

search.rfc2307-resolve-groups-memberUid.search-request.filter = 
&(objectClass=posixGroup)(|(memberUid=${seq:_rfc2307_uid_encoded})(gidNumber=${seq:_rfc2307_gid_encoded}))

search.rfc2307-resolve-principal-uid.search-request.attributes = uid, gidNumber

sequence.bmrc-resolve-groups.010.description = set dn
sequence.bmrc-resolve-groups.010.type = var-set
sequence.bmrc-resolve-groups.010.var-set.variable = _rfc2307_dn
sequence.bmrc-resolve-groups.010.var-set.value = ${seq:dn}
sequence.bmrc-resolve-groups.010.description = resolve uid
sequence.bmrc-resolve-groups.020.type = fetch-record
sequence.bmrc-resolve-groups.020.fetch-record.search = 
rfc2307-resolve-principal-uid
sequence.bmrc-resolve-groups.020.fetch-record.map.uid.name
 = _rfc2307_uid
sequence.bmrc-resolve-groups.030.description = resolve gid
sequence.bmrc-resolve-groups.030.type = fetch-record
sequence.bmrc-resolve-groups.030.fetch-record.search = 
rfc2307-resolve-principal-uid

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Donny Davis
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
>The user callum@Biomedical Research Computing is not authorized to perform
login

On Mon, Jun 11, 2018 at 6:23 AM, Callum Smith  wrote:

> Dear Donny,
>
> No, though the user shows the permissions inherited from the Everyone
> group:
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
> On 11 Jun 2018, at 11:21, Donny Davis  wrote:
>
> Just a shot in the dark, but after you setup ldap did you go in as the
> default admin and give an ldap account permissions?
>
> On Mon, Jun 11, 2018 at 6:04 AM, Callum Smith 
> wrote:
>
>> Dear All,
>>
>> Could this be as our LDAP is fairly short on attributes?
>>
>> 2018-06-11 11:00:52,856+01 INFO  
>> [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand]
>> (default task-5) [5dff9eb0] Running command: CreateUserSessionCommand
>> internal: false.
>> 2018-06-11 11:00:52,884+01 ERROR [org.ovirt.engine.core.dal.dbb
>> roker.auditloghandling.AuditLogDirector] (default task-5) [5dff9eb0]
>> EVENT_ID: USER_VDC_LOGIN_FAILED(114), User callum@Biomedical Research
>> Computing connecting from '--ipaddr--' failed to log in.
>> 2018-06-11 11:00:52,884+01 ERROR 
>> [org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet]
>> (default task-5) [] The user callum@Biomedical Research Computing is not
>> authorized to perform login
>>
>> I note that a number of variables are included in this action, but which
>> are required and which are optional is the question:
>>
>> https://github.com/oVirt/ovirt-engine/blob/master/backend/
>> manager/modules/aaa/src/main/java/org/ovirt/engine/core/
>> aaa/servlet/SsoPostLoginServlet.java#L88
>>
>> Regards,
>> Callum
>>
>> --
>>
>> Callum Smith
>> Research Computing Core
>> Wellcome Trust Centre for Human Genetics
>> University of Oxford
>> e. cal...@well.ox.ac.uk
>>
>> On 11 Jun 2018, at 09:35, Callum Smith  wrote:
>>
>> What would be the next step to help solve this issue? All users
>> authenticating through LDAP get "This user is not authorised to perform
>> authentication".
>>
>> Regards,
>> Callum
>>
>> --
>>
>> Callum Smith
>> Research Computing Core
>> Wellcome Trust Centre for Human Genetics
>> University of Oxford
>> e. cal...@well.ox.ac.uk
>>
>> On 5 Jun 2018, at 11:42, Callum Smith  wrote:
>>
>> Ok I spoke too soon, I have resolved the groups, but authentication still
>> isn't working for LDAP users, same error as before (114).
>>
>> Regards,
>> Callum
>>
>> --
>>
>> Callum Smith
>> Research Computing Core
>> Wellcome Trust Centre for Human Genetics
>> University of Oxford
>> e. cal...@well.ox.ac.uk
>>
>> On 5 Jun 2018, at 10:14, Callum Smith  wrote:
>>
>> Dear Ondra, all,
>>
>> Managed to solve this once i got my head around the properties file.
>> Conceptually the problem is that users are typically not a member of their
>> primary group in a POSIX scenario, and their primary group is set by the
>> gidNumber of the user's record, with additional group memberships specified
>> by memberUid entries against a posixGroup entry.
>>
>> search.rfc2307-resolve-groups-memberUid.search-request.filter =
>> &(objectClass=posixGroup)(|(memberUid=${seq:_rfc2307_uid_enc
>> oded})(gidNumber=${seq:_rfc2307_gid_encoded}))
>>
>> search.rfc2307-resolve-principal-uid.search-request.attributes = uid,
>> gidNumber
>>
>> sequence.bmrc-resolve-groups.010.description = set dn
>> sequence.bmrc-resolve-groups.010.type = var-set
>> sequence.bmrc-resolve-groups.010.var-set.variable = _rfc2307_dn
>> sequence.bmrc-resolve-groups.010.var-set.value = ${seq:dn}
>> sequence.bmrc-resolve-groups.010.description = resolve uid
>> sequence.bmrc-resolve-groups.020.type = fetch-record
>> sequence.bmrc-resolve-groups.020.fetch-record.search =
>> rfc2307-resolve-principal-uid
>> sequence.bmrc-resolve-groups.020.fetch-record.map.uid.name = _rfc2307_uid
>> sequence.bmrc-resolve-groups.030.description = resolve gid
>> sequence.bmrc-resolve-groups.030.type = fetch-record
>> sequence.bmrc-resolve-groups.030.fetch-record.search =
>> rfc2307-resolve-principal-uid
>> sequence.bmrc-resolve-groups.030.fetch-record.map.gidNumber.name
>> 
>> = _rfc2307_gid
>> sequence.bmrc-resolve-groups.040.description = query groups
>> sequence.bmrc-resolve-groups.040.type = search-open
>> sequence.bmrc-resolve-groups.040.search-open.search =
>> rfc2307-resolve-groups-memberUid
>> sequence.bmrc-resolve-groups.040.search-open.variable =
>> queryRFC2307ByMemberUid
>>
>> sequence.rfc2307-resolve-groups.020.call.name = bmrc-resolve-groups
>>
>>
>> Regards,
>> Callum
>>
>> --
>>
>> Callum Smith
>> Research Computing Core
>> Wellcome Trust Centre for Human Genetics
>> University of 

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Callum Smith
Dear Donny,

No, though the user shows the permissions inherited from the Everyone group:
[cid:3C4DA68E-6FBF-4D50-AA88-9E063CFBED6C@well.ox.ac.uk]
Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 11:21, Donny Davis 
mailto:do...@fortnebula.com>> wrote:

Just a shot in the dark, but after you setup ldap did you go in as the default 
admin and give an ldap account permissions?

On Mon, Jun 11, 2018 at 6:04 AM, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear All,

Could this be as our LDAP is fairly short on attributes?

2018-06-11 11:00:52,856+01 INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-5) 
[5dff9eb0] Running command: CreateUserSessionCommand internal: false.
2018-06-11 11:00:52,884+01 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-5) [5dff9eb0] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User callum@Biomedical 
Research Computing connecting from '--ipaddr--' failed to log in.
2018-06-11 11:00:52,884+01 ERROR 
[org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-5) [] The 
user callum@Biomedical Research Computing is not authorized to perform login

I note that a number of variables are included in this action, but which are 
required and which are optional is the question:

https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/aaa/src/main/java/org/ovirt/engine/core/aaa/servlet/SsoPostLoginServlet.java#L88

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 09:35, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

What would be the next step to help solve this issue? All users authenticating 
through LDAP get "This user is not authorised to perform authentication".

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 5 Jun 2018, at 11:42, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Ok I spoke too soon, I have resolved the groups, but authentication still isn't 
working for LDAP users, same error as before (114).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 5 Jun 2018, at 10:14, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Dear Ondra, all,

Managed to solve this once i got my head around the properties file. 
Conceptually the problem is that users are typically not a member of their 
primary group in a POSIX scenario, and their primary group is set by the 
gidNumber of the user's record, with additional group memberships specified by 
memberUid entries against a posixGroup entry.

search.rfc2307-resolve-groups-memberUid.search-request.filter = 
&(objectClass=posixGroup)(|(memberUid=${seq:_rfc2307_uid_encoded})(gidNumber=${seq:_rfc2307_gid_encoded}))

search.rfc2307-resolve-principal-uid.search-request.attributes = uid, gidNumber

sequence.bmrc-resolve-groups.010.description = set dn
sequence.bmrc-resolve-groups.010.type = var-set
sequence.bmrc-resolve-groups.010.var-set.variable = _rfc2307_dn
sequence.bmrc-resolve-groups.010.var-set.value = ${seq:dn}
sequence.bmrc-resolve-groups.010.description = resolve uid
sequence.bmrc-resolve-groups.020.type = fetch-record
sequence.bmrc-resolve-groups.020.fetch-record.search = 
rfc2307-resolve-principal-uid
sequence.bmrc-resolve-groups.020.fetch-record.map.uid.name
 = _rfc2307_uid
sequence.bmrc-resolve-groups.030.description = resolve gid
sequence.bmrc-resolve-groups.030.type = fetch-record
sequence.bmrc-resolve-groups.030.fetch-record.search = 
rfc2307-resolve-principal-uid
sequence.bmrc-resolve-groups.030.fetch-record.map.gidNumber.name
 = _rfc2307_gid
sequence.bmrc-resolve-groups.040.description = query groups
sequence.bmrc-resolve-groups.040.type = search-open
sequence.bmrc-resolve-groups.040.search-open.search = 
rfc2307-resolve-groups-memberUid
sequence.bmrc-resolve-groups.040.search-open.variable = queryRFC2307ByMemberUid

sequence.rfc2307-resolve-groups.020.call.name
 = bmrc-resolve-groups


Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 4 Jun 2018, at 15:07, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Dear Ondra,

I went for openldap-rfc2307 as that best describes our ldap setup. The issue 
seems to be that the gidNumber is set, but users are not a member of their 

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Donny Davis
Just a shot in the dark, but after you setup ldap did you go in as the
default admin and give an ldap account permissions?

On Mon, Jun 11, 2018 at 6:04 AM, Callum Smith  wrote:

> Dear All,
>
> Could this be as our LDAP is fairly short on attributes?
>
> 2018-06-11 11:00:52,856+01 INFO  
> [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand]
> (default task-5) [5dff9eb0] Running command: CreateUserSessionCommand
> internal: false.
> 2018-06-11 11:00:52,884+01 ERROR [org.ovirt.engine.core.dal.
> dbbroker.auditloghandling.AuditLogDirector] (default task-5) [5dff9eb0]
> EVENT_ID: USER_VDC_LOGIN_FAILED(114), User callum@Biomedical Research
> Computing connecting from '--ipaddr--' failed to log in.
> 2018-06-11 11:00:52,884+01 ERROR 
> [org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet]
> (default task-5) [] The user callum@Biomedical Research Computing is not
> authorized to perform login
>
> I note that a number of variables are included in this action, but which
> are required and which are optional is the question:
>
> https://github.com/oVirt/ovirt-engine/blob/master/
> backend/manager/modules/aaa/src/main/java/org/ovirt/
> engine/core/aaa/servlet/SsoPostLoginServlet.java#L88
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
> On 11 Jun 2018, at 09:35, Callum Smith  wrote:
>
> What would be the next step to help solve this issue? All users
> authenticating through LDAP get "This user is not authorised to perform
> authentication".
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
> On 5 Jun 2018, at 11:42, Callum Smith  wrote:
>
> Ok I spoke too soon, I have resolved the groups, but authentication still
> isn't working for LDAP users, same error as before (114).
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
> On 5 Jun 2018, at 10:14, Callum Smith  wrote:
>
> Dear Ondra, all,
>
> Managed to solve this once i got my head around the properties file.
> Conceptually the problem is that users are typically not a member of their
> primary group in a POSIX scenario, and their primary group is set by the
> gidNumber of the user's record, with additional group memberships specified
> by memberUid entries against a posixGroup entry.
>
> search.rfc2307-resolve-groups-memberUid.search-request.filter =
> &(objectClass=posixGroup)(|(memberUid=${seq:_rfc2307_uid_
> encoded})(gidNumber=${seq:_rfc2307_gid_encoded}))
>
> search.rfc2307-resolve-principal-uid.search-request.attributes = uid,
> gidNumber
>
> sequence.bmrc-resolve-groups.010.description = set dn
> sequence.bmrc-resolve-groups.010.type = var-set
> sequence.bmrc-resolve-groups.010.var-set.variable = _rfc2307_dn
> sequence.bmrc-resolve-groups.010.var-set.value = ${seq:dn}
> sequence.bmrc-resolve-groups.010.description = resolve uid
> sequence.bmrc-resolve-groups.020.type = fetch-record
> sequence.bmrc-resolve-groups.020.fetch-record.search =
> rfc2307-resolve-principal-uid
> sequence.bmrc-resolve-groups.020.fetch-record.map.uid.name = _rfc2307_uid
> sequence.bmrc-resolve-groups.030.description = resolve gid
> sequence.bmrc-resolve-groups.030.type = fetch-record
> sequence.bmrc-resolve-groups.030.fetch-record.search =
> rfc2307-resolve-principal-uid
> sequence.bmrc-resolve-groups.030.fetch-record.map.gidNumber.name =
> _rfc2307_gid
> sequence.bmrc-resolve-groups.040.description = query groups
> sequence.bmrc-resolve-groups.040.type = search-open
> sequence.bmrc-resolve-groups.040.search-open.search =
> rfc2307-resolve-groups-memberUid
> sequence.bmrc-resolve-groups.040.search-open.variable =
> queryRFC2307ByMemberUid
>
> sequence.rfc2307-resolve-groups.020.call.name = bmrc-resolve-groups
>
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
> On 4 Jun 2018, at 15:07, Callum Smith  wrote:
>
> Dear Ondra,
>
> I went for openldap-rfc2307 as that best describes our ldap setup. The
> issue seems to be that the gidNumber is set, but users are not a member of
> their primary group within the LDAP. So, user's gidNumber represents
> primary group and posixGroup membership (memberUid) represents their
> secondary groups. What's the best way to approach this (fix the filters on
> oVirt end or change the LDAP? This is a question of what is most compliant
> with standards really).
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
> On 29 May 2018, at 11:29, Ondra Machacek  wrote:
>
> What's you LDAP and what profile did you choose? This looks like you have
> chosen incorect profile during setup. 

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Callum Smith
Dear All,

Could this be as our LDAP is fairly short on attributes?

2018-06-11 11:00:52,856+01 INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-5) 
[5dff9eb0] Running command: CreateUserSessionCommand internal: false.
2018-06-11 11:00:52,884+01 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-5) [5dff9eb0] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User callum@Biomedical 
Research Computing connecting from '--ipaddr--' failed to log in.
2018-06-11 11:00:52,884+01 ERROR 
[org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-5) [] The 
user callum@Biomedical Research Computing is not authorized to perform login

I note that a number of variables are included in this action, but which are 
required and which are optional is the question:

https://github.com/oVirt/ovirt-engine/blob/master/backend/manager/modules/aaa/src/main/java/org/ovirt/engine/core/aaa/servlet/SsoPostLoginServlet.java#L88

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 11 Jun 2018, at 09:35, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

What would be the next step to help solve this issue? All users authenticating 
through LDAP get "This user is not authorised to perform authentication".

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 5 Jun 2018, at 11:42, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Ok I spoke too soon, I have resolved the groups, but authentication still isn't 
working for LDAP users, same error as before (114).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 5 Jun 2018, at 10:14, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Dear Ondra, all,

Managed to solve this once i got my head around the properties file. 
Conceptually the problem is that users are typically not a member of their 
primary group in a POSIX scenario, and their primary group is set by the 
gidNumber of the user's record, with additional group memberships specified by 
memberUid entries against a posixGroup entry.

search.rfc2307-resolve-groups-memberUid.search-request.filter = 
&(objectClass=posixGroup)(|(memberUid=${seq:_rfc2307_uid_encoded})(gidNumber=${seq:_rfc2307_gid_encoded}))

search.rfc2307-resolve-principal-uid.search-request.attributes = uid, gidNumber

sequence.bmrc-resolve-groups.010.description = set dn
sequence.bmrc-resolve-groups.010.type = var-set
sequence.bmrc-resolve-groups.010.var-set.variable = _rfc2307_dn
sequence.bmrc-resolve-groups.010.var-set.value = ${seq:dn}
sequence.bmrc-resolve-groups.010.description = resolve uid
sequence.bmrc-resolve-groups.020.type = fetch-record
sequence.bmrc-resolve-groups.020.fetch-record.search = 
rfc2307-resolve-principal-uid
sequence.bmrc-resolve-groups.020.fetch-record.map.uid.name = _rfc2307_uid
sequence.bmrc-resolve-groups.030.description = resolve gid
sequence.bmrc-resolve-groups.030.type = fetch-record
sequence.bmrc-resolve-groups.030.fetch-record.search = 
rfc2307-resolve-principal-uid
sequence.bmrc-resolve-groups.030.fetch-record.map.gidNumber.name = _rfc2307_gid
sequence.bmrc-resolve-groups.040.description = query groups
sequence.bmrc-resolve-groups.040.type = search-open
sequence.bmrc-resolve-groups.040.search-open.search = 
rfc2307-resolve-groups-memberUid
sequence.bmrc-resolve-groups.040.search-open.variable = queryRFC2307ByMemberUid

sequence.rfc2307-resolve-groups.020.call.name = bmrc-resolve-groups


Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 4 Jun 2018, at 15:07, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Dear Ondra,

I went for openldap-rfc2307 as that best describes our ldap setup. The issue 
seems to be that the gidNumber is set, but users are not a member of their 
primary group within the LDAP. So, user's gidNumber represents primary group 
and posixGroup membership (memberUid) represents their secondary groups. What's 
the best way to approach this (fix the filters on oVirt end or change the LDAP? 
This is a question of what is most compliant with standards really).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 29 May 2018, at 11:29, Ondra Machacek 
mailto:omach...@redhat.com>> wrote:

What's you LDAP and what profile did you choose? This looks like you have 
chosen incorect profile during setup. Are you sure you arent using posix group 
and using non-posix aaa profile? Sharing a debug log of 
ovirt-engine-extensions-tool 

[ovirt-users] Re: LDAP Authentication issues

2018-06-11 Thread Callum Smith
What would be the next step to help solve this issue? All users authenticating 
through LDAP get "This user is not authorised to perform authentication".

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 5 Jun 2018, at 11:42, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Ok I spoke too soon, I have resolved the groups, but authentication still isn't 
working for LDAP users, same error as before (114).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 5 Jun 2018, at 10:14, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Dear Ondra, all,

Managed to solve this once i got my head around the properties file. 
Conceptually the problem is that users are typically not a member of their 
primary group in a POSIX scenario, and their primary group is set by the 
gidNumber of the user's record, with additional group memberships specified by 
memberUid entries against a posixGroup entry.

search.rfc2307-resolve-groups-memberUid.search-request.filter = 
&(objectClass=posixGroup)(|(memberUid=${seq:_rfc2307_uid_encoded})(gidNumber=${seq:_rfc2307_gid_encoded}))

search.rfc2307-resolve-principal-uid.search-request.attributes = uid, gidNumber

sequence.bmrc-resolve-groups.010.description = set dn
sequence.bmrc-resolve-groups.010.type = var-set
sequence.bmrc-resolve-groups.010.var-set.variable = _rfc2307_dn
sequence.bmrc-resolve-groups.010.var-set.value = ${seq:dn}
sequence.bmrc-resolve-groups.010.description = resolve uid
sequence.bmrc-resolve-groups.020.type = fetch-record
sequence.bmrc-resolve-groups.020.fetch-record.search = 
rfc2307-resolve-principal-uid
sequence.bmrc-resolve-groups.020.fetch-record.map.uid.name = _rfc2307_uid
sequence.bmrc-resolve-groups.030.description = resolve gid
sequence.bmrc-resolve-groups.030.type = fetch-record
sequence.bmrc-resolve-groups.030.fetch-record.search = 
rfc2307-resolve-principal-uid
sequence.bmrc-resolve-groups.030.fetch-record.map.gidNumber.name = _rfc2307_gid
sequence.bmrc-resolve-groups.040.description = query groups
sequence.bmrc-resolve-groups.040.type = search-open
sequence.bmrc-resolve-groups.040.search-open.search = 
rfc2307-resolve-groups-memberUid
sequence.bmrc-resolve-groups.040.search-open.variable = queryRFC2307ByMemberUid

sequence.rfc2307-resolve-groups.020.call.name = bmrc-resolve-groups


Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 4 Jun 2018, at 15:07, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Dear Ondra,

I went for openldap-rfc2307 as that best describes our ldap setup. The issue 
seems to be that the gidNumber is set, but users are not a member of their 
primary group within the LDAP. So, user's gidNumber represents primary group 
and posixGroup membership (memberUid) represents their secondary groups. What's 
the best way to approach this (fix the filters on oVirt end or change the LDAP? 
This is a question of what is most compliant with standards really).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 29 May 2018, at 11:29, Ondra Machacek 
mailto:omach...@redhat.com>> wrote:

What's you LDAP and what profile did you choose? This looks like you have 
chosen incorect profile during setup. Are you sure you arent using posix group 
and using non-posix aaa profile? Sharing a debug log of 
ovirt-engine-extensions-tool would be helpfull.


On Fri, May 25, 2018, 10:04 AM Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear All,

I'm having problems getting LDAP running, login works, but I'm getting "user is 
not authorised to perform login" - this is even if i specify the UserRole 
specifically to the LDAP group the user is in.

2018-05-25 08:56:16,212+01 INFO  
[org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-23) [] User 
callum@Biomedical Research Computing successfully logged in with scopes: 
ovirt-app-admin ovirt-app-api ovirt-app-portal 
ovirt-ext=auth:sequence-priority=~ ovirt-ext=revoke:revoke-all 
ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search 
ovirt-ext=token-info:validate ovirt-ext=token:password-access
2018-05-25 08:56:16,391+01 INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-25) 
[63e60fe9] Running command: CreateUserSessionCommand internal: false.
2018-05-25 08:56:16,430+01 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-25) [63e60fe9] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User 
callum@Biomedical Research Computing connecting from '192.168.65.254' failed to 
log in.
2018-05-25 08:56:16,430+01 ERROR 

[ovirt-users] Re: LDAP Authentication issues

2018-06-05 Thread Callum Smith
Ok I spoke too soon, I have resolved the groups, but authentication still isn't 
working for LDAP users, same error as before (114).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 5 Jun 2018, at 10:14, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Dear Ondra, all,

Managed to solve this once i got my head around the properties file. 
Conceptually the problem is that users are typically not a member of their 
primary group in a POSIX scenario, and their primary group is set by the 
gidNumber of the user's record, with additional group memberships specified by 
memberUid entries against a posixGroup entry.

search.rfc2307-resolve-groups-memberUid.search-request.filter = 
&(objectClass=posixGroup)(|(memberUid=${seq:_rfc2307_uid_encoded})(gidNumber=${seq:_rfc2307_gid_encoded}))

search.rfc2307-resolve-principal-uid.search-request.attributes = uid, gidNumber

sequence.bmrc-resolve-groups.010.description = set dn
sequence.bmrc-resolve-groups.010.type = var-set
sequence.bmrc-resolve-groups.010.var-set.variable = _rfc2307_dn
sequence.bmrc-resolve-groups.010.var-set.value = ${seq:dn}
sequence.bmrc-resolve-groups.010.description = resolve uid
sequence.bmrc-resolve-groups.020.type = fetch-record
sequence.bmrc-resolve-groups.020.fetch-record.search = 
rfc2307-resolve-principal-uid
sequence.bmrc-resolve-groups.020.fetch-record.map.uid.name = _rfc2307_uid
sequence.bmrc-resolve-groups.030.description = resolve gid
sequence.bmrc-resolve-groups.030.type = fetch-record
sequence.bmrc-resolve-groups.030.fetch-record.search = 
rfc2307-resolve-principal-uid
sequence.bmrc-resolve-groups.030.fetch-record.map.gidNumber.name = _rfc2307_gid
sequence.bmrc-resolve-groups.040.description = query groups
sequence.bmrc-resolve-groups.040.type = search-open
sequence.bmrc-resolve-groups.040.search-open.search = 
rfc2307-resolve-groups-memberUid
sequence.bmrc-resolve-groups.040.search-open.variable = queryRFC2307ByMemberUid

sequence.rfc2307-resolve-groups.020.call.name = bmrc-resolve-groups


Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 4 Jun 2018, at 15:07, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Dear Ondra,

I went for openldap-rfc2307 as that best describes our ldap setup. The issue 
seems to be that the gidNumber is set, but users are not a member of their 
primary group within the LDAP. So, user's gidNumber represents primary group 
and posixGroup membership (memberUid) represents their secondary groups. What's 
the best way to approach this (fix the filters on oVirt end or change the LDAP? 
This is a question of what is most compliant with standards really).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 29 May 2018, at 11:29, Ondra Machacek 
mailto:omach...@redhat.com>> wrote:

What's you LDAP and what profile did you choose? This looks like you have 
chosen incorect profile during setup. Are you sure you arent using posix group 
and using non-posix aaa profile? Sharing a debug log of 
ovirt-engine-extensions-tool would be helpfull.


On Fri, May 25, 2018, 10:04 AM Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear All,

I'm having problems getting LDAP running, login works, but I'm getting "user is 
not authorised to perform login" - this is even if i specify the UserRole 
specifically to the LDAP group the user is in.

2018-05-25 08:56:16,212+01 INFO  
[org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-23) [] User 
callum@Biomedical Research Computing successfully logged in with scopes: 
ovirt-app-admin ovirt-app-api ovirt-app-portal 
ovirt-ext=auth:sequence-priority=~ ovirt-ext=revoke:revoke-all 
ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search 
ovirt-ext=token-info:validate ovirt-ext=token:password-access
2018-05-25 08:56:16,391+01 INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-25) 
[63e60fe9] Running command: CreateUserSessionCommand internal: false.
2018-05-25 08:56:16,430+01 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-25) [63e60fe9] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User 
callum@Biomedical Research Computing connecting from '192.168.65.254' failed to 
log in.
2018-05-25 08:56:16,430+01 ERROR 
[org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-25) [] 
The user callum@Biomedical Research Computing is not authorized to perform login


on a side note: is it possible to assign permissions to all members of an LDAP 
tree where they dont have a common group membership?

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of 

[ovirt-users] Re: LDAP Authentication issues

2018-06-05 Thread Callum Smith
Dear Ondra, all,

Managed to solve this once i got my head around the properties file. 
Conceptually the problem is that users are typically not a member of their 
primary group in a POSIX scenario, and their primary group is set by the 
gidNumber of the user's record, with additional group memberships specified by 
memberUid entries against a posixGroup entry.

search.rfc2307-resolve-groups-memberUid.search-request.filter = 
&(objectClass=posixGroup)(|(memberUid=${seq:_rfc2307_uid_encoded})(gidNumber=${seq:_rfc2307_gid_encoded}))

search.rfc2307-resolve-principal-uid.search-request.attributes = uid, gidNumber

sequence.bmrc-resolve-groups.010.description = set dn
sequence.bmrc-resolve-groups.010.type = var-set
sequence.bmrc-resolve-groups.010.var-set.variable = _rfc2307_dn
sequence.bmrc-resolve-groups.010.var-set.value = ${seq:dn}
sequence.bmrc-resolve-groups.010.description = resolve uid
sequence.bmrc-resolve-groups.020.type = fetch-record
sequence.bmrc-resolve-groups.020.fetch-record.search = 
rfc2307-resolve-principal-uid
sequence.bmrc-resolve-groups.020.fetch-record.map.uid.name = _rfc2307_uid
sequence.bmrc-resolve-groups.030.description = resolve gid
sequence.bmrc-resolve-groups.030.type = fetch-record
sequence.bmrc-resolve-groups.030.fetch-record.search = 
rfc2307-resolve-principal-uid
sequence.bmrc-resolve-groups.030.fetch-record.map.gidNumber.name = _rfc2307_gid
sequence.bmrc-resolve-groups.040.description = query groups
sequence.bmrc-resolve-groups.040.type = search-open
sequence.bmrc-resolve-groups.040.search-open.search = 
rfc2307-resolve-groups-memberUid
sequence.bmrc-resolve-groups.040.search-open.variable = queryRFC2307ByMemberUid

sequence.rfc2307-resolve-groups.020.call.name = bmrc-resolve-groups


Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 4 Jun 2018, at 15:07, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Dear Ondra,

I went for openldap-rfc2307 as that best describes our ldap setup. The issue 
seems to be that the gidNumber is set, but users are not a member of their 
primary group within the LDAP. So, user's gidNumber represents primary group 
and posixGroup membership (memberUid) represents their secondary groups. What's 
the best way to approach this (fix the filters on oVirt end or change the LDAP? 
This is a question of what is most compliant with standards really).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 29 May 2018, at 11:29, Ondra Machacek 
mailto:omach...@redhat.com>> wrote:

What's you LDAP and what profile did you choose? This looks like you have 
chosen incorect profile during setup. Are you sure you arent using posix group 
and using non-posix aaa profile? Sharing a debug log of 
ovirt-engine-extensions-tool would be helpfull.


On Fri, May 25, 2018, 10:04 AM Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear All,

I'm having problems getting LDAP running, login works, but I'm getting "user is 
not authorised to perform login" - this is even if i specify the UserRole 
specifically to the LDAP group the user is in.

2018-05-25 08:56:16,212+01 INFO  
[org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-23) [] User 
callum@Biomedical Research Computing successfully logged in with scopes: 
ovirt-app-admin ovirt-app-api ovirt-app-portal 
ovirt-ext=auth:sequence-priority=~ ovirt-ext=revoke:revoke-all 
ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search 
ovirt-ext=token-info:validate ovirt-ext=token:password-access
2018-05-25 08:56:16,391+01 INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-25) 
[63e60fe9] Running command: CreateUserSessionCommand internal: false.
2018-05-25 08:56:16,430+01 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-25) [63e60fe9] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User 
callum@Biomedical Research Computing connecting from '192.168.65.254' failed to 
log in.
2018-05-25 08:56:16,430+01 ERROR 
[org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-25) [] 
The user callum@Biomedical Research Computing is not authorized to perform login


on a side note: is it possible to assign permissions to all members of an LDAP 
tree where they dont have a common group membership?

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 
users-le...@ovirt.org

___
Users mailing list -- users@ovirt.org
To unsubscribe 

[ovirt-users] Re: LDAP Authentication issues

2018-06-04 Thread Callum Smith
Dear Ondra,

I went for openldap-rfc2307 as that best describes our ldap setup. The issue 
seems to be that the gidNumber is set, but users are not a member of their 
primary group within the LDAP. So, user's gidNumber represents primary group 
and posixGroup membership (memberUid) represents their secondary groups. What's 
the best way to approach this (fix the filters on oVirt end or change the LDAP? 
This is a question of what is most compliant with standards really).

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 29 May 2018, at 11:29, Ondra Machacek 
mailto:omach...@redhat.com>> wrote:

What's you LDAP and what profile did you choose? This looks like you have 
chosen incorect profile during setup. Are you sure you arent using posix group 
and using non-posix aaa profile? Sharing a debug log of 
ovirt-engine-extensions-tool would be helpfull.


On Fri, May 25, 2018, 10:04 AM Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:
Dear All,

I'm having problems getting LDAP running, login works, but I'm getting "user is 
not authorised to perform login" - this is even if i specify the UserRole 
specifically to the LDAP group the user is in.

2018-05-25 08:56:16,212+01 INFO  
[org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-23) [] User 
callum@Biomedical Research Computing successfully logged in with scopes: 
ovirt-app-admin ovirt-app-api ovirt-app-portal 
ovirt-ext=auth:sequence-priority=~ ovirt-ext=revoke:revoke-all 
ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search 
ovirt-ext=token-info:validate ovirt-ext=token:password-access
2018-05-25 08:56:16,391+01 INFO  
[org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-25) 
[63e60fe9] Running command: CreateUserSessionCommand internal: false.
2018-05-25 08:56:16,430+01 ERROR 
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (default 
task-25) [63e60fe9] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User 
callum@Biomedical Research Computing connecting from '192.168.65.254' failed to 
log in.
2018-05-25 08:56:16,430+01 ERROR 
[org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-25) [] 
The user callum@Biomedical Research Computing is not authorized to perform login


on a side note: is it possible to assign permissions to all members of an LDAP 
tree where they dont have a common group membership?

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 
users-le...@ovirt.org

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/NAEUHLW3YMYAP6L44RRS5MCLRU2OTXPZ/


[ovirt-users] Re: LDAP Authentication issues

2018-05-29 Thread Ondra Machacek
What's you LDAP and what profile did you choose? This looks like you have
chosen incorect profile during setup. Are you sure you arent using posix
group and using non-posix aaa profile? Sharing a debug log of
ovirt-engine-extensions-tool would be helpfull.


On Fri, May 25, 2018, 10:04 AM Callum Smith  wrote:

> Dear All,
>
> I'm having problems getting LDAP running, login works, but I'm getting
> "user is not authorised to perform login" - this is even if i specify the
> UserRole specifically to the LDAP group the user is in.
>
> 2018-05-25 08:56:16,212+01 INFO
>  [org.ovirt.engine.core.sso.utils.AuthenticationUtils] (default task-23) []
> User callum@Biomedical Research Computing successfully logged in with
> scopes: ovirt-app-admin ovirt-app-api ovirt-app-portal
> ovirt-ext=auth:sequence-priority=~ ovirt-ext=revoke:revoke-all
> ovirt-ext=token-info:authz-search ovirt-ext=token-info:public-authz-search
> ovirt-ext=token-info:validate ovirt-ext=token:password-access
> 2018-05-25 08:56:16,391+01 INFO
>  [org.ovirt.engine.core.bll.aaa.CreateUserSessionCommand] (default task-25)
> [63e60fe9] Running command: CreateUserSessionCommand internal: false.
> 2018-05-25 08:56:16,430+01 ERROR
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (default task-25) [63e60fe9] EVENT_ID: USER_VDC_LOGIN_FAILED(114), User
> callum@Biomedical Research Computing connecting from '192.168.65.254'
> failed to log in.
> 2018-05-25 08:56:16,430+01 ERROR
> [org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default task-25)
> [] The user callum@Biomedical Research Computing is not authorized to
> perform login
>
>
> on a side note: is it possible to assign permissions to all members of an
> LDAP tree where they dont have a common group membership?
>
> Regards,
> Callum
>
> --
>
> Callum Smith
> Research Computing Core
> Wellcome Trust Centre for Human Genetics
> University of Oxford
> e. cal...@well.ox.ac.uk
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/PCOI5I47AKTGEWCHVKKAEOOCN5FDOTYW/