This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 554887 - Net::LDAP password modify extop breaks; msgid in response is 0xFF
Net::LDAP password modify extop breaks; msgid in response is 0xFF
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Security - Password Policy (Show other bugs)
1.2.1
All Linux
low Severity medium
: ---
: ---
Assigned To: Rich Megginson
Viktor Ashirov
:
Depends On:
Blocks: 434914 389_1.2.6
  Show dependency treegraph
 
Reported: 2010-01-12 17:06 EST by Chris St. Pierre
Modified: 2015-12-07 12:17 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-07 12:17:52 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
tcpdump of Net::LDAP password modify extop and ldappasswd extop (8.06 KB, application/octet-stream)
2010-01-12 17:06 EST, Chris St. Pierre
no flags Details
patch (1.83 KB, patch)
2010-01-25 20:05 EST, Rich Megginson
nkinder: review+
Details | Diff

  None (edit)
Description Chris St. Pierre 2010-01-12 17:06:37 EST
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.
Comment 1 Rich Megginson 2010-01-25 20:05:52 EST
Created attachment 386746 [details]
patch
Comment 2 Rich Megginson 2010-01-26 11:59:09 EST
To ssh://git.fedorahosted.org/git/389/ds.git
   1a76980..9b38ac3  master -> master

commit 485cecd849dcaaee4677d832dbd171b091fe1dee
Author: Rich Megginson <rmeggins@redhat.com>
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@redhat.com>
Date:   Mon Jan 25 18:05:38 2010 -0700

    Clean up assert for entrydn
    
    Use entryrdn instead
Comment 3 Rich Megginson 2010-01-26 11:59:52 EST
commit 485cecd849dcaaee4677d832dbd171b091fe1dee
Author: Rich Megginson <rmeggins@redhat.com>
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

Note You need to log in before you can comment on or make changes to this bug.