Issue 3630 - [JLDAP] GetBindID extended operation gives ClassCastException when used on AD
Summary: [JLDAP] GetBindID extended operation gives ClassCastException when used on AD
Status: RESOLVED FEEDBACK
Alias: None
Product: JLDAP
Classification: Unclassified
Component: JLDAP (show other issues)
Version: unspecified
Hardware: All All
: --- normal
Target Milestone: ---
Assignee: OpenLDAP project
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-04-04 12:59 UTC by russell_howe@wreckage.org
Modified: 2021-08-03 17:48 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description russell_howe@wreckage.org 2005-04-04 12:59:21 UTC
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..)


Comment 1 russell_howe@wreckage.org 2005-04-04 13:20:47 UTC
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
Comment 2 mboorshtein@openldap.org 2005-09-12 02:34:06 UTC
moved from Incoming to Contrib
Comment 3 Kurt Zeilenga 2005-10-12 00:59:06 UTC
changed notes
Comment 4 Rastogi Arpit 2007-11-28 06:56:09 UTC
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). 
 
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 
 
Login succeeded 
Error: LDAPException: Protocol Error (2) Protocol ErrorLDAPException: Server Message: 0000203D: LdapErr: DSID-0C090C7D, comment: Unknown extended request OID, data 0, vece 
 
which is the expected behavior.
 
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.
Comment 5 Rastogi Arpit 2007-11-28 06:57:03 UTC
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). 
 
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 
 
Login succeeded 
Error: LDAPException: Protocol Error (2) Protocol ErrorLDAPException: Server Message: 0000203D: LdapErr: DSID-0C090C7D, comment: Unknown extended request OID, data 0, vece 
 
which is the expected behavior.
 
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.
Comment 6 npalani@openldap.org 2007-12-13 06:08:20 UTC
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__=--
> 
> 
Comment 7 npalani@openldap.org 2007-12-13 06:08:33 UTC
changed state Open to Feedback
Comment 8 npalani@openldap.org 2008-01-25 09:00:10 UTC
resent 3630.reply.1
Comment 9 npalani@openldap.org 2008-01-25 09:04:13 UTC
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 .
 
Comment 10 npalani@openldap.org 2008-01-25 10:24:17 UTC
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 .
 
Comment 11 Hallvard Furuseth 2011-11-25 10:09:05 UTC
changed state Feedback to Open
Comment 12 Hallvard Furuseth 2011-11-25 10:48:31 UTC
changed state Open to Feedback
Comment 13 OpenLDAP project 2014-08-01 21:03:27 UTC
JLDAP