+++ This bug was initially created as a clone of upstream Bug #784162 +++

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.

--- Additional comment from genman@noderunner.net on 2012-01-23 22:32:24 EST ---

This allows support for 'posixGroup' type groups for authentication. This object class is described here:

http://ldap.akbkhome.com/index.php/objectclass/posixGroup.html

If you have a tough time prioritizing this for 4.3 release, let me know. I think the changes are quite straightforward, I believe.

--- Additional comment from mfoley@redhat.com on 2012-01-30 11:22:03 EST ---

12/30/2012 BZ triage meeting mfoley, ccrouch, loleary, asantos

--- Additional comment from spinder@redhat.com on 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:
(&(objectclass=groupOfUniqueNames)(uniqueMember=uid=anotherUser,cn=groups,dc=xxx,dc=com)   

I was not able to use the following to browse the relevant attributes(fails for me)
  http://ldap.akbkhome.com/index.php/objectclass/posixGroup.html 
but instead used 
  http://www.andrew.cmu.edu/user/dd26/ldap.akbkhome.com/objectclass/posixGroup.html

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:
http://www.rhq-project.org/display/RHQ/Testing+the+RHQ+LDAP+Integration 

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.

--- Additional comment from genman@noderunner.net on 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

--- Additional comment from spinder@redhat.com on 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.

--- Additional comment from genman@noderunner.net on 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.

--- Additional comment from spinder@redhat.com on 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.

--- Additional comment from ccrouch@redhat.com on 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

--- Additional comment from spinder@redhat.com on 2012-05-02 18:29:30 EDT ---

These will be pushed to master as soon as 4.4 is released.

--- Additional comment from spinder@redhat.com on 2012-05-10 13:00:18 EDT ---

This is available for testing in master with commit:
9431e3b720

Moving this to ON_QA.