Bug 742054 - SASL/PLAIN binds do not work
Summary: SASL/PLAIN binds do not work
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.1
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Sankar Ramalingam
URL:
Whiteboard:
Depends On: 741999
Blocks: 756082
TreeView+ depends on / blocked
 
Reported: 2011-09-28 21:18 UTC by Dmitri Pal
Modified: 2013-02-21 08:16 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-1.2.11.12-1.el6
Doc Type: Bug Fix
Doc Text:
Cause: SASL PLAIN mechanism was not supported. Consequence: SASL PLAIN mechanism was not working Fix: Added PLAIN to the SASL supported mechanisms. Result: SASL PLAIN mechanism now works.
Clone Of: 741999
Environment:
Last Closed: 2013-02-21 08:16:37 UTC
Target Upstream Version:

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2013:0503 0 normal SHIPPED_LIVE Moderate: 389-ds-base security, bug fix, and enhancement update 2013-02-21 08:18:44 UTC

Description Dmitri Pal 2011-09-28 21:18:41 UTC 
+++ This bug was initially created as a clone of Bug #741999 +++

I have tried to use a SASL/PLAIN bind in order to do binds with a user id that is not a DN.
Because SASL mappings can resolve an arbitrary uid into a DN I was hoping to use that to bind to a directory where anonymous searches are disabled (therefore the client can't use an anonymous bind to search the DN itself.

Unfortunately it appears the current DS code is not able to perform SASL/PLAIN authentication. Sasl mapping is incorrectly performed. It happens twice, the first time it properly maps the provided user name to a DN the second time it tries to map the found DN again as if it were a user name.

Rich says DS may no be able to properly provide SASL with callback to handle checking the password.
Comment 1 Jenny Severance 2011-12-13 14:37:09 UTC 
will need steps to reproduce/verify this issue
Comment 2 Nathan Kinder 2011-12-15 17:31:32 UTC 
This is not needed for 6.3.  Moving forward to 6.4.
Comment 3 Rich Megginson 2012-01-06 23:56:20 UTC 
Upstream ticket:
https://fedorahosted.org/389/ticket/27
Comment 4 Jenny Severance 2012-06-22 18:58:15 UTC 
please add steps to verify this issue
Comment 5 RHEL Program Management 2012-07-10 06:18:22 UTC 
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 7 Suzanne Logcher 2012-07-10 14:49:16 UTC 
This request was erroneously denied for the current release of Red Hat Enterprise Linux.  The error has been fixed and this request has been re-proposed for the current release.
Comment 8 Jenny Severance 2012-07-24 12:40:26 UTC 
Test automated :: trac27 in ldapi test suite
Comment 10 Jenny Severance 2013-01-14 14:50:31 UTC 
verified :: 

400|0 19 1 22:33:39|IC Start
200|0 19 22:33:39|TP Start
520|0 19 18906 1 1|LDAPI TEST 19: SASL PLAIN over ldapi
520|0 19 18906 1 2|Search by "uid=ldapi_user0,o=ldapi.net" with SASL PLAIN mech: Success
520|0 19 18906 1 3|TestCase [trac27] result-> [PASS]
520|0 19 18906 1 4|Deleting passwordStorageScheme failed: 53
520|0 19 18906 1 5|TestCase [trac27] result-> [PASS]
220|0 19 0 22:33:40|PASS
410|0 19 1 22:33:40|IC End

version :: 89-ds-base-1.2.11.15-8.el6
Comment 12 errata-xmlrpc 2013-02-21 08:16:37 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-0503.html
Note You need to log in before you can comment on or make changes to this bug.