Bug 1082806
Summary: | Context referrals are hardcoded to "ignore" in LDAP configuration | ||
---|---|---|---|
Product: | [JBoss] JBoss Operations Network | Reporter: | Marc Shirley <mshirley> |
Component: | Security | Assignee: | Jirka Kremser <jkremser> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Mike Foley <mfoley> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | JON 3.2 | CC: | asantos, hrupp, jshaughn, lkrejci, loleary, myarboro, skondkar |
Target Milestone: | CR01 | Keywords: | TestCaseNeeded, Triaged |
Target Release: | JON 3.2.2 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-07-29 00:17:26 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Marc Shirley
2014-03-31 20:54:50 UTC
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? 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> 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/ 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. 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/ 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'. 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 |