Bug 1369194

Summary:	[RFE] Allow specifying the LDAP filter
Product:	[oVirt] ovirt-engine	Reporter:	nicolas
Component:	AAA	Assignee:	Martin Perina <mperina>
Status:	CLOSED DEFERRED	QA Contact:	Lukas Svaty <lsvaty>
Severity:	low	Docs Contact:
Priority:	low
Version:	4.0.2	CC:	bugs, lsvaty, mperina, omachace
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---	Flags:	mperina: ovirt-future? rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack?
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-04-01 14:46:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Infra	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description nicolas 2016-08-22 15:43:27 UTC

Description of problem:

We've oVirt 4.0.1 with LDAP (RFC-2307) as authentication backend configured in our infrastructures. 

Currently, the filter that is built when a user search is made from the engine (for example, to grant a role to a user) is like this:

  &(objectClass=posixAccount)(uid=*)(|(givenName=username)(sn=username)(displayName=username)(uid=username))

When the LDAP directory is big enough (in our case we handle > 230K objects), the OR (|) clause causes the query to fail due to "ERR: 11, admin
limit exceeded".

That happens due to the huge amount of results that are returned (it's not a time exceeded error).

I'm aware this is a LDAP server issue, but to avoid it, instead of changing limits on the LDAP side, it would be nice if users could define the LDAP filter to apply. As this RFC enforces the object to be a posixAccount, I think it would be enough to allow users to define the (|(...)) part. In our case, we'll never search by givenName, sn, displayName, but just by uid, so this would simplify the query and we'd eliminate the need of using an "admin" account, as we do currently.

Comment 1 Ondra Machacek 2016-08-26 10:10:23 UTC

You can overcome this with little aaa-ldap hack.
Add following lines into your '/etc/ovirt-engine/aaa/profile.properties' file:

 sequence.simple-query-principals.005.description = modify filter to search only by uid
 sequence.simple-query-principals.005.type = regex
 sequence.simple-query-principals.005.regex.value = ${seq:filter}
 sequence.simple-query-principals.005.regex.flags = a
 sequence.simple-query-principals.005.regex.pattern = \\(givenName=[^)]*\\)|\\(sn=[^)]*\\)|\\(displayName=[^)]*\\)
 sequence.simple-query-principals.005.regex.replacement.filter = 

It will replaces occurances of givenName, sn and displayName and it's values by empty string. So only uid persist in filter.

Comment 2 Ondra Machacek 2016-08-26 11:21:30 UTC

I am setting low prio/severity as we have workaround for aaa-ldap, and I don't see
any reason to have it for aaa-jdbc. Also changing component accordingly.

Comment 3 nicolas 2016-08-26 11:25:29 UTC

Confirmed the workaround works, by now it's enough for us. Thanks.

Comment 4 Yaniv Kaul 2017-06-07 19:20:48 UTC

If this is properly documented, we can close this RFE. Please verify it is.

Comment 5 Martin Perina 2017-08-08 05:19:50 UTC

Ondro, could you please add workaround from Comment 1 into http://www.ovirt.org/develop/release-management/features/infra/aaa_faq/

Comment 6 Ondra Machacek 2017-08-08 09:39:35 UTC

Created - https://github.com/oVirt/ovirt-site/pull/1131.

Comment 7 Michal Skrivanek 2020-03-19 15:42:28 UTC

We didn't get to this bug for more than 2 years, and it's not being considered for the upcoming 4.4. It's unlikely that it will ever be addressed so I'm suggesting to close it.
If you feel this needs to be addressed and want to work on it please remove cond nack and target accordingly.

Comment 8 Michal Skrivanek 2020-04-01 14:46:36 UTC

ok, closing. Please reopen if still relevant/you want to work on it.

Comment 9 Michal Skrivanek 2020-04-01 14:50:27 UTC

ok, closing. Please reopen if still relevant/you want to work on it.