ppolicy control and change password exop (again)

[Guillaume Rousse]

Hello list.

Some time ago, I had an issue with set_password() not handling controls:
http://www.nntp.perl.org/group/perl.ldap/2008/09/msg2950.html

It was fixed in perl-ldap 0.38.

I also opened an ITS in openldap, because apparently password modify
exop was not returning ppolicy control correctly:
http://www.openldap.org/lists/openldap-bugs/200809/msg00178.html

It was fixed in openldap 2.4.12

However, it still doesn't work. The following test case shows than the
value returned by $response->control( LDAP_CONTROL_PASSWORDPOLICY ) is
always '1', instead of an instance of Net::LDAP::Control::PasswordPolicy
class.

#!/usr/bin/perl
use Net::LDAP;
use Net::LDAP::Extension::SetPassword;
use Net::LDAP::Control::PasswordPolicy;
use Net::LDAP::Constant qw( LDAP_CONTROL_PASSWORDPOLICY );
use Data::Dumper;

my $ldap = Net::LDAP->new(
'ldaps://ldap.domain.com',
verify => 'require',
capath => '/etc/pki/tls/certs'
) or die "impossible to connect: $@";

my $pp = Net::LDAP::Control::PasswordPolicy->new();
my $result = $ldap->bind(
shift,
password => shift,
);
die 'impossible to bind: ' . $result->error() if $result->code();

$result = $ldap->set_password(
newpasswd => 'a',
control => [ $pp ]
);

my $response = $result->control(LDAP_CONTROL_PASSWORDPOLICY);
print Dumper($response);

[root@etoile ~]# perl test.pl <user> <password>
$VAR1 = 1;

Before I reopen the ITS, I'd like to be sure my perl code is correct
first. In particular, is this normal to send a control object in the
request, and to get another distinct control object from the response ?

I tested with perl-ldap 0.39.
--
BOFH excuse #333:

A plumber is needed, the network drain is clogged

[Chris Ridd]

On 26 May 2009, at 14:42, Guillaume Rousse wrote:

> Hello list.
>
> Some time ago, I had an issue with set_password() not handling
> controls:
> http://www.nntp.perl.org/group/perl.ldap/2008/09/msg2950.html
>
> It was fixed in perl-ldap 0.38.
>
> I also opened an ITS in openldap, because apparently password modify
> exop was not returning ppolicy control correctly:
> http://www.openldap.org/lists/openldap-bugs/200809/msg00178.html
>
> It was fixed in openldap 2.4.12
>
> However, it still doesn't work. The following test case shows than
> the value returned by $response-
> >control( LDAP_CONTROL_PASSWORDPOLICY ) is always '1', instead of an
> instance of Net::LDAP::Control::PasswordPolicy class.

Can you give us BER dumps of the exop itself and the response?

> Before I reopen the ITS, I'd like to be sure my perl code is correct
> first. In particular, is this normal to send a control object in the
> request, and to get another distinct control object from the
> response ?

Not sure what you mean by "distinct" but it is how the password policy
draft is designed. Paged results is a little similar.

Cheers,

Chris

[Guillaume Rousse]

Chris Ridd a �crit :

>
> On 26 May 2009, at 14:42, Guillaume Rousse wrote:
>
>> Hello list.
>>
>> Some time ago, I had an issue with set_password() not handling controls:
>> http://www.nntp.perl.org/group/perl.ldap/2008/09/msg2950.html
>>
>> It was fixed in perl-ldap 0.38.
>>
>> I also opened an ITS in openldap, because apparently password modify
>> exop was not returning ppolicy control correctly:
>> http://www.openldap.org/lists/openldap-bugs/200809/msg00178.html
>>
>> It was fixed in openldap 2.4.12
>>
>> However, it still doesn't work. The following test case shows than the
>> value returned by $response->control( LDAP_CONTROL_PASSWORDPOLICY ) is
>> always '1', instead of an instance of
>> Net::LDAP::Control::PasswordPolicy class.
>
> Can you give us BER dumps of the exop itself and the response?

Is there any other way beyond network capture directly ?

>> Before I reopen the ITS, I'd like to be sure my perl code is correct
>> first. In particular, is this normal to send a control object in the
>> request, and to get another distinct control object from the response ?
>
> Not sure what you mean by "distinct" but it is how the password policy
> draft is designed. Paged results is a little similar.

distinct here means calling $result->control(), instead of directly
using the control created earlier with
Net::LDAP::Control::PasswordPolicy->new(), and passed to the
set_passwd() operation.

--
BOFH excuse #336:

the xy axis in the trackball is coordinated with the summer solstice

[Chris Ridd]

On 26 May 2009, at 15:56, Guillaume Rousse wrote:

> Chris Ridd a écrit :

>> On 26 May 2009, at 14:42, Guillaume Rousse wrote:
>>> Hello list.
>>>
>>> Some time ago, I had an issue with set_password() not handling
>>> controls:
>>> http://www.nntp.perl.org/group/perl.ldap/2008/09/msg2950.html
>>>
>>> It was fixed in perl-ldap 0.38.
>>>
>>> I also opened an ITS in openldap, because apparently password
>>> modify exop was not returning ppolicy control correctly:
>>> http://www.openldap.org/lists/openldap-bugs/200809/msg00178.html
>>>
>>> It was fixed in openldap 2.4.12
>>>
>>> However, it still doesn't work. The following test case shows than
>>> the value returned by $response-
>>> >control( LDAP_CONTROL_PASSWORDPOLICY ) is always '1', instead of
>>> an instance of Net::LDAP::Control::PasswordPolicy class.
>> Can you give us BER dumps of the exop itself and the response?
> Is there any other way beyond network capture directly ?

It is the only way to prove what's being sent/returned is buggy (or
not). If the data being sent/returned is good, we look to see where
the perl code's gone wrong, if it is bad there's not much we can do.

Use the debug method on your Net::LDAP object to get the output, maybe
xx out the sensitive hex and ASCII data.

>
>>> Before I reopen the ITS, I'd like to be sure my perl code is
>>> correct first. In particular, is this normal to send a control
>>> object in the request, and to get another distinct control object
>>> from the response ?
>> Not sure what you mean by "distinct" but it is how the password
>> policy draft is designed. Paged results is a little similar.
> distinct here means calling $result->control(), instead of directly
> using the control created earlier with
> Net::LDAP::Control::PasswordPolicy->new(), and passed to the
> set_passwd() operation.

I see what you mean. In the case of ppolicy it is normal; the server
sends information to you in an LDAP control inside the response
(password good/bad/too short/etc), and that's what you're extracting.
In paged results the server sends you some kind of cookie which you
resend to continue the search. They're both normal techniques then,
but uncommon ones.

Cheers,

Chris

[Guillaume Rousse]

Chris Ridd a �crit :

>
> On 26 May 2009, at 15:56, Guillaume Rousse wrote:
>

>> Chris Ridd a �crit :

>>> On 26 May 2009, at 14:42, Guillaume Rousse wrote:
>>>> Hello list.
>>>>
>>>> Some time ago, I had an issue with set_password() not handling
>>>> controls:
>>>> http://www.nntp.perl.org/group/perl.ldap/2008/09/msg2950.html
>>>>
>>>> It was fixed in perl-ldap 0.38.
>>>>
>>>> I also opened an ITS in openldap, because apparently password modify
>>>> exop was not returning ppolicy control correctly:
>>>> http://www.openldap.org/lists/openldap-bugs/200809/msg00178.html
>>>>
>>>> It was fixed in openldap 2.4.12
>>>>
>>>> However, it still doesn't work. The following test case shows than
>>>> the value returned by $response->control(
>>>> LDAP_CONTROL_PASSWORDPOLICY ) is always '1', instead of an instance
>>>> of Net::LDAP::Control::PasswordPolicy class.
>>> Can you give us BER dumps of the exop itself and the response?
>> Is there any other way beyond network capture directly ?
>
> It is the only way to prove what's being sent/returned is buggy (or
> not). If the data being sent/returned is good, we look to see where the
> perl code's gone wrong, if it is bad there's not much we can do.
>
> Use the debug method on your Net::LDAP object to get the output, maybe
> xx out the sensitive hex and ASCII data.

Here you have, with both debug output mode.
--
BOFH excuse #372:

Forced to support NT servers; sysadmins quit.

[Chris Ridd]

On 26 May 2009, at 16:17, Guillaume Rousse wrote:

> Net::LDAP=HASH(0x9e63030) sending:
> 0000 68: SEQUENCE {
> 0002 1: INTEGER = 2
> 0005 32: [APPLICATION 23] {
> 0007 23: [CONTEXT 0]
> 0009 : 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 34 32 30 33
> 1.3.6.1.4.1.4203
> 0019 : 2E 31 2E 31 31 2E 31 __ __ __ __ __ __ __ __ __ .
> 1.11.1
> 0020 5: [CONTEXT 1]
> 0022 : 30 03 82 01 61 __ __ __ __ __ __ __ __ __ __ __ 0...a
> 0027 : }
> 0027 29: [CONTEXT 0] {
> 0029 27: SEQUENCE {
> 002B 25: STRING = '1.3.6.1.4.1.42.2.27.8.5.1'
> 0046 : }
> 0046 : }
> 0046 : }

That looks like the passwd modify op, with the right control and no
control value.

> Net::LDAP=HASH(0x9e63030) received:
> 0000 88: SEQUENCE {
> 0002 1: INTEGER = 2
> 0005 45: [APPLICATION 24] {
> 0007 1: ENUM = 19
> 000A 0: STRING = ''
> 000C 38: STRING = 'Password fails quality checking policy'
> 0034 : }
> 0034 36: [CONTEXT 0] {
> 0036 34: SEQUENCE {
> 0038 25: STRING = '1.3.6.1.4.1.42.2.27.8.5.1'
> 0053 5: STRING
> 0055 : 30 03 81 01 06 __ __ __ __ __ __ __ __ __ __ __
> 0....
> 005A : }
> 005A : }
> 005A : }

That looks OK too. The value is internally BER encoded, and decodes as:

SEQUENCE {
[1] INTEGER -- 0x06
}

which is "passwordTooShort". So... the server seems OK and it must be
the perl code that's going wrong somewhere. If you single-step into
result->control does it look like it is finding and returning the
right thing?

Cheers,

Chris

[Guillaume Rousse]

Chris Ridd a �crit :

> which is "passwordTooShort". So... the server seems OK and it must be
> the perl code that's going wrong somewhere. If you single-step into
> result->control does it look like it is finding and returning the right
> thing?

Actually, it returns a list of controls, and the code enforce a scalar
context...

Changing the code to
my ($response) = $result->control(LDAP_CONTROL_PASSWORDPOLICY);
is enough to fix the issue. And the documentation is correct, I just
misread it :(

Having the method named controlS would have been less error-prone but I
guess it's a bit late to change it.

Thanks for your help.
--
BOFH excuse #143:

had to use hammer to free stuck disk drive heads.

[Guillaume Rousse]

Graham Barr a �crit :

>
> On May 27, 2009, at 2:58 AM, Guillaume Rousse wrote:
>
>> Chris Ridd a �crit :
>>> which is "passwordTooShort". So... the server seems OK and it must be
>>> the perl code that's going wrong somewhere. If you single-step into
>>> result->control does it look like it is finding and returning the
>>> right thing?
>> Actually, it returns a list of controls, and the code enforce a scalar
>> context...
>>
>> Changing the code to
>> my ($response) = $result->control(LDAP_CONTROL_PASSWORDPOLICY);
>> is enough to fix the issue. And the documentation is correct, I just
>> misread it :(
>>
>> Having the method named controlS would have been less error-prone but
>> I guess it's a bit late to change it.
>

> Actually I htink there is a bug. As you only have one control in your
> response, if you did
>
> my $response = $result->control;
>
> you would have got the control.
>
> That is because when there are arguments to ->control, the code is
> returning an array, not a list, which in a scalar context returns its
> length.
>
> Also, the current code only supports passing one OID, although the docs
> suggest otherwise
>
> Try this patch
It works as expected.

--
BOFH excuse #61:

not approved by the FCC