Logged in as guest
Viewing Contrib/3630 Full headers
Major security issue: yes no
Notes: JLDAP Notification:
Date: Mon, 4 Apr 2005 12:59:21 GMT From: russell_howe@wreckage.org To: openldap-its@OpenLDAP.org Subject: [JLDAP] GetBindID extended operation gives ClassCastException when used on AD
Full_Name: Russell Howe Version: CVS HEAD OS: Linux/Java 1.[45] URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.207.158.98) I get the following when trying to execute a GetBindDN extended operation against Active Directory. I don't know whether AD supports the operation or not, but JLDAP doesn't seem to like whatever AD tells it: Exception in thread "Thread-7" java.lang.ClassCastException: com.novell.ldap.asn1.ASN1Sequence at com.novell.ldap.rfc2251.RfcExtendedResponse.getResultCode(RfcExtendedResponse.java:144) at com.novell.ldap.Message.putReply(Message.java:305) at com.novell.ldap.Connection$ReaderThread.run(Connection.java:1201) at java.lang.Thread.run(Thread.java:595) This was using a freshly built CVS HEAD of jldap, as of about 1200 GMT on 4th April 2005. The code I am using is as follows: conn.connect(hostname, port); conn.bind(ldapVersion, bindDN, ((String)webCredential).getBytes("UTF8")); // ... LDAPExtendedResponse response = conn.extendedOperation(new GetBindDNRequest()); LDAPEntry user = null; if (((response.getResultCode()) == LDAPException.SUCCESS) && (response instanceof GetBindDNResponse)) { String bindDNResponse = ((GetBindDNResponse)response).getIdentity(); log.info("You were logged in as: " + bindDNResponse); user = conn.read(bindDNResponse); } else { log.warn("GetBindDN extended operation failed. Perhaps your LDAP server doesn't support it?"); } I can make the complete source available upon request (it's not restricted in any way..)
Date: Mon, 04 Apr 2005 14:20:47 +0100 From: Russell Howe <russell_howe@wreckage.org> To: openldap-its@OpenLDAP.org Subject: Re: (ITS#3630) [JLDAP] GetBindID extended operation gives ClassCastException when used on AD
This is a cryptographically signed message in MIME format. --------------ms090708050504030608040900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Modification of the lines around 144 to be: public final ASN1Enumerated getResultCode() { Object o = get(0); System.out.println("get(0) returns " + o); return (ASN1Enumerated)o; } gives: get(0) returns [UNIVERSAL 16] SEQUENCE: { [UNIVERSAL 10] ENUMERATED: 2, [UNIVERSAL 4] OCTET STRING: , [UNIVERSAL 4] OCTET STRING: } Exception in thread "Thread-7" java.lang.ClassCastException: com.novell.ldap.asn1.ASN1Sequence at com.novell.ldap.rfc2251.RfcExtendedResponse.getResultCode(RfcExtendedResponse.java:146) at com.novell.ldap.Message.putReply(Message.java:305) at com.novell.ldap.Connection$ReaderThread.run(Connection.java:1201) at java.lang.Thread.run(Thread.java:595) -- Russell Howe russell_howe@wreckage.org Today's Nemi: http://www.metro.co.uk/img/pix/nemi_apr4.jpg --------------ms090708050504030608040900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIbjCC BDMwggOcoAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwga0xCzAJBgNVBAYTAkdCMRYwFAYDVQQI Ew1HcmVhdCBCcml0YWluMQ8wDQYDVQQHEwZMb25kb24xIDAeBgNVBAoTF1RoZSBTYWx2YWdl IEFzc29jaWF0aW9uMQ0wCwYDVQQLEwRJLlQuMR8wHQYDVQQDExZTYWx2YWdlIEFzc29jaWF0 aW9uIENBMSMwIQYJKoZIhvcNAQkBFhRzeXN0ZW1zQHdyZWNrYWdlLm9yZzAeFw0wNDEyMTUx MjAyMTZaFw0wNTEyMTUxMjAyMTZaMIGZMQswCQYDVQQGEwJHQjEPMA0GA1UECBMGTG9uZG9u MSAwHgYDVQQKExdUaGUgU2FsdmFnZSBBc3NvY2lhdGlvbjEWMBQGA1UECxMNSVQgRGVwYXJ0 bWVudDEVMBMGA1UEAxMMUnVzc2VsbCBIb3dlMSgwJgYJKoZIhvcNAQkBFhlydXNzZWxsX2hv d2VAd3JlY2thZ2Uub3JnMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDHLKXhyuTAJFt6 8rdULyMKdmLgIL1LiF4SLAjXRguFOqjjsyxDJ4HpsUmjEb3KNiVqCU3fyl7qOSnBWkTCQ2nu x3YYi3r84ccuKEU9Qv2xkOqZNiokUCKCZE86JYjhhPJJ9SmcjDorCDrzt66kucjAffr4FFns I/MPHz3n8oRkpQIDAQABo4IBczCCAW8wCQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAw CwYDVR0PBAQDAgWgMEYGCWCGSAGG+EIBDQQ5FjdPcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZp Y2F0ZSAtIFRoZSBTYWx2YWdlIEFzc29jaWF0aW9uMB0GA1UdDgQWBBRDqOqZLeFF9nch0q34 702kFV87IjCB2gYDVR0jBIHSMIHPgBS5Bpo93RST16UeqHukdILwx5kXTaGBs6SBsDCBrTEL MAkGA1UEBhMCR0IxFjAUBgNVBAgTDUdyZWF0IEJyaXRhaW4xDzANBgNVBAcTBkxvbmRvbjEg MB4GA1UEChMXVGhlIFNhbHZhZ2UgQXNzb2NpYXRpb24xDTALBgNVBAsTBEkuVC4xHzAdBgNV BAMTFlNhbHZhZ2UgQXNzb2NpYXRpb24gQ0ExIzAhBgkqhkiG9w0BCQEWFHN5c3RlbXNAd3Jl Y2thZ2Uub3JnggEAMA0GCSqGSIb3DQEBBAUAA4GBAH35iQmS6VR+iee+GZ/RTKHYMp44okq9 Fp1DQg5CPeJJGd/XOpW9aqRn7Z7JZdR6GKOkdJl7y1/q83g3hN1h0JUpDFiYlKULRVULOG+E cvt/PHST562UtkXGUogpFf45DWHdx/xvaS1hr1ud0rgvC/Y6BrhZ7r7fhlqITo2AFH5mMIIE MzCCA5ygAwIBAgIBBDANBgkqhkiG9w0BAQQFADCBrTELMAkGA1UEBhMCR0IxFjAUBgNVBAgT DUdyZWF0IEJyaXRhaW4xDzANBgNVBAcTBkxvbmRvbjEgMB4GA1UEChMXVGhlIFNhbHZhZ2Ug QXNzb2NpYXRpb24xDTALBgNVBAsTBEkuVC4xHzAdBgNVBAMTFlNhbHZhZ2UgQXNzb2NpYXRp b24gQ0ExIzAhBgkqhkiG9w0BCQEWFHN5c3RlbXNAd3JlY2thZ2Uub3JnMB4XDTA0MTIxNTEy MDIxNloXDTA1MTIxNTEyMDIxNlowgZkxCzAJBgNVBAYTAkdCMQ8wDQYDVQQIEwZMb25kb24x IDAeBgNVBAoTF1RoZSBTYWx2YWdlIEFzc29jaWF0aW9uMRYwFAYDVQQLEw1JVCBEZXBhcnRt ZW50MRUwEwYDVQQDEwxSdXNzZWxsIEhvd2UxKDAmBgkqhkiG9w0BCQEWGXJ1c3NlbGxfaG93 ZUB3cmVja2FnZS5vcmcwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMcspeHK5MAkW3ry t1QvIwp2YuAgvUuIXhIsCNdGC4U6qOOzLEMngemxSaMRvco2JWoJTd/KXuo5KcFaRMJDae7H dhiLevzhxy4oRT1C/bGQ6pk2KiRQIoJkTzoliOGE8kn1KZyMOisIOvO3rqS5yMB9+vgUWewj 8w8fPefyhGSlAgMBAAGjggFzMIIBbzAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIFoDAL BgNVHQ8EBAMCBaAwRgYJYIZIAYb4QgENBDkWN09wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmlj YXRlIC0gVGhlIFNhbHZhZ2UgQXNzb2NpYXRpb24wHQYDVR0OBBYEFEOo6pkt4UX2dyHSrfjv TaQVXzsiMIHaBgNVHSMEgdIwgc+AFLkGmj3dFJPXpR6oe6R0gvDHmRdNoYGzpIGwMIGtMQsw CQYDVQQGEwJHQjEWMBQGA1UECBMNR3JlYXQgQnJpdGFpbjEPMA0GA1UEBxMGTG9uZG9uMSAw HgYDVQQKExdUaGUgU2FsdmFnZSBBc3NvY2lhdGlvbjENMAsGA1UECxMESS5ULjEfMB0GA1UE AxMWU2FsdmFnZSBBc3NvY2lhdGlvbiBDQTEjMCEGCSqGSIb3DQEJARYUc3lzdGVtc0B3cmVj a2FnZS5vcmeCAQAwDQYJKoZIhvcNAQEEBQADgYEAffmJCZLpVH6J574Zn9FModgynjiiSr0W nUNCDkI94kkZ39c6lb1qpGftnsll1HoYo6R0mXvLX+rzeDeE3WHQlSkMWJiUpQtFVQs4b4Ry +388dJPnrZS2RcZSiCkV/jkNYd3H/G9pLWGvW53SuC8L9joGuFnuvt+GWohOjYAUfmYxggOf MIIDmwIBATCBszCBrTELMAkGA1UEBhMCR0IxFjAUBgNVBAgTDUdyZWF0IEJyaXRhaW4xDzAN BgNVBAcTBkxvbmRvbjEgMB4GA1UEChMXVGhlIFNhbHZhZ2UgQXNzb2NpYXRpb24xDTALBgNV BAsTBEkuVC4xHzAdBgNVBAMTFlNhbHZhZ2UgQXNzb2NpYXRpb24gQ0ExIzAhBgkqhkiG9w0B CQEWFHN5c3RlbXNAd3JlY2thZ2Uub3JnAgEEMAkGBSsOAwIaBQCgggJBMBgGCSqGSIb3DQEJ AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTA1MDQwNDEzMjA0N1owIwYJKoZIhvcN AQkEMRYEFKJCg+WPBcQhvVr779VbAg8+jqxNMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIHEBgkrBgEEAYI3EAQxgbYwgbMwga0xCzAJBgNVBAYTAkdCMRYwFAYDVQQIEw1HcmVh dCBCcml0YWluMQ8wDQYDVQQHEwZMb25kb24xIDAeBgNVBAoTF1RoZSBTYWx2YWdlIEFzc29j aWF0aW9uMQ0wCwYDVQQLEwRJLlQuMR8wHQYDVQQDExZT
Date: Tue, 27 Nov 2007 23:56:09 -0700 From: "Rastogi Arpit" <rarpit@novell.com> To: <openldap-its@OpenLDAP.org> Cc: "Nachiappan Palaniappan" <NPalaniappan@novell.com>, "Rajkumar V" <VRAJKUMAR@novell.com>, <russell_howe@wreckage.org> Subject: Re: (ITS#3630) [JLDAP] GetBindID extended operation gives ClassCastException
This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part6A4C6D19.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Generally, the extensions (extended operations) are not common to all the = LDAP servers. Most of the extensions available here as part of jldap(includ= ing the GetBindDN) are exensions supported by eDirectory. However one = should not get such exceptions, which you've reported even on the other = LDAP servers (as Active Directory).=20 =20 However, I tried the same code as stated on AD server and I didn't get the = exception you got. Instead I am getting the following exceptions=20 =20 Login succeeded=20 Error: LDAPException: Protocol Error (2) Protocol ErrorLDAPException: = Server Message: 0000203D: LdapErr: DSID-0C090C7D, comment: Unknown = extended request OID, data 0, vece=20 =20 which is the expected behavior. =20 Please check the issues once again with the latest JLDAP code and please = do let me know if I need to do something more for replicating the problem, = it it still persists. --=__Part6A4C6D19.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>Generally, the extensions (extended operations) are not common to all = the LDAP servers. Most of the extensions available here as part of = jldap(including the GetBindDN) are exensions supported by eDirectory. = However one should not get such exceptions, which you've reported even on = the other LDAP servers (as Active Directory). </DIV> <DIV> </DIV> <DIV>However, I tried the same code as stated on AD server and I didn't = get the exception you got. Instead I am getting the following exceptions = </DIV> <DIV> </DIV> <DIV>Login succeeded <BR>Error: LDAPException: Protocol Error (2) Protocol = ErrorLDAPException: Server Message: 0000203D: LdapErr: DSID-0C090C7D, = comment: Unknown extended request OID, data 0, vece </DIV> <DIV> </DIV> <DIV>which is the expected behavior.</DIV> <DIV> </DIV> <DIV>Please check the issues once again with the latest JLDAP code and = please do let me know if I need to do something more for replicating the = problem, it it still persists.</DIV></BODY></HTML> --=__Part6A4C6D19.0__=--
Date: Tue, 27 Nov 2007 23:57:03 -0700 From: "Rastogi Arpit" <rarpit@novell.com> To: <openldap-its@OpenLDAP.org> Cc: "Nachiappan Palaniappan" <NPalaniappan@novell.com>, "Rajkumar V" <VRAJKUMAR@novell.com>, <russell_howe@wreckage.org> Subject: Re: (ITS#3630) [JLDAP] GetBindID extended operation gives ClassCastException
This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part5C7A5B2F.0__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Generally, the extensions (extended operations) are not common to all the = LDAP servers. Most of the extensions available here as part of jldap(includ= ing the GetBindDN) are exensions supported by eDirectory. However one = should not get such exceptions, which you've reported even on the other = LDAP servers (as Active Directory).=20 =20 However, I tried the same code as stated on AD server and I didn't get the = exception you got. Instead I am getting the following exceptions=20 =20 Login succeeded=20 Error: LDAPException: Protocol Error (2) Protocol ErrorLDAPException: = Server Message: 0000203D: LdapErr: DSID-0C090C7D, comment: Unknown = extended request OID, data 0, vece=20 =20 which is the expected behavior. =20 Please check the issues once again with the latest JLDAP code and please = do let me know if I need to do something more for replicating the problem, = if it still persists. --=__Part5C7A5B2F.0__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>Generally, the extensions (extended operations) are not common to all = the LDAP servers. Most of the extensions available here as part of = jldap(including the GetBindDN) are exensions supported by eDirectory. = However one should not get such exceptions, which you've reported even on = the other LDAP servers (as Active Directory). </DIV> <DIV> </DIV> <DIV>However, I tried the same code as stated on AD server and I didn't = get the exception you got. Instead I am getting the following exceptions = </DIV> <DIV> </DIV> <DIV>Login succeeded <BR>Error: LDAPException: Protocol Error (2) Protocol = ErrorLDAPException: Server Message: 0000203D: LdapErr: DSID-0C090C7D, = comment: Unknown extended request OID, data 0, vece </DIV> <DIV> </DIV> <DIV>which is the expected behavior.</DIV> <DIV> </DIV> <DIV>Please check the issues once again with the latest JLDAP code and = please do let me know if I need to do something more for replicating the = problem, if it still persists.</DIV></BODY></HTML> --=__Part5C7A5B2F.0__=--
From: Nachiappan Palaniappan <openldap-its@OpenLDAP.org> To: russell_howe@wreckage.org Subject: Re: [JLDAP] GetBindID extended operation gives ClassCastException when used on AD (ITS#3630) Date: Thu Dec 13 06:08:20 2007 CC: rarpit@novell.com
Hi, Sorry for the delay. With reference to the below quote, could you please let us know, whether you face the issue still with the latest source? Thanks, Palaniappan. > > Generally, the extensions (extended operations) are not common to all the = > LDAP servers. Most of the extensions available here as part of jldap(includ= > ing the GetBindDN) are exensions supported by eDirectory. However one = > should not get such exceptions, which you've reported even on the other = > LDAP servers (as Active Directory).=20 > =20 > However, I tried the same code as stated on AD server and I didn't get the = > exception you got. Instead I am getting the following exceptions=20 > =20 > Login succeeded=20 > Error: LDAPException: Protocol Error (2) Protocol ErrorLDAPException: = > Server Message: 0000203D: LdapErr: DSID-0C090C7D, comment: Unknown = > extended request OID, data 0, vece=20 > =20 > which is the expected behavior. > =20 > Please check the issues once again with the latest JLDAP code and please = > do let me know if I need to do something more for replicating the problem, = > it it still persists. > > --=__Part6A4C6D19.0__= > Content-Type: text/html; charset=US-ASCII > Content-Transfer-Encoding: quoted-printable > > <HTML><HEAD> > <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= > "> > <META content=3D"MSHTML 6.00.2900.3157" name=3DGENERATOR></HEAD> > <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> > <DIV>Generally, the extensions (extended operations) are not common to all = > the LDAP servers. Most of the extensions available here as part of = > jldap(including the GetBindDN) are exensions supported by eDirectory. = > However one should not get such exceptions, which you've reported even on = > the other LDAP servers (as Active Directory). </DIV> > <DIV> </DIV> > <DIV>However, I tried the same code as stated on AD server and I didn't = > get the exception you got. Instead I am getting the following exceptions = > </DIV> > <DIV> </DIV> > <DIV>Login succeeded <BR>Error: LDAPException: Protocol Error (2) Protocol = > ErrorLDAPException: Server Message: 0000203D: LdapErr: DSID-0C090C7D, = > comment: Unknown extended request OID, data 0, vece </DIV> > <DIV> </DIV> > <DIV>which is the expected behavior.</DIV> > <DIV> </DIV> > <DIV>Please check the issues once again with the latest JLDAP code and = > please do let me know if I need to do something more for replicating the = > problem, it it still persists.</DIV></BODY></HTML> > > --=__Part6A4C6D19.0__=-- > >
From: Nachiappan Palaniappan <openldap-its@OpenLDAP.org> To: russell_howe@wreckage.org Subject: Re: [JLDAP] GetBindID extended operation gives ClassCastException when used on AD (ITS#3630) Date: Fri Jan 25 09:04:13 2008 CC: rarpit@novell.com
Please , look at the bug . As it has been for a long time in the feedback state . Please check with the latest source code if the problem is replicated and if it does not please move the bug to closed state . We will be moving it to suspend state after a couple of weeks time . If you find it replicated please feel free to repoen the bug .
From: Nachiappan Palaniappan <openldap-its@OpenLDAP.org> To: russell_howe@wreckage.org Subject: Re: [JLDAP] GetBindID extended operation gives ClassCastException when used on AD (ITS#3630) Date: Fri Jan 25 10:24:17 2008 CC: rarpit@novell.com
Please , look at the bug . As it has been for a long time in the feedback state . Please check with the latest source code if the problem is replicated and if it does not please move the bug to closed state . We will be moving it to suspend state after a couple of weeks time . If you find it replicated please feel free to reopen the bug .
______________ © Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org
