Unprocessed continuation reference java

LDAP search Unprocessed Continuation Reference(s)

I am using Grails 2, Groovy 1.8.5, Grails Ldap plugin to perform lookups via LDAP on Active Directory and I am getting javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name ‘/’. For authorization I use Spring LDAP which works fine with no problems.
I have looked around and most threads are talking about automatically following referrals which I use this flag for derefLinkFlag = true
I have even tried to pass this argument to JVM -Djava.naming.referral=follow

Has anyone come across this? Any suggestions are welcomed. Do you think it is something related to how AD is set up and if yes, what should I look for, I am new to AD.

I can avoid this exception because it happens my Active Directory to be Global Catalog, so I just connect to port 3268 and everything works fine. However, there is a caveat, not all attributes are added to Global Catalog, such as physicalDeliveryOfficeName. Which is also something that can be solved by replicating/including the attribute to GC schema, but it is something I do not wish to do for a number of reasons.

The code follows:
The config

ldap < directories < rootdir < url = "ldap://my.company.com:389" base = "DC=my,DC=company,DC=com" userDn = "cn=User Name,cn=Users,dc=my,dc=company,dc=com" password = "secret" searchControls < countLimit = 400 timeLimit = 6000 searchScope = "subtree" derefLinkFlag = true >> > schemas = [ com.mycompany.ldap.User, com.mycompany.ldap.Group ] > 

@GldapoSchemaFilter("(objectclass=person)") class User

 class UserController < def index() < redirect(action: "list") >def list() < List users = User.findAll() [userInstanceList: users, userInstanceTotal: users.size()] >> 

Unprocessed Continuation Reference(s). Stacktrace follows: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name '/' at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2846) at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2820) at com.sun.jndi.ldap.LdapNamingEnumeration.getNextBatch(LdapNamingEnumeration.java:129) at com.sun.jndi.ldap.LdapNamingEnumeration.hasMoreImpl(LdapNamingEnumeration.java:198) at com.sun.jndi.ldap.LdapNamingEnumeration.hasMore(LdapNamingEnumeration.java:171) at gldapo.GldapoDirectory.nonPagedSearch(GldapoDirectory.groovy:162) at gldapo.GldapoDirectory.search(GldapoDirectory.groovy:144) at gldapo.schema.GldapoSchemaClassInjecto$__clinit__closure35.doCall(GldapoSchemaClassInjecto.groovy:374) at gldapo.schema.GldapoSchemaClassInjecto$__clinit__closure38.doCall(GldapoSchemaClassInjecto.groovy:390) at uk.co.mycomp.myapp.ldap.UserController.list(UserController.groovy:15) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) 

Best Solution

The solution is to include the following line to your ldap settings in Config.groovy

ignorePartialResultExcepton = true 

Источник

How to resolve javax.naming.PartialResultException?

How to resolve javax.naming.PartialResultException?

We are seeing this warning messages in our logs

javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name ‘dc=global,dc=com’

It appears whenever users log-in to our application.

As per this SO post, it can be resolved, by setting Context.REFERRAL to follow . But it increases the search time from 1 second to 4 seconds.

In fact you can refer this SO post, it says using follow slows down the search.

So my question is, what is the best way to get rid of this exception from our logs without affecting performance?.

Solution – 1

OK. You will be seeing this exception, when your search returns referral and you set to ignore the referral.

[Referral: When you search in AD, if AD thinks there are more information available in another place, it returns a referral [place to find more info] along with your search results.]

You could avoid this exception by setting Context.REFERRAL to follow . Then it would search in the referral also [That’s why it takes more time to return result].

But in my case the referral is invalid and returned an another exception.

I fixed this issue by changing the baseDN (search base) to be more specific. E.g. ou=users,dc=mydomain,dc=com . Now I’m not seeing this exception, because it doesn’t return any referral.

Solution – 2

Another possible solution that may work is to change the port number (assuming this is a GC server):

If you were using the port 389 change it to 3268

If you were using the port 636 change it to 3269

This may work because (and I quote):

A GC (global catalog) server returns referrals on 389 to refer to the
greater AD «forest», but acts like a regular LDAP server on 3268 (and
3269 for LDAPS)

I found this solution in the Shibboleth Users list, answered by Paul Caskey (all the credit to him).

You can check the conversation on this link:

Solution – 3

Both of the other two answers work by following any referral that is returned in the LDAP query. That’s probably the recommended way in most situations.

However, if the requirement is if fact to use «ignore» so not to follow referrals, then a javax.naming.PartialResultException: Unprocessed Continuation Reference(s) will always be returned whenever a referral is found.

The solution is to also ignore the javax.naming.PartialResultException (by catching and swallowing it) when Context.REFERRAL is set to ignore . I recommend to at least log a warning though.

I assume this somehow awkward implementation of «ignore» was made to make sure that the caller is aware of the fact that partial results are really accepted.

Источник

LdapTemplate: javax.naming.PartialResultException: Unprocessed Continuation Reference(s); remaining name ‘…’

To prevent the referral issues when dealing with Active Directory, we may query against the Global Catalog by using port 3268.

@Bean ContextSource contextSource(AuthenticationSource authenticationSource) < return new LdapContextSource( authenticationSource: authenticationSource, url: 'ldap://server:3268', base: 'dc=domain' ) >

The possible downside to this approach is the Global Catalog may not have the pertinent data we need, such as employeeID, etc.

Configure Referral to Follow

We can configure LdapTemplate to automatically follow any referrals.

@Bean ContextSource contextSource(AuthenticationSource authenticationSource) < return new LdapContextSource( authenticationSource: authenticationSource, url: 'ldap://server:389', base: 'dc=domain', referral: 'follow' ) >

The downside to this approach is it makes the query much slower. Based on my testing, it is at least 5 to 10 seconds slower.

Ignore Exception

Sometimes, it pays to read the JavaDoc. Based on the LdapTemplate’s documentation, it says…

Note for Active Directory (AD) users: AD servers are apparently unable to handle referrals automatically, which causes a PartialResultException to be thrown whenever a referral is encountered in a search. To avoid this, set the ignorePartialResultException property to true. There is currently no way of manually handling these referrals in the form of ReferralException, i.e. either you get the exception (and your results are lost) or all referrals are ignored (if the server is unable to handle them properly. Neither is there any simple way to get notified that a PartialResultException has been ignored (other than in the log).

@Bean LdapTemplate getLdapTemplate(ContextSource contextSource)

Share this:

Источник

Saved searches

Use saved searches to filter your results more quickly

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Unprocessed Continuation on LDAP Connections #1413

I’m trying to use LDAP with AKHQ, with the following configs:

micronaut: security: enabled: true ldap: default: enabled: true context: server: ldap://myldap.local:389 managerDn: CN=ldap_kafka,CN=Managed Service Accounts,DC=mycompany,DC=local managerPassword: 'bbb' search: base: "DC=mycompany,DC=local" attributes: - "sAMAccountName" filter: "sAMAccountName=" groups: enabled: true subtree: true base: "OU=Kafka,OU=Grupos de Segurança TI,OU=Grupos Segurança,DC=mycompany,DC=local" filter: "member=" 

But when trying to login I got the following error:

2023-03-12 08:31:56,968 ERROR r-thread-3 o.a.c.ErrorController Unprocessed Continuation Reference(s) javax.naming.PartialResultException: Unprocessed Continuation Reference(s) 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.AbstractLdapNamingEnumeration.getNextBatch(AbstractLdapNamingEnumeration.java:148) at java.naming/com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMoreImpl(AbstractLdapNamingEnumeration.java:217) at java.naming/com.sun.jndi.ldap.AbstractLdapNamingEnumeration.hasMore(AbstractLdapNamingEnumeration.java:189) at io.micronaut.security.ldap.context.DefaultLdapSearchService.createResults(DefaultLdapSearchService.java:68) at io.micronaut.security.ldap.context.DefaultLdapSearchService.search(DefaultLdapSearchService.java:56) at io.micronaut.security.ldap.context.DefaultLdapSearchService.searchFirst(DefaultLdapSearchService.java:40) at io.micronaut.security.ldap.LdapAuthenticationProvider.lambda$authenticate$2(LdapAuthenticationProvider.java:111) at reactor.core.publisher.FluxCreate.subscribe(FluxCreate.java:95) at reactor.core.publisher.InternalFluxOperator.subscribe(InternalFluxOperator.java:62) at reactor.core.publisher.FluxSubscribeOn$SubscribeOnSubscriber.run(FluxSubscribeOn.java:194) at io.micronaut.reactive.reactor.instrument.ReactorInstrumentation.lambda$init$0(ReactorInstrumentation.java:62) at reactor.core.scheduler.WorkerTask.call(WorkerTask.java:84) at reactor.core.scheduler.WorkerTask.call(WorkerTask.java:37) at io.micrometer.core.instrument.composite.CompositeTimer.recordCallable(CompositeTimer.java:77) at io.micrometer.core.instrument.Timer.lambda$wrap$1(Timer.java:162) at io.micronaut.scheduling.instrument.InvocationInstrumenterWrappedCallable.call(InvocationInstrumenterWrappedCallable.java:53) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829) 

Beta Was this translation helpful? Give feedback.

1 You must be logged in to vote

Источник