Bug 582471 - PartialResultException when choosing particular Search Bases when using Active Directory
PartialResultException when choosing particular Search Bases when using Activ...
Product: RHQ Project
Classification: Other
Component: Core Server (Show other bugs)
All Linux
low Severity medium (vote)
: ---
: ---
Assigned To: Simeon Pinder
Corey Welton
: 583748 (view as bug list)
Depends On:
Blocks: jon24-ldap
  Show dependency treegraph
Reported: 2010-04-15 00:55 EDT by Charles Crouch
Modified: 2015-02-01 18:26 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-08-12 12:45:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Charles Crouch 2010-04-15 00:55:47 EDT
When setting LDAP Configuration Properties, if you specify a value for "Search Base:", e.g. DC=ad,DC=analog,DC=com, beneath which there are entries which are referrals...

DC=ForestDnsZones,DC=ad,DC=analog,DC=com is a referral to

then if you go to add LDAP groups to a role, i.e.
then you will get the following error:

java.lang.RuntimeException: javax.naming.PartialResultException [Root exception is javax.naming.CommunicationException: ad.analog.com:389 [Root exception is java.net.UnknownHostException: ad.analog.com]] at org.rhq.enterprise.server.resource.group.LdapGroupManager.buildGroup(LdapGroupManager.java:209) at org.rhq.enterprise.server.resource.group.LdapGroupManager.findAvailableGroups(LdapGroupManager.java:67) at org.rhq.enterprise.gui.admin.role.AddLdapGroupsFormPrepareAction.execute(AddLdapGroupsFormPrepareAction.java:84) at org.apache.struts.tiles.actions.TilesAction.execute(TilesAction.java:73) at org.rhq.enterprise.gui.legacy.action.BaseRequestProce...

The description for the cause of the problem appears to be given here:


"When searching LDAP from the root,  you will get a referral reply from AD
that has a server DNS name of JUST the domain name (ie company.com). NOT the
initial server name you used in your connectionURL. If your DNS or your
local hosts files does not resolve that root domain name to an AD server, it
will throw a 

javax.naming.PartialResultException [Root exception is
javax.naming.CommunicationException: company.com:389
[Root exception is java.net.UnknownHostException: company.com]]"

Looking at this page:
we should not need to turn referrals off explicitly, since they should be off by default. Also note the ominous warning at the end: "Because Active Directory does not support the Manage Referral control, none of the examples in this lesson will work against Active Directory."

I think we should try turning referrals off explicitly and seeing if that will help this situation.
Comment 1 Charles Crouch 2010-04-19 12:57:17 EDT
*** Bug 583748 has been marked as a duplicate of this bug. ***
Comment 2 Simeon Pinder 2010-04-22 11:01:25 EDT
A few source code/issue resolution updates.

1)Setting referrals to 'ignore' resolves the initial java.net.UnknownHostException but then continuation exceptions ensue.

EXCEPTION:Unprocessed Continuation Reference(s)
javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'dc=ad, dc=analog, dc=com'
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2793)
	at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2767)
	at com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1821)
	at com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1744)
	at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:368)
	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:338)
	at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:321)
	at javax.naming.directory.InitialDirContext.search(InitialDirContext.java:248)
	at com.test.beans.LdapTest.test(LdapTest.java:131)
	at com.test.beans.LdapTest.main(LdapTest.java:30)

2) This fix for these continuation exceptions is to use 
NamingEnumeration.hasMoreElements() instead of NamingEnumeration.hasMore() during search iteration.  Fixing those references now exposes the following NPE when moving through the enumerations despite getting true from NamingEnumeration.hasMoreElements():

Exception in thread "main" java.lang.NullPointerException
	at com.sun.jndi.ldap.LdapNamingEnumeration.getNextBatch(LdapNamingEnumeration.java:111)
	at com.sun.jndi.ldap.LdapNamingEnumeration.nextAux(LdapNamingEnumeration.java:245)
	at com.sun.jndi.ldap.LdapNamingEnumeration.nextImpl(LdapNamingEnumeration.java:236)
	at com.sun.jndi.ldap.LdapNamingEnumeration.next(LdapNamingEnumeration.java:184)
	at com.sun.jndi.ldap.LdapNamingEnumeration.nextElement(LdapNamingEnumeration.java:88)

3) As above NPE is obviously caused by some nonexistent condition check in the sun ldap libraries, I modified the rhq code to detect that NPE in the few places in our code where it could occur and move on. 

After which another RHQ bug was encountered but the AD lists are now being populated as one would expect.
Comment 3 Simeon Pinder 2010-04-22 16:26:46 EDT
Fixes committed and available in master build >= 241.

git commit hash:
Comment 4 Sunil Kondkar 2010-04-23 08:28:08 EDT
Verified in rhq build#241 (Revision: e38d846200a6bee16b87f7e8c0fe4679ff01752a)

If the search base configured is at the higher level where the groups
are created on active directory server (dc=test,dc=pnq,dc=com), the screen displays the list of available groups on active directory server and the ldap group mapping to rhq role is working.
Comment 5 Corey Welton 2010-08-12 12:45:54 EDT
Mass-closure of verified bugs against JON.

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