Bug 181587 - (pwd_extop_old_pwd) Password Modify LDAPv3 extended operation erroneously forces the client to supply old password
Password Modify LDAPv3 extended operation erroneously forces the client to su...
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Security - Password Policy (Show other bugs)
1.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Rich Megginson
Viktor Ashirov
1.0.2
:
Depends On:
Blocks: 152373 183369 240316
  Show dependency treegraph
 
Reported: 2006-02-14 19:14 EST by Felipe Alfaro Solana
Modified: 2015-12-07 12:01 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:01:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Felipe Alfaro Solana 2006-02-14 19:14:03 EST
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-14 19:28:36 EST
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-14 19:30:59 EST
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-14 20:53:57 EST
Created attachment 124663 [details]
check for correctly bound connection

check for correctly bound connection
Comment 4 Rich Megginson 2006-02-15 16:18:19 EST
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 10:22:31 EST
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 10:30:39 EST
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.