Bug 904847

Summary:	RFE: Make LDAP group search base configurable
Product:	[Other] RHQ Project	Reporter:	Thomas Segismont <tsegismo>
Component:	Core Server	Assignee:	Nobody <nobody>
Status:	NEW ---	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	4.5	CC:	hrupp, loleary
Target Milestone:	---	Keywords:	FutureFeature
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Thomas Segismont 2013-01-27 20:45:46 UTC

When configuring LDAP integration, RHQ administrators set a search base which will be used for both user searching and group searching.

Consequently, users have to whether specify a very high node in the LDAP tree or to put group definitions under the the same node as where they put users.

They should be able to specify two distinct search bases for users and groups.

By default, the new field "Group Search Base" would be marked unset in the GUI and the search code would use the "User Search Base".

Comment 1 Larry O'Leary 2013-04-26 00:03:14 UTC

Has something changed? Perhaps the existing fields are confusing?

The current implementation (keeping in mind I am basing this on RHQ 4.4) is that you have:

 * Search Base
 * Search Filter
 * Group Search Filter

"Search Base" is common and provides a base for all LDAP queries.
"Search Filter" is really "User Search Filter" and is the search criteria applied to user look-up.
"Group Search Filter" is the search criteria applied to group look-up.

This is the standard implementation for many LDAP servers from what I recall. Even ActiveDirectory discourages the "search base" and requires you to specify it as part of the LDAP URL. It is intended to represent the organizations root. For example, dc=mycompany,dc=com. This allows multiple organizations to share the same LDAP server and store their directory entries under their respective domain or organization.

It is the job of the filters to narrow the search down to a specific parent node. This allows users and groups to be stored in different locations within the hierarchy assuming they both are under the same base.

I could just as easily not use "Search Base" (leave it blank or wild) and specify the base as part of the group or user filters.

Comment 2 Thomas Segismont 2013-04-26 08:33:01 UTC

(In reply to comment #1)
> Has something changed? Perhaps the existing fields are confusing?

Nothing has changed since 4.4

> 
> The current implementation (keeping in mind I am basing this on RHQ 4.4) is
> that you have:
> 
>  * Search Base
>  * Search Filter
>  * Group Search Filter
> 
> "Search Base" is common and provides a base for all LDAP queries.
> "Search Filter" is really "User Search Filter" and is the search criteria
> applied to user look-up.
> "Group Search Filter" is the search criteria applied to group look-up.
> 

Yes

> This is the standard implementation for many LDAP servers from what I
> recall. Even ActiveDirectory discourages the "search base" and requires you
> to specify it as part of the LDAP URL. It is intended to represent the
> organizations root. For example, dc=mycompany,dc=com. This allows multiple
> organizations to share the same LDAP server and store their directory
> entries under their respective domain or organization.
> 
> It is the job of the filters to narrow the search down to a specific parent
> node. This allows users and groups to be stored in different locations
> within the hierarchy assuming they both are under the same base.
> 
> I could just as easily not use "Search Base" (leave it blank or wild) and
> specify the base as part of the group or user filters.

I didn't know this was possible. Could you give me an example of such a filter? I thought we could only inspect node attributes in search filter, and set a base node for searching.