Jdk1.3 vs jdk1.4 and SASL authentication

I'm trying to get SASL authentication work with jdk1.3 and iPlanet Directory Server. Everytime I get same exception:
SASL authentication failed. Root exception is java.lang.NoSuchMethodError
When I try with jdk1.4 everything works fine. Now I'm just wondering that is there other things that I should take care when I try get authentication work with jdk1.3. I know that all the extension packages are integrated to the jdk1.4 and I have set same packages to the CLASSPATH when I'm trying to do same with jdk1.3, but same exception occurs than above.
Does anyone know what's the problem?
Thanks,
Janne

Hi ,
Jsse 1.0.3 (strictly this version only) is needed along with jdk1.3 for the SASL or SSL authentication to be done fine.
Hope this helps,
Regards,
Sathya

Similar Messages

Jdk1.3 vs jdk1.4 SASL authentication

I'm trying to get SASL authentication work with jdk1.3 and iPlanet Directory Server. Everytime I get same exception:
SASL authentication failed. Root exception is java.lang.NoSuchMethodError
When I try with jdk1.4 everything works fine. Now I'm just wondering that is there other things that I should take care when I try get authentication work with jdk1.3. I know that all the extension packages are integrated to the jdk1.4 and I have set same packages to the CLASSPATH when I'm trying to do same with jdk1.3, but same exception occurs than above.
Does anyone know what's the problem?
Thanks,
Janne

Hi ,
Jsse 1.0.3 (strictly this version only) is needed along with jdk1.3 for the SASL or SSL authentication to be done fine.
Hope this helps,
Regards,
Sathya

JDK1.2.2 and untrusted server chain and HELP

Hi,
I'm using JDK1.2.2 and I've downloaded and installed JSSE1.02. I have also installed the server cert in my own truststore.
The server to whom I want to connect sends two certificates.
One is valid and this is the one I need and I have and one that is timed out and of no importance for me...at least I guess it is.
But my JSSE-application throws an this exception. For more detailled information I've attached the log:
keyStore is :
keyStore type is : jks
init keystore
init keymanager of type SunX509
trustStore is: C:/NetDynamics50/java/jre/lib/security/lauerstore
trustStore type is : jks
init truststore
adding as trusted cert: [
Version: V3
Subject: CN=inte.myaxa.de, OU=Executive Management, O=@AXA GmbH, L=Koeln, ST=NRW, C=DE
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@31cdcb27
Validity: [From: Fri Jun 15 16:25:05 GMT+02:00 2001,
               To: Sun Jun 15 16:25:05 GMT+02:00 2003]
Issuer: [email protected], CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
SerialNumber: [    080e20]
Certificate Extensions: 2
[1]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
[2]: ObjectId: 2.5.29.37 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 17 30 15 06 08 2B 06 01 05 05 07 03 01 06 09 ..0...+.........
0010: 60 86 48 01 86 F8 42 04 01 `.H...B..
Algorithm: [MD5withRSA]
Signature:
0000: 32 D8 11 96 F5 66 CE 7A 2C DD 39 03 BB 54 41 66 2....f.z,.9..TAf
0010: EE B7 6E 7A 95 57 73 C5 66 83 67 9C 35 B7 75 05 ..nz.Ws.f.g.5.u.
0020: A1 6D 9D 36 A7 7A AA 12 CD AE 64 5B E5 F9 EE EF .m.6.z....d[....
0030: 7C BB 63 7E 5A E6 9F BA 50 8F 92 A2 C6 FA B5 8B ..c.Z...P.......
0040: 25 8B 95 37 AA C4 6D 7A C1 E6 DA 35 18 82 24 1A %..7..mz...5..$.
0050: 9A 0D E3 A2 F1 3B 4D 35 C6 00 B7 E8 6B 14 0B 82 .....;M5....k...
0060: BC E1 29 6E 24 10 27 B2 86 52 CD 85 C5 A9 CE 69 ..)n$.'..R.....i
0070: D1 69 79 67 07 9E 8B A2 23 DA 97 36 F5 D8 57 57 .iyg....#..6..WW
init context
trigger seeding of SecureRandom
done seeding SecureRandom
%% No cached client session
*** ClientHello, v3.1
RandomCookie: GMT: 983585972 bytes = { 41, 169, 119, 141, 169, 223, 159, 184, 182, 97, 133, 56, 227, 20, 209, 115, 225, 62, 106, 169, 106, 250, 37, 25, 45, 7, 25, 215 }
Session ID: {}
Cipher Suites: { 0, 5, 0, 4, 0, 9, 0, 10, 0, 18, 0, 19, 0, 3, 0, 17 }
Compression Methods: { 0 }
[write] MD5 and SHA1 hashes: len = 59
0000: 01 00 00 37 03 01 3B A0 55 B4 29 A9 77 8D A9 DF ...7..;.U.).w...
0010: 9F B8 B6 61 85 38 E3 14 D1 73 E1 3E 6A A9 6A FA ...a.8...s.>j.j.
0020: 25 19 2D 07 19 D7 00 00 10 00 05 00 04 00 09 00 %.-.............
0030: 0A 00 12 00 13 00 03 00 11 01 00 ...........
Thread-6, WRITE: SSL v3.1 Handshake, length = 59
[write] MD5 and SHA1 hashes: len = 77
0000: 01 03 01 00 24 00 00 00 20 00 00 05 00 00 04 01 ....$... .......
0010: 00 80 00 00 09 06 00 40 00 00 0A 07 00 C0 00 00 .......@........
0020: 12 00 00 13 00 00 03 02 00 80 00 00 11 3B A0 55 .............;.U
0030: B4 29 A9 77 8D A9 DF 9F B8 B6 61 85 38 E3 14 D1 .).w......a.8...
0040: 73 E1 3E 6A A9 6A FA 25 19 2D 07 19 D7 s.>j.j.%.-...
Thread-6, WRITE: SSL v2, contentType = 22, translated length = 16310
Thread-6, READ: SSL v3.0 Handshake, length = 1599
*** ServerHello, v3.0
RandomCookie: GMT: 722821779 bytes = { 190, 56, 167, 5, 198, 89, 180, 112, 96, 251, 78, 78, 144, 103, 57, 130, 219, 11, 56, 169, 199, 73, 79, 241, 241, 131, 74, 145 }
Session ID: {0, 154, 4, 1, 195, 195, 38, 26, 66, 92, 154, 191, 59, 96, 218, 24, 81, 133, 102, 48, 169, 26, 50, 42, 10, 49, 78, 150, 71, 182, 163, 33}
Cipher Suite: { 0, 4 }
Compression Method: 0
%% Created: [Session-1, SSL_RSA_WITH_RC4_128_MD5]
** SSL_RSA_WITH_RC4_128_MD5
[read] MD5 and SHA1 hashes: len = 74
0000: 02 00 00 46 03 00 2B 15 63 93 BE 38 A7 05 C6 59 ...F..+.c..8...Y
0010: B4 70 60 FB 4E 4E 90 67 39 82 DB 0B 38 A9 C7 49 .p`.NN.g9...8..I
0020: 4F F1 F1 83 4A 91 20 00 9A 04 01 C3 C3 26 1A 42 O...J. ......&.B
0030: 5C 9A BF 3B 60 DA 18 51 85 66 30 A9 1A 32 2A 0A \..;`..Q.f0..2*.
0040: 31 4E 96 47 B6 A3 21 00 04 00 1N.G..!...
*** Certificate chain
chain [0] = [
Version: V3
Subject: CN=inte.myaxa.de, OU=Executive Management, O=@AXA GmbH, L=Koeln, ST=NRW, C=DE
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@5f45cb24
Validity: [From: Fri Jun 15 16:25:05 GMT+02:00 2001,
               To: Sun Jun 15 16:25:05 GMT+02:00 2003]
Issuer: [email protected], CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
SerialNumber: [    080e20]
Certificate Extensions: 2
[1]: ObjectId: 2.5.29.19 Criticality=true
BasicConstraints:[
CA:false
PathLen: undefined
[2]: ObjectId: 2.5.29.37 Criticality=false
Extension unknown: DER encoded OCTET string =
0000: 04 17 30 15 06 08 2B 06 01 05 05 07 03 01 06 09 ..0...+.........
0010: 60 86 48 01 86 F8 42 04 01 `.H...B..
Algorithm: [MD5withRSA]
Signature:
0000: 32 D8 11 96 F5 66 CE 7A 2C DD 39 03 BB 54 41 66 2....f.z,.9..TAf
0010: EE B7 6E 7A 95 57 73 C5 66 83 67 9C 35 B7 75 05 ..nz.Ws.f.g.5.u.
0020: A1 6D 9D 36 A7 7A AA 12 CD AE 64 5B E5 F9 EE EF .m.6.z....d[....
0030: 7C BB 63 7E 5A E6 9F BA 50 8F 92 A2 C6 FA B5 8B ..c.Z...P.......
0040: 25 8B 95 37 AA C4 6D 7A C1 E6 DA 35 18 82 24 1A %..7..mz...5..$.
0050: 9A 0D E3 A2 F1 3B 4D 35 C6 00 B7 E8 6B 14 0B 82 .....;M5....k...
0060: BC E1 29 6E 24 10 27 B2 86 52 CD 85 C5 A9 CE 69 ..)n$.'..R.....i
0070: D1 69 79 67 07 9E 8B A2 23 DA 97 36 F5 D8 57 57 .iyg....#..6..WW
chain [1] = [
Version: V1
Subject: [email protected], CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@96e1cb27
Validity: [From: Sat Jul 27 20:07:57 GMT+02:00 1996,
               To: Mon Jul 27 20:07:57 GMT+02:00 1998]
Issuer: [email protected], CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
SerialNumber: [ 0 ]
Algorithm: [MD5withRSA]
Signature:
0000: 8B 2F 9F B8 9F 5F 74 54 22 BB D8 5E DA 48 E0 33 ./..._tT"..^.H.3
0010: 9F 01 19 13 A2 0C 26 EA 8E CE C1 57 65 F7 7C 85 ......&....We...
0020: 84 37 17 EE 1E 6D D1 76 75 D4 C5 00 33 38 8A 75 .7...m.vu...38.u
0030: D7 B7 AE 64 EF CD 46 08 50 26 28 63 96 F4 DF 62 ...d..F.P&(c...b
0040: 30 18 C4 EF 76 27 25 2B E4 93 37 A3 4F DA 6E 67 0...v'%+..7.O.ng
0050: BC 50 0C A8 94 F9 80 2E 4E FA 3F E3 06 E6 51 43 .P......N.?...QC
0060: 88 B4 00 C6 10 AF 91 78 95 3F 28 04 99 E1 81 A7 .......x.?(.....
0070: F0 E8 F2 FC 68 36 36 BC C1 C6 48 F9 7D FB BB 9F ....h66...H.....
out of date cert: [
Version: V1
Subject: [email protected], CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@96e1cb27
Validity: [From: Sat Jul 27 20:07:57 GMT+02:00 1996,
               To: Mon Jul 27 20:07:57 GMT+02:00 1998]
Issuer: [email protected], CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
SerialNumber: [ 0 ]
Algorithm: [MD5withRSA]
Signature:
0000: 8B 2F 9F B8 9F 5F 74 54 22 BB D8 5E DA 48 E0 33 ./..._tT"..^.H.3
0010: 9F 01 19 13 A2 0C 26 EA 8E CE C1 57 65 F7 7C 85 ......&....We...
0020: 84 37 17 EE 1E 6D D1 76 75 D4 C5 00 33 38 8A 75 .7...m.vu...38.u
0030: D7 B7 AE 64 EF CD 46 08 50 26 28 63 96 F4 DF 62 ...d..F.P&(c...b
0040: 30 18 C4 EF 76 27 25 2B E4 93 37 A3 4F DA 6E 67 0...v'%+..7.O.ng
0050: BC 50 0C A8 94 F9 80 2E 4E FA 3F E3 06 E6 51 43 .P......N.?...QC
0060: 88 B4 00 C6 10 AF 91 78 95 3F 28 04 99 E1 81 A7 .......x.?(.....
0070: F0 E8 F2 FC 68 36 36 BC C1 C6 48 F9 7D FB BB 9F ....h66...H.....
Thread-6, SEND SSL v3.0 ALERT: fatal, description = certificate_unknown
Thread-6, WRITE: SSL v3.0 Alert, length = 2
javax.net.ssl.SSLException: untrusted server cert chain
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a([DashoPro-V1.2-120198])
     at com.sun.net.ssl.internal.ssl.ClientHandshaker.a([DashoPro-V1.2-120198])
     at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage([DashoPro-V1.2-120198])
     at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Compiled Code)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Compiled Code)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(Compiled Code)
     at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Compiled Code)
     at java.io.OutputStream.write(OutputStream.java:65)
     at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake([DashoPro-V1.2-120198])
     at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.doConnect([DashoPro-V1.2-120198])
     at com.sun.net.ssl.internal.www.protocol.https.NetworkClient.openServer([DashoPro-V1.2-120198])
     at com.sun.net.ssl.internal.www.protocol.https.HttpClient.l([DashoPro-V1.2-120198])
     at com.sun.net.ssl.internal.www.protocol.https.HttpClient.<init>([DashoPro-V1.2-120198])
     at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.<init>([DashoPro-V1.2-120198])
     at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a([DashoPro-V1.2-120198])
     at com.sun.net.ssl.internal.www.protocol.https.HttpsClient.a([DashoPro-V1.2-120198])
     at com.sun.net.ssl.internal.www.protocol.https.HttpsURLConnection.connect([DashoPro-V1.2-120198])
     at de.myaxa.application.adapter.SessionController.hitSession(Compiled Code)
     at java.lang.reflect.Method.invoke(Native Method)
     at de.myaxa.application.adapter.Command.execute(Compiled Code)
     at de.myaxa.application.adapter.MyAxaInterfaceServlet.doPost(MyAxaInterfaceServlet.java:117)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:747)
     at javax.servlet.http.HttpServlet.service(HttpServlet.java:840)
     at netdyn.servlet.CNdServletRequestHandler.handleRequest(CNdServletRequestHandler.java:132)
     at netdyn.servlet.env.CNdRequestEnvironment.executeRequest(Compiled Code)
     at netdyn.servlet.env.CNdRequestEnvironment.executeRequest(CNdRequestEnvironment.java:427)
     at netdyn.servlet.env.CNdRequestEnvironment.executeRequest(CNdRequestEnvironment.java:376)
     at netdyn.servlet.CNdServletManager.handleRequest(CNdServletManager.java:347)
     at netdyn.services.cp.worker.CNdCPWorkerOperations.webEventMessage(CNdCPWorkerOperations.java:530)
     at netdyn.services.cp.worker.CNdCPWorkerImpl.webEventMessage(CNdCPWorkerImpl.java:82)
     at netdyn.services.cp.stubs._tie_INdCPWorker.webEventMessage(_tie_INdCPWorker.java:23)
     at netdyn.services.cp.stubs._INdCPWorkerImplBase._execute(_INdCPWorkerImplBase.java:73)
     at netdyn.services.cp.stubs._INdCPWorkerImplBase._execute(_INdCPWorkerImplBase.java:48)
     at com.visigenic.vbroker.orb.SkeletonDelegateImpl.execute(Compiled Code)
     at com.visigenic.vbroker.orb.GiopProtocolAdapter.doRequest(Compiled Code)
     at com.visigenic.vbroker.orb.GiopProtocolAdapter.dispatchMessage(Compiled Code)
     at com.visigenic.vbroker.orb.ThreadPoolDispatcher.run(Compiled Code)
     at com.visigenic.vbroker.orb.WorkerThread.run(Compiled Code)
de.myaxa.application.adapter.SessionController@89c5cb25 : javax.net.ssl.SSLException: untrusted server cert chain :

[ O66183],
This exception occurs because of an invalid or expired certificate within a public key certificate chain that causes the JSSE to terminate abnormally.
If you look at your log file, you can see an 'out of date cert' message. I have extracted that part of the log with this statement:
          <SNIPPED>
out of date cert: [
Version: V1
Subject: EmailAddress=[email protected],
, CN=Thawte Server CA, OU=Certification Services
Division, O=Thawte Consulting cc, L=Cape Town,
ST=Western Cape, C=ZA
Signature Algorithm: MD5withRSA, OID =
= 1.2.840.113549.1.1.4
Key:
com.sun.net.ssl.internal.ssl.JSA_RSAPublicKey@96e1cb27
Validity: [From: Sat Jul 27 20:07:57 GMT+02:00
0 1996,
To: Mon Jul 27 20:07:57 GMT+02:00
7:57 GMT+02:00 1998]
Issuer: EmailAddress=[email protected],
, CN=Thawte Server CA, OU=Certification Services
Division, O=Thawte Consulting cc, L=Cape Town,
ST=Western Cape, C=ZA
SerialNumber: [ 0 ]          <SNIPPED>
HTH.
Allen Lai
Developer Technical Support
SUN Microsystems
http://www.sun.com/developers/support/

Date - difference between JDK1.3.1 and 1.4.2 ???

I tried running this piece of code on JDK1.3.1_08 and JDK1.4.2 - and the output i different! Why???
import java.util.Date;
import java.util.TimeZone;
public class Test {
     public static void main(String[] args) {
          long longDate = Long.parseLong("-883620000000");
          Date date = new Date(longDate);
          TimeZone zone = TimeZone.getDefault();
          System.out.println("Zone : " + zone.getID());
          System.out.println("Date value : " + date.getTime());
          System.out.println("Date string: " + date.toString());
Output with JDK1.3.1_08:
Zone : Europe/Berlin
Date value : -883620000000
Date string: Wed Dec 31 23:00:00 CET 1941
Output with JDK1.4.2
Zone : Europe/Berlin
Date value : -883620000000
Date string: Thu Jan 01 00:00:00 CEST 1942
This is pretty troublesome while my Swing Client is running on 1.4+ and the appserver on 1.3.1.

It looks more like a timezone difference between the
two. SDK 1.4 supports a much larger set of timezones than earlier versions of the language, and it looks like they are more historically correct too. No doubt there were changes in the daylight saving rules in Germany between 1941 and 1970 (you'll recall there were a lot of things going on back then), and my guess is that 1.4 is more likely to be correct.
As limeybrit9 suggests, you may want to set a specific timezone to make your applications consistent.

JTable 's tableChanged() works differently in jdk1.2.2 and jdk1.3

While updating the contents of the jtable I am using the following
table.tableChanged(new TableModelEvent(model));
table.repaint();
In jdk1.2.2, this updates the contents and repaints the table without clearing the row selection
But the same in jdk1.3 updates and repaints the table but clears the row selection.
How can I overcome with problem.
I also tried model.fireTableStructurChanged();
along with this but it works in jdk1.2.2 and not in jdk1.3.
Any suggestion is greatly appreciated.
Thanks

They have fixed a bug. If you are replacing the whole table, then the row selection for the old table doesn't mean anything for the new table. In fact, that row might not even exist any more.

Compiled with jdk1.3.1_01 and run under VM 2.0

I have compilied all my source code with jdk1.3.1_01 and ias6.0 sp3 uses jdk1.2.2 or 2.0VM....is this difference going to affect my application?

Hi,
It depends upon how your application is coded. If you use some of
the functionalities which JDK 1.2 uses and incase JDK 1.3 doesn't likes
that, you are likely to get errors. Infact, iAS encourages you to use
the JVM which is bundled along with iAS SP3 and using JDK apart from
that troubles. Please refer to my previous posting on iAS SP3 & JDK 1.3,
I've tested them, which threw lots of errors. Hope this helps.
Regards
Raj
Mansoor Quraishi wrote:
I have compilied all my source code with jdk1.3.1_01 and ias6.0 sp3
uses jdk1.2.2 or 2.0VM....is this difference going to affect my
application?
Try our New Web Based Forum at http://softwareforum.sun.com
Includes Access to our Product Knowledge Base!

JDK1.3.1 and JAI1.1 Installation

I have the same problem with JDK1.3.1 and JAI1.1.
OS: Win2000 Pro, JDK1.3 installed and works
PATH = V:\Java\jdk1.3\bin\;...
java -version:
java version "1.3.1"
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
CLASSPATH - is not set
If I try to install JAI1.1 with jai-1_1-lib-win-jdk.exe, I bekome a message:
the program requires the installation of Java 2 Jdk Version 1.3. Aborting setup.
Do You know the solution?

- The solution is to install first Jdk1.3 again with InstallShield installation programm, bacause the Jai installation for Windows is similar to check the Windows Registry, if JDK is already installed.

What are the latest supported versions of JDK1.4.1 and JRE1.4 on Windows

Please tell the latest supported versions of both JDK1.4.1 and JRE1.4.1 on Windows 2003.
If no support is there for 1.4.1 versions then are there any higher versions.
we have to port the application from Windows2000 to windows2003. On win2000 it runs fine on JRE1.4.1.
But on Windows 2003 it is running properly on jre included in JDK1.4.1 but not on JRE1.4.1.
What can be the reason for it ? Does win2003 supports JRE1.4.1?

You didn't say why it isn't running.
The most likely reason is that there is an environment problem.
If you have the same versions of the JDK and JRE then the JRE in the JDK is exactly the same as the standalone JRE.
It could be that it is also using OS specific stuff, like JNI and/or Runtime.exec().

JDK1.5.0 and J2SE 5.0

Hi Friends,
I'm trying to download jdk from sun website...I got a doubt like is JDK1.5.0 and J2SE both are same...if not...wht is the difference....
thanks
keshav

JDK (Java Developpment Kit) is the old name.
J2SE (Java2 Standard Edition) is the new name for standard JDK (versus J2EE, Java2 Enterprise Edition)
So JDK1.5.0 == J2SE 1.5.0 == J2SE 5.0 (for marketing concerns, Sun crunched the "1." before the "5". "1.5.0" is developpers language, "5.0" is end-user langauge)

JDK1.4.2 and xalan conflict?

In my java code, I apply an xsl to an xml file. It works fine in JDK 1.4.1 but when I change JDK to 1.4.2
I got the following error
javax.xml.transform.TransformerException: java.lang.ArrayIndexOutOfBoundsException: 0.
The error occurs in org.apache.xalan.transformer.TransformerImpl class. I know JDK1.4.2 bundled with xalan classes. Is there any conflict? Why it works in JDK1.4.1 but not JDK1.4.2? How can I bypass xalan classes in JDK1.4.2 and use seperate xalan.jar from apache?

I have a similar problem where using XPathAPI.selectSingleNode(aNode, "/Parent/Child/") works
fine with jdk1.4.1 but not with jdk1.4.2;
the error i get is a javax.xml.transform.TransformerException where is complains about
"A location step was expected following the '/' or '//' token."
What i tried doing was removing the trailing slash at the end of the xpath expression and it seemed
to resolve it fine.
Is this a change in the way xalan's XPathAPI behaves to remove ambiguity in the xpath expression?
As a side not, I am using weblogic 8.1 SP1 and trying to put another version of xalan in the startup
PRE_CLASSPATH doesnt seem to get around this.
would appreciate any insight.

SASL Authentication...again...

Last time i posted this question:
While using iDS 5.1 and a test user "uid=jdoe,ou=xxx,o=xxx" we've been getting same results over and over again: Authentication failed. Passwords are being set to CLEARTEXT, user being created using default user template so it contains the userpassword-attribute, and in the Java-code we've been using MD5 Digest authentication 'cause that's the method it supports. This is what is being done in the code:
1. Client connects server using ldapHost and ldapPort.
2. Hashtable "env" is being constructed.
3. Environment properties INITIAL_CONTEXT_FACTORY, PROVIDER_URL, SECURITY_PRINCIPAL and SECURITY_CREDENTIALS of context are being specified.
4. if ldapconnection.isauthenticated() is TRUE, print "success", else print "failed".
All environment properties are of course used via env.put(context.property_name, "value");
Is this it? What else should it do? All values match the ones being set in DS. Still authentication fails. "
We still have this problem but the thing that has come up is the supportedSASLMechanisms gives "no attributes" if asked with database name, but gives correct values when asked just with IP-address of server. To make long story short, this works:
Attributes attrs = ctx.getAttributes("ldap://<ip-address>"new String[]{"supportedSASLMechanisms"});
System.out.println(attrs);
This doesn't work:
Attributes attrs = ctx.getAttributes("ldap://<ip-address>/o=<organization>"new String[]{"supportedSASLMechanisms"});
System.out.println(attrs);
Is there a access control in NetscapeRoot that differs from our database controls that makes this happen?

I think I have get little bit closer to get SASL authentication work, but now my program throws this kind of exception:
javax.naming.AuthenticationException: SASL authentication failed. Root exception is java.lang.NoSuchMethodError
at com.sun.jndi.ldap.sasl.LdapSasl.saslBind(LdapSasl.java:116)
at java.lang.reflect.Method.invoke(Native Method)
at com.sun.jndi.ldap.LdapClient.saslBind(LdapClient.java:369)
at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:185)
at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2386)
at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:239)
at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:74)
at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:660)
at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:241)
at javax.naming.InitialContext.init(InitialContext.java:217)
at javax.naming.InitialContext.<init>(InitialContext.java:193)
at javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:78)
My code (I'm using jdk1.3.1):
import javax.naming.*;
import javax.naming.directory.*;
import java.util.Hashtable;
class DigestTesti {
public static void main(String[] args) {
     Hashtable env = new Hashtable();
     env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
     env.put(Context.PROVIDER_URL, "ldap://000.000.000.000:000");
     env.put(Context.SECURITY_AUTHENTICATION, "DIGEST-MD5");
     env.put(Context.SECURITY_PRINCIPAL, "dn:uid=JDoe,ou=...,o=...,dc=..., dc=...");
     env.put(Context.SECURITY_CREDENTIALS, "...");
     env.put("java.naming.security.sasl.realm", "...");
     try {
     DirContext ctx = new InitialDirContext(env);
     System.out.println(ctx);
     } catch (NamingException e) {
     e.printStackTrace();
What could been wrong with my code?
Regards,
Janne

Cannot use SASL Authentication Through GSSAPI on DS 6.3

I try to kerberized DS 6.3. I do step by step instruction from "Sun Java System Directory Server Enterprise Edition 6.3" and it doesn't work.
When I try to configure the Directory Server to Enable GSSAPI I get an error:
modifying entry cn=SASL,cn=security,cn=config
ldap_modify: DSA is unwilling to perform
ldap_modify: additional info: Modification not allowed on attribute dsSaslPluginsPath
After all when I try to authenticate to the Directory Server i get response:
ldap_sasl_interactive_bind_s: Authentication method not supported
ldap_sasl_interactive_bind_s: additional info: sasl mechanism not supported
Logs file:
+[22/Sep/2008:10:28:11 +0200] conn=2 op=-1 msgId=-1 - fd=22 slot=22 LDAP connection from 10.3.233.4:33054 to 10.3.233.4+
+[22/Sep/2008:10:28:11 +0200] conn=2 op=0 msgId=1 - BIND dn="" method=sasl version=3 mech=GSSAPI+
+[22/Sep/2008:10:28:11 +0200] conn=2 op=0 msgId=1 - RESULT err=7 tag=97 nentries=0 etime=0, sasl mechanism not supported+
+[22/Sep/2008:10:28:11 +0200] conn=2 op=1 msgId=2 - UNBIND+
+[22/Sep/2008:10:28:11 +0200] conn=2 op=1 msgId=-1 - closing from 10.3.233.4:33054 - U1 - Connection closed by unbind client -+
+[22/Sep/2008:10:28:12 +0200] conn=2 op=-1 msgId=-1 - closed.+
system specyfication:
Solaris 10 x86 64-bit
DS 6.3 B2008.0311.0212 NAT

See http://forums.sun.com/thread.jspa?forumID=761&threadID=5202246 for a description of the problem and a workaround.
If you have a Sun support contract, you can request an escalation of CR 6637404.
Also, note that it looks like part of the documentation went missing. In DS5.2 the docs included an additional step
Chapter 11 Implementing Security
Configuring Client Authentication
SASL Authentication Through GSSAPI (Solaris Only)
http://docs.sun.com/source/816-6698-10/ssl.html#18500
ldapmodify -D 'cn=directory manager'
dn: cn=SASL,cn=security,cn=config
changetype: modify
add: dsSaslPluginsEnable
dsSaslPluginsEnable: GSSAPI
replace: dsSaslPluginsPath
dsSaslPluginsPath: /usr/lib/mps/sasl2/libsasl.so
modifying entry cn=SASL,cn=security,cn=config
ldap_modify: DSA is unwilling to perform
ldap_modify: additional info: Adding attributes is not allowed
-------------------------------------------------------------

Difference between JDB of jdk1.3 & jdk1.4 (hot swap)

Hello all,
I have compiled & enahnced ny classes using jdk1.3.
By enhancing the classes I mean I am modifying the classfile at bytecode level & not at source code level. For enhancing the classes we load the original classes once & then change the bytecodes.
When I try to debug the the classes after enhancement using JDB of jdk1.3 I am getting error like,
"Unable to set breakpoint Person:11 : No linenumber information for Person. Try compiling with debugging on."
But when debugged the class using JDB of jdk1.4 its working fine.
Did anybody come around this situation anytime?
Do anybody know , is there any difference in JDB of jdk1.3 & jdk1.4?
According to jdk1.4 datasheet, JDB 1.4 provides one feature
called "hotswap". Does this feature helping us to debug the classes even after enhancement? If yes then how it is doing?

Hello all,
I have compiled & enahnced ny classes using jdk1.3.
By enhancing the classes I mean I am modifying the
e classfile at bytecode level & not at source code
level. For enhancing the classes we load the original
classes once & then change the bytecodes.What kind of changes are you making when you "enhance"?
Do you write the modified .class files out again, and
then run them? Is the debug information in the new .class
file (line number table, local variable information, etc)
still accurate and consistent after your modification?
Do the enhanced classes run OK when you turn on verification?
EG: without debugging, can you run them with -Xfuture
added to the command line?
Can you use javap -l -verbose <class id> to inspect
the modified class?
When I try to debug the the classes after
r enhancement using JDB of jdk1.3 I am getting error
like,
"Unable to set breakpoint Person:11 : No linenumber
information for Person. Try compiling with debugging
on."
But when debugged the class using JDB of jdk1.4 its
working fine.
Did anybody come around this situation anytime?
Do anybody know , is there any difference in JDB of
jdk1.3 & jdk1.4?
According to jdk1.4 datasheet, JDB 1.4 provides one
feature
called "hotswap". Does this feature helping us to
debug the classes even after enhancement? If yes then
how it is doing?"hotswap" allows you to redefine the bytecodes of a class. Not all
JVM implementations support this feature. Refer to this page for more
information:
http://java.sun.com/j2se/1.4.1/docs/guide/jpda/jdi/com/sun/jdi/VirtualMachine.html#redefineClasses(java.util.Map)
redefineClass is implemented in the jdb reference debugger
via the redefine <class id> <class file name> command.

Mail SASL authentication problem - solved

My outgoing mail stopped working. I had been relaying mail through my ISP's smtp server and at some point i started getting SASL authentication errors ("no worthy mechs found").
I searched and found a thread that contained a fix: http://discussions.apple.com/thread.jspa?threadID=2207959
The fix was rather mysterious (to me at least) in that it involved adding one line to my /etc/postcript/main.cf file. The line was: "smtpsasl_securityoptions =".
I was going to post a reply to the thread, but the thread is "archived".
Why do threads get archived? Too old?
Well, anyway, I don't like having to open a separate thread for this, but I hope this helps someone solve the same problem I was having.
Also, if anyone has any kind of real explanation for why this fix works and/or whether it is likely to survive future software changes made by apple (or has a better way to fix that will), I would love to hear about it.
Thanks.

Try installing ldap1.2.4 and putting ldap.jar and providerutil.jar in your bootclasspath.

Portal Drive Single Sign On and Kerberos Authentication

Hi,
We are using NW2004s SP10 Portal and we have successfully configured Kerberos authentication with Windows Active Directory 2003. To access the KM Content in windows explorer format, we are using Portal Drive but Portal Drive still asks for authentication i.e. SSO is not working for Portal Drive. I have understood from the forums and sap help site that SSO from portal drive will work only for NTLM authentication and client certificates. Can you please help regarding below questions.
1. Can Kerberos and NTLM authentication be configured together.
2. If yes, what are the steps to configure NTLM authentication for NW2004s SAP Portal and Active Directory 2003.
3. Any other approach to make Portal Drive SSO work.
Helpful answers will be rewarded.
Regards,
Chandra

Hi Gregor,
I did two things:
first i made a change in the portalapp.xml in the PAR file "com.sap.km.cm.par". In the section authentication scheme for "docs" I changed the authentication scheme to "default" to make sure that documents are opened using the default authentication scheme (SPNego) instead of basic authentication
second, I used the SPNego wizard to configure SPNego. So I didn't adjust anything in the Visual Admin or the authentication template apart from adding the Template to the Ticket policy configuration.
Again, this only worked after installing the latest vesion.
Hope this helps
Marcel

Jdk1.3 vs jdk1.4 and SASL authentication

Similar Messages

Maybe you are looking for