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.
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.
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.
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.
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
Could you please add steps to verify this bug? Thanks Jenny
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.
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
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?
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 ?)
(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.
[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)
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.
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
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.
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
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.
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.
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)
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 ...
I suggest using Fedora 10
if this will be relevant in future releases for RHDS, I suggest we remove this from blocking DS 8.1 release. Agreed?
Well, it depends on what clients we want to support.
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)
Hmm - I didn't see the output that Nathan posted in Comment #19 - Nathan, what version of ldappasswd did you use?
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
Perhaps there is a difference if you try with SASL/DIGEST-MD5 as I did vs. LDAPS?
[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
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)
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