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
Steps to Reproduce:
1. Attempt to use an LDAP base that requires the client to follow referrals
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'"
Should be able to successfully retrieve LDAP data.
Referrals were turned off due to BZ 582471 to work around a specific issue.
commit in master 4ddea9bb2d940408
..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.
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.
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?
Author: Jirka Kremser <firstname.lastname@example.org>
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 <email@example.com>
(cherry picked from commit 828815e564c1d1d56fd2674518699505c79acff5)
Signed-off-by: Lukas Krejci <firstname.lastname@example.org>
Moving to ON_QA as available for test in latest build:
release/jon3.2.x commit 7fd6b112dbdb4334082a8fd26ac807593c75f5cc
Author: Jay Shaughnessy <email@example.com>
Date: Thu Jul 3 11:13:52 2014 -0400
 - 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.
Moving to ON_QA as available for test with build:
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'.
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'.
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.