Created attachment 383348 [details] tcpdump of Net::LDAP password modify extop and ldappasswd extop Using Net::LDAP::Extension::SetPassword to perform a password modify extended operation breaks with the following error of Fedora 11 decode error at /usr/lib/perl5/vendor_perl/5.10.0/Convert/ASN1/_decode.pm line 228. It produces the same error on RHEL 5, albeit on line 227. Despite this error, the password change succeeds. The problem appears to be that the msgid of the response is 0xFF. The following code produces the problem for me on 389DS 1.2.5rc3 using either perl-LDAP-0.33-3 (RHEL 5) or perl-LDAP-0.34-5 (F11): my $ldap = Net::LDAP->new($hostname); if ($ldap) { my $result = $ldap->start_tls(); if (!$result->is_error()) { $result = $ldap->bind($dn, password => $oldpass); if (!$result->is_error()) { $result = $ldap->set_password(newpasswd => $newpass); print $result->code() . "\n" if $result->is_error(); } } } The 389DS logs show no response being sent to Net::LDAP: [11/Jan/2010:16:03:36 -0600] conn=35150 fd=73 slot=73 connection from 10.9.3.7 to 10.1.1.21 [11/Jan/2010:16:03:36 -0600] conn=35150 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [11/Jan/2010:16:03:36 -0600] conn=35150 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [11/Jan/2010:16:03:36 -0600] conn=35150 SSL 256-bit AES [11/Jan/2010:16:03:36 -0600] conn=35150 op=1 BIND dn="uid=ppolicy,ou=people,o=nebrwesleyan.edu,o=isp" method=128 version=3 [11/Jan/2010:16:03:36 -0600] conn=35150 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=ppolicy,ou=people,o=nebrwesleyan.edu,o=isp" [11/Jan/2010:16:03:36 -0600] conn=35150 op=2 SRCH base="ou=people,o=nebrwesleyan.edu,o=isp" scope=2 filter="(uid=ppolicy)" attrs="dn" [11/Jan/2010:16:03:36 -0600] conn=35150 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [11/Jan/2010:16:03:36 -0600] conn=35150 op=3 EXT oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop" [11/Jan/2010:16:03:36 -0600] conn=35150 op=4 UNBIND [11/Jan/2010:16:03:36 -0600] conn=35150 op=4 fd=73 closed - U1 If I use the OpenLDAP ldappasswd command, though, the logs show a response being sent: [12/Jan/2010:11:24:39 -0600] conn=42519 fd=71 slot=71 connection from 10.9.3.7 to 10.1.1.21 [12/Jan/2010:11:24:39 -0600] conn=42519 op=0 EXT oid="1.3.6.1.4.1.1466.20037" name="startTLS" [12/Jan/2010:11:24:39 -0600] conn=42519 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [12/Jan/2010:11:24:39 -0600] conn=42519 SSL 256-bit AES [12/Jan/2010:11:24:39 -0600] conn=42519 op=1 BIND dn="uid=ppolicy,ou=people,o=nebrwesleyan.edu,o=isp" method=128 version=3 [12/Jan/2010:11:24:39 -0600] conn=42519 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=ppolicy,ou=people,o=nebrwesleyan.edu,o=isp" [12/Jan/2010:11:24:39 -0600] conn=42519 op=2 EXT oid="1.3.6.1.4.1.4203.1.11.1" name="passwd_modify_extop" [12/Jan/2010:11:24:39 -0600] conn=42519 op=2 RESULT err=0 tag=120 nentries=0 etime=0 [12/Jan/2010:11:24:39 -0600] conn=42519 op=3 UNBIND [12/Jan/2010:11:24:39 -0600] conn=42519 op=3 fd=71 closed - U1 I have attached a tcpdump showing two LDAP conversations. The first is a password modify operation as performed by Net::LDAP, which shows the lack of response. The second is a password modify operation as performed by the OpenLDAP ldappasswd command, which shows the same problem with the msgid being 0xFF, but still has a response anyway. The passwords contained in the tcpdump are junk passwords for a test account, and have been changed anyway.
Created attachment 386746 [details] patch
To ssh://git.fedorahosted.org/git/389/ds.git 1a76980..9b38ac3 master -> master commit 485cecd849dcaaee4677d832dbd171b091fe1dee Author: Rich Megginson <rmeggins> Date: Mon Jan 25 17:30:23 2010 -0700 Net::LDAP password modify extop breaks; msgid in response is 0xFF Reviewed by: nkinder Fix Description: We use a fake conn for the internal password modify operati so that we can use the real credentials. Unfortunately, this messes up the result code - because there is a real, non-NULL conn, it thinks it needs to send the result back to a real client rather than handle it as an internal operation. It looks as though o_result_handler is only used for internal operations. The fix is to change the result handling code to check for an internal op OR conn == NULL to see if we should use the result handler instead. commit 9b38ac3b5d27014c072cffb5a83e5888689c411b Author: Rich Megginson <rmeggins> Date: Mon Jan 25 18:05:38 2010 -0700 Clean up assert for entrydn Use entryrdn instead
commit 485cecd849dcaaee4677d832dbd171b091fe1dee Author: Rich Megginson <rmeggins> Date: Mon Jan 25 17:30:23 2010 -0700 Net::LDAP password modify extop breaks; msgid in response is 0xFF is a possible candidate for DS 8.2