Bug 904847 - RFE: Make LDAP group search base configurable
RFE: Make LDAP group search base configurable
Status: NEW
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
4.5
Unspecified Unspecified
unspecified Severity unspecified (vote)
: ---
: ---
Assigned To: RHQ Project Maintainer
Mike Foley
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-27 15:45 EST by Thomas Segismont
Modified: 2013-04-26 04:33 EDT (History)
2 users (show)

See Also:
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:


Attachments (Terms of Use)

  None (edit)
Description Thomas Segismont 2013-01-27 15:45:46 EST
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-25 20:03:14 EDT
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 04:33:01 EDT
(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.

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