Re: set-password extended operation encoding error

[Chris R. <chr...@me...>]

Darryl C Price <da...@co...> wrote:
> I Think I figured out the problem.  The ldap implementation under test
> returns  an error if the userIdentity or old password fields are present
> in the  request.  This sort of sucks.  If I only pass the newpass to the
> encode method  (for passwordModReq) It works (i.e. changes the password)
> but I get a BER  decoding error and the script hangs with an unexpected
> PDU:

I've run the ldappasswd program from OpenLDAP 2.0.22 against a server using
the '-s secret' mode (which just sets newpasswd), and I've run a perl-ldap
script using the correct ASN.1 with just a newpasswd, and the protocol I
can see using a packet sniffer (ethereal) is *identical*.

The server I tested against doesn't support this extended operation, so in
both cases the operation failed, but my point is that the perl script is
sending the same bytes as the ldappasswd program. If one works, so must the
other :-)

The "Unexpected" PDU

0000   62: SEQUENCE {
0006    1:   INTEGER = 0
0009   53:   [APPLICATION 24] {
000F    1:     ENUM = 0
0012    0:     STRING = ''
0014   20:     STRING = 'BER decoding problem'
002A   22:     [CONTEXT 10]
002C     :       31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 31 34 36 36 
1.3.6.1.4.1.1466
003C     :       2E 32 30 30 33 36 __ __ __ __ __ __ __ __ __ __ .20036
0042    0:     [CONTEXT 11]
0044     :   }
0044     : }
Unexpected PDU, ignored

is the server sending a standard disconnection notification (RFC 2251
4.4.1), ie "pulling the plug" on the client because it sent it bad
protocol. Bad client, no biscuit. Net::LDAP should probably handle these
notifications in some graceful way. I would expect that calling a
client-provided callback would be useful here.

Cheers,

Chris