Bug 1134855 - [AAA] search within another pool to complete group membership
Summary: [AAA] search within another pool to complete group membership
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine-extension-aaa-ldap
Classification: oVirt
Component: Core
Version: master
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 1.0.0
Assignee: Alon Bar-Lev
QA Contact: Ondra Machacek
URL:
Whiteboard: infra
Depends On:
Blocks: oVirt-AAA-LDAP
TreeView+ depends on / blocked
 
Reported: 2014-08-28 11:08 UTC by Ondra Machacek
Modified: 2016-02-10 19:40 UTC (History)
10 users (show)

Fixed In Version: vt3.1
Clone Of:
Environment:
Last Closed: 2014-10-17 12:40:54 UTC
oVirt Team: Infra
Embargoed:


Attachments (Terms of Use)
engine startup log (429.41 KB, text/plain)
2014-09-11 08:58 UTC, Ondra Machacek
no flags Details
login as user from group log (265.71 KB, text/plain)
2014-09-11 08:59 UTC, Ondra Machacek
no flags Details


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 32223 0 None None None Never

Description Ondra Machacek 2014-08-28 11:08:08 UTC
Description of problem:


Version-Release number of selected component (if applicable):
ovirt-engine-3.5.0-0.0.master.20140821064931.gitb794d66.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. Have at least two AD domains with trust.
2. Create group in AD1.
3. Create user in AD2, who is part of group from AD1.
4. Add group to engine and assign it permissions.
5. Try to login as user from AD2.

Actual results:
User don't inherit group permissions and thus error messages:
"User is not authorized to perform this action."
is shown.

Expected results:
User inherit permissions from group and successfully login.

Additional info:

[root@om-rh35 profiles]# ldapsearch -LLL -x -h 10.34.63.245 -p 389 -D Administrator.lab.eng.brq.redhat.com -W -b 'DC=ad-w2k12r2,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com' "CN=TopLevelGroup"
dn: CN=TopLevelGroup,CN=Users,DC=ad-w2k12r2,DC=rhev,DC=lab,DC=eng,DC=brq,DC=re
 dhat,DC=com
objectClass: top
objectClass: group
cn: TopLevelGroup
member: CN=topLeveluser topLeveluser,CN=Users,DC=ad-w2k12r2pc,DC=ad-w2k12r2p,D
 C=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com
member: CN=user1FirstName user1LastName,CN=Users,DC=ad-w2k12r2,DC=rhev,DC=lab,
 DC=eng,DC=brq,DC=redhat,DC=com
distinguishedName: CN=TopLevelGroup,CN=Users,DC=ad-w2k12r2,DC=rhev,DC=lab,DC=e
 ng,DC=brq,DC=redhat,DC=com


ldapsearch -LLL -x -h 10.34.63.33 -p 389 -D Administrator.lab.eng.brq.redhat.com -w Heslo123 -b 'DC=ad-w2k12r2pc,DC=ad-w2k12r2p,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com' "sn=topLeveluser"
dn: CN=topLeveluser topLeveluser,CN=Users,DC=ad-w2k12r2pc,DC=ad-w2k12r2p,DC=rh
 ev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: topLeveluser topLeveluser
sn: topLeveluser


2014-08-28 13:07:34,230 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp--127.0.0.1-8702-8) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User AD-W2K12R2PC\topLevelUser failed to log in.
2014-08-28 13:07:34,232 WARN  [org.ovirt.engine.core.bll.aaa.LoginUserCommand] (ajp--127.0.0.1-8702-8) CanDoAction of action LoginUser failed. Reasons:USER_NOT_AUTHORIZED_TO_PERFORM_ACTION

Comment 1 Alon Bar-Lev 2014-08-28 18:30:34 UTC
Hi,

Please use more generic subject when opening bugs, please do not add trailing dots.

Also, marking new features (not existed in previous stable versions) as severity high is kind of strange.

Thanks,

Comment 2 Alon Bar-Lev 2014-08-28 18:48:53 UTC
user should have memberOf while topLeveluser does not have this attribute.

group is not important in this case.

Comment 3 Alon Bar-Lev 2014-08-28 19:11:36 UTC
In this case you should query global catalog[1]

$ ldapsearch -LLL -x -h 10.34.63.245 -p 3268 -D Administrator.lab.eng.brq.redhat.com -w Heslo123 -b 'DC=ad-w2k12r2pc,DC=ad-w2k12r2p,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com' "sn=topLeveluser"
dn: CN=topLeveluser topLeveluser,CN=Users,DC=ad-w2k12r2pc,DC=ad-w2k12r2p,DC=rh
 ev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: topLeveluser topLeveluser
sn: topLeveluser
givenName: topLeveluser
distinguishedName: CN=topLeveluser topLeveluser,CN=Users,DC=ad-w2k12r2pc,DC=ad
 -w2k12r2p,DC=rhev,DC=lab,DC=eng,DC=brq,DC=redhat,DC=com
instanceType: 0
whenCreated: 20140828101522.0Z
whenChanged: 20140828103942.0Z
displayName: topLeveluser topLeveluser
uSNCreated: 231373
memberOf: CN=TopLevelGroup,CN=Users,DC=ad-w2k12r2,DC=rhev,DC=lab,DC=eng,DC=brq
 ,DC=redhat,DC=com
uSNChanged: 231470
name: topLeveluser topLeveluser
objectGUID:: WUGCFnhhdkW9hPAbZ4fmdA==
userAccountControl: 66048
primaryGroupID: 513
objectSid:: AQUAAAAAAAUVAAAAHmtufYB1Jk9DP9w1XQQAAA==
sAMAccountName: topLeveluser
sAMAccountType: 805306368
userPrincipalName: topLeveluser.rhev.lab.eng.brq.redh
 at.com
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=ad-w2k12r2,DC=rhev,DC=
 lab,DC=eng,DC=brq,DC=redhat,DC=com
dSCorePropagationData: 16010101000000.0Z
lastLogonTimestamp: 130536959670245415

[1] http://msdn.microsoft.com/en-us/library/ms677943.aspx#memberOf

Comment 4 Alon Bar-Lev 2014-08-28 19:57:10 UTC
the plan was for these who needs cross domain queries, to set up the authz pool to gc:

 pool.default.serverset.srvrecord.service = gc

however, unlike in documentation active directory's gc does not contain a full Configuration subtree, it also does not contain local domain group membership.

since the above information is missing query against any single ldap is incomplete.

in order to have cross domain group, I will add another set of pools to query, this will reduce performance as the implementation will need to query more than one ldap to obtain all information.

user will require to set both "standard" ldap pool and one "additional" (gc) ldap pool in this case.

Comment 5 Alon Bar-Lev 2014-09-01 10:30:56 UTC
README

+Global catalog lookup can be enabled to support inter-forest group
+resolution. Not enabled by default as it has performance costs. Add the
+following to authz extension configuration:
+
+ config.globals.000.ad_enable_gc = true

Comment 6 Ondra Machacek 2014-09-11 08:41:06 UTC
I can't get it work.
I have - config.globals.000.ad_enable_gc = true , in autz properties.

I add group with permissions.

Then I try to login as user from group, and engine is not quering gc.

#tcpdump -l -s 65535 -A -vv port 3268 -w gc.cap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
0 packets captured

Are there any other special configurations?

Comment 7 Alon Bar-Lev 2014-09-11 08:47:21 UTC
you should first see that the gc pool is created. anyway, a log would be nice...

Comment 8 Ondra Machacek 2014-09-11 08:58:40 UTC
Created attachment 936455 [details]
engine startup log

Comment 9 Ondra Machacek 2014-09-11 08:59:20 UTC
Created attachment 936456 [details]
login as user from group log

Comment 10 Alon Bar-Lev 2014-09-11 09:03:58 UTC
I am unsure you are using a version of the ldap provider with that fix, what hash do you use?

Comment 11 Ondra Machacek 2014-09-11 09:39:17 UTC
[root@om-rh35 extensions.d]# rpm -qi ovirt-engine-extension-aaa-ldap
Name        : ovirt-engine-extension-aaa-ldap  Relocations: (not relocatable)
Version     : 0.0.0                             Vendor: Red Hat, Inc.
Release     : 0.0.2.master.el6_5            Build Date: Sun 24 Aug 2014 12:33:55 PM CEST

It's not there, build date is Sun 24 Aug 2014 12:33:55. Fix is 31.8...

Comment 12 Alon Bar-Lev 2014-09-11 09:40:28 UTC
this is not vt3

Comment 13 Alon Bar-Lev 2014-09-11 09:46:02 UTC
the current build was not included in vt3 due to engine dependency issue. I will rebuild and republish.
sorry, I was not aware that it was not pulled.

Comment 14 Alon Bar-Lev 2014-09-14 10:21:29 UTC
was included in vt3.1, great.

Comment 15 Ondra Machacek 2014-09-16 09:26:42 UTC
Works fine in vt3.1 with line

config.globals.000.ad_enable_gc = true

in authz extension.

Comment 16 Sandro Bonazzola 2014-10-17 12:40:54 UTC
oVirt 3.5 has been released and should include the fix for this issue.


Note You need to log in before you can comment on or make changes to this bug.