Bug 181587 (pwd_extop_old_pwd)
| Summary: | Password Modify LDAPv3 extended operation erroneously forces the client to supply old password | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | Felipe Alfaro Solana <felipe_alfaro> | ||||||
| Component: | Security - Password Policy | Assignee: | Rich Megginson <rmeggins> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Viktor Ashirov <vashirov> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 1.0 | ||||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | 1.0.2 | ||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2015-12-07 17:01:40 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 152373, 183369, 240316 | ||||||||
| Attachments: |
|
||||||||
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.
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? Created attachment 124663 [details]
check for correctly bound connection
check for correctly bound connection
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 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? 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. |
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: