Bug 1082806 - Context referrals are hardcoded to "ignore" in LDAP configuration
Summary: Context referrals are hardcoded to "ignore" in LDAP configuration
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: JBoss Operations Network
Classification: JBoss
Component: Security
Version: JON 3.2
Hardware: All
OS: All
unspecified
high
Target Milestone: CR01
: JON 3.2.2
Assignee: Jirka Kremser
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-31 20:54 UTC by Marc Shirley
Modified: 2018-12-06 16:12 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-29 00:17:26 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 582471 0 low CLOSED PartialResultException when choosing particular Search Bases when using Active Directory 2021-02-22 00:41:40 UTC

Internal Links: 582471

Description Marc Shirley 2014-03-31 20:54:50 UTC
Description of problem:
Context referrals are hardcoded to "ignore" in LDAP configuration.  This appears to be due to a previous specific AD issue that resulted in a fix of setting LDAP queries to ignore referrals.

The original issue appears to affect a specific circumstance of using AD but using another source for DNS resolval.  References to the fix of setting "ignore" state from BZ 582471 imply that the issue does not manifest when the environment uses AD DNS.

As we only allow the specification of one search base (which in some cases may need to be the LDAP root), enabling/disabling context referrals should be a configurable property in the server's LDAP configuration.  Alternatively, additional LDAP configuration options should be added to enable a user to specify both a user search base and a group search base which would avoid the referral issue with the LDAP root of AD sources and allow for limiting of the number of result objects being returned by searches through targetting specific branches of the LDAP tree for user and group selection.

Version-Release number of selected component (if applicable):
JBoss ON 3.2.0

How reproducible:
Very

Steps to Reproduce:
1. Attempt to use an LDAP base that requires the client to follow referrals

Actual results:
Attempt to retrieve data from LDAP results in an error.  For example, the below from an AD source:
Caused by: javax.naming.PartialResultException: [LDAP: error code 10 - 0000202B: RefErr: DSID-03100641, data 0, 1 access points
        ref 1: 'example.com'
]; remaining name 'dc=example,dc=com'"

Expected results:
Should be able to successfully retrieve LDAP data.

Additional info:
Referrals were turned off due to BZ 582471 to work around a specific issue.

Comment 2 Heiko W. Rupp 2014-06-24 15:18:48 UTC
commit in master 4ddea9bb2d940408

Comment 3 Jirka Kremser 2014-06-24 15:50:46 UTC
..and this one 3814b4bf6 (also in master)

The schema update is not allowed in CPs, so I'll create another commit specific to the release branch without the schema update part considering the missing system property in the db as a default value.

Comment 4 Jirka Kremser 2014-06-24 16:10:20 UTC
actually, no additional changes are needed for the release branch, c-picking the aforementioned two commits should be enough.

default behavior when the value is not present:
https://github.com/rhq-project/rhq/commit/4ddea9bb2d940408dbb7d47c2be84624f541eec9#diff-b4bfb9662d22bd8c1f6db428db5ddb21R231 does the trick

and if updating the non-existent value in the web UI it works as well (it gets created with a generated id)

So if upgrading from 3.2.2 to, say 3.3, the upgrade task that inserts the default value in to the db, will fail (because of the db constraint)

ERROR:  duplicate key value violates unique constraint "rhq_system_config_key_indx"
DETAIL:  Key (property_key)=(CAM_LDAP_FOLLOW_REFERRALS) already exists.

but the upgrade task has the flag 'ignoreError' set to true, so it won't blow up the upgrade db process and we should be good.

Comment 5 Jirka Kremser 2014-06-24 16:50:24 UTC
taking it back, another commit that will remove the db upgrade work is still needed. So only the first sentence of my previous comment was wrong, the rest holds.

828815e56 (not in master, but in the jkremser/bz1082806 branch)

Now, all is needed is to c-pick only this commit to the release branch, I've already resolved the conflicts.

Lukas, can you please cherry-pick it over?

Comment 6 Lukas Krejci 2014-06-24 21:18:24 UTC
commit 4f23c5dc8cc7831eb01d53138fde1b831e4cc496
Author: Jirka Kremser <jkremser>
Date:   Mon Jun 23 16:13:50 2014 +0200

    [BZ 1082806] - Context referrals are hardcoded to ignore in LDAP configuration - making 'follow referrals' optionally configurable in system settings
     * reverting the db schema part of the the commit 4ddea9bb2d940408 because we don't allow for schema updates in cumulative patches
    
    Signed-off-by: Lukas Krejci <lkrejci>
    
    Conflicts:
        modules/core/dbutils/src/main/scripts/dbsetup/sysconfig-data.xml
        modules/core/dbutils/src/main/scripts/dbupgrade/db-upgrade.xml
        modules/enterprise/gui/coregui/src/main/resources/org/rhq/coregui/client/Messages_de.properties
        modules/enterprise/gui/coregui/src/main/resources/org/rhq/coregui/client/Messages_ja.properties
    
    (cherry picked from commit 828815e564c1d1d56fd2674518699505c79acff5)
    Signed-off-by: Lukas Krejci <lkrejci>

Comment 7 Simeon Pinder 2014-06-30 06:03:08 UTC
Moving to ON_QA as available for test in latest build:
http://jon01.mw.lab.eng.bos.redhat.com:8042/dist/release/jon/3.2.2.GA/6-28-2014/

Comment 8 Jay Shaughnessy 2014-07-03 15:18:04 UTC
release/jon3.2.x commit 7fd6b112dbdb4334082a8fd26ac807593c75f5cc
Author: Jay Shaughnessy <jshaughn>
Date:   Thu Jul 3 11:13:52 2014 -0400

    [1082806] - addendum: Maintain existing enum ordinals by adding new
    enum entry to the end of the list.  For a CP it's important that we
    don't re-number existing ordinals.

Comment 13 Simeon Pinder 2014-07-11 13:43:07 UTC
Moving to ON_QA as available for test with build:
http://jon01.mw.lab.eng.bos.redhat.com:8042/dist/release/jon/3.2.2.GA/7-11-14_0600/

Comment 14 Sunil Kondkar 2014-07-16 15:02:06 UTC
Documenting what is tested on JON 3.2.2 CR1 build:

Tested on following setup on Windows server 2012 Active Directory:

Created two domains in one forest to follow referrals:
1. setup a root domain: mars.corp.com 
2. setup a child domain above root as: venus.mars.corp.com 

By default there is a trust relationship between the two domains.

In LDAP system settings in UI, provided the search base as basedn of root domain - mars.corp.com (dc=mars,dc=corp,dc=com)

-Verified that there is no PartialResultException in UI and server log when searching the ldap groups from JBoss ON roles UI.

-Verified that ldap groups to Jboss ON roles mapping is working and authentication and authorisation is working. 

-I could search the ldap groups and login with users in mars.corp.com (root domain) 

-The LDAP system settings in UI has a new config property 'Follow Referrals'. 

Tested searching ldap groups from JBoss ON roles UI with 'Follow Referrals' value as 'yes' and 'no'. There are no errors. 

What could not be tested:

Could not search groups and login with users in child domain ( venus.mars.corp.com) when search base provided in UI is root domain ( mars.corp.com ) and when 'Follow Referrals' value is 'yes'.

Additional Info:

I could search groups and login with users in child domain ( venus.mars.corp.com) when using the global catalog which contains information from each domain in the forest. ( Ex: provided the port number as '3268' in ldap URL).

However found that when search base is basedn of root domain, ldap groups in parent and child domain are available for both 'yes or 'no' values of 'Follow Referrals'.

Comment 16 Larry O'Leary 2014-07-29 00:17:26 UTC
This has been verified and released in Red Hat JBoss Operations Network 3.2 Update 02 (3.2.2) available from the Red Hat Customer Portal[1].



[1]: https://access.redhat.com/jbossnetwork/restricted/softwareDetail.html?softwareId=31783


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