Bug 872019

Summary: [Port enhancement from upstream] LDAP - PosixGroup lookup performed doesn't allow for uid versus DN check
Product: [JBoss] JBoss Operations Network Reporter: Larry O'Leary <loleary>
Component: Core ServerAssignee: Simeon Pinder <spinder>
Status: CLOSED CURRENTRELEASE QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: medium    
Version: JON 3.1.1CC: mkittrell, spinder
Target Milestone: ER01   
Target Release: JON 3.2.0   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 784162 Environment:
Last Closed: 2014-01-02 20:43:26 UTC Type: Enhancement
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 784162    
Bug Blocks:    

Description Larry O'Leary 2012-11-01 02:17:04 UTC
+++ 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 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 on 2012-01-30 11:22:03 EST ---

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

--- Additional comment from spinder 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 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 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 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 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 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 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 on 2012-05-10 13:00:18 EDT ---

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

Moving this to ON_QA.

Comment 1 Larry O'Leary 2012-11-01 02:21:28 UTC
This appears to be in two separate commits in master:

commit 193d087ef2f2bf40aa4d4bb556905d9c4b630f83
Author: Simeon Pinder <spinder>
Date:   Tue May 1 12:04:34 2012 -0400

     [BZ 784162] Adding PosixGroup support to LDAP Group mechanism.
       - with change after checking the "Use PosixGroup" typically you'll use objectclass=posixGroup and 'memberUid' for the group filter.


- and -


commit 9431e3b72032b514e4e70753ae0b172f722a52a7
Author: Simeon Pinder <spinder>
Date:   Tue May 1 16:14:20 2012 -0400

     [BZ 784162] adding null value check for posix property, clarify posix label and details and put better ldap default values.