Bug 742054

Summary:	SASL/PLAIN binds do not work
Product:	Red Hat Enterprise Linux 6	Reporter:	Dmitri Pal <dpal>
Component:	389-ds-base	Assignee:	Rich Megginson <rmeggins>
Status:	CLOSED ERRATA	QA Contact:	Sankar Ramalingam <sramling>
Severity:	unspecified	Docs Contact:
Priority:	medium
Version:	6.1	CC:	jgalipea, nhosoi, nkinder, ssorce, syeghiay
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
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.	Story Points:	---
Clone Of:	741999	Environment:
Last Closed:	2013-02-21 08:16:37 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Bug Depends On:	741999
Bug Blocks:	756082

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