Assets LDAP Import configuration times out or throws "javax.naming.PartialResultException: Unprocessed Continuation Reference(s)"


   

Platform Notice: Data Center - This article applies to Atlassian products on the Data Center platform.

Note that this knowledge base article was created for the Data Center version of the product. Data Center knowledge base articles for non-Data Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

 

Summary

While configuring Assets LDAP Import with an Active Directory or LDAP directory with a complex LDIF structure Assets import may time-out or throw this error "javax.naming.PartialResultException: Unprocessed Continuation Reference(s)". This has been seen in environments with the following situations:

  • You have a deep and complex LDAP/AD structure
  • The LDAP import is configured with "Follow Referrals = true"
  • For Windows Active Directory you're using port 389


Environment

Jira Service Management with Assets App

Diagnosis

  • Opening the Network tab while reproducing the issue you may see 400 error for the POST https://<JIRA_URL>/rest/insight/1.0/importsource/ot/ request with the following error in the response:


    {
      "errorMessages": [],
      "errors": {
        "ldapConfiguration": "Invalid LDAP configuration with detailed message (Unprocessed Continuation Reference(s))"
      }
    }
  • In the insight_import.log and atlassian-jira.log you may see the following exceptions:


insight_import.log

2024-01-24 22:36:54,033 [http-nio-8080-exec-31] | Unable to fetch data locators for configuration com.riadalabs.jira.plugins.insight.services.imports.modules.ldap.LdapConfiguration@5b8898cf, Error: Unprocessed Continuation Reference(s)
javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'DC=xxxx,DC=yyyy'
	at java.naming/com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3022)
	at java.naming/com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2996)
	at java.naming/com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1875)
	at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1798)
	at java.naming/com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392)
	at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
	at java.naming/javax.naming.directory.InitialDirContext.search(InitialDirContext.java:276)
	at com.riadalabs.jira.plugins.insight.services.imports.modules.ldap.LdapImportModule.searchLDAPObjects(LdapImportModule.java:602)
	at com.riadalabs.jira.plugins.insight.services.imports.modules.ldap.LdapImportModule.searchLDAPObjects(LdapImportModule.java:566)
	at com.riadalabs.jira.plugins.insight.services.imports.modules.ldap.LdapImportModule.fetchDataLocators(LdapImportModule.java:183)
	at com.riadalabs.jira.plugins.insight.services.imports.modules.ldap.LdapImportModule.fetchDataLocators(LdapImportModule.java:70)
	at com.riadalabs.jira.plugins.insight.services.jira.module.ImportModuleDelegator.fetchDataLocators(ImportModuleDelegator.java:119)
	at com.riadalabs.jira.plugins.insight.services.imports.common.DefaultImportService.getDataLocators(DefaultImportService.java:483)
	at com.riadalabs.jira.plugins.insight.services.imports.common.DefaultImportService.fetchDataLocators(DefaultImportService.java:334)
[...]
atlassian-jira.log

2024-01-24 22:36:54,036+0100 http-nio-8080-exec-31 ERROR xxx 1356x783998x1 w95ffe 10.97.22.66,10.151.209.179 /rest/insight/1.0/import/datalocators/36 [c.r.j.p.i.s.i.modules.ldap.LdapImportModule] Unable to fetch data locators for configuration com.riadalabs.jira.plugins.insight.services.imports.modules.ldap.LdapConfiguration@5b8898cf
javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name 'DC=xxxx,DC=yyyy'
	at java.naming/com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:3022)
	at java.naming/com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2996)
	at java.naming/com.sun.jndi.ldap.LdapCtx.searchAux(LdapCtx.java:1875)
	at java.naming/com.sun.jndi.ldap.LdapCtx.c_search(LdapCtx.java:1798)
	at java.naming/com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(ComponentDirContext.java:392)
	at java.naming/com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(PartialCompositeDirContext.java:358)
	at java.naming/javax.naming.directory.InitialDirContext.search(InitialDirContext.java:276)
	at com.riadalabs.jira.plugins.insight.services.imports.modules.ldap.LdapImportModule.searchLDAPObjects(LdapImportModule.java:602)
	at com.riadalabs.jira.plugins.insight.services.imports.modules.ldap.LdapImportModule.searchLDAPObjects(LdapImportModule.java:566)
	at com.riadalabs.jira.plugins.insight.services.imports.modules.ldap.LdapImportModule.fetchDataLocators(LdapImportModule.java:183)
	at com.riadalabs.jira.plugins.insight.services.imports.modules.ldap.LdapImportModule.fetchDataLocators(LdapImportModule.java:70)
	at com.riadalabs.jira.plugins.insight.services.jira.module.ImportModuleDelegator.fetchDataLocators(ImportModuleDelegator.java:119)
	at com.riadalabs.jira.plugins.insight.services.imports.common.DefaultImportService.getDataLocators(DefaultImportService.java:483)
	at com.riadalabs.jira.plugins.insight.services.imports.common.DefaultImportService.fetchDataLocators(DefaultImportService.java:334)
	at com.riadalabs.jira.plugins.insight.channel.web.api.rest.services.imports.ImportResource.fetchDataLocators(ImportResource.java:244)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[...]


Cause

There are a couple of layers to this problem and why it happens - 

  1. Using the "Follow Referrals = true" in a deep and complex LDAP/AD structure means that the REST calls to fetch the LDAP attributes and users/groups would take longer
  2. Using the port 389 for Active Directory instead of Global Catalogue Port 3268 (or 3269 for ldaps) fetches the required information in an iterative way which may timeout in a large AD infrastructure

Solution

To work around this issue, we need to address the problem in layers:

  • to proceed with the LDAP Import configuration, use port 3268 (or 3269 for LDAPS);
  • Global catalogue generally would not be configured to return all the attributes to keep the port performance and hence to find the missing attributes in the import configuration switch back to the regular LDAP port (389) and turn off the Follow Referrals option in the Import Configuration

This way the initial configuration of the import works quickly as we're using Global Catalogue port 3268 which is much more performant than the regular LDAP port 389. Following that up with a switch back to the 389 port fetches all the missing attributes in the Import configuration since Global catalogue woulnd't return all of them. Once you follow it up with Synchronizing the data, you'll have the user information you need on Assets Object Schema.




Last modified on Mar 12, 2024

Was this helpful?

Yes
No
Provide feedback about this article
Powered by Confluence and Scroll Viewport.