Come risolvere javax.naming.PartialResultException?

Question

Stiamo vedendo questo messaggio di avviso nei nostri registri di

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

Sembra ogni volta log-negli utenti alla nostra applicazione.

Come da this SO post, può essere risolto impostando Context.REFERRAL su follow. Ma aumenta il tempo di ricerca da 1 secondo a 4 secondi.

In effetti è possibile fare riferimento a this SO post, si dice che utilizzando follow rallenta la ricerca.

Quindi la mia domanda è: qual è il modo migliore per sbarazzarsi di questa eccezione dai nostri registri senza influire sulle prestazioni ?.

Answer 1

OK. Visualizzerai questa eccezione, quando la tua ricerca restituisce referral e tu decidi di ignorare il referral.

[Referral:. Quando si cerca in AD, se dC pensa che ci sono ulteriori informazioni disponibili in un altro luogo, restituisce un rinvio [posto giusto per trovare maggiori informazioni] insieme con i risultati della ricerca]

Si poteva evitare questa eccezione impostando Context.REFERRAL a follow. Quindi cercherebbe anche nel referral [Ecco perché ci vuole più tempo per restituire il risultato].

Ma nel mio caso il riferimento non è valido e ha restituito un'altra eccezione.

Ho risolto questo problema cambiando il baseDN (base di ricerca) per essere più specifico. Per Ex: "ou = users, dc = mydomain, dc = com". Ora non vedo questa eccezione, perché non restituisce alcun riferimento.

Answer 2

Un'altra possibile soluzione che può funzionare è quello di cambiare il numero di porta (supponendo che questo è un server GC):

Se si sta utilizzando il cambiamento porta 389 a 3268

Se si sta utilizzando il cambiamento porta 636 a 3269

Questo può funzionare perché (cito):

Un GC Server (catalogo globale) restituisce i rinvii da 389 a si riferiscono alla maggior AD "foresta", ma agisce come un server LDAP regolare su 3268 (e 3269 per LDAPS)

ha funzionato per me.

Ho trovato questa soluzione nell'elenco degli utenti di Shibboleth, a cui ha risposto Paul Caskey (tutto il merito a lui).

È possibile controllare la conversazione su questo link:

https://lists.internet2.edu/sympa/arc/shibboleth-users/2008-06/msg00039.html