Bug 582471

Summary:	PartialResultException when choosing particular Search Bases when using Active Directory
Product:	[Other] RHQ Project	Reporter:	Charles Crouch <ccrouch>
Component:	Core Server	Assignee:	Simeon Pinder <spinder>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Corey Welton <cwelton>
Severity:	medium	Docs Contact:
Priority:	low
Version:	unspecified	CC:	hbrock, skondkar
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	2.4	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-08-12 16:45:54 UTC	Type:	---
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:
Bug Blocks:	577267

Description Charles Crouch 2010-04-15 04:55:47 UTC

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...

 e.g.
DC=ForestDnsZones,DC=ad,DC=analog,DC=com is a referral to
ldap://ForestDnsZones.ad.analog.com:389 

then if you go to add LDAP groups to a role, i.e. http://10.16.120.195:7080/admin/role/RoleAdmin.do?r=2&mode=addLdapGroups
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:
http://mail-archives.apache.org/mod_mbox/tomcat-users/200611.mbox/%3CC16E4268.9601B%25mwarren@hnw.com%3E

Namely...

"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:
http://java.sun.com/products/jndi/tutorial/ldap/referral/jndi.html
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 16:57:17 UTC

*** Bug 583748 has been marked as a duplicate of this bug. ***

Comment 2 Simeon Pinder 2010-04-22 15:01:25 UTC

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 20:26:46 UTC

Fixes committed and available in master build >= 241.

git commit hash:
e38d846200a6bee16b87f7e8c0fe4679ff01752a

Comment 4 Sunil Kondkar 2010-04-23 12:28:08 UTC

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 16:45:54 UTC

Mass-closure of verified bugs against JON.