[ovirt-users] Re: ldap auth problem after upgrade from 4.4.1 to 4.4.2

[Jiří Sléžka]

On 10/1/20 9:41 PM, Martin Perina wrote:
> 
> 
> On Thu, Oct 1, 2020 at 3:18 PM Jiří Sléžka  > wrote:
> 
> Hi,
> 
> On 10/1/20 2:53 PM, Martin Perina wrote:
> > Hi,
> >
> > it seems that you are affected by
> > https://bugzilla.redhat.com/show_bug.cgi?id=1880149
> > Could you please try the workaround mentioned there?
> 
> bingo! Thanks a lot!
> 
> It is interesting behavior as my engine has no public ipv6 address (ipv6
> is set to ignore in nm).
> 
> also
> 
> [root@ovirt ~]# ping6 google.com 
> connect: Network is unreachable
> 
> but ok, problem is solved :-)
> 
> 
> Most probably your LDAP server can be resolved to both IPv4 and IPv6
> addresses and we choose a random resolved address in aaa-ldap when
> connecting. Enabling IPv6 by default was introduced in
> https://bugzilla.redhat.com/1726189 but unfortunately we have missed
> this scenario (engine IPv4, LDAP dual IPv4/IPv6) during testing ...

yes, this is exactly our case. No problem, it is really hard to catch
all variants.

Cheers,

Jiri


> 
> 
> Jiri
> 
> 
> >
> > Thanks,
> > Martin
> >
> >
> > On Thu, Oct 1, 2020 at 11:17 AM Jiří Sléžka  
> > >> wrote:
> >
> >     Hi,
> >
> >     I just upgraded my HE to 4.4.2 but now I cannot login using my
> ldap aaa
> >     profile anymore.
> >
> >     We are using Novell/NetIQ E-directory (load ballanced by haproxy,
> >     probably not important...)
> >
> >     In 4.4.1 I was hit by removed TLSv1 (which is the newest protocol
> >     supported by our edir) from default crypto policies but I was able
> >     revert it by
> >
> >     update-crypto-policies --set LEGACY
> >
> >     after upgrade to 4.4.2 the error is
> >
> >     server_error: An error occurred while attempting to connect to
> server
> >     ldap1.slu.cz:389 
> :
> >     IOException(LDAPException(resultCode=91 (connect
> >     error), errorMessage='An error occurred while attempting to
> establish a
> >     connection to server ldap1.slu.cz/193.84.206.212:389
> 
> >     :
> >     SocketException(Network is unreachable (connect failed)),
> >     ldapSDKVersion=4.0.14,
> >     revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
> >
> >     but our ldap server is reachable from ovirt, I tested it via
> (also ldaps
> >     and startls variants are working)
> >
> >     ldapsearch -H ldap://ldap1.slu.cz 
>  -x -D
> >     cn=*,ou=**,o=su -w
> >     '' -b 'o=su'
> >
> >     As a workaround I tried to set plain ldap protocol in profile
> >
> >     cat /etc/ovirt-engine/aaa/CRO.properties
> >
> >
> >     include = 
> >
> >     vars.server = ldap1.slu.cz 
> 
> >     vars.port = 389
> >     vars.user = cn=*,ou=**,o=su
> >     vars.password = **
> >
> >     pool.default.serverset.single.server = ${global:vars.server}
> >     pool.default.serverset.single.port = ${global:vars.port}
> >     pool.default.auth.simple.bindDN = ${global:vars.user}
> >     pool.default.auth.simple.password = ${global:vars.password}
> >
> >     pool.default.ssl.startTLS = false
> >     pool.default.ssl.enable = false
> >     #pool.default.ssl.protocol = TLSv1
> >     #pool.default.ssl.startTLSProtocol = TLSv1
> >     #pool.default.ssl.insecure = true
> >
> >     sequence-init.init.100-my-edir-init-vars = my-edir-init-vars
> >     sequence.my-edir-init-vars.010.description = set baseDN
> >     sequence.my-edir-init-vars.010.type = var-set
> >     sequence.my-edir-init-vars.010.var-set.variable = simple_baseDN
> >     sequence.my-edir-init-vars.010.var-set.value = o=su
> >
> >     #search.default.search-request.derefPolicy = ALWAYS
> >
> >
> >     but the error is the same...
> >
> >     ovirt-engine-extensions-tool aaa login-user --profile=CRO
> >     --user-name=my_user
> >
> >     
> >     WARNING:
> [ovirt-engine-extension-aaa-ldap.authn::SU-LDAP-authentication]
> >     TLS/SSL insecure mode
> >     ...
> >     WARNING:
> [ovirt-engine-extension-aaa-ldap.authn::auth.CRO.slu.cz
> 
> >     ] Cannot
> >     initialize LDAP framework, deferring initialization. Error: An
> error
> >     occurred while attempting to connect to server
> ldap1.slu.cz:389 
> >     

[ovirt-users] Re: ldap auth problem after upgrade from 4.4.1 to 4.4.2

[Martin Perina]

On Thu, Oct 1, 2020 at 3:18 PM Jiří Sléžka  wrote:

> Hi,
>
> On 10/1/20 2:53 PM, Martin Perina wrote:
> > Hi,
> >
> > it seems that you are affected by
> > https://bugzilla.redhat.com/show_bug.cgi?id=1880149
> > Could you please try the workaround mentioned there?
>
> bingo! Thanks a lot!
>
> It is interesting behavior as my engine has no public ipv6 address (ipv6
> is set to ignore in nm).
>
> also
>
> [root@ovirt ~]# ping6 google.com
> connect: Network is unreachable
>
> but ok, problem is solved :-)
>

Most probably your LDAP server can be resolved to both IPv4 and IPv6
addresses and we choose a random resolved address in aaa-ldap when
connecting. Enabling IPv6 by default was introduced in
https://bugzilla.redhat.com/1726189 but unfortunately we have missed this
scenario (engine IPv4, LDAP dual IPv4/IPv6) during testing ...


> Jiri
>
>
> >
> > Thanks,
> > Martin
> >
> >
> > On Thu, Oct 1, 2020 at 11:17 AM Jiří Sléžka  > > wrote:
> >
> > Hi,
> >
> > I just upgraded my HE to 4.4.2 but now I cannot login using my ldap
> aaa
> > profile anymore.
> >
> > We are using Novell/NetIQ E-directory (load ballanced by haproxy,
> > probably not important...)
> >
> > In 4.4.1 I was hit by removed TLSv1 (which is the newest protocol
> > supported by our edir) from default crypto policies but I was able
> > revert it by
> >
> > update-crypto-policies --set LEGACY
> >
> > after upgrade to 4.4.2 the error is
> >
> > server_error: An error occurred while attempting to connect to server
> > ldap1.slu.cz:389 :
> > IOException(LDAPException(resultCode=91 (connect
> > error), errorMessage='An error occurred while attempting to
> establish a
> > connection to server ldap1.slu.cz/193.84.206.212:389
> > :
> > SocketException(Network is unreachable (connect failed)),
> > ldapSDKVersion=4.0.14,
> > revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
> >
> > but our ldap server is reachable from ovirt, I tested it via (also
> ldaps
> > and startls variants are working)
> >
> > ldapsearch -H ldap://ldap1.slu.cz  -x -D
> > cn=*,ou=**,o=su -w
> > '' -b 'o=su'
> >
> > As a workaround I tried to set plain ldap protocol in profile
> >
> > cat /etc/ovirt-engine/aaa/CRO.properties
> >
> >
> > include = 
> >
> > vars.server = ldap1.slu.cz 
> > vars.port = 389
> > vars.user = cn=*,ou=**,o=su
> > vars.password = **
> >
> > pool.default.serverset.single.server = ${global:vars.server}
> > pool.default.serverset.single.port = ${global:vars.port}
> > pool.default.auth.simple.bindDN = ${global:vars.user}
> > pool.default.auth.simple.password = ${global:vars.password}
> >
> > pool.default.ssl.startTLS = false
> > pool.default.ssl.enable = false
> > #pool.default.ssl.protocol = TLSv1
> > #pool.default.ssl.startTLSProtocol = TLSv1
> > #pool.default.ssl.insecure = true
> >
> > sequence-init.init.100-my-edir-init-vars = my-edir-init-vars
> > sequence.my-edir-init-vars.010.description = set baseDN
> > sequence.my-edir-init-vars.010.type = var-set
> > sequence.my-edir-init-vars.010.var-set.variable = simple_baseDN
> > sequence.my-edir-init-vars.010.var-set.value = o=su
> >
> > #search.default.search-request.derefPolicy = ALWAYS
> >
> >
> > but the error is the same...
> >
> > ovirt-engine-extensions-tool aaa login-user --profile=CRO
> > --user-name=my_user
> >
> > 
> > WARNING:
> [ovirt-engine-extension-aaa-ldap.authn::SU-LDAP-authentication]
> > TLS/SSL insecure mode
> > ...
> > WARNING: [ovirt-engine-extension-aaa-ldap.authn::auth.CRO.slu.cz
> > ] Cannot
> > initialize LDAP framework, deferring initialization. Error: An error
> > occurred while attempting to connect to server ldap1.slu.cz:389
> > :
> > IOException(LDAPException(resultCode=91 (connect error),
> > errorMessage='An error occurred while attempting to establish a
> > connection to server ldap1.slu.cz/193.84.206.212:389
> > :
> > SocketException(Network is unreachable (connect failed)),
> > ldapSDKVersion=4.0.14,
> > revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
> > ...
> > INFO: API: -->Authn.InvokeCommands.AUTHENTICATE_CREDENTIALS
> > profile='CRO' user='my_user'
> > Password:
> > ...
> > WARNING: [ovirt-engine-extension-aaa-ldap.authn::auth.CRO.slu.cz
> > ] Cannot
> > initialize LDAP framework, deferring initialization. Error: An error
> > occurred while attempting to connect to server ldap1.slu.cz:389
> > :
> > IOException(LDAPException(resultCode=91 (connect error),
> >

[ovirt-users] Re: ldap auth problem after upgrade from 4.4.1 to 4.4.2

[Jiří Sléžka]

Hi,

On 10/1/20 2:53 PM, Martin Perina wrote:
> Hi,
> 
> it seems that you are affected by
> https://bugzilla.redhat.com/show_bug.cgi?id=1880149
> Could you please try the workaround mentioned there?

bingo! Thanks a lot!

It is interesting behavior as my engine has no public ipv6 address (ipv6
is set to ignore in nm).

also

[root@ovirt ~]# ping6 google.com
connect: Network is unreachable

but ok, problem is solved :-)

Jiri


> 
> Thanks,
> Martin
> 
> 
> On Thu, Oct 1, 2020 at 11:17 AM Jiří Sléžka  > wrote:
> 
> Hi,
> 
> I just upgraded my HE to 4.4.2 but now I cannot login using my ldap aaa
> profile anymore.
> 
> We are using Novell/NetIQ E-directory (load ballanced by haproxy,
> probably not important...)
> 
> In 4.4.1 I was hit by removed TLSv1 (which is the newest protocol
> supported by our edir) from default crypto policies but I was able
> revert it by
> 
> update-crypto-policies --set LEGACY
> 
> after upgrade to 4.4.2 the error is
> 
> server_error: An error occurred while attempting to connect to server
> ldap1.slu.cz:389 :
> IOException(LDAPException(resultCode=91 (connect
> error), errorMessage='An error occurred while attempting to establish a
> connection to server ldap1.slu.cz/193.84.206.212:389
> :
> SocketException(Network is unreachable (connect failed)),
> ldapSDKVersion=4.0.14,
> revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
> 
> but our ldap server is reachable from ovirt, I tested it via (also ldaps
> and startls variants are working)
> 
> ldapsearch -H ldap://ldap1.slu.cz  -x -D
> cn=*,ou=**,o=su -w
> '' -b 'o=su'
> 
> As a workaround I tried to set plain ldap protocol in profile
> 
> cat /etc/ovirt-engine/aaa/CRO.properties
> 
> 
> include = 
> 
> vars.server = ldap1.slu.cz 
> vars.port = 389
> vars.user = cn=*,ou=**,o=su
> vars.password = **
> 
> pool.default.serverset.single.server = ${global:vars.server}
> pool.default.serverset.single.port = ${global:vars.port}
> pool.default.auth.simple.bindDN = ${global:vars.user}
> pool.default.auth.simple.password = ${global:vars.password}
> 
> pool.default.ssl.startTLS = false
> pool.default.ssl.enable = false
> #pool.default.ssl.protocol = TLSv1
> #pool.default.ssl.startTLSProtocol = TLSv1
> #pool.default.ssl.insecure = true
> 
> sequence-init.init.100-my-edir-init-vars = my-edir-init-vars
> sequence.my-edir-init-vars.010.description = set baseDN
> sequence.my-edir-init-vars.010.type = var-set
> sequence.my-edir-init-vars.010.var-set.variable = simple_baseDN
> sequence.my-edir-init-vars.010.var-set.value = o=su
> 
> #search.default.search-request.derefPolicy = ALWAYS
> 
> 
> but the error is the same...
> 
> ovirt-engine-extensions-tool aaa login-user --profile=CRO
> --user-name=my_user
> 
> 
> WARNING: [ovirt-engine-extension-aaa-ldap.authn::SU-LDAP-authentication]
> TLS/SSL insecure mode
> ...
> WARNING: [ovirt-engine-extension-aaa-ldap.authn::auth.CRO.slu.cz
> ] Cannot
> initialize LDAP framework, deferring initialization. Error: An error
> occurred while attempting to connect to server ldap1.slu.cz:389
> :
> IOException(LDAPException(resultCode=91 (connect error),
> errorMessage='An error occurred while attempting to establish a
> connection to server ldap1.slu.cz/193.84.206.212:389
> :
> SocketException(Network is unreachable (connect failed)),
> ldapSDKVersion=4.0.14,
> revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
> ...
> INFO: API: -->Authn.InvokeCommands.AUTHENTICATE_CREDENTIALS
> profile='CRO' user='my_user'
> Password:
> ...
> WARNING: [ovirt-engine-extension-aaa-ldap.authn::auth.CRO.slu.cz
> ] Cannot
> initialize LDAP framework, deferring initialization. Error: An error
> occurred while attempting to connect to server ldap1.slu.cz:389
> :
> IOException(LDAPException(resultCode=91 (connect error),
> errorMessage='An error occurred while attempting to establish a
> connection to server ldap1.slu.cz/193.84.206.212:389
> :
> SocketException(Network is unreachable (connect failed)),
> ldapSDKVersion=4.0.14,
> revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
> Oct 01, 2020 10:57:37 AM
> org.ovirt.engine.exttool.core.ExtensionsToolExecutor main
> SEVERE: An error occurred while attempting to connect to server
> ldap1.slu.cz:389 : 
> IOException(LDAPException(resultCode=91 (connect
> error), err

[ovirt-users] Re: ldap auth problem after upgrade from 4.4.1 to 4.4.2

[Martin Perina]

Hi,

it seems that you are affected by
https://bugzilla.redhat.com/show_bug.cgi?id=1880149
Could you please try the workaround mentioned there?

Thanks,
Martin


On Thu, Oct 1, 2020 at 11:17 AM Jiří Sléžka  wrote:

> Hi,
>
> I just upgraded my HE to 4.4.2 but now I cannot login using my ldap aaa
> profile anymore.
>
> We are using Novell/NetIQ E-directory (load ballanced by haproxy,
> probably not important...)
>
> In 4.4.1 I was hit by removed TLSv1 (which is the newest protocol
> supported by our edir) from default crypto policies but I was able
> revert it by
>
> update-crypto-policies --set LEGACY
>
> after upgrade to 4.4.2 the error is
>
> server_error: An error occurred while attempting to connect to server
> ldap1.slu.cz:389: IOException(LDAPException(resultCode=91 (connect
> error), errorMessage='An error occurred while attempting to establish a
> connection to server ldap1.slu.cz/193.84.206.212:389:
> SocketException(Network is unreachable (connect failed)),
> ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
>
> but our ldap server is reachable from ovirt, I tested it via (also ldaps
> and startls variants are working)
>
> ldapsearch -H ldap://ldap1.slu.cz -x -D cn=*,ou=**,o=su -w
> '' -b 'o=su'
>
> As a workaround I tried to set plain ldap protocol in profile
>
> cat /etc/ovirt-engine/aaa/CRO.properties
>
>
> include = 
>
> vars.server = ldap1.slu.cz
> vars.port = 389
> vars.user = cn=*,ou=**,o=su
> vars.password = **
>
> pool.default.serverset.single.server = ${global:vars.server}
> pool.default.serverset.single.port = ${global:vars.port}
> pool.default.auth.simple.bindDN = ${global:vars.user}
> pool.default.auth.simple.password = ${global:vars.password}
>
> pool.default.ssl.startTLS = false
> pool.default.ssl.enable = false
> #pool.default.ssl.protocol = TLSv1
> #pool.default.ssl.startTLSProtocol = TLSv1
> #pool.default.ssl.insecure = true
>
> sequence-init.init.100-my-edir-init-vars = my-edir-init-vars
> sequence.my-edir-init-vars.010.description = set baseDN
> sequence.my-edir-init-vars.010.type = var-set
> sequence.my-edir-init-vars.010.var-set.variable = simple_baseDN
> sequence.my-edir-init-vars.010.var-set.value = o=su
>
> #search.default.search-request.derefPolicy = ALWAYS
>
>
> but the error is the same...
>
> ovirt-engine-extensions-tool aaa login-user --profile=CRO
> --user-name=my_user
>
> 
> WARNING: [ovirt-engine-extension-aaa-ldap.authn::SU-LDAP-authentication]
> TLS/SSL insecure mode
> ...
> WARNING: [ovirt-engine-extension-aaa-ldap.authn::auth.CRO.slu.cz] Cannot
> initialize LDAP framework, deferring initialization. Error: An error
> occurred while attempting to connect to server ldap1.slu.cz:389:
> IOException(LDAPException(resultCode=91 (connect error),
> errorMessage='An error occurred while attempting to establish a
> connection to server ldap1.slu.cz/193.84.206.212:389:
> SocketException(Network is unreachable (connect failed)),
> ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
> ...
> INFO: API: -->Authn.InvokeCommands.AUTHENTICATE_CREDENTIALS
> profile='CRO' user='my_user'
> Password:
> ...
> WARNING: [ovirt-engine-extension-aaa-ldap.authn::auth.CRO.slu.cz] Cannot
> initialize LDAP framework, deferring initialization. Error: An error
> occurred while attempting to connect to server ldap1.slu.cz:389:
> IOException(LDAPException(resultCode=91 (connect error),
> errorMessage='An error occurred while attempting to establish a
> connection to server ldap1.slu.cz/193.84.206.212:389:
> SocketException(Network is unreachable (connect failed)),
> ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
> Oct 01, 2020 10:57:37 AM
> org.ovirt.engine.exttool.core.ExtensionsToolExecutor main
> SEVERE: An error occurred while attempting to connect to server
> ldap1.slu.cz:389:  IOException(LDAPException(resultCode=91 (connect
> error), errorMessage='An error occurred while attempting to establish a
> connection to server ldap1.slu.cz/193.84.206.212:389:
> SocketException(Network is unreachable (connect failed)),
> ldapSDKVersion=4.0.14, revision=c0fb784eebf9d36a67c736d0428fb3577f2e25bb'))
>
> debug with tcpdump reveals only that connection is made and there are
> only "bindRequest" and "bindResponse success" messages visible (with
> correct tcp handshake and close) and nothing more
>
> any help would be appreciated
>
> Cheers,
>
> Jiri
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/M4MFGXGJ33R5DFX66HHGENOROHGOTF2D/
>


-- 
Martin Perina
Manager, Software Engineering
Red Hat Czech s.r.o.
___
Users mail

[ovirt-users] Re: LDAP/AD issue

[Staniforth, Paul]

Hi Kim,
   it will be using the engine hosts DNS configuration to find the 
service record, is it in stud.noroff.no or one of the other domains?

you can check with "dig _ldap._tcp.example.com SRV"

DNS and Active directory domains aren't the same thing.

there are examples of different A.D. configurations are in 
/usr/share/ovirt-engine-extension-aaa-ldap/examples

you can also use the tool  ovirt-engine-extension-aaa-ldap-setup

Some of the useful things to find out for you organization is
The forest name  A.D default domain, GC global catalogue.
as well as the UPN account the users probably have a sAMAccountName.


Regards,
  Paul S.



From: kim.karga...@noroff.no 
Sent: 26 August 2020 13:01
To: users@ovirt.org 
Subject: [ovirt-users] LDAP/AD issue

Caution External Mail: Do not click any links or open any attachments unless 
you trust the sender and know that the content is safe.

Hi all,

We have had our ovirt instance connected to our internal AD for users to log 
into the VM portal for the last year, linked to studentdomene.noroff.no. This 
has been working without any problems. We had it set up and the DNS server had 
a forward record to the DC's. All good.

Then, of course, the institution decided to introduce student emails and they 
decided to add the domain stud.noroff.no for student emails and made this the 
primary domain in the AD. The problem is that when this is changed, students 
can no longer log into the engine. I have of course changed the ldap settings 
and added a forward record on the DNS to the new domain. However, it seems that 
the domain is studentdomene.noroff.no, but with an added UPN suffix with 
stud.noroff.no

When students try to log in, with the config changes, they get this error in 
the browser:

server_error: An error occurred while attempting to query DNS in order to 
retrieve SRV records with name '_ldap._tcp.stud.noroff.no': 
NameNotFoundException(DNS name not found [response code 3]), 
ldapSDKVersion=4.0.7, revision=b28fb50058dfe2864171df2448ad2ad2b4c2ad58

Any ideas on how to solve this issue?

My config looks like this:

sudo cat /etc/ovirt-engine/aaa/Students.properties
[sudo] password for noroffadmin:
include = 

vars.domain = studentdomene.noroff.no
vars.user = CN=ovirt auth,CN=Users,DC=stud,DC=noroff,DC=no
vars.password = PASSWORD

pool.default.auth.simple.bindDN = ${global:vars.user}
pool.default.auth.simple.password = ${global:vars.password}
pool.default.serverset.type = srvrecord
pool.default.serverset.srvrecord.domain = ${global:vars.domain}

my forward on the DNS server looks like this:
sudo cat /etc/named/named.conf.local
[sudo] password for noroffadmin:
zone "platform.noroff.no"{
type master;
file "/etc/named/zones/db.platform.noroff.no";  # zone file path
};
zone "stud.noroff.no" {
type forward;
forward only;
forwarders { 172.24.111.20; 172.27.111.20; 172.21.111.20; 
172.16.111.20; };
};
zone "studentdomene.noroff.no" {
type forward;
forward only;
forwarders { 172.24.111.20; 172.27.111.20; 172.21.111.20; 
172.16.111.20; };
};
zone "122.16.172.in-addr.arpa" {
type master;
file "/etc/named/zones/db.122.16.172";  # 172.16.122.0/24 subnet
};

Any pointers would be greatly appreciated :)

Kim
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fprivacy-policy.html&data=02%7C01%7Cp.staniforth%40leedsbeckett.ac.uk%7C3c76fd23065347b640d608d849b87173%7Cd79a81124fbe417aa112cd0fb490d85c%7C0%7C0%7C637340403828422768&sdata=ROiY8odta%2FjSgFd6zQSSoCPXuo5JSYTSnGXAfiAOBs8%3D&reserved=0
oVirt Code of Conduct: 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ovirt.org%2Fcommunity%2Fabout%2Fcommunity-guidelines%2F&data=02%7C01%7Cp.staniforth%40leedsbeckett.ac.uk%7C3c76fd23065347b640d608d849b87173%7Cd79a81124fbe417aa112cd0fb490d85c%7C0%7C0%7C637340403828422768&sdata=EyzNyb%2FruzMS0SFfvDqWmXwLYuYknVcN%2FnMbbgwPD9c%3D&reserved=0
List Archives: 
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.ovirt.org%2Farchives%2Flist%2Fusers%40ovirt.org%2Fmessage%2F4NUUMBLEUD2MYZVAMGY2AJVBS235CEQK%2F&data=02%7C01%7Cp.staniforth%40leedsbeckett.ac.uk%7C3c76fd23065347b640d608d849b87173%7Cd79a81124fbe417aa112cd0fb490d85c%7C0%7C0%7C637340403828422768&sdata=%2FUeHhCgeQro6Ec%2FiPNWNhkDGubYGkqgWXUQpow2UnkI%3D&reserved=0
To view the terms under which this email is distributed, please go to:-
http://leedsbeckett.ac.uk/disclaimer/email/
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
ht

[ovirt-users] Re: LDAP setup fails on 4.4 reading PEM file

[Eli Mesika]

IMO your first error
[ ERROR ] Failed to execute stage 'Environment customization': a
byte-like object is required, not 'str'

seems to me as related to python2=>python3 upgrade and worth filing a bug
with all the relevant details


On Thu, Jun 11, 2020 at 8:38 PM Stack Korora 
wrote:

> Greetings,
> I'm having some issues getting LDAP working on CentOS 8 with oVirt 4.4.
> I would appreciate some help please.
>
> When I run ovirt-engine-extension-aaa-ldap-setup I choose "11 - RFC-2307
> Schema (Generic)" because that's what my LDAP guy said I should do. :-)
>
> Next I select the default Yes for "Use DNS".
>
> I select 4 for "Failover between multiple hosts".
>
> I put in my two hosts "svr1.my.domain srv2.my.domain".
>
> To select the protocol I type "ldaps".
>
> To select the method to obtain the PEM I type "File".
>
> Then the "File path". A full path to the file. Not quoted. Yes, I
> checked that I typed it correct. I can copy-paste into "ls" and it's
> fine with the correct read permissions and everything. (I can't copy
> paste into the script but that's another issue.)
>
> It immediately fails with:
> [ ERROR ] Failed to execute stage 'Environment customization': a
> byte-like object is required, not 'str'
>
> There is a log file, here is the snippet at the point it goes wrong.
>
> 2020-06-11 11:35:49,915-0500 DEBUG otopi.plugins.otopi.dialog.human
> dialog.__logString:204 DIALOG:SEND File path:
> 2020-06-11 11:36:24,373-0500 DEBUG otopi.plugins.otopi.dialog.human
> dialog.__logString:204 DIALOG:RECEIVE
> /etc/pki/ca-trust/source/anchors/Infrastructure.pem
> 2020-06-11 11:36:24,375-0500 DEBUG otopi.context
> context._executeMethod:145 method exception
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 132, in
> _executeMethod
> method['method']()
>   File
>
> "/usr/share/ovirt-engine-extension-aaa-ldap/setup/bin/../plugins/ovirt-engine-extension-aaa-ldap/ldap/common.py",
> line 781, in _customization_late
> cacert, cacertfile, insecure = self._getCACert()
>   File
>
> "/usr/share/ovirt-engine-extension-aaa-ldap/setup/bin/../plugins/ovirt-engine-extension-aaa-ldap/ldap/common.py",
> line 357, in _getCACert
> _cacertfile.write('\n'.join(cacert) + '\n')
>   File "/usr/lib64/python3.6/tempfile.py", line 485, in func_wrapper
> return func(*args, **kwargs)
> TypeError: a bytes-like object is required, not 'str'
> 2020-06-11 11:36:24,376-0500 ERROR otopi.context
> context._executeMethod:154 Failed to execute stage 'Environment
> customization': a bytes-like object is required, not 'str'
> 2020-06-11 11:36:24,376-0500 DEBUG otopi.context
> context.dumpEnvironment:765 ENVIRONMENT DUMP - BEGIN
> 2020-06-11 11:36:24,376-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV BASE/error=bool:'True'
> 2020-06-11 11:36:24,376-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV BASE/exceptionInfo=list:'[( 'TypeError'>, TypeError("a bytes-like object is required, not 'str'",),
> )]'
> 2020-06-11 11:36:24,377-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/hosts=str:'svr1.my.domain
> srv2.my.domain'
> 2020-06-11 11:36:24,377-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/protocol=str:'ldaps'
> 2020-06-11 11:36:24,377-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/serverset=str:'failover'
> 2020-06-11 11:36:24,377-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/useDNS=bool:'True'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV
>
> QUESTION/1/OVAAALDAP_LDAP_CACERT_FILE=str:'/etc/pki/ca-trust/source/anchors/Infrastructure.pem'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV
> QUESTION/1/OVAAALDAP_LDAP_CACERT_METHOD=str:'file'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV
> QUESTION/1/OVAAALDAP_LDAP_PROTOCOL=str:'ldaps'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV QUESTION/1/OVAAALDAP_LDAP_SERVERSET=str:'4'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV QUESTION/1/OVAAALDAP_LDAP_USE_DNS=str:'yes'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV
> QUESTION/2/OVAAALDAP_LDAP_SERVERSET=str:'svr1.my.domain srv2.my.domain'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:779 ENVIRONMENT DUMP - END
>
>
> Can someone help please?
> Thanks!
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/MHBAPSJOFLAWFMBT4HPJAZUYB3ODL7BX/
>
___

[ovirt-users] Re: LDAP setup fails on 4.4 reading PEM file

[Stack Korora]

On 2020-06-11 20:55, Stack Korora wrote:
> Well made one discovery. While named with an 's' in EL7, in EL8 that 's'
> is missing. ovirt-engine-extensions-aaa-ldap is now
> ovirt-engine-extension-aaa-ldap.
>
> However, even after fixing that in the properties it still gives the
> same error message (just missing the 's' now). I do have the packages
> installed and I do have
> /usr/share/java/ovirt-engine-extension-aaa-ldap/ovirt-engine-extension-aaa-ldap.jar
> (and the symlinks that point there). Still throws errors. :-(

I finally cracked it. There's a bunch of small minor changes that don't
allow for the config file from 4.3 to work with 4.4. Things like
dropping the 's' or exchanging the '-' for '.'.  Also had a heck of a
time with the ugly verbosity of the output from
ovirt-engine-extension-aaa-ldap tool. Not nearly as clean as it was
under 4.3.

But, as I said, I cracked the issue and I've got it working. Thanks to
all on the list. I found a lot of good info in searching the archive.

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

[ovirt-users] Re: LDAP setup fails on 4.4 reading PEM file

[Stack Korora]

On 2020-06-11 20:32, Stack Korora wrote:
> [snip]
>> Since I wasn't getting anywhere with this, I decided to try a few
>> things. I copied the following files from a working 4.3 on RHEL 7
>> (again, this setup is CentOS8 with 4.4):
>> /etc/ovirt-engine/aaa/ldap.jks
>> /etc/ovirt-engine/aaa/ldap.properties
>> /etc/ovirt-engine/extensions.d/ldap-authn.properties
>> /etc/ovirt-engine/extensions.d/ldap-authz.properties
>>
>> I verified permissions were all good (including SELinux). I restarted a
>> few services but wasn't getting anything at all of value telling me what
>> was wrong...so I rebooted. That did the trick! Now I get an error,
>> though nothing of use is turning up from the internet searches.
>>
>> # ovirt-engine-extensions-tool info list-extensions
>> [snip]
>> SEVERE: Extension 'ldap-authn.properties' load failed (ignored): Error
>> loading 'ldap-authn': The module 'org.ovirt.engine-extensions.aaa.ldap'
>> cannot be loaded: org.ovirt.engine-extensions.aaa.ldap
>> SEVERE: Extension 'ldap-authn.properties' load failed (ignored): Error
>> loading 'ldap-authz': The module 'org.ovirt.engine-extensions.aaa.ldap'
>> cannot be loaded: org.ovirt.engine-extensions.aaa.ldap
>> [snip]
>>
>> I do have these packages installed:
>> ovirt-engine-extensions-aaa-ldap
>> ovirt-engine-extensions-aaa-ldap-setup

Well made one discovery. While named with an 's' in EL7, in EL8 that 's'
is missing. ovirt-engine-extensions-aaa-ldap is now
ovirt-engine-extension-aaa-ldap.

However, even after fixing that in the properties it still gives the
same error message (just missing the 's' now). I do have the packages
installed and I do have
/usr/share/java/ovirt-engine-extension-aaa-ldap/ovirt-engine-extension-aaa-ldap.jar
(and the symlinks that point there). Still throws errors. :-(

Thoughts? Thanks!

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

[ovirt-users] Re: LDAP setup fails on 4.4 reading PEM file

[Stack Korora]

Bottom posted update:

On 2020-06-11 17:35, Stack Korora wrote:
> Greetings,
> I'm having some issues getting LDAP working on CentOS 8 with oVirt 4.4.
> I would appreciate some help please.
>
> When I run ovirt-engine-extension-aaa-ldap-setup I choose "11 - RFC-2307
> Schema (Generic)" because that's what my LDAP guy said I should do. :-)
>
> Next I select the default Yes for "Use DNS".
>
> I select 4 for "Failover between multiple hosts".
>
> I put in my two hosts "svr1.my.domain srv2.my.domain".
>
> To select the protocol I type "ldaps".
>
> To select the method to obtain the PEM I type "File".
>
> Then the "File path". A full path to the file. Not quoted. Yes, I
> checked that I typed it correct. I can copy-paste into "ls" and it's
> fine with the correct read permissions and everything. (I can't copy
> paste into the script but that's another issue.)
>
> It immediately fails with:
> [ ERROR ] Failed to execute stage 'Environment customization': a
> byte-like object is required, not 'str'
>
> There is a log file, here is the snippet at the point it goes wrong.
>
> 2020-06-11 11:35:49,915-0500 DEBUG otopi.plugins.otopi.dialog.human
> dialog.__logString:204 DIALOG:SEND File path:
> 2020-06-11 11:36:24,373-0500 DEBUG otopi.plugins.otopi.dialog.human
> dialog.__logString:204 DIALOG:RECEIVE
> /etc/pki/ca-trust/source/anchors/Infrastructure.pem
> 2020-06-11 11:36:24,375-0500 DEBUG otopi.context
> context._executeMethod:145 method exception
> Traceback (most recent call last):
>   File "/usr/lib/python3.6/site-packages/otopi/context.py", line 132, in
> _executeMethod
> method['method']()
>   File
> "/usr/share/ovirt-engine-extension-aaa-ldap/setup/bin/../plugins/ovirt-engine-extension-aaa-ldap/ldap/common.py",
> line 781, in _customization_late
> cacert, cacertfile, insecure = self._getCACert()
>   File
> "/usr/share/ovirt-engine-extension-aaa-ldap/setup/bin/../plugins/ovirt-engine-extension-aaa-ldap/ldap/common.py",
> line 357, in _getCACert
> _cacertfile.write('\n'.join(cacert) + '\n')
>   File "/usr/lib64/python3.6/tempfile.py", line 485, in func_wrapper
> return func(*args, **kwargs)
> TypeError: a bytes-like object is required, not 'str'
> 2020-06-11 11:36:24,376-0500 ERROR otopi.context
> context._executeMethod:154 Failed to execute stage 'Environment
> customization': a bytes-like object is required, not 'str'
> 2020-06-11 11:36:24,376-0500 DEBUG otopi.context
> context.dumpEnvironment:765 ENVIRONMENT DUMP - BEGIN
> 2020-06-11 11:36:24,376-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV BASE/error=bool:'True'
> 2020-06-11 11:36:24,376-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV BASE/exceptionInfo=list:'[( 'TypeError'>, TypeError("a bytes-like object is required, not 'str'",),
> )]'
> 2020-06-11 11:36:24,377-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/hosts=str:'svr1.my.domain
> srv2.my.domain'
> 2020-06-11 11:36:24,377-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/protocol=str:'ldaps'
> 2020-06-11 11:36:24,377-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/serverset=str:'failover'
> 2020-06-11 11:36:24,377-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV OVAAALDAP_LDAP/useDNS=bool:'True'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV
> QUESTION/1/OVAAALDAP_LDAP_CACERT_FILE=str:'/etc/pki/ca-trust/source/anchors/Infrastructure.pem'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV
> QUESTION/1/OVAAALDAP_LDAP_CACERT_METHOD=str:'file'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV
> QUESTION/1/OVAAALDAP_LDAP_PROTOCOL=str:'ldaps'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV QUESTION/1/OVAAALDAP_LDAP_SERVERSET=str:'4'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV QUESTION/1/OVAAALDAP_LDAP_USE_DNS=str:'yes'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:775 ENV
> QUESTION/2/OVAAALDAP_LDAP_SERVERSET=str:'svr1.my.domain srv2.my.domain'
> 2020-06-11 11:36:24,378-0500 DEBUG otopi.context
> context.dumpEnvironment:779 ENVIRONMENT DUMP - END
>

Since I wasn't getting anywhere with this, I decided to try a few
things. I copied the following files from a working 4.3 on RHEL 7
(again, this setup is CentOS8 with 4.4):
/etc/ovirt-engine/aaa/ldap.jks
/etc/ovirt-engine/aaa/ldap.properties
/etc/ovirt-engine/extensions.d/ldap-authn.properties
/etc/ovirt-engine/extensions.d/ldap-authz.properties

I verified permissions were all good (including SELinux). I restarted a
few services but wasn't getting anything at all of value telling me what
was wrong...so I rebooted. That did the trick! Now I get an error,
though nothing of use is turning up from the internet searches.

# ovirt-engine-extensions-tool info list-extensions
[snip]
SEVERE: Extension 'ldap-authn.prop

[ovirt-users] Re: LDAP

[Wesley Stewart]

https://www.ovirt.org/documentation/admin-guide/chap-Users_and_Roles.html

Specifically:
ovirt-engine-extension-aaa-ldap

This will help you log into the console.  The
Guest will need to bind or setup ldap normally.  Ovirt auth would not pass
through to the guest.

On Fri, Mar 20, 2020, 1:58 PM Nicholas Emmerling 
wrote:

> Would you please provide any documentation you have regarding configuring
> oVirt to work with LDAP. Preferably the guest VMs as well as the
> Hosts/Nodes themselves. Thank you.
>
> nicholas.emmerl...@me.com
>
>
> Sent from my iPhone
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/privacy-policy.html
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/users@ovirt.org/message/CV7IAUQHUC2YIAHITQKDN5YIYSR533AE/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/27OJDWNVI5EOTHZ6M4EKRSG2H2SY73I6/

[ovirt-users] Re: LDAP - not able to find members of groups

[Timmi]

Hi Ondra,

thank you for the reply.

The openldap.properties did not work with my openLDAP config.
It looks like I'm using a kind of RFC2307bis configuration but I managed 
to solve problem while overwriting the following search filter:

search.rfc2307-resolve-groups-memberUid.search-request.filter

The test tool is providing me all assigned groups for my user now.
ovirt-engine-extensions-tool aaa login-user --profile=domain.com 
--user-name=timmi


Best regards
Timmi


Am 09.05.19 um 09:18 schrieb Ondra Machacek:

By default the openldap configuration on oVirt does connect it via
member attribute of the group, so you shouldn't have any issue logging
in as user from some group. We support also memberOf plugin, but it's
not default for openldap.

On 08/05/2019 13:10, Timmi wrote:

Hi oVirt List,

I manage to connect oVirt to my LDAP and I'm able to search for users 
and groups.


I'm using openLDAP within a ClearOS installation and it looks like 
this is a bit different to the standard openLDAP.


Inside the LDAP groups there is an attribute with is calls "member".

Example:
member    cn=Timmi,ou=Users,ou=Accounts,dc=domain,dc=com

Is someone able to help me how to make sure that oVirt is able to 
join the users to the groups?


Best regards
Timmi
___
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/PBQXDJGOZ2ET347YDZFSQPFJGMNSALHD/ 




___
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/B56SJNLXPVP3XMXVCDS7JW4NM2JKRQK4/

[ovirt-users] Re: LDAP - not able to find members of groups

[Ondra Machacek]

By default the openldap configuration on oVirt does connect it via
member attribute of the group, so you shouldn't have any issue logging
in as user from some group. We support also memberOf plugin, but it's
not default for openldap.

On 08/05/2019 13:10, Timmi wrote:

Hi oVirt List,

I manage to connect oVirt to my LDAP and I'm able to search for users 
and groups.


I'm using openLDAP within a ClearOS installation and it looks like this 
is a bit different to the standard openLDAP.


Inside the LDAP groups there is an attribute with is calls "member".

Example:
member    cn=Timmi,ou=Users,ou=Accounts,dc=domain,dc=com

Is someone able to help me how to make sure that oVirt is able to join 
the users to the groups?


Best regards
Timmi
___
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/PBQXDJGOZ2ET347YDZFSQPFJGMNSALHD/ 


___
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/EEPERSQD5IMKNYHCS7MUSNVARTPWJSLN/

[ovirt-users] Re: LDAP Bind failing because of SSLHandshakeException after Virtualization Manager was rebooted

[Ondra Machacek]

On 11/13/18 10:09 PM, Will Hegedus wrote:

So, it turns out that one of the domain controllers had a different certificate 
chain (outside of my team's control) which was inexplicably causing the whole 
thing to fail.

I would run "ovirt-engine-extensions-tool --log-level=FINEST --log-file=/tmp/aaa.log aaa login-user 
--user-name=prea...@liberty.edu --profile=liberty.edu" and everything would look fine up until the point 
that it needed to "doFetchPrincipalRecord", at which point it would fail to get the principal 
record for the account. The bind would succeed, but because "Creating LDAPConnectionPool" would 
fail on *just one* of the domain controllers, it for some reason seemed to invalidate all of the entries in 
that pool, thereby causing the fetching of principal records to fail even though the bind succeeded on one of 
the OK domain controllers.

Is this behavior intended? I really think this should be classified as a bug.

For what it's worth, this was resolved by getting the certificate chain from 
the problem DC and then adding it to the Java Keystore with the other 
certificate chain that all the other domain controllers use.


Please open a bug will detail information of the AD infrastructure, like
what's the forest what's the domains, and which DC are in domain, and I
will try to take a look. Thanks a lot!


___
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/ZCQPBSP4HW35JNJDPJUULDQVAP7C5A43/


___
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/JNWW5R2Y5AA2TX3HRZD5VLJQCFKRESOV/

[ovirt-users] Re: LDAP Bind failing because of SSLHandshakeException after Virtualization Manager was rebooted

[Will Hegedus]

So, it turns out that one of the domain controllers had a different certificate 
chain (outside of my team's control) which was inexplicably causing the whole 
thing to fail.

I would run "ovirt-engine-extensions-tool --log-level=FINEST 
--log-file=/tmp/aaa.log aaa login-user --user-name=prea...@liberty.edu 
--profile=liberty.edu" and everything would look fine up until the point that 
it needed to "doFetchPrincipalRecord", at which point it would fail to get the 
principal record for the account. The bind would succeed, but because "Creating 
LDAPConnectionPool" would fail on *just one* of the domain controllers, it for 
some reason seemed to invalidate all of the entries in that pool, thereby 
causing the fetching of principal records to fail even though the bind 
succeeded on one of the OK domain controllers.

Is this behavior intended? I really think this should be classified as a bug.

For what it's worth, this was resolved by getting the certificate chain from 
the problem DC and then adding it to the Java Keystore with the other 
certificate chain that all the other domain controllers use.
___
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/ZCQPBSP4HW35JNJDPJUULDQVAP7C5A43/

[ovirt-users] Re: LDAP-Error

[Budur Nagaraju]

Thanks for the update , done the changes by adding the below lines in the
(example.properties)

pool.default.serverset.type = srvrecord
pool.default.serverset.srvrecord.domain = ${global:vars.domain}
pool.default.auth.simple.bindDN = ${global:vars.user}
pool.default.auth.simple.password = ${global:vars.password}


On Thu, Sep 27, 2018 at 4:10 PM Ondra Machacek  wrote:

> You get following error:
>
>Internal Server Error: Cannot resolve principal 'nbud...@psecure.net'
> 2018-09-26 21:30:35,573+05 ERROR [org.ovirt.engine.core.sso.utils.SsoUt
>
> Meaning that user with UPN(user principal name) nbud...@psecure.net
> can't be found. Please double check if the user with that UPN exists.
>
> On 9/26/18 6:09 PM, Budur Nagaraju wrote:
> > Hi
> >
> > Have configured LDAP authentication in oVirt4.2, but unable to login
> facing
> > issues below is the error log and configuration, able to search the users
> > in the UI at same time unable to search the Group.
> >
> > Can someone help on the same?
> >
> >
> > Error :
> >
> > https://pastebin.com/76cZdV7d
> >
> > Configuration:
> >
> > https://pastebin.com/nRmibZh7
> >
> > Thanks,
> > Nagaraju
> >
> >
> > ___
> > 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/XYNGCLUPDFRI4QSGBBFSYXS4RIVSZZJU/
> >
>
___
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/QHJ45GLLTSTZGJTFTRPBT2URDQ22FERB/

[ovirt-users] Re: LDAP-Error

[Ondra Machacek]

You get following error:

  Internal Server Error: Cannot resolve principal 'nbud...@psecure.net'
2018-09-26 21:30:35,573+05 ERROR [org.ovirt.engine.core.sso.utils.SsoUt

Meaning that user with UPN(user principal name) nbud...@psecure.net 
can't be found. Please double check if the user with that UPN exists.


On 9/26/18 6:09 PM, Budur Nagaraju wrote:

Hi

Have configured LDAP authentication in oVirt4.2, but unable to login facing
issues below is the error log and configuration, able to search the users
in the UI at same time unable to search the Group.

Can someone help on the same?


Error :

https://pastebin.com/76cZdV7d

Configuration:

https://pastebin.com/nRmibZh7

Thanks,
Nagaraju


___
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/XYNGCLUPDFRI4QSGBBFSYXS4RIVSZZJU/


___
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/4GZ235JVW7YRRFXR54QNC4CTXTV7EREP/

[ovirt-users] Re: Ldap-configure

[Ondra Machacek]

Hi,

you can check the documentation:


https://www.ovirt.org/documentation/admin-guide/chap-Users_and_Roles/#chapter-15-users-and-roles

On 9/26/18 10:12 AM, Budur Nagaraju wrote:

Hi

Can you please let us know how to configure LDAP authentication in oVirt
4.2 ?

Thanks,
Nagaraju


___
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/DNHC4DIEM6OSYWR7XG4SXMHL7I6UUIE7/


___
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/I6EES4XIBQ65PSV64S5CMBU2IPLGSFEA/

[ovirt-users] Re: LDAP authentication does not work after engine upgrade to ovirt 4.6

[Michael Watters]

For those wondering, I was able to fix this by running
ovirt-engine-extension-aaa-ldap-setup and setting the CA certificate
method to "Insecure".

> Please select method to obtain PEM encoded CA certificate (File, URL,
Inline, System, Insecure): Insecure

I was previously using "System" but that does not work despite our
internal CA being installed as a trusted certificate authority.


On 09/11/2018 10:07 AM, Michael Watters wrote:
> I've just upgraded our ovirt engine server to ovirt 4.6 and it appears
> that LDAP logins no longer work.  When I attempt to log in using an AD
> account the following errors are shown in the engine log.
>
> 2018-09-11 10:03:44,610-04 ERROR
> [org.ovirt.engine.core.sso.servlets.InteractiveAuthServlet] (default
> task-10) [] Internal Server Error: Cannot locate principal
> 'usern...@example.com'
> 2018-09-11 10:03:44,610-04 ERROR
> [org.ovirt.engine.core.sso.utils.SsoUtils] (default task-10) [] Cannot
> locate principal 'usern...@example.com'
> 2018-09-11 10:03:44,645-04 ERROR
> [org.ovirt.engine.core.aaa.servlet.SsoPostLoginServlet] (default
> task-10) [] server_error: Cannot locate principal 'usern...@example.com'
>
> I have not changed any LDAP settings and ldapsearch is able to find this
> object without any issues.  Does anybody have any idea what would cause
> this?
>
>
> ___
> 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/JRRXINSYZXLGD4YCQL5NKEIRGMOCV4AV/
___
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/G5CBMR7SIB5BAYCYTBWAIV7GQ232ERHO/

[ovirt-users] Re: LDAP login extension

[Martin Perina]

On Wed, Jun 27, 2018 at 9:14 AM, Mariusz Kozakowski <
mariusz.kozakow...@sallinggroup.com> wrote:

> Hello,
>
> We managed to setup oVirt Engine with your help, now we're facing other
> issue.
>
> I'm trying to configure AD auth for web portal, but unfortunately I got
> error during ovirt-engine-extension-aaa-ldap-setup:
>
>
>   2018-06-27 09:06:21,926+02 INFO==
> ==
>   2018-06-27 09:06:21,926+02 INFO==
> Execution ===
>   2018-06-27 09:06:21,926+02 INFO==
> ==
>   2018-06-27 09:06:21,927+02 INFOIteration: 0
>   2018-06-27 09:06:21,928+02 INFOProfile='ad' authn='ad-authn'
> authz='ad-authz' mapping='null'
>   2018-06-27 09:06:21,928+02 INFOAPI: 
> -->Authn.InvokeCommands.AUTHENTICATE_CREDENTIALS
> profile='ad' user='username'
>   2018-06-27 09:06:21,945+02 INFOAPI: 
> <--Authn.InvokeCommands.AUTHENTICATE_CREDENTIALS
> profile='ad' result=SUCCESS
>   2018-06-27 09:06:21,948+02 INFO--- Begin AuthRecord ---
>   2018-06-27 09:06:21,949+02 INFOAAA_AUTHN_AUTH_RECORD_PRINCIPAL:
> username
>   2018-06-27 09:06:21,949+02 INFO--- End   AuthRecord ---
>   2018-06-27 09:06:21,950+02 INFOAPI:
> -->Authz.InvokeCommands.FETCH_PRINCIPAL_RECORD principal='username'
>   2018-06-27 09:06:21,952+02 WARNING Ignoring records from pool:
> 'gc'
>   2018-06-27 09:06:21,953+02 SEVERE  Cannot resolve principal
> 'username'
>

​Hi,

are you sure that you are trying to configure either "standalone AD domain"
or "AD forrest with ​multi-domain trust" using the tool? I'm asking because
if want to configure AD which is part of AD forrest, you cannot do that
using the tool, as this is advanced configuration. And we don't support
multi-forrest with multi-domain trusts at all.

Could you please describe your AD setup and share with us full output of
aaa-ldap-setup tool?

Thanks

Martin


> Do you have any idea what's the issue and what we're missing? As it looks
> like credentials are correct - passing wrong username gives fail earlier,
> so issue is somewhere after authentication.
>
> --
>
> Best regards/Pozdrawiam/MfG
>
> *Mariusz Kozakowski*
>
> Site Reliability Engineer
>
> Dansk Supermarked Group
> Baltic Business Park
> ul. 1 Maja 38-39
> 71-627 Szczecin
> dansksupermarked.com
>
> ___
> 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/6BZXOA6ZXMSN5EPC67LNBUSANJLUBHA7/
>
>


-- 
Martin Perina
Associate Manager, Software Engineering
Red Hat Czech s.r.o.
___
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/VD2CTLJTEA2MUKM3DHF2TFMBFIANAGKQ/

[ovirt-users] Re: LDAP logins do not work

[Michael Watters]

Thanks.  I've deleted the old roles/users and recreated them using the
System Permissions tab and logins are working now.


On 06/14/2018 09:20 AM, Ondra Machacek wrote:
> This error:
>
> The user u...@example.com@example.com is not authorized to perform login
>
> means that you don't have any role assigned to your user.
>
> Please check following documentation:
>
>
> https://www.ovirt.org/documentation/admin-guide/chap-Users_and_Roles/#user-authorization
>
>
> to understand permission model of oVirt.
>
> On 06/14/2018 02:39 PM, Michael Watters wrote:
>> ldapsearch works correctly and I'm able to bind to AD without any
>> issues.  ovirt-engine-extension-aaa-ldap-setup also shows searches
>> working correctly.
>>
>> One thing I've discovered is that I can login as "u...@domain.com" but
>> then receive an error as follows.
>>
>>> The user u...@example.com@example.com is not authorized to perform
>>> login
>>
>> How do I enable debug logs?  The log entries from the engine.log file
>> are the same as my previous message.
>>
>>
>> On 06/14/2018 06:37 AM, Ondra Machacek wrote:
>>> Can you share the debug log, and also make sure the search user you are
>>> using is correct for example by running the ldapsearch command with it.
>>>
>>> On 06/13/2018 05:33 PM, Michael Watters wrote:
 I've ran the ovirt-engine-extension-aaa-ldap-setup command to
 configure
 LDAP authentication using Active Directory however I am unable to
 authenticate using valid credentials.  Here is the output show while
 testing the login flow.

 [ INFO  ] Executing login sequence...
     Login output:
     2018-06-13 11:27:17,931-04 INFO
 

     2018-06-13 11:27:17,960-04 INFO
  Initialization
 
     2018-06-13 11:27:17,960-04 INFO
 

     2018-06-13 11:27:17,999-04 INFO    Loading extension
 'example.com-authn'
     2018-06-13 11:27:18,072-04 INFO    Extension
 'example.com-authn' loaded
     2018-06-13 11:27:18,077-04 INFO    Loading extension
 'example.com-authz'
     2018-06-13 11:27:18,089-04 INFO    Extension
 'example.com-authz' loaded
     2018-06-13 11:27:18,090-04 INFO    Initializing extension
 'example.com-authn'
     2018-06-13 11:27:18,091-04 INFO
 [ovirt-engine-extension-aaa-ldap.authn::example.com-authn] Creating
 LDAP
 pool 'authz'
     2018-06-13 11:27:19,574-04 WARNING Exception: 80090308:
 LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data
 52e,
 v3839
     2018-06-13 11:27:19,576-04 INFO
 [ovirt-engine-extension-aaa-ldap.authn::example.com-authn] Creating
 LDAP
 pool 'authn'
     2018-06-13 11:27:20,668-04 INFO
 [ovirt-engine-extension-aaa-ldap.authn::example.com-authn] LDAP pool
 'authn' information: vendor='null' version='null'
     2018-06-13 11:27:20,674-04 WARNING Ignoring records from
 pool:
 'authz'
     2018-06-13 11:27:20,676-04 WARNING Ignoring records from
 pool:
 'authz'
     2018-06-13 11:27:20,676-04 INFO    Extension
 'example.com-authn' initialized
     2018-06-13 11:27:20,677-04 INFO    Initializing extension
 'example.com-authz'
     2018-06-13 11:27:20,679-04 INFO
 [ovirt-engine-extension-aaa-ldap.authz::example.com-authz] Creating
 LDAP
 pool 'authz'
     2018-06-13 11:27:21,270-04 WARNING Exception: 80090308:
 LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data
 52e,
 v3839
     2018-06-13 11:27:21,273-04 INFO
 [ovirt-engine-extension-aaa-ldap.authz::example.com-authz] Creating
 LDAP
 pool 'gc'
     2018-06-13 11:27:22,065-04 WARNING Exception: 80090308:
 LdapErr: DSID-0C090400, comment: AcceptSecurityContext error, data
 52e,
 v1db1
     2018-06-13 11:27:22,069-04 WARNING Ignoring records from
 pool:
 'authz'
     2018-06-13 11:27:22,072-04 WARNING Ignoring records from
 pool:
 'authz'
     2018-06-13 11:27:22,085-04 WARNING Ignoring records from
 pool:
 'authz'
     2018-06-13 11:27:22,086-04 INFO
 [ovirt-engine-extension-aaa-ldap.authz::example.com-authz] Available
 Namespaces: []
     2018-06-13 11:27:22,087-04 INFO    Extension
 'example.com-authz' initialized
     2018-06-13 11:27:22,088-04 INFO    Start of enabled
 extensions
 list
     2018-06-13 11:27:22,089-04 INFO    Instance name:
 'example.com-authz', Extension name:
 'ovirt-engine-extension-aaa-ldap.authz', Version: '1.3.7', Notes:
 'Display na

[ovirt-users] Re: LDAP logins do not work

[Ondra Machacek]

This error:

The user u...@example.com@example.com is not authorized to perform login

means that you don't have any role assigned to your user.

Please check following documentation:


https://www.ovirt.org/documentation/admin-guide/chap-Users_and_Roles/#user-authorization

to understand permission model of oVirt.

On 06/14/2018 02:39 PM, Michael Watters wrote:

ldapsearch works correctly and I'm able to bind to AD without any
issues.  ovirt-engine-extension-aaa-ldap-setup also shows searches
working correctly.

One thing I've discovered is that I can login as "u...@domain.com" but
then receive an error as follows.


The user u...@example.com@example.com is not authorized to perform login


How do I enable debug logs?  The log entries from the engine.log file
are the same as my previous message.


On 06/14/2018 06:37 AM, Ondra Machacek wrote:

Can you share the debug log, and also make sure the search user you are
using is correct for example by running the ldapsearch command with it.

On 06/13/2018 05:33 PM, Michael Watters wrote:

I've ran the ovirt-engine-extension-aaa-ldap-setup command to configure
LDAP authentication using Active Directory however I am unable to
authenticate using valid credentials.  Here is the output show while
testing the login flow.

[ INFO  ] Executing login sequence...
    Login output:
    2018-06-13 11:27:17,931-04 INFO

    2018-06-13 11:27:17,960-04 INFO
 Initialization 
    2018-06-13 11:27:17,960-04 INFO

    2018-06-13 11:27:17,999-04 INFO    Loading extension
'example.com-authn'
    2018-06-13 11:27:18,072-04 INFO    Extension
'example.com-authn' loaded
    2018-06-13 11:27:18,077-04 INFO    Loading extension
'example.com-authz'
    2018-06-13 11:27:18,089-04 INFO    Extension
'example.com-authz' loaded
    2018-06-13 11:27:18,090-04 INFO    Initializing extension
'example.com-authn'
    2018-06-13 11:27:18,091-04 INFO
[ovirt-engine-extension-aaa-ldap.authn::example.com-authn] Creating LDAP
pool 'authz'
    2018-06-13 11:27:19,574-04 WARNING Exception: 80090308:
LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e,
v3839
    2018-06-13 11:27:19,576-04 INFO
[ovirt-engine-extension-aaa-ldap.authn::example.com-authn] Creating LDAP
pool 'authn'
    2018-06-13 11:27:20,668-04 INFO
[ovirt-engine-extension-aaa-ldap.authn::example.com-authn] LDAP pool
'authn' information: vendor='null' version='null'
    2018-06-13 11:27:20,674-04 WARNING Ignoring records from
pool:
'authz'
    2018-06-13 11:27:20,676-04 WARNING Ignoring records from
pool:
'authz'
    2018-06-13 11:27:20,676-04 INFO    Extension
'example.com-authn' initialized
    2018-06-13 11:27:20,677-04 INFO    Initializing extension
'example.com-authz'
    2018-06-13 11:27:20,679-04 INFO
[ovirt-engine-extension-aaa-ldap.authz::example.com-authz] Creating LDAP
pool 'authz'
    2018-06-13 11:27:21,270-04 WARNING Exception: 80090308:
LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e,
v3839
    2018-06-13 11:27:21,273-04 INFO
[ovirt-engine-extension-aaa-ldap.authz::example.com-authz] Creating LDAP
pool 'gc'
    2018-06-13 11:27:22,065-04 WARNING Exception: 80090308:
LdapErr: DSID-0C090400, comment: AcceptSecurityContext error, data 52e,
v1db1
    2018-06-13 11:27:22,069-04 WARNING Ignoring records from
pool:
'authz'
    2018-06-13 11:27:22,072-04 WARNING Ignoring records from
pool:
'authz'
    2018-06-13 11:27:22,085-04 WARNING Ignoring records from
pool:
'authz'
    2018-06-13 11:27:22,086-04 INFO
[ovirt-engine-extension-aaa-ldap.authz::example.com-authz] Available
Namespaces: []
    2018-06-13 11:27:22,087-04 INFO    Extension
'example.com-authz' initialized
    2018-06-13 11:27:22,088-04 INFO    Start of enabled
extensions
list
    2018-06-13 11:27:22,089-04 INFO    Instance name:
'example.com-authz', Extension name:
'ovirt-engine-extension-aaa-ldap.authz', Version: '1.3.7', Notes:
'Display name: ovirt-engine-extension-aaa-ldap-1.3.7-1.el7.centos',
License: 'ASL 2.0', Home: 'http://www.ovirt.org', Author 'The oVirt
Project', Build interface Version: '0',  File:
'/tmp/tmpPQluAI/extensions.d/example.com-authz.properties', Initialized:
'true'
    2018-06-13 11:27:22,089-04 INFO    Instance name:
'example.com-authn', Extension name:
'ovirt-engine-extension-aaa-ldap.authn', Version: '1.3.7', Notes:
'Display name: ovirt-engine-extension-aaa-ldap-1.3.7-1.el7.centos',
License: 'ASL 2.0', Home: 'http://www.ovirt.org', Author 'The oVirt
Project', Build interface Version: '0',  File:
'/tmp/tmpPQluAI/extensions.d/example.com-authn.properties', Initialized:
'true'
    

[ovirt-users] Re: LDAP logins do not work

[Michael Watters]

ldapsearch works correctly and I'm able to bind to AD without any
issues.  ovirt-engine-extension-aaa-ldap-setup also shows searches
working correctly.

One thing I've discovered is that I can login as "u...@domain.com" but
then receive an error as follows.

> The user u...@example.com@example.com is not authorized to perform login

How do I enable debug logs?  The log entries from the engine.log file
are the same as my previous message.


On 06/14/2018 06:37 AM, Ondra Machacek wrote:
> Can you share the debug log, and also make sure the search user you are
> using is correct for example by running the ldapsearch command with it.
>
> On 06/13/2018 05:33 PM, Michael Watters wrote:
>> I've ran the ovirt-engine-extension-aaa-ldap-setup command to configure
>> LDAP authentication using Active Directory however I am unable to
>> authenticate using valid credentials.  Here is the output show while
>> testing the login flow.
>>
>> [ INFO  ] Executing login sequence...
>>    Login output:
>>    2018-06-13 11:27:17,931-04 INFO
>> 
>>    2018-06-13 11:27:17,960-04 INFO
>>  Initialization 
>>    2018-06-13 11:27:17,960-04 INFO
>> 
>>    2018-06-13 11:27:17,999-04 INFO    Loading extension
>> 'example.com-authn'
>>    2018-06-13 11:27:18,072-04 INFO    Extension
>> 'example.com-authn' loaded
>>    2018-06-13 11:27:18,077-04 INFO    Loading extension
>> 'example.com-authz'
>>    2018-06-13 11:27:18,089-04 INFO    Extension
>> 'example.com-authz' loaded
>>    2018-06-13 11:27:18,090-04 INFO    Initializing extension
>> 'example.com-authn'
>>    2018-06-13 11:27:18,091-04 INFO
>> [ovirt-engine-extension-aaa-ldap.authn::example.com-authn] Creating LDAP
>> pool 'authz'
>>    2018-06-13 11:27:19,574-04 WARNING Exception: 80090308:
>> LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e,
>> v3839
>>    2018-06-13 11:27:19,576-04 INFO
>> [ovirt-engine-extension-aaa-ldap.authn::example.com-authn] Creating LDAP
>> pool 'authn'
>>    2018-06-13 11:27:20,668-04 INFO
>> [ovirt-engine-extension-aaa-ldap.authn::example.com-authn] LDAP pool
>> 'authn' information: vendor='null' version='null'
>>    2018-06-13 11:27:20,674-04 WARNING Ignoring records from
>> pool:
>> 'authz'
>>    2018-06-13 11:27:20,676-04 WARNING Ignoring records from
>> pool:
>> 'authz'
>>    2018-06-13 11:27:20,676-04 INFO    Extension
>> 'example.com-authn' initialized
>>    2018-06-13 11:27:20,677-04 INFO    Initializing extension
>> 'example.com-authz'
>>    2018-06-13 11:27:20,679-04 INFO
>> [ovirt-engine-extension-aaa-ldap.authz::example.com-authz] Creating LDAP
>> pool 'authz'
>>    2018-06-13 11:27:21,270-04 WARNING Exception: 80090308:
>> LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e,
>> v3839
>>    2018-06-13 11:27:21,273-04 INFO
>> [ovirt-engine-extension-aaa-ldap.authz::example.com-authz] Creating LDAP
>> pool 'gc'
>>    2018-06-13 11:27:22,065-04 WARNING Exception: 80090308:
>> LdapErr: DSID-0C090400, comment: AcceptSecurityContext error, data 52e,
>> v1db1
>>    2018-06-13 11:27:22,069-04 WARNING Ignoring records from
>> pool:
>> 'authz'
>>    2018-06-13 11:27:22,072-04 WARNING Ignoring records from
>> pool:
>> 'authz'
>>    2018-06-13 11:27:22,085-04 WARNING Ignoring records from
>> pool:
>> 'authz'
>>    2018-06-13 11:27:22,086-04 INFO
>> [ovirt-engine-extension-aaa-ldap.authz::example.com-authz] Available
>> Namespaces: []
>>    2018-06-13 11:27:22,087-04 INFO    Extension
>> 'example.com-authz' initialized
>>    2018-06-13 11:27:22,088-04 INFO    Start of enabled
>> extensions
>> list
>>    2018-06-13 11:27:22,089-04 INFO    Instance name:
>> 'example.com-authz', Extension name:
>> 'ovirt-engine-extension-aaa-ldap.authz', Version: '1.3.7', Notes:
>> 'Display name: ovirt-engine-extension-aaa-ldap-1.3.7-1.el7.centos',
>> License: 'ASL 2.0', Home: 'http://www.ovirt.org', Author 'The oVirt
>> Project', Build interface Version: '0',  File:
>> '/tmp/tmpPQluAI/extensions.d/example.com-authz.properties', Initialized:
>> 'true'
>>    2018-06-13 11:27:22,089-04 INFO    Instance name:
>> 'example.com-authn', Extension name:
>> 'ovirt-engine-extension-aaa-ldap.authn', Version: '1.3.7', Notes:
>> 'Display name: ovirt-engine-extension-aaa-ldap-1.3.7-1.el7.centos',
>> License: 'ASL 2.0', Home: 'http://www.ovirt.org', Author 'The oVirt
>> Project', Build interface Version: '0',  File:
>> '/tmp/tmpPQluAI/extensions.d/example.com-authn.properties', Initialized:
>> 'true'
>>    2018-06-13 11:27:22,090-04 INFO    End of enabled
>> extensions list
>>    2018-06-13 11:27:22,090-04 INFO
>

[ovirt-users] Re: LDAP logins do not work

[Ondra Machacek]

Can you share the debug log, and also make sure the search user you are
using is correct for example by running the ldapsearch command with it.

On 06/13/2018 05:33 PM, Michael Watters wrote:

I've ran the ovirt-engine-extension-aaa-ldap-setup command to configure
LDAP authentication using Active Directory however I am unable to
authenticate using valid credentials.  Here is the output show while
testing the login flow.

[ INFO  ] Executing login sequence...
   Login output:
   2018-06-13 11:27:17,931-04 INFO

   2018-06-13 11:27:17,960-04 INFO
 Initialization 
   2018-06-13 11:27:17,960-04 INFO

   2018-06-13 11:27:17,999-04 INFO    Loading extension
'example.com-authn'
   2018-06-13 11:27:18,072-04 INFO    Extension
'example.com-authn' loaded
   2018-06-13 11:27:18,077-04 INFO    Loading extension
'example.com-authz'
   2018-06-13 11:27:18,089-04 INFO    Extension
'example.com-authz' loaded
   2018-06-13 11:27:18,090-04 INFO    Initializing extension
'example.com-authn'
   2018-06-13 11:27:18,091-04 INFO
[ovirt-engine-extension-aaa-ldap.authn::example.com-authn] Creating LDAP
pool 'authz'
   2018-06-13 11:27:19,574-04 WARNING Exception: 80090308:
LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e,
v3839
   2018-06-13 11:27:19,576-04 INFO
[ovirt-engine-extension-aaa-ldap.authn::example.com-authn] Creating LDAP
pool 'authn'
   2018-06-13 11:27:20,668-04 INFO
[ovirt-engine-extension-aaa-ldap.authn::example.com-authn] LDAP pool
'authn' information: vendor='null' version='null'
   2018-06-13 11:27:20,674-04 WARNING Ignoring records from pool:
'authz'
   2018-06-13 11:27:20,676-04 WARNING Ignoring records from pool:
'authz'
   2018-06-13 11:27:20,676-04 INFO    Extension
'example.com-authn' initialized
   2018-06-13 11:27:20,677-04 INFO    Initializing extension
'example.com-authz'
   2018-06-13 11:27:20,679-04 INFO
[ovirt-engine-extension-aaa-ldap.authz::example.com-authz] Creating LDAP
pool 'authz'
   2018-06-13 11:27:21,270-04 WARNING Exception: 80090308:
LdapErr: DSID-0C09042A, comment: AcceptSecurityContext error, data 52e,
v3839
   2018-06-13 11:27:21,273-04 INFO
[ovirt-engine-extension-aaa-ldap.authz::example.com-authz] Creating LDAP
pool 'gc'
   2018-06-13 11:27:22,065-04 WARNING Exception: 80090308:
LdapErr: DSID-0C090400, comment: AcceptSecurityContext error, data 52e,
v1db1
   2018-06-13 11:27:22,069-04 WARNING Ignoring records from pool:
'authz'
   2018-06-13 11:27:22,072-04 WARNING Ignoring records from pool:
'authz'
   2018-06-13 11:27:22,085-04 WARNING Ignoring records from pool:
'authz'
   2018-06-13 11:27:22,086-04 INFO
[ovirt-engine-extension-aaa-ldap.authz::example.com-authz] Available
Namespaces: []
   2018-06-13 11:27:22,087-04 INFO    Extension
'example.com-authz' initialized
   2018-06-13 11:27:22,088-04 INFO    Start of enabled extensions
list
   2018-06-13 11:27:22,089-04 INFO    Instance name:
'example.com-authz', Extension name:
'ovirt-engine-extension-aaa-ldap.authz', Version: '1.3.7', Notes:
'Display name: ovirt-engine-extension-aaa-ldap-1.3.7-1.el7.centos',
License: 'ASL 2.0', Home: 'http://www.ovirt.org', Author 'The oVirt
Project', Build interface Version: '0',  File:
'/tmp/tmpPQluAI/extensions.d/example.com-authz.properties', Initialized:
'true'
   2018-06-13 11:27:22,089-04 INFO    Instance name:
'example.com-authn', Extension name:
'ovirt-engine-extension-aaa-ldap.authn', Version: '1.3.7', Notes:
'Display name: ovirt-engine-extension-aaa-ldap-1.3.7-1.el7.centos',
License: 'ASL 2.0', Home: 'http://www.ovirt.org', Author 'The oVirt
Project', Build interface Version: '0',  File:
'/tmp/tmpPQluAI/extensions.d/example.com-authn.properties', Initialized:
'true'
   2018-06-13 11:27:22,090-04 INFO    End of enabled extensions list
   2018-06-13 11:27:22,090-04 INFO

   2018-06-13 11:27:22,090-04 INFO
== Execution ===
   2018-06-13 11:27:22,091-04 INFO

   2018-06-13 11:27:22,091-04 INFO    Iteration: 0
   2018-06-13 11:27:22,093-04 INFO    Profile='example.com'
authn='example.com-authn' authz='example.com-authz' mapping='null'
   2018-06-13 11:27:22,094-04 INFO    API:
-->Authn.InvokeCommands.AUTHENTICATE_CREDENTIALS profile='example.com'
user='d861703'
   2018-06-13 11:27:22,251-04 INFO    API:
<--Authn.InvokeCommands.AUTHENTICATE_CREDENTIALS profile='example.com'
result=CREDENTIA

[ovirt-users] Re: LDAP Authentication issues

[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?

On

[ovirt-users] Re: LDAP Authentication issues

[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 permis

[ovirt-users] Re: LDAP Authentication issues

[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

[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 t

[ovirt-users] Re: LDAP Authentication issues

[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 n

[ovirt-users] Re: LDAP Authentication issues

[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 Resear

[ovirt-users] Re: LDAP Authentication issues

[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

On

[ovirt-users] Re: LDAP Authentication issues

[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
> U

[ovirt-users] Re: LDAP Authentication issues

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

[ovirt-users] Re: LDAP Authentication issues

[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

[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 
mailto:cal...@we

[ovirt-users] Re: LDAP Authentication issues

[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 =
>>> &(objectClass=posixGroup)

[ovirt-users] Re: LDAP Authentication issues

[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
sequence.bmrc-resolve-groups.020.fetch

[ovirt-users] Re: LDAP Authentication issues

[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
sequence.bmrc-resolve-gro

[ovirt-users] Re: LDAP Authentication issues

[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 Oxford

[ovirt-users] Re: LDAP Authentication issues

[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

[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. Are

[ovirt-users] Re: LDAP Authentication issues

[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 wo

[ovirt-users] Re: LDAP Authentication issues

[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 
[o

[ovirt-users] Re: LDAP Authentication issues

[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

[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 sen

[ovirt-users] Re: LDAP Authentication issues

[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

[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/