Bug 206053 - FDS should permit configuration of SASL mechanisms
Summary: FDS should permit configuration of SASL mechanisms
Alias: None
Product: 389
Classification: Retired
Component: Security - SASL
Version: 1.0.2
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Nathan Kinder
QA Contact: Chandrasekar Kannan
Depends On:
Blocks: 389_1.3.0 512820
TreeView+ depends on / blocked
Reported: 2006-09-11 18:37 UTC by Josh Kelley
Modified: 2015-01-04 23:20 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-04-04 20:47:41 UTC

Attachments (Terms of Use)

Description Josh Kelley 2006-09-11 18:37:08 UTC
Description of problem:

Fedora Directory Server should permit individual SASL mechanisms to be enabled
and disabled.  (The inability to do so causes problems for OS X clients, which
expect CRAM-MD5 authentication to either work or return a "user not found in
database" error.)

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Note the list of supportedSASLMechanisms in the root DSE.
2. Check cn=config and the Admin console for a way to change this list.
Actual results:
Unable to change the list of supportedSASLMechanisms.

Expected results:
Able to change the list of supportedSASLMechanisms.

Additional info:

Comment 1 Rich Megginson 2007-10-05 16:08:02 UTC
I think you may be able to do something like this:
1) Create a private sasl directory for the server e.g.
 mkdir /opt/fedora-ds/slapd-instance/sasl2
2) create symlinks to the sasl plugins in that directory
 cd /opt/fedora-ds/slapd-instance/sasl2 ; for file in $libdir/sasl2/*.so* ; do
   ln -s $file
3) Remove the symlinks for the mechanisms you don't want to support e.g.
 rm *cram*
4) edit the start-slapd shell script
 SASL_PATH=/opt/fedora-ds/slapd-instance/sasl2 ; export SASL_PATH
5) restart the directory server

If the server can't find the mech plugin, it should not list it.

Comment 2 Nathan Kinder 2007-10-05 17:23:39 UTC
Rich's suggestion should work fine.  There is also another method that should
work, although I haven't attempted to use it myself.  Cyrus SASL has support for
creating an <app>.conf file that allows you to configure what mechanisms the
SASL library will support for that given application.  We rely on SASL to
generate the list of supported mechanisms that are listed in the root DSE, so
this would address the problem.

Comment 3 Rich Megginson 2009-04-09 16:55:34 UTC
Putting this on the list for the next release.

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