Bug 184141 - pwpolicy response control not sent with passwd modify extop response
pwpolicy response control not sent with passwd modify extop response
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Security - Password Policy (Show other bugs)
1.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Nathan Kinder
Chandrasekar Kannan
:
Depends On:
Blocks: 152373 249650 FDS1.2.0
  Show dependency treegraph
 
Reported: 2006-03-06 14:49 EST by Rich Megginson
Modified: 2015-01-04 18:19 EST (History)
4 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 18:58:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
CVS Diffs (11.96 KB, patch)
2009-01-15 12:50 EST, Nathan Kinder
no flags Details | Diff
Revised Diffs (11.96 KB, patch)
2009-01-15 13:23 EST, Nathan Kinder
no flags Details | Diff

  None (edit)
Description Rich Megginson 2006-03-06 14:49:55 EST
The 
#define LDAP_X_CONTROL_PWPOLICY_RESPONSE	"1.3.6.1.4.1.42.2.27.8.5.1"
is not being sent back in the response when using the passwd modify extop.  This
is due to the fact that the actual password modify is done via an internal
operation when using the extop, and we do not pass in the request controls to
the internal modify operation.
Comment 2 Nathan Kinder 2009-01-15 12:50:59 EST
Created attachment 329114 [details]
CVS Diffs

There are numerous issues causing the password policy response control to not be returned when using the password modify extended operation.

As Rich pointed out, we were not passing the controls through to the internal modify operation.  I found that we were not setting the request controls in the pblock for any extended operations, which made it impossible to copy those and pass them into the internal modify.

In the internal modify code, we were not setting SLAPI_PWPOLICY if the password policy control was present.  This needs to be set for the password policy code to determine if the response control needs to be sent.

There are also a few password policy checks that are not processed for internal operations.  We need to perform these checks in the password modify extended operation code since they need to know which user is performing the operation, which is unknown when dealing with an internal operation.
Comment 3 Rich Megginson 2009-01-15 13:16:07 EST
I think you need to set passwdPolicy    *pwpolicy = NULL here - https://bugzilla.redhat.com/attachment.cgi?id=329114&action=diff#ldap/servers/slapd/passwd_extop.c_sec4

Other than that, looks good.
Comment 4 Nathan Kinder 2009-01-15 13:23:25 EST
Created attachment 329120 [details]
Revised Diffs

This simply initializes pwpolicy to NULL as suggested by Rich.  The diffs are otherwise identical to the previous version.
Comment 5 Nathan Kinder 2009-01-15 13:25:14 EST
Checked into ldapserver (HEAD).  Thanks to Rich for his review!

Checking in ldap/servers/slapd/extendop.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/extendop.c,v  <--  extendop.c
new revision: 1.12; previous revision: 1.11
done
Checking in ldap/servers/slapd/modify.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/modify.c,v  <--  modify.c
new revision: 1.21; previous revision: 1.20
done
Checking in ldap/servers/slapd/passwd_extop.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/passwd_extop.c,v  <--  passwd_extop.c
new revision: 1.19; previous revision: 1.18
done
Comment 6 Jenny Galipeau 2009-03-11 12:25:47 EDT
Could you please add steps to verify this bug?
Thanks
Jenny
Comment 7 Nathan Kinder 2009-03-11 13:48:32 EDT
Set up a password policy (expiration, grace period, etc.).  Use the mozldap ldappasswd utility to update a users password (this will send the pwpolicy request control by default).  There should be some information about the policy output after changing the password.
Comment 8 Jenny Galipeau 2009-03-11 14:11:27 EDT
fix verified DS 8.1 RHEL 5

[root@jennyv2 mozldap]# ./ldappasswd -h `hostname` -p 389 -D "uid=dduck,ou=people,dc=bos,dc=redhat,dc=com" -w redhat -v -S
New Password: 
Re-enter new Password: 
ldappasswd: started Wed Mar 11 14:11:07 2009

ldap_init( jennyv2.bos.redhat.com, 389 )
ldappasswd: Confidentiality required
ldappasswd: additional info: Operation requires a secure connection.

[root@jennyv2 slapd-jennyv2]# /usr/lib/mozldap/ldappasswd -Z -h `hostname` -p 636 -D "uid=dduck,ou=people,dc=bos,dc=redhat,dc=com" -w redhat -v -S
New Password: 
Re-enter new Password: 
ldappasswd: started Wed Mar 11 14:16:13 2009

ldap_init( jennyv2.bos.redhat.com, 636 )
ldaptool_getcertpath -- .
ldaptool_getkeypath -- .
ldaptool_getmodpath -- (null)
ldaptool_getdonglefilename -- (null)
ldappasswd: password successfully changed
Comment 9 Nathan Kinder 2009-03-11 14:15:16 EDT
I don't see any pwpolicy response info listed above, but that may be the client applications fault.  Could you try it with openldap's ldappasswd tool and paste the output?
Comment 10 Jenny Galipeau 2009-03-11 14:47:11 EDT
with openLDAP client

[root@jennyv2 slapd-jennyv2]# ldappasswd -x -h `hostname` -p 389 -D "uid=dduck,ou=people,dc=bos,dc=redhat,dc=com" -w '!online3' -v -S
New password: 
Re-enter new password: 
ldap_initialize( ldap://jennyv2.bos.redhat.com:389 )
Result: Confidentiality required (13)
Additional info: Operation requires a secure connection.



[root@jennyv2 slapd-jennyv2]# ldappasswd -x -Z -h `hostname` -p 636 -D "uid=dduck,ou=people,dc=bos,dc=redhat,dc=com" -w '!online3' -v -S
New password: 
Re-enter new password: 
ldap_initialize( ldap://jennyv2.bos.redhat.com:636  )

(then it hangs ?)
Comment 11 Nathan Kinder 2009-03-11 17:28:06 EDT
(In reply to comment #10)
> [root@jennyv2 slapd-jennyv2]# ldappasswd -x -Z -h `hostname` -p 636 -D
> "uid=dduck,ou=people,dc=bos,dc=redhat,dc=com" -w '!online3' -v -S
> New password: 
> Re-enter new password: 
> ldap_initialize( ldap://jennyv2.bos.redhat.com:636  )
> 
> (then it hangs ?)  

The "-Z" option is for startTLS, which would use the regular port, not 636.  It is likely hanging due to this.
Comment 12 Jenny Galipeau 2009-03-12 08:54:30 EDT
[root@jennyv2 slapd-jennyv2]# ldappasswd -x -H ldaps://jennyv2.bos.redhat.com -W -D "uid=dduck,ou=people,dc=bos,dc=redhat,dc=com" -v -S
New password: 
Re-enter new password: 
Enter LDAP Password: 
ldap_initialize( ldaps://jennyv2.bos.redhat.com )
Result: Success (0)
Comment 13 Nathan Kinder 2009-03-12 11:56:03 EDT
What sort of password policy did you set for this verification?  Is password expiration enabled?

From looking at the code, te respose is only sent to warn you of pending expiration, or if the new password violates the password policy.  The easiest way to verify this is going to be to just try to set a password that is too short for the policy.
Comment 14 Jenny Galipeau 2009-03-12 12:04:14 EDT
does this look better?  maybe if I actually set a policy it work ;-|

[root@jennyv2 slapd-jennyv2]# ldappasswd -x -H ldaps://jennyv2.bos.redhat.com -W -D "uid=dduck,ou=people,dc=bos,dc=redhat,dc=com" -v -S
New password: 
Re-enter new password: 
Enter LDAP Password: 
ldap_initialize( ldaps://jennyv2.bos.redhat.com )
Result: Constraint violation (19)
Additional info: Failed to update password
Comment 15 Nathan Kinder 2009-03-12 12:25:21 EDT
Still don't see anything from the response control, but I just noticed that the openldap ldappasswd usage message shows that we have to use another option to send the request control (the man page fails to mention this option).

Add the "-e ppolicy" option.
Comment 16 Jenny Galipeau 2009-03-12 12:33:43 EDT
Mozilla client:

[root@jennyv2 slapd-jennyv2]# /usr/lib/mozldap/ldappasswd -Z -h `hostname` -p 636 -D "uid=dduck,ou=people,dc=bos,dc=redhat,dc=com" -w 123 -v -S
New Password: 
Re-enter new Password: 
ldappasswd: started Thu Mar 12 12:38:46 2009

ldap_init( jennyv2.bos.redhat.com, 636 )
ldaptool_getcertpath -- .
ldaptool_getkeypath -- .
ldaptool_getmodpath -- (null)
ldaptool_getdonglefilename -- (null)
ldappasswd: Constraint violation
ldappasswd: additional info: Failed to update password



OpenLDAP with -e ppolicy:

[root@jennyv2 slapd-jennyv2]# ldappasswd -x -H ldaps://jennyv2.bos.redhat.com -W -D "uid=dduck,ou=people,dc=bos,dc=redhat,dc=com" -v -S -e ppolicy
New password: 
Re-enter new password: 
Enter LDAP Password: 
ldap_initialize( ldaps://jennyv2.bos.redhat.com )
Result: Constraint violation (19)
Additional info: Failed to update password
Comment 17 Nathan Kinder 2009-03-12 15:06:12 EDT
I've been checking this out in the debugger, and what I'm seeing is odd.  We are trying to read any request controls from the ber using get_ldapmessage_controls(), but it's not finding any controls.  I've tried using the openldap client with "-e ppolicy" as well as the mozldap client which sends the control by default (I've also explicitly send the control using the "-J" option).

I'm not sure what is going on here, but the server is not getting the request control.  I do know that I tested this when I made the fix, so I'm not sure what is different now.
Comment 18 Jenny Galipeau 2009-03-12 15:18:48 EDT
Okay - thanks for keeping on track here.  It was difficult from the description to tell exactly what was supposed to be returned.  I'm going to tag fails for now until we figure out what is going on.
Comment 19 Nathan Kinder 2009-03-12 17:57:25 EDT
After a few hours of debugging, it turns out that this is a client problem.  With mozldap and openldap 2.3 clients, the password policy request control is only sent with the bind operation, not the password modify extended operation.

If you test this with the openldap 2.4 ldappasswd client, it will work.  Here's an example of what you should see:

[root@localhost dirsrv]# ldappasswd -h localhost -p 389 -Y DIGEST-MD5 -U nkinder -w Secret12 -a Secret12 -s secret -e ppolicy
SASL/DIGEST-MD5 authentication started
SASL username: nkinder
SASL SSF: 128
SASL data security layer installed.
Result: Constraint violation (19)
Additional info: Failed to update password

control: 1.3.6.1.4.1.42.2.27.8.5.1 false MIQAAAADgQEG
ppolicy: error=6 (Password is too short for policy)
Comment 20 Jenny Galipeau 2009-04-15 14:06:13 EDT
openldap 2.4 does not seem to be available for RHEL via yum or up2date - 

RHEL 4 is 2.2.13
RHEL 5 is 2.3.43

Please advice ...
Comment 21 Rich Megginson 2009-04-15 14:32:27 EDT
I suggest using Fedora 10
Comment 22 Jenny Galipeau 2009-04-15 14:57:27 EDT
if this will be relevant in future releases for RHDS, I suggest we remove this from blocking DS 8.1 release.  Agreed?
Comment 23 Rich Megginson 2009-04-15 15:03:26 EDT
Well, it depends on what clients we want to support.
Comment 24 Jenny Galipeau 2009-04-15 15:52:16 EDT
using Fedora 9:
[root@jmonster openldap]# uname -a
Linux jmonster 2.6.27.19-78.2.30.fc9.x86_64 #1 SMP Tue Feb 24 19:44:45 EST 2009 x86_64 x86_64 x86_64 GNU/Linux

[root@jmonster openldap]# rpm -qi openldap-clients
Name        : openldap-clients             Relocations: (not relocatable)
Version     : 2.4.10                            Vendor: Fedora Project
Release     : 2.fc9                         Build Date: Mon 13 Oct 2008 07:40:37 AM EDT
Install Date: Tue 11 Nov 2008 11:28:47 AM EST      Build Host: x86-3.fedora.phx.redhat.com
Group       : Applications/Internet         Source RPM: openldap-2.4.10-2.fc9.src.rpm
Size        : 539956                           License: OpenLDAP
Signature   : DSA/SHA1, Mon 03 Nov 2008 10:48:37 AM EST, Key ID 62aec3dc6df2196f
Packager    : Fedora Project
URL         : http://www.openldap.org/
Summary     : Client programs for OpenLDAP
Description :
OpenLDAP is an open-source suite of LDAP (Lightweight Directory Access
Protocol) applications and development tools. LDAP is a set of
protocols for accessing directory services (usually phone book style
information, but other information is possible) over the Internet,
similar to the way DNS (Domain Name System) information is propagated
over the Internet. The openldap-clients package contains the client
programs needed for accessing and modifying OpenLDAP directories.


[root@jmonster openldap]# ldappasswd -x -H ldaps://jennyv4.bos.redhat.com -W -D "uid=jenny,ou=people,dc=example,dc=com" -v -S -e ppolicy
New password: 
Re-enter new password: 
Enter LDAP Password: 
ldap_initialize( ldaps://jennyv4.bos.redhat.com:636/??base )
Result: Constraint violation (19)
Additional info: Failed to update password

[root@jmonster openldap]# ldappasswd -x -H ldaps://jennyv4.bos.redhat.com -W -D "uid=jenny,ou=people,dc=example,dc=com" -v -S -e ppolicy
New password: 
Re-enter new password: 
Enter LDAP Password: 
ldap_initialize( ldaps://jennyv4.bos.redhat.com:636/??base )
Result: Success (0)
Comment 25 Rich Megginson 2009-04-15 16:06:21 EDT
Hmm - I didn't see the output that Nathan posted in Comment #19 - Nathan, what version of ldappasswd did you use?
Comment 26 Nathan Kinder 2009-04-15 17:10:37 EDT
I was using a F9 system for my testing.  The version of openldap-clients on that system is:

openldap-clients-2.4.10-2.fc9.x86_64
Comment 27 Nathan Kinder 2009-04-15 17:20:08 EDT
Perhaps there is a difference if you try with SASL/DIGEST-MD5 as I did vs. LDAPS?
Comment 28 Jenny Galipeau 2009-04-16 09:08:00 EDT
[root@jmonster ~]# ldappasswd -h jennyv4.bos.redhat.com -p 389 -Y DIGEST-MD5 -U jenny -w james99 -a james99 -s secret -e ppolicy -v
ldap_initialize( ldap://jennyv4.bos.redhat.com:389 )
SASL/DIGEST-MD5 authentication started
SASL username: jenny
SASL SSF: 128
SASL data security layer installed.
Result: Success (0)

[root@jmonster ~]# ldappasswd -h jennyv4.bos.redhat.com -p 389 -Y DIGEST-MD5 -U jenny -w james99 -a james99 -s 123 -e ppolicy -v
ldap_initialize( ldap://jennyv4.bos.redhat.com:389 )
SASL/DIGEST-MD5 authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
[root@jmonster ~]# ldappasswd -h jennyv4.bos.redhat.com -p 389 -Y DIGEST-MD5 -U jenny -w secret -a secret -s 123 -e ppolicy -v
ldap_initialize( ldap://jennyv4.bos.redhat.com:389 )
SASL/DIGEST-MD5 authentication started
SASL username: jenny
SASL SSF: 128
SASL data security layer installed.
Result: Constraint violation (19)
Additional info: Failed to update password
Comment 29 Jenny Galipeau 2009-04-16 11:13:25 EDT
fix verified - DS 8.1 - RHEL 4

[root@jmonster ~]# ldappasswd -h jennyv4.bos.redhat.com -p 389 -Y DIGEST-MD5 -U jenny -w redhat -a redhat -s james99 -e ppolicy -v
ldap_initialize( ldap://jennyv4.bos.redhat.com:389 )
SASL/DIGEST-MD5 authentication started
SASL username: jenny
SASL SSF: 128
SASL data security layer installed.
Result: Success (0)
[root@jmonster ~]# ldappasswd -h jennyv4.bos.redhat.com -p 389 -Y DIGEST-MD5 -U jenny -w james99 -a james99 -s 123 -e ppolicy -v
ldap_initialize( ldap://jennyv4.bos.redhat.com:389 )
SASL/DIGEST-MD5 authentication started
SASL username: jenny
SASL SSF: 128
SASL data security layer installed.
Result: Constraint violation (19)
Additional info: Failed to update password

control: 1.3.6.1.4.1.42.2.27.8.5.1 false MIQAAAADgQEG
ppolicy: error=6 (Password is too short for policy)
Comment 30 Chandrasekar Kannan 2009-04-29 18:58:29 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHEA-2009-0455.html

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