Bug 181587 (pwd_extop_old_pwd) - Password Modify LDAPv3 extended operation erroneously forces the client to supply old password
Summary: Password Modify LDAPv3 extended operation erroneously forces the client to su...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: pwd_extop_old_pwd
Product: 389
Classification: Retired
Component: Security - Password Policy
Version: 1.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard: 1.0.2
Depends On:
Blocks: 152373 183369 240316
TreeView+ depends on / blocked
 
Reported: 2006-02-15 00:14 UTC by Felipe Alfaro Solana
Modified: 2015-12-07 17:01 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 17:01:40 UTC
Embargoed:


Attachments (Terms of Use)
Quick n'Dirty patch to fix the problem (1.30 KB, patch)
2006-02-15 00:28 UTC, Felipe Alfaro Solana
no flags Details | Diff
check for correctly bound connection (6.82 KB, text/plain)
2006-02-15 01:53 UTC, Rich Megginson
no flags Details

Description Felipe Alfaro Solana 2006-02-15 00:14:03 UTC
Description of problem:
Fedora Directory Server 1.0.1 implements LDAPv3 Passowrd Modify extended operation (RFC3062). This 
extended operation allows a client to change its LDAP password (userPassword attribute). The ASN.1 
definition for this operation is as follows:

PasswdModifyRequestValue ::= SEQUENCE {
     userIdentity    [0]  OCTET STRING OPTIONAL
     oldPasswd       [1]  OCTET STRING OPTIONAL
     newPasswd       [2]  OCTET STRING OPTIONAL }

As you can see, the old client password is an optional field. However, Fedora Directory Server code 
currently forces this parameter to always be specified in the request. Just take a look at http://
cvs.fedora.redhat.com/lxr/dirsec/source/ldapserver/ldap/servers/slapd/passwd_extop.c, lines 
312-327. There you can see this parameter is always required or else the change operation will fail.

This is an excerpt of RFC3062:

"The userIdentity field, if present, SHALL contain an octet string
   representation of the user associated with the request.  This string
   may or may not be an LDAPDN [RFC2253].  If no userIdentity field is
   present, the request acts up upon the password of the user currently
   associated with the LDAP session.

   The oldPasswd field, if present, SHALL contain the user's current
   password.

   The newPasswd field, if present, SHALL contain the desired password
   for this user."

Version-Release number of selected component (if applicable):
Fedora Directory Server 1.0.1

How reproducible:
Always.

This causes integration problems for Samba with LDAP password synchronization. When a user changes 
its SAMBA/Windows password, SAMBA starts an password modify LDAPv3 extended operation, but in 
the request, SAMBA does not specify the old password (since it is unavailable). Fedora Directory Server 
aborts the operation with error code 89, since the old password has been (erroneously) omitted.

Steps to Reproduce:
1. Enable a SAMBA server with LDAP password synchronization enabled.
2. Try to use "smbpasswd" to change both SAMBA/Windows and LDAP password.
3. The SAMBA/Windows password gets updated, but the LDAP password does not.
  
Actual results:
This causes integration problems with other products, like SAMBA 3.0.

Expected results:
Fedora Directory Server should allow the client to omit the old password when invoking the Password 
Modify LDAPv3 Extended Operation, as per RFC3062.

Additional info:

Comment 1 Felipe Alfaro Solana 2006-02-15 00:28:36 UTC
Created attachment 124660 [details]
Quick n'Dirty patch to fix the problem

This is a quick and dirty patch which I think should fix the problem. However,
I must say I have _not_ tested it.

Comment 2 Felipe Alfaro Solana 2006-02-15 00:30:59 UTC
Could it be possible to apply patch https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=124660 and 
build a test binary RPM using Red Hats build facilities for me to try?

Comment 3 Rich Megginson 2006-02-15 01:53:57 UTC
Created attachment 124663 [details]
check for correctly bound connection

check for correctly bound connection

Comment 4 Rich Megginson 2006-02-15 21:18:19 UTC
Reviewed by: Pete & Nathan (Thanks!)
Files: passwd_extop.c
Branch: HEAD
Fix Description: If the BIND operation was successful, the CONN_DN field 
is always set to the proper DN.  This is even the case during a SASL or 
client cert DN if the authentication was successful AND the given 
identity could be mapped to a real user in the directory.  Also, the 
authmethod will be something other than NULL or none.  So, if the old 
password was not given, that is ok if there is a non-anonymous bind DN 
and a real authmethod.  The rest of the operation passes through the usual
access control.
Platforms tested: Fedora Core 4
Flag Day: no
Doc impact: no

Checking in passwd_extop.c;
/cvs/dirsec/ldapserver/ldap/servers/slapd/passwd_extop.c,v  <--  passwd_extop.c
new revision: 1.7; previous revision: 1.6
done


Comment 5 Felipe Alfaro Solana 2006-02-17 15:22:31 UTC
I have rebuilt Fedora Directory Server from CVS. The changes you commited to "passwd_extop.c" are 
working fine. I'm finally able to synchronize passwords between SAMBA and Fedora Directory Server.

Will you build a new RPM for Fedora Directory Server with these changes included?

Comment 6 Rich Megginson 2006-02-17 15:30:39 UTC
Yes, we are working on a new release.  This fix will be in that new release when
it comes out.  Thanks for your help with this issue.


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