On Tue, 12 Jun 2018 at 11:48 Callum Smith <[email protected]> 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-000000000250 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. [email protected] > > On 12 Jun 2018, at 06:44, Roy Golan <[email protected]> wrote: > > > > On Tue, 12 Jun 2018 at 02:24 Donny Davis <[email protected]> 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 <[email protected]> >> 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. [email protected] >>> >>> On 11 Jun 2018, at 11:57, Donny Davis <[email protected]> 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 <[email protected]> >>> 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. [email protected] >>>> >>>> On 11 Jun 2018, at 11:48, Donny Davis <[email protected]> wrote: >>>> >>>> did you add system permissions to the everyone group? >>>> >>>> On Mon, Jun 11, 2018 at 6:42 AM, Callum Smith <[email protected]> >>>> 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. [email protected] >>>>> >>>>> On 11 Jun 2018, at 11:38, Donny Davis <[email protected]> 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 <[email protected]> >>>>> 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. [email protected] >>>>>> >>>>>> On 11 Jun 2018, at 11:29, Callum Smith <[email protected]> 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. [email protected] >>>>>> >>>>>> On 11 Jun 2018, at 11:26, Donny Davis <[email protected]> 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 <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Dear Donny, >>>>>>> >>>>>>> No, though the user shows the permissions inherited from the >>>>>>> Everyone group: >>>>>>> <Screen Shot 2018-06-11 at 11.22.42.png> >>>>>>> Regards, >>>>>>> Callum >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> Callum Smith >>>>>>> Research Computing Core >>>>>>> Wellcome Trust Centre for Human Genetics >>>>>>> University of Oxford >>>>>>> e. [email protected] >>>>>>> >>>>>>> On 11 Jun 2018, at 11:21, Donny Davis <[email protected]> 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 <[email protected]> >>>>>>> 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<UNKNOWN>. >>>>>>>> 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. [email protected] >>>>>>>> >>>>>>>> On 11 Jun 2018, at 09:35, Callum Smith <[email protected]> >>>>>>>> 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. [email protected] >>>>>>>> >>>>>>>> On 5 Jun 2018, at 11:42, Callum Smith <[email protected]> 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. [email protected] >>>>>>>> >>>>>>>> On 5 Jun 2018, at 10:14, Callum Smith <[email protected]> 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 >>>>>>>> <http://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. [email protected] >>>>>>>> >>>>>>>> On 4 Jun 2018, at 15:07, Callum Smith <[email protected]> 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. [email protected] >>>>>>>> >>>>>>>> On 29 May 2018, at 11:29, Ondra Machacek <[email protected]> >>>>>>>> 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 <[email protected]> >>>>>>>> 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<UNKNOWN>. >>>>>>>>> 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. [email protected] >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Users mailing list -- [email protected] >>>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list -- [email protected] >>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>> 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/[email protected]/message/NAEUHLW3YMYAP6L44RRS5MCLRU2OTXPZ/ >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list -- [email protected] >>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>> 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/[email protected]/message/2WR4PGLW4Z4PM2UOVN4YZUJHSBRYVMOJ/ >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list -- [email protected] >>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>> 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/[email protected]/message/O7DLMLFEBHLNCE2VCCCNNOXXGGERKAKZ/ >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list -- [email protected] >>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>> 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/[email protected]/message/BNZ5KRXOYYRFZCQIQQU6IJVDNNBDVZSF/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Users mailing list -- [email protected] >>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>> 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/[email protected]/message/EOWAPL6ZQE63S3732NQRH5YVJC26CQDR/ >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> _______________________________________________ >> Users mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> 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/[email protected]/message/3PEP2BOH74QXB3HPKOKSH5BNCL3O4KHC/ > > >
_______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/2V4MEXOAKVPLKRLFW5DJD7JU6ENTFCVN/
