Bug 784162 - LDAP - PosixGroup lookup performed doesn't allow for uid versus DN check
LDAP - PosixGroup lookup performed doesn't allow for uid versus DN check
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
Unspecified Unspecified
high Severity unspecified (vote)
: ---
: RHQ 4.5.0
Assigned To: RHQ Project Maintainer
Mike Foley
Depends On:
Blocks: jon310-sprint11/rhq44-sprint11 872019
  Show dependency treegraph
Reported: 2012-01-23 22:26 EST by Elias Ross
Modified: 2013-09-01 06:04 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 872019 (view as bug list)
Last Closed: 2013-09-01 06:04:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Elias Ross 2012-01-23 22:26:40 EST
Description of problem:

LDAP module (modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/resource/group/LdapGroupManagerBean.java) assumes that group members must be assigned by DN. In some cases, memberUid is appropriate.

Version-Release number of selected component (if applicable): 4.3

Here is a sample LDAP entry:

# iAdRHQAdmin, groups, xxx.com
dn: cn=iAdRHQAdmin,cn=groups,dc=xxx,dc=com
objectClass: posixGroup
objectClass: apple-group
objectClass: extensibleObject
objectClass: top
gidNumber: 541947
apple-group-realname: iAdRHQAdmin
cn: iAdRHQAdmin
apple-generateduid: 73F583B0-CB70-4A6E-A1FC-E6F4EE9A32FF
apple-ownerguid: E2E856B0-0C71-11E0-A702-8F7B44AB7485
apple-group-memberguid: E2E856B0-0C71-11E0-A702-8F7B44AB7485
apple-group-memberguid: 9FEB0930-6766-11DF-A564-A3ECB90E8B02
apple-group-memberguid: A08C5F10-F664-11DE-9F10-8905B3C166CB
memberUid: elias_ross

'memberUid' is the login.

Should be an option to support 'groupMemberAttribute' similar to Splunk:

groupMemberAttribute = memberuid

By default this would be 'dn':

groupMemberAttribute = dn

This is what I mean:

diff --git a/modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/resource/group/LdapGroupManagerBean.java b/modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/resource/group/LdapGroupManagerBean
index 396b2c8..af74a95 100644
--- a/modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/resource/group/LdapGroupManagerBean.java
+++ b/modules/enterprise/server/jar/src/main/java/org/rhq/enterprise/server/resource/group/LdapGroupManagerBean.java
@@ -103,15 +103,16 @@ public class LdapGroupManagerBean implements LdapGroupManagerLocal {
         Properties options = systemManager.getSystemConfiguration(subjectManager.getOverlord());
         String groupFilter = options.getProperty(RHQConstants.LDAPGroupFilter, "");
         String groupMember = options.getProperty(RHQConstants.LDAPGroupMember, "");
-        String userDN = getUserDN(options, userName);
+        String groupMemberAttribute = options.getProperty(RHQConstants.LDAPGroupMemberAttribute, "dn");
+        String userAttribute = getUserAttribute(options, userName, groupMemberAttribute);
         Set<String> ldapSet = new HashSet<String>();
-        if (userDN != null && userDN.trim().length() > 0) {
+        if (userAttribute != null && userAttribute.trim().length() > 0) {
             //TODO: spinder 4/21/10 put in error/debug logging messages for badly formatted filter combinations
             String filter = "";
             //form assumes examples where groupFilter is like 'objectclass=groupOfNames' and groupMember is 'member'
             // to produce ldap filter like (&(objectclass=groupOfNames)(member=cn=Administrator,ou=People,dc=test,dc=com))
-            filter = String.format("(&(%s)(%s=%s))", groupFilter, groupMember, LDAPStringUtil.encodeForFilter(userDN));
+            filter = String.format("(&(%s)(%s=%s))", groupFilter, groupMember, LDAPStringUtil.encodeForFilter(userAttribute));
             Set<Map<String, String>> matched = buildGroup(options, filter);
             log.trace("Located '" + matched.size() + "' LDAP groups for user '" + userName
@@ -255,11 +256,11 @@ public class LdapGroupManagerBean implements LdapGroupManagerLocal {
      * @param userName
      * @return
-    private String getUserDN(Properties options, String userName) {
+    private String getUserAttribute(Properties options, String userName, String groupMemberAttribute) {
         Map<String, String> details = findLdapUserDetails(userName);
-        String userDN = details.get("dn");
+        String userAttribute = details.get(groupMemberAttribute);
-        return userDN;
+        return userAttribute;

You also need to add the UI pieces to this.
Comment 1 Elias Ross 2012-01-23 22:32:24 EST
This allows support for 'posixGroup' type groups for authentication. This object class is described here:


If you have a tough time prioritizing this for 4.3 release, let me know. I think the changes are quite straightforward, I believe.
Comment 2 Mike Foley 2012-01-30 11:22:03 EST
12/30/2012 BZ triage meeting mfoley, ccrouch, loleary, asantos
Comment 4 Simeon Pinder 2012-03-29 11:10:39 EDT
Hi Elias Ross,

  Can you give me some more details about your configuration? I'm not sure that we need to make this change to be able to support the PosixGroup groups as you've described them.  We shouldn't require the Dn component when looking up groups. A typical group membership query would look something like:

I was not able to use the following to browse the relevant attributes(fails for me)
but instead used 

and it looks like the posixGroup extends the objectClass entry.  If this is the case, then I think your settings should look something like:

Url: ldap://(server):(port)      Search Filter:(leave empty)
Search Base: dc=xxx,dc=com       Login Property: cn
User Name: cn=iAdRHQAdmin,cn=groups,dc=xxx,dc=com 
Password: (yadda yadda)
Group Search Filter: objectclass=posixGroup
Group Member Filter: memberUid 

Can you reply with what your current configuration looks like? 

Also, are you aware of this graphical debug tool for testing arbitrary configurations against ldap servers? 
It's an executable jar at the very bottom of the following page:

If you turn up debug and logging you'll see the ldap queries being generated and the responses from the target server.  You can also paste in the debug log generated if necessary.
Comment 5 Elias Ross 2012-03-29 20:00:38 EDT
Group Member Filter is what queries the membership of groups. This is not going to fix the problem. I know this from both running the program and looking at the code that RHQ cannot query memberUid by _just the username_ NOT the full DN of the user.

What I need to change is the group member attribute. What I have:

dn: cn=iAdRHQAdmin,cn=groups,dc=xxx,dc=com
memberUid: elias_ross

But RHQ only supports groups that appear like this:

dn: cn=iAdRHQAdmin,cn=groups,dc=xxx,dc=com
member: cn=Elias Ross,ou=people,dc=xxx,dc=com

The changes included in the issue should fix this...Please see what is in the patch. I do need the UI components for this to change the configuration and need direction on this.

See also this message on the same problem: https://forums.oracle.com/forums/thread.jspa?threadID=895872
Comment 6 Simeon Pinder 2012-03-30 08:36:15 EDT
Yes. This should not be hard to do. Should take a couple of hours to do and test through a couple of the scenarios.  We'll need to add support for the new flag in the backend and update the UI as you mention.  And a few more tasks to update the documentation to describe the new functionality in such a way so that it does not add confusion to the majority of LDAP users to which this new flag is not relevant.   

It's really just an alternative form of LDAP group authorization that is supported by a small subset of LDAP servers.
Comment 7 Elias Ross 2012-03-30 14:46:28 EDT
Thanks so much looking into this.

I don't know about "small subset". RFC 2307 describes using posixGroup for NIS authentication. Most services supporting LDAP authentication do support posixGroup from what I have seen.
Comment 9 Simeon Pinder 2012-05-01 10:12:53 EDT
Setting this to urgent for a ruling of whether to commit changes when they're done to master for 4.4.
Comment 10 Charles Crouch 2012-05-02 09:21:19 EDT
Re-targeting this to RHQ4.5. We simply don't have the bandwidth to complete and verify this change (including upgrade procedures) at this time. For the moment the development will be go into a branch.

We should be able to make this one of the first things that hits master post RHQ4.4
Comment 11 Simeon Pinder 2012-05-02 18:29:30 EDT
These will be pushed to master as soon as 4.4 is released.
Comment 12 Simeon Pinder 2012-05-10 13:00:18 EDT
This is available for testing in master with commit:

Moving this to ON_QA.
Comment 13 Heiko W. Rupp 2013-09-01 06:04:12 EDT
Bulk closing of items that are on_qa and in old RHQ releases, which are out for a long time and where the issue has not been re-opened since.

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