[Jxplorer-users] jxplorer with GSSAPI gives ArrayIndexOutOfBoundsException: 13

[Soós László]

Dear Members,

Any of you experience the following issue:
When I try to connect to an LDAP server (no SSL, port 389, LDAP v3) with
GSSAPI I get the following message:
"java.lang.ArrayIndexOutOfBoundsException: 13
at sun.security.jgss.krb5.WrapToken.getPadding(Unknown Source)
at sun.security.jgss.krb5.WrapToken.<init>(Unknown Source)
at sun.security.jgss.krb5.Krb5Context.wrap(Unknown Source)
at sun.security.jgss.GSSContextImpl.wrap(Unknown Source)
at com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(Unknown Source)
at com.sun.jndi.ldap.sasl.SaslOutputStream.write(Unknown Source)
at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source)
at com.sun.jndi.ldap.LdapClient.search(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.doSearch(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown
Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
at com.ca.commons.jndi.JNDIOps.exists(JNDIOps.java:702)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:491)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:422)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processRequest(JNDIDataBroker.java:396)
at
com.ca.directory.jxplorer.broker.DataBroker.processQueue(DataBroker.java:200)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processQueue(JNDIDataBroker.java:913)
at com.ca.directory.jxplorer.broker.DataBroker.run(DataBroker.java:165)
at java.lang.Thread.run(Unknown Source)"


System is Windows Server 2012 R2

java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) Client VM (build 25.25-b02, mixed mode)

I have my KRB5 credcache in %USERPROFILE%\krb5cc_%USERNAME%

I'm not exactly sure what happened when it stopped working but it worked
before (either a windows update or java update or openldap server upgrade)

It still works without GSSAPI (plain user/pass)

I'm open for any suggestions how to troubleshoot further as I'm out of
ideas.

Regards,
Laszlo

[Chris Betts]

Hi Laszio,

I'm a bit out of my depth here myself; JX is calling the jndi library
to open the connection, and it looks like deep in the processing there's a
problem with the kerberos token?

You could try adding "-Djavax.net.debug" in the jxplorer.bat file and
see if the trace information gives you any more detail?

cheers,

- Chris

-----
*Dr Christopher Betts*
Australian Cloud Identity
http://cloudidentity.com.au
m: 0408 533 456

Post by Soós László
Dear Members,
When I try to connect to an LDAP server (no SSL, port 389, LDAP v3) with
"java.lang.ArrayIndexOutOfBoundsException: 13
at sun.security.jgss.krb5.WrapToken.getPadding(Unknown Source)
at sun.security.jgss.krb5.WrapToken.<init>(Unknown Source)
at sun.security.jgss.krb5.Krb5Context.wrap(Unknown Source)
at sun.security.jgss.GSSContextImpl.wrap(Unknown Source)
at com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(Unknown Source)
at com.sun.jndi.ldap.sasl.SaslOutputStream.write(Unknown Source)
at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source)
at com.sun.jndi.ldap.LdapClient.search(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.doSearch(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown
Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
at com.ca.commons.jndi.JNDIOps.exists(JNDIOps.java:702)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:491)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:422)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processRequest(JNDIDataBroker.java:396)
at
com.ca.directory.jxplorer.broker.DataBroker.processQueue(DataBroker.java:200)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processQueue(JNDIDataBroker.java:913)
at
com.ca.directory.jxplorer.broker.DataBroker.run(DataBroker.java:165)
at java.lang.Thread.run(Unknown Source)"
System is Windows Server 2012 R2
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) Client VM (build 25.25-b02, mixed mode)
I have my KRB5 credcache in %USERPROFILE%\krb5cc_%USERNAME%
I'm not exactly sure what happened when it stopped working but it worked
before (either a windows update or java update or openldap server upgrade)
It still works without GSSAPI (plain user/pass)
I'm open for any suggestions how to troubleshoot further as I'm out of
ideas.
Regards,
Laszlo
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

[Soós László]

Hi Chris,

I believe there is something changed in jndi that jxplorer did not
follow yet?

It surely worked before on exactly same environment, except we did a
couple of updates but all in once so I cannot tell which one exactly
broke it down.
(usual upgrades: windows updates, java update, on server openldap updates)

Anyway -Djavaxnet.debug gives kinda the same.

c:\Program Files (x86)\jxplorer>java -classpath ".;jars/*;jasper/lib/*"
-Djavax.net.debug -Dfile.encoding=utf-8 com.ca.directory.jxplorer.JXplorer
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXplorer printTime
INFO: main start
TIME: Tue Dec 16 22:48:18 CET 2014 (411)

dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXplorer
checkJavaEnvironment
INFO: running java from: C:\Program Files (x86)\Java\jre1.8.0_25
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXplorer
checkJavaEnvironment
INFO: running java version 1.8.0_25
dec. 16, 2014 10:48:18 DU com.ca.commons.cbutil.CBUtility
checkAndCreateWorkingDirectory
WARNING: ERROR: unable to save config or store user data in c:\Program
Files (x86)\jxplorer\ (may try elsewhere)
unable to use user.dir
On Windows
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXConfig
getConfigDirectory
INFO: JX using configDirectory:
C:\Users\<username>\AppData\Roaming\jxplorer\
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXConfig
getConfigDirectory
INFO: JX using configDirectory:
C:\Users\<username>\AppData\Roaming\jxplorer\
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXConfig
getConfigDirectory
INFO: JX using configDirectory:
C:\Users\<username>\AppData\Roaming\jxplorer\
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXConfig setupLogger
INFO: setting up logger
logging level set from config to: WARNING with 0 parents=true
dec. 16, 2014 10:48:18 DU com.ca.commons.cbutil.CBUtility readPropertyFile
WARNING: No property list:
C:\Users\<username>\AppData\Roaming\jxplorer\search_filters.txt
dec. 16, 2014 10:48:18 DU com.ca.commons.cbutil.CBUtility readPropertyFile
WARNING: No property list:
bookmarks.txt
dec. 16, 2014 10:48:18 DU com.ca.commons.cbutil.CBUtility readPropertyFile
WARNING: No property list:
quicksearch.txt
Debug is true storeKey false useTicketCache true useKeyTab false
doNotPrompt false ticketCache is null isInitiator true KeyTab is null
refreshKrb5Config is false principal is null tryFirstPass is fal
se useFirstPass is false storePass is false clearPass is false
Acquire TGT from Cache
Principal is <username>@REALM.LAN
Commit Succeeded

dec. 16, 2014 10:48:23 DU
com.ca.directory.jxplorer.broker.JNDIDataBroker openConnection
WARNING: initial receipt of exception by jndi broker 13
java.lang.ArrayIndexOutOfBoundsException: 13
at sun.security.jgss.krb5.WrapToken.getPadding(Unknown Source)
at sun.security.jgss.krb5.WrapToken.<init>(Unknown Source)
at sun.security.jgss.krb5.Krb5Context.wrap(Unknown Source)
at sun.security.jgss.GSSContextImpl.wrap(Unknown Source)
at com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(Unknown Source)
at com.sun.jndi.ldap.sasl.SaslOutputStream.write(Unknown Source)
at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source)
at com.sun.jndi.ldap.LdapClient.search(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.doSearch(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
at com.ca.commons.jndi.JNDIOps.exists(JNDIOps.java:702)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:491)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:422)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processRequest(JNDIDataBroker.java:396)
at
com.ca.directory.jxplorer.broker.DataBroker.processQueue(DataBroker.java:200)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processQueue(JNDIDataBroker.java:913)
at
com.ca.directory.jxplorer.broker.DataBroker.run(DataBroker.java:165)
at java.lang.Thread.run(Unknown Source)
dec. 16, 2014 10:48:49 DU com.ca.directory.jxplorer.JXOpenConWin dataReady
WARNING: Error opening connection
java.lang.ArrayIndexOutOfBoundsException: 13
at sun.security.jgss.krb5.WrapToken.getPadding(Unknown Source)
at sun.security.jgss.krb5.WrapToken.<init>(Unknown Source)
at sun.security.jgss.krb5.Krb5Context.wrap(Unknown Source)
at sun.security.jgss.GSSContextImpl.wrap(Unknown Source)
at com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(Unknown Source)
at com.sun.jndi.ldap.sasl.SaslOutputStream.write(Unknown Source)
at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source)
at com.sun.jndi.ldap.LdapClient.search(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.doSearch(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
at com.ca.commons.jndi.JNDIOps.exists(JNDIOps.java:702)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:491)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:422)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processRequest(JNDIDataBroker.java:396)
at
com.ca.directory.jxplorer.broker.DataBroker.processQueue(DataBroker.java:200)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processQueue(JNDIDataBroker.java:913)
at
com.ca.directory.jxplorer.broker.DataBroker.run(DataBroker.java:165)
at java.lang.Thread.run(Unknown Source)

Regards,
Laszlo

Post by Chris Betts
Hi Laszio,
I'm a bit out of my depth here myself; JX is calling the jndi
library to open the connection, and it looks like deep in the
processing there's a problem with the kerberos token?
You could try adding "-Djavax.net.debug" in the jxplorer.bat file
and see if the trace information gives you any more detail?
cheers,
- Chris
-----
*Dr Christopher Betts*
Australian Cloud Identity
http://cloudidentity.com.au
m: 0408 533 456
Dear Members,
When I try to connect to an LDAP server (no SSL, port 389, LDAP v3) with
"java.lang.ArrayIndexOutOfBoundsException: 13
at sun.security.jgss.krb5.WrapToken.getPadding(Unknown Source)
at sun.security.jgss.krb5.WrapToken.<init>(Unknown Source)
at sun.security.jgss.krb5.Krb5Context.wrap(Unknown Source)
at sun.security.jgss.GSSContextImpl.wrap(Unknown Source)
at com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(Unknown Source)
at com.sun.jndi.ldap.sasl.SaslOutputStream.write(Unknown Source)
at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source)
at com.sun.jndi.ldap.LdapClient.search(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.doSearch(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown
Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
at com.ca.commons.jndi.JNDIOps.exists(JNDIOps.java:702)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:491)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:422)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processRequest(JNDIDataBroker.java:396)
at
com.ca.directory.jxplorer.broker.DataBroker.processQueue(DataBroker.java:200)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processQueue(JNDIDataBroker.java:913)
at
com.ca.directory.jxplorer.broker.DataBroker.run(DataBroker.java:165)
at java.lang.Thread.run(Unknown Source)"
System is Windows Server 2012 R2
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) Client VM (build 25.25-b02, mixed mode)
I have my KRB5 credcache in %USERPROFILE%\krb5cc_%USERNAME%
I'm not exactly sure what happened when it stopped working but it worked
before (either a windows update or java update or openldap server upgrade)
It still works without GSSAPI (plain user/pass)
I'm open for any suggestions how to troubleshoot further as I'm out of
ideas.
Regards,
Laszlo
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar
corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

[Chris Betts]

Hi Laszlo,

I think you might be right about changes in gsapi handling in java 1.8
- I don't know if this stuff is relevant but it sounds like others have had
trouble recently with GSAPI?

https://issues.apache.org/bugzilla/show_bug.cgi?id=57022

... my problem is that the GSAPI code was very kindly contributed by a
JX user, and I'm not familiar enough with how GSAPI operates to work on it
safely :-/. So apart from obvious suggestions (like keep using java 1.7
for awhile and hope 1.8 sorts its problems out!) I'm not sure how to help
you. If there are any GSAPI experts out there that can suggest a patch I'd
be happy to take their advice!

cheers,

- Chris

-----
*Dr Christopher Betts*
Australian Cloud Identity
http://cloudidentity.com.au
m: 0408 533 456

Post by Soós László
Hi Chris,
I believe there is something changed in jndi that jxplorer did not follow
yet?
It surely worked before on exactly same environment, except we did a
couple of updates but all in once so I cannot tell which one exactly broke
it down.
(usual upgrades: windows updates, java update, on server openldap updates)
Anyway -Djavaxnet.debug gives kinda the same.
c:\Program Files (x86)\jxplorer>java -classpath ".;jars/*;jasper/lib/*"
-Djavax.net.debug -Dfile.encoding=utf-8 com.ca.directory.jxplorer.JXplorer
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXplorer printTime
INFO: main start
TIME: Tue Dec 16 22:48:18 CET 2014 (411)
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXplorer
checkJavaEnvironment
INFO: running java from: C:\Program Files (x86)\Java\jre1.8.0_25
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXplorer
checkJavaEnvironment
INFO: running java version 1.8.0_25
dec. 16, 2014 10:48:18 DU com.ca.commons.cbutil.CBUtility
checkAndCreateWorkingDirectory
WARNING: ERROR: unable to save config or store user data in c:\Program
Files (x86)\jxplorer\ (may try elsewhere)
unable to use user.dir
On Windows
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXConfig
getConfigDirectory
C:\Users\<username>\AppData\Roaming\jxplorer\
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXConfig
getConfigDirectory
C:\Users\<username>\AppData\Roaming\jxplorer\
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXConfig
getConfigDirectory
C:\Users\<username>\AppData\Roaming\jxplorer\
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXConfig setupLogger
INFO: setting up logger
logging level set from config to: WARNING with 0 parents=true
dec. 16, 2014 10:48:18 DU com.ca.commons.cbutil.CBUtility readPropertyFile
C:\Users\<username>\AppData\Roaming\jxplorer\search_filters.txt
dec. 16, 2014 10:48:18 DU com.ca.commons.cbutil.CBUtility readPropertyFile
bookmarks.txt
dec. 16, 2014 10:48:18 DU com.ca.commons.cbutil.CBUtility readPropertyFile
quicksearch.txt
Debug is true storeKey false useTicketCache true useKeyTab false
doNotPrompt false ticketCache is null isInitiator true KeyTab is null
refreshKrb5Config is false principal is null tryFirstPass is fal
se useFirstPass is false storePass is false clearPass is false
Acquire TGT from Cache
Commit Succeeded
dec. 16, 2014 10:48:23 DU com.ca.directory.jxplorer.broker.JNDIDataBroker
openConnection
WARNING: initial receipt of exception by jndi broker 13
java.lang.ArrayIndexOutOfBoundsException: 13
at sun.security.jgss.krb5.WrapToken.getPadding(Unknown Source)
at sun.security.jgss.krb5.WrapToken.<init>(Unknown Source)
at sun.security.jgss.krb5.Krb5Context.wrap(Unknown Source)
at sun.security.jgss.GSSContextImpl.wrap(Unknown Source)
at com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(Unknown Source)
at com.sun.jndi.ldap.sasl.SaslOutputStream.write(Unknown Source)
at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source)
at com.sun.jndi.ldap.LdapClient.search(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.doSearch(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown
Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
at com.ca.commons.jndi.JNDIOps.exists(JNDIOps.java:702)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:491)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:422)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processRequest(JNDIDataBroker.java:396)
at
com.ca.directory.jxplorer.broker.DataBroker.processQueue(DataBroker.java:200)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processQueue(JNDIDataBroker.java:913)
at
com.ca.directory.jxplorer.broker.DataBroker.run(DataBroker.java:165)
at java.lang.Thread.run(Unknown Source)
dec. 16, 2014 10:48:49 DU com.ca.directory.jxplorer.JXOpenConWin dataReady
WARNING: Error opening connection
java.lang.ArrayIndexOutOfBoundsException: 13
at sun.security.jgss.krb5.WrapToken.getPadding(Unknown Source)
at sun.security.jgss.krb5.WrapToken.<init>(Unknown Source)
at sun.security.jgss.krb5.Krb5Context.wrap(Unknown Source)
at sun.security.jgss.GSSContextImpl.wrap(Unknown Source)
at com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(Unknown Source)
at com.sun.jndi.ldap.sasl.SaslOutputStream.write(Unknown Source)
at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source)
at com.sun.jndi.ldap.LdapClient.search(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.doSearch(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown
Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
at com.ca.commons.jndi.JNDIOps.exists(JNDIOps.java:702)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:491)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:422)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processRequest(JNDIDataBroker.java:396)
at
com.ca.directory.jxplorer.broker.DataBroker.processQueue(DataBroker.java:200)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processQueue(JNDIDataBroker.java:913)
at
com.ca.directory.jxplorer.broker.DataBroker.run(DataBroker.java:165)
at java.lang.Thread.run(Unknown Source)
Regards,
Laszlo
Hi Laszio,
I'm a bit out of my depth here myself; JX is calling the jndi
library to open the connection, and it looks like deep in the processing
there's a problem with the kerberos token?
You could try adding "-Djavax.net.debug" in the jxplorer.bat file and
see if the trace information gives you any more detail?
cheers,
- Chris
-----
*Dr Christopher Betts*
Australian Cloud Identity
http://cloudidentity.com.au
m: 0408 533 456

Post by Soós László
Dear Members,
When I try to connect to an LDAP server (no SSL, port 389, LDAP v3) with
"java.lang.ArrayIndexOutOfBoundsException: 13
at sun.security.jgss.krb5.WrapToken.getPadding(Unknown Source)
at sun.security.jgss.krb5.WrapToken.<init>(Unknown Source)
at sun.security.jgss.krb5.Krb5Context.wrap(Unknown Source)
at sun.security.jgss.GSSContextImpl.wrap(Unknown Source)
at com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(Unknown Source)
at com.sun.jndi.ldap.sasl.SaslOutputStream.write(Unknown Source)
at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source)
at com.sun.jndi.ldap.LdapClient.search(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.doSearch(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown
Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
at com.ca.commons.jndi.JNDIOps.exists(JNDIOps.java:702)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:491)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:422)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processRequest(JNDIDataBroker.java:396)
at
com.ca.directory.jxplorer.broker.DataBroker.processQueue(DataBroker.java:200)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processQueue(JNDIDataBroker.java:913)
at
com.ca.directory.jxplorer.broker.DataBroker.run(DataBroker.java:165)
at java.lang.Thread.run(Unknown Source)"
System is Windows Server 2012 R2
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) Client VM (build 25.25-b02, mixed mode)
I have my KRB5 credcache in %USERPROFILE%\krb5cc_%USERNAME%
I'm not exactly sure what happened when it stopped working but it worked
before (either a windows update or java update or openldap server upgrade)
It still works without GSSAPI (plain user/pass)
I'm open for any suggestions how to troubleshoot further as I'm out of
ideas.
Regards,
Laszlo
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREEhttp://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

[Soós László]

Hi Chris,

Sorry for long turnaround I finally installed back Java 1.7 and that
didn't work out either.

But I noticed another strange behaviour. If I change the krb5.ini to
default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5
default_tkt_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5

I get:
java.lang.ArrayIndexOutOfBoundsException: 13

WARNING: initial receipt of exception by jndi broker 13
java.lang.ArrayIndexOutOfBoundsException: 13
at sun.security.jgss.krb5.WrapToken.getPadding(Unknown Source)
at sun.security.jgss.krb5.WrapToken.<init>(Unknown Source)
at sun.security.jgss.krb5.Krb5Context.wrap(Unknown Source)
at sun.security.jgss.GSSContextImpl.wrap(Unknown Source)
--
If I comment these line out (eg let kerberos to use default setting) I get:
java.lang.NegativeArraySizeException

WARNING: Error opening connection
java.lang.NegativeArraySizeException
at sun.security.jgss.krb5.CipherHelper.aes128Encrypt(Unknown
Source)
at sun.security.jgss.krb5.CipherHelper.encryptData(Unknown Source)
at sun.security.jgss.krb5.WrapToken_v2.<init>(Unknown Source)
at sun.security.jgss.krb5.Krb5Context.wrap(Unknown Source)

I run the debug batch with command:
"c:\Program Files\Java\jre1.8.0_31\bin\java.exe" -classpath
".;jars/*;jasper/lib/*" -Dsun.security.krb5.debug=true
-Djava.security.krb5.conf=C:\windows\krb5.ini -Dfile.encoding=utf-8
%JXOPTS% com.ca.directory.jxplorer.JXplorer %*

but I do not get any new useful output.
Do you have any idea what else I can do here to get it back working like
it worked before?

Thanks,
Laszlo

Post by Chris Betts
Hi Laszlo,
I think you might be right about changes in gsapi handling in
java 1.8 - I don't know if this stuff is relevant but it sounds like
others have had trouble recently with GSAPI?
https://issues.apache.org/bugzilla/show_bug.cgi?id=57022
... my problem is that the GSAPI code was very kindly contributed
by a JX user, and I'm not familiar enough with how GSAPI operates to
work on it safely :-/. So apart from obvious suggestions (like keep
using java 1.7 for awhile and hope 1.8 sorts its problems out!) I'm
not sure how to help you. If there are any GSAPI experts out there
that can suggest a patch I'd be happy to take their advice!
cheers,
- Chris
-----
*Dr Christopher Betts*
Australian Cloud Identity
http://cloudidentity.com.au
m: 0408 533 456
Hi Chris,
I believe there is something changed in jndi that jxplorer did not
follow yet?
It surely worked before on exactly same environment, except we did
a couple of updates but all in once so I cannot tell which one
exactly broke it down.
(usual upgrades: windows updates, java update, on server openldap updates)
Anyway -Djavaxnet.debug gives kinda the same.
c:\Program Files (x86)\jxplorer>java -classpath
".;jars/*;jasper/lib/*" -Djavax.net.debug -Dfile.encoding=utf-8
com.ca.directory.jxplorer.JXplorer
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXplorer printTime
INFO: main start
TIME: Tue Dec 16 22:48:18 CET 2014 (411)
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXplorer
checkJavaEnvironment
INFO: running java from: C:\Program Files (x86)\Java\jre1.8.0_25
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXplorer
checkJavaEnvironment
INFO: running java version 1.8.0_25
dec. 16, 2014 10:48:18 DU com.ca.commons.cbutil.CBUtility
checkAndCreateWorkingDirectory
WARNING: ERROR: unable to save config or store user data in
c:\Program Files (x86)\jxplorer\ (may try elsewhere)
unable to use user.dir
On Windows
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXConfig
getConfigDirectory
C:\Users\<username>\AppData\Roaming\jxplorer\
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXConfig
getConfigDirectory
C:\Users\<username>\AppData\Roaming\jxplorer\
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXConfig
getConfigDirectory
C:\Users\<username>\AppData\Roaming\jxplorer\
dec. 16, 2014 10:48:18 DU com.ca.directory.jxplorer.JXConfig setupLogger
INFO: setting up logger
logging level set from config to: WARNING with 0 parents=true
dec. 16, 2014 10:48:18 DU com.ca.commons.cbutil.CBUtility
readPropertyFile
C:\Users\<username>\AppData\Roaming\jxplorer\search_filters.txt
dec. 16, 2014 10:48:18 DU com.ca.commons.cbutil.CBUtility
readPropertyFile
bookmarks.txt
dec. 16, 2014 10:48:18 DU com.ca.commons.cbutil.CBUtility
readPropertyFile
quicksearch.txt
Debug is true storeKey false useTicketCache true useKeyTab false
doNotPrompt false ticketCache is null isInitiator true KeyTab is
null refreshKrb5Config is false principal is null tryFirstPass is fal
se useFirstPass is false storePass is false clearPass is false
Acquire TGT from Cache
Commit Succeeded
dec. 16, 2014 10:48:23 DU
com.ca.directory.jxplorer.broker.JNDIDataBroker openConnection
WARNING: initial receipt of exception by jndi broker 13
java.lang.ArrayIndexOutOfBoundsException: 13
at sun.security.jgss.krb5.WrapToken.getPadding(Unknown Source)
at sun.security.jgss.krb5.WrapToken.<init>(Unknown Source)
at sun.security.jgss.krb5.Krb5Context.wrap(Unknown Source)
at sun.security.jgss.GSSContextImpl.wrap(Unknown Source)
at com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(Unknown Source)
at com.sun.jndi.ldap.sasl.SaslOutputStream.write(Unknown Source)
at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source)
at com.sun.jndi.ldap.LdapClient.search(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.doSearch(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
at com.ca.commons.jndi.JNDIOps.exists(JNDIOps.java:702)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:491)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:422)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processRequest(JNDIDataBroker.java:396)
at
com.ca.directory.jxplorer.broker.DataBroker.processQueue(DataBroker.java:200)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processQueue(JNDIDataBroker.java:913)
at
com.ca.directory.jxplorer.broker.DataBroker.run(DataBroker.java:165)
at java.lang.Thread.run(Unknown Source)
dec. 16, 2014 10:48:49 DU com.ca.directory.jxplorer.JXOpenConWin dataReady
WARNING: Error opening connection
java.lang.ArrayIndexOutOfBoundsException: 13
at sun.security.jgss.krb5.WrapToken.getPadding(Unknown Source)
at sun.security.jgss.krb5.WrapToken.<init>(Unknown Source)
at sun.security.jgss.krb5.Krb5Context.wrap(Unknown Source)
at sun.security.jgss.GSSContextImpl.wrap(Unknown Source)
at com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(Unknown Source)
at com.sun.jndi.ldap.sasl.SaslOutputStream.write(Unknown Source)
at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source)
at com.sun.jndi.ldap.LdapClient.search(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.doSearch(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source)
at javax.naming.directory.InitialDirContext.search(Unknown Source)
at com.ca.commons.jndi.JNDIOps.exists(JNDIOps.java:702)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:491)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:422)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processRequest(JNDIDataBroker.java:396)
at
com.ca.directory.jxplorer.broker.DataBroker.processQueue(DataBroker.java:200)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processQueue(JNDIDataBroker.java:913)
at
com.ca.directory.jxplorer.broker.DataBroker.run(DataBroker.java:165)
at java.lang.Thread.run(Unknown Source)
Regards,
Laszlo

Post by Chris Betts
Hi Laszio,
I'm a bit out of my depth here myself; JX is calling the
jndi library to open the connection, and it looks like deep in
the processing there's a problem with the kerberos token?
You could try adding "-Djavax.net.debug" in the jxplorer.bat
file and see if the trace information gives you any more detail?
cheers,
- Chris
-----
*Dr Christopher Betts*
Australian Cloud Identity
http://cloudidentity.com.au
m: 0408 533 456
On 17 December 2014 at 08:16, Soós László
Dear Members,
When I try to connect to an LDAP server (no SSL, port 389, LDAP v3) with
"java.lang.ArrayIndexOutOfBoundsException: 13
at sun.security.jgss.krb5.WrapToken.getPadding(Unknown Source)
at sun.security.jgss.krb5.WrapToken.<init>(Unknown Source)
at sun.security.jgss.krb5.Krb5Context.wrap(Unknown Source)
at sun.security.jgss.GSSContextImpl.wrap(Unknown Source)
at
com.sun.security.sasl.gsskerb.GssKrb5Base.wrap(Unknown Source)
at com.sun.jndi.ldap.sasl.SaslOutputStream.write(Unknown Source)
at com.sun.jndi.ldap.Connection.writeRequest(Unknown Source)
at com.sun.jndi.ldap.LdapClient.search(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.doSearch(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source)
at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown
Source)
at
com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown
Source)
at
javax.naming.directory.InitialDirContext.search(Unknown Source)
at com.ca.commons.jndi.JNDIOps.exists(JNDIOps.java:702)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:491)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.openConnection(JNDIDataBroker.java:422)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processRequest(JNDIDataBroker.java:396)
at
com.ca.directory.jxplorer.broker.DataBroker.processQueue(DataBroker.java:200)
at
com.ca.directory.jxplorer.broker.JNDIDataBroker.processQueue(JNDIDataBroker.java:913)
at
com.ca.directory.jxplorer.broker.DataBroker.run(DataBroker.java:165)
at java.lang.Thread.run(Unknown Source)"
System is Windows Server 2012 R2
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) Client VM (build 25.25-b02, mixed mode)
I have my KRB5 credcache in %USERPROFILE%\krb5cc_%USERNAME%
I'm not exactly sure what happened when it stopped working but it worked
before (either a windows update or java update or openldap
server upgrade)
It still works without GSSAPI (plain user/pass)
I'm open for any suggestions how to troubleshoot further as I'm out of
ideas.
Regards,
Laszlo
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar
corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar
corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

[Sergio Gelato]

Which brings us to com.sun.jndi.ldap.sasl.SaslOutputStream.write, where I
have trouble seeing how the length could ever be negative… unless rawSendSize
is negative. The default value of rawSendSize is a safe 65536 but a different
one can be negotiated in the SASL handshake. There ought to be client-side
safeguards too, but is your LDAP server sane?

Following up on myself due to a sensation of déjà vu: could this be the
same problem I reported in https://bugs.debian.org/721010 ?

[Soós László]

The one referrenced was for openldap 2.1 I have 2.4 installed. Was't the
issue fixed in 2 years? possible.

openldap.x86_64 2.4.39-8.el6 @base
openldap-clients.x86_64 2.4.39-8.el6 @base
openldap-devel.x86_64 2.4.39-8.el6 @base
openldap-servers.x86_64 2.4.39-8.el6 @base

What do you mean ldap server sane? I've got very plane gssapi config and
the exactly same config worked before with the same environment. I just
do not know what caused the breakdown as we upgraded more components in
the same time: windows updates; java; on servers end: yum centos updates

#GSSAPI
sasl-realm XXX.LAN
sasl-host backend.xxx.lan
#sasl-secprops noplain,noactive,noanonymous

Any hint on how to debug forther would be useful.

Thank you

Which brings us to com.sun.jndi.ldap.sasl.SaslOutputStream.write, where I
have trouble seeing how the length could ever be negative
 unless rawSendSize
is negative. The default value of rawSendSize is a safe 65536 but a different
one can be negotiated in the SASL handshake. There ought to be client-side
safeguards too, but is your LDAP server sane?

Following up on myself due to a sensation of déjà vu: could this be the
same problem I reported in https://bugs.debian.org/721010 ?
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

[Sergio Gelato]

Post by Soós László
The one referrenced was for openldap 2.1 I have 2.4 installed. Was't
the issue fixed in 2 years? possible.

Not OpenLDAP but Cyrus SASL. The bug was fixed upstream in version 2.1.26
which may or may not have propagated to RHEL6. Of course I cannot be
certain that you're seeing the same problem but it's worth checking.

Post by Soós László
What do you mean ldap server sane? I've got very plane gssapi config
and the exactly same config worked before with the same environment.

If you're sure you haven't upgraded the GSSAPI plugin for libsasl2 on the
server, or enabled TLS, or anything of that sort, then one may have to look
for an alternative explanation.

Post by Soós László
I just do not know what caused the breakdown as we upgraded more
yum centos updates

Aha. You did apply CentOS updates on the servers; so it's not quite the same
environment any more, is it?

Post by Soós László
#GSSAPI
sasl-realm XXX.LAN
sasl-host backend.xxx.lan
#sasl-secprops noplain,noactive,noanonymous
Any hint on how to debug forther would be useful.

If you're using Oracle Java, try OpenJDK instead, just so we're 100% sure that
we have the source code. (I don't expect this to make any difference but it's
good to remove sources of uncertainty.)

Try disabling SSL/TLS (GSSAPI has its own encryption) and see if the problem
persists. (If "my" bug is the culprit the symptoms will probably disappear.)
If the problem does persist, capture the traffic with tcpdump or equivalent
and look at the SASL handshake.

Post by Soós László
Thank you

Post by Sergio Gelato

Which brings us to com.sun.jndi.ldap.sasl.SaslOutputStream.write, where I
have trouble seeing how the length could ever be negative… unless rawSendSize
is negative. The default value of rawSendSize is a safe 65536 but a different
one can be negotiated in the SASL handshake. There ought to be client-side
safeguards too, but is your LDAP server sane?

Following up on myself due to a sensation of déjà vu: could this be the
same problem I reported in https://bugs.debian.org/721010 ?
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

[Soós László]

ok, you're right Centos 6 has 2.1.23.

cyrus-sasl.x86_64 2.1.23-15.el6_6.1 @updates
cyrus-sasl-devel.x86_64 2.1.23-15.el6_6.1 @updates
cyrus-sasl-gssapi.x86_64 2.1.23-15.el6_6.1 @updates
cyrus-sasl-lib.x86_64 2.1.23-15.el6_6.1 @updates
cyrus-sasl-plain.x86_64 2.1.23-15.el6_6.1 @updates

From yum logs this was indeed updated:
Nov 19 21:50:36 Updated: cyrus-sasl-lib-2.1.23-15.el6.x86_64

previously had 2.1.23-13

I give it a try to roll back to the old version (if possible), need some
time for it as I need to ask some experts to do that.

Thanks for the hints on other debugs will give them a try too. I'll
reply back with findings.

Post by Sergio Gelato

Post by Soós László
The one referrenced was for openldap 2.1 I have 2.4 installed. Was't
the issue fixed in 2 years? possible.

Not OpenLDAP but Cyrus SASL. The bug was fixed upstream in version 2.1.26
which may or may not have propagated to RHEL6. Of course I cannot be
certain that you're seeing the same problem but it's worth checking.

Post by Soós László
What do you mean ldap server sane? I've got very plane gssapi config
and the exactly same config worked before with the same environment.

If you're sure you haven't upgraded the GSSAPI plugin for libsasl2 on the
server, or enabled TLS, or anything of that sort, then one may have to look
for an alternative explanation.

Post by Soós László
I just do not know what caused the breakdown as we upgraded more
yum centos updates

Aha. You did apply CentOS updates on the servers; so it's not quite the same
environment any more, is it?

Post by Soós László
#GSSAPI
sasl-realm XXX.LAN
sasl-host backend.xxx.lan
#sasl-secprops noplain,noactive,noanonymous
Any hint on how to debug forther would be useful.

If you're using Oracle Java, try OpenJDK instead, just so we're 100% sure that
we have the source code. (I don't expect this to make any difference but it's
good to remove sources of uncertainty.)
Try disabling SSL/TLS (GSSAPI has its own encryption) and see if the problem
persists. (If "my" bug is the culprit the symptoms will probably disappear.)
If the problem does persist, capture the traffic with tcpdump or equivalent
and look at the SASL handshake.

Post by Soós László
Thank you

Which brings us to com.sun.jndi.ldap.sasl.SaslOutputStream.write, where I
have trouble seeing how the length could ever be negative
 unless rawSendSize
is negative. The default value of rawSendSize is a safe 65536 but a different
one can be negotiated in the SASL handshake. There ought to be client-side
safeguards too, but is your LDAP server sane?

Following up on myself due to a sensation of déjà vu: could this be the
same problem I reported in https://bugs.debian.org/721010 ?
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

[Sergio Gelato]

Post by Soós László
Nov 19 21:50:36 Updated: cyrus-sasl-lib-2.1.23-15.el6.x86_64

Actually cyrus-sasl-gssapi should be the more directly relevant package.
Since it's from the same source it was probably updated at the same time.

The bug I'm thinking of was introduced by commit http://git.cyrusimap.org/cyrus-sasl/commit/plugins/gssapi.c?id=bbe52c3b05b6b86927208c9a03839a6d21e341e8
--- see also the earlier, related commit http://git.cyrusimap.org/cyrus-sasl/commit/plugins/gssapi.c?id=f16192a2ef647dd2282104bc146efd8d08095532 .

Post by Soós László
previously had 2.1.23-13

Can you compare the source code for the old and the new version and see if
the difference involves commit bbe52c3b05b6b86927208c9a03839a6d21e341e8 ?
(Probably as a backported patch since the upstream version number is
2.1.23 in both cases.)

Post by Soós László
I give it a try to roll back to the old version (if possible), need
some time for it as I need to ask some experts to do that.

There could be security implications in doing that. Maybe your experts will
want to think about my patch. (I recommend source code inspection.)

[Soós László]

Hi Sergio, this one really worked!!! Thanks for the hint! You saved us!

Documenting for the future:
We recompiled cyrus-sasl from SRPM
(cyrus-sasl-lib-2.1.23-15.el6.x86_64.src.rpm) and removed patch file
called: cyrus-sasl-2.1.23-ad_compat.patch which has the same patch
content that Sergio referred to.

Regards,
Laszlo

Post by Sergio Gelato

Post by Soós László
Nov 19 21:50:36 Updated: cyrus-sasl-lib-2.1.23-15.el6.x86_64

Actually cyrus-sasl-gssapi should be the more directly relevant package.
Since it's from the same source it was probably updated at the same time.
The bug I'm thinking of was introduced by commit http://git.cyrusimap.org/cyrus-sasl/commit/plugins/gssapi.c?id=bbe52c3b05b6b86927208c9a03839a6d21e341e8
--- see also the earlier, related commit http://git.cyrusimap.org/cyrus-sasl/commit/plugins/gssapi.c?id=f16192a2ef647dd2282104bc146efd8d08095532 .

Post by Soós László
previously had 2.1.23-13

Can you compare the source code for the old and the new version and see if
the difference involves commit bbe52c3b05b6b86927208c9a03839a6d21e341e8 ?
(Probably as a backported patch since the upstream version number is
2.1.23 in both cases.)

Post by Soós László
I give it a try to roll back to the old version (if possible), need
some time for it as I need to ask some experts to do that.

There could be security implications in doing that. Maybe your experts will
want to think about my patch. (I recommend source code inspection.)
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

[Chris Betts]

Hi Laszlo,

thanks for letting us all know the resolution!!

cheers,

- Chris

-----
*Dr Christopher Betts*
Australian Cloud Identity
http://cloudidentity.com.au
m: 0408 533 456

Post by Soós László
Hi Sergio, this one really worked!!! Thanks for the hint! You saved us!
We recompiled cyrus-sasl from SRPM
(cyrus-sasl-lib-2.1.23-15.el6.x86_64.src.rpm) and removed patch file
called: cyrus-sasl-2.1.23-ad_compat.patch which has the same patch content
that Sergio referred to.
Regards,
Laszlo
Nov 19 21:50:36 Updated: cyrus-sasl-lib-2.1.23-15.el6.x86_64
Actually cyrus-sasl-gssapi should be the more directly relevant package.
Since it's from the same source it was probably updated at the same time.
The bug I'm thinking of was introduced by commit http://git.cyrusimap.org/cyrus-sasl/commit/plugins/gssapi.c?id=bbe52c3b05b6b86927208c9a03839a6d21e341e8
--- see also the earlier, related commit http://git.cyrusimap.org/cyrus-sasl/commit/plugins/gssapi.c?id=f16192a2ef647dd2282104bc146efd8d08095532 .
previously had 2.1.23-13
Can you compare the source code for the old and the new version and see if
the difference involves commit bbe52c3b05b6b86927208c9a03839a6d21e341e8 ?
(Probably as a backported patch since the upstream version number is
2.1.23 in both cases.)
I give it a try to roll back to the old version (if possible), need
some time for it as I need to ask some experts to do that.
There could be security implications in doing that. Maybe your experts will
want to think about my patch. (I recommend source code inspection.)
------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for
all
things parallel software development, from weekly thought leadership blogs
to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Jxplorer-users mailing list
https://lists.sourceforge.net/lists/listinfo/jxplorer-users

[Sergio Gelato]

Post by Sergio Gelato

Post by Soós László
The one referrenced was for openldap 2.1 I have 2.4 installed. Was't
the issue fixed in 2 years? possible.

Not OpenLDAP but Cyrus SASL. The bug was fixed upstream in version 2.1.26

I'll take that back. The Debian bug was closed with such a claim but a
review of the source code shows the claim to have been false. Also, it
seems my original report to cyrus-bugs didn't make it into their Bugzilla.
I'm still running with my own patched version of 2.1.25 so I hadn't
noticed this until now.

Conclusion: you may want to look at my patch. It's unlikely to have been
picked up by your distribution.