#395 RFE: 389-ds shouldn't advertise in the rootDSE that we can handle a sasl mech if we really can't
Closed: wontfix None Opened 11 years ago by abbra.

In some setups we'll have specific SASL mechs not supported. For example, FreeIPA does not support SASL digest-md5 mech.
When rootDSE advertises this mech because it exists in the list of SASL mechs, client tries to use it and always fails.

We would like to see a method in cn=config to blacklist certain SASL mechs per instance. This is different from ticket #220 in which 389-ds can detect unusable mechs by way of used transport.


set default ticket origin to Community

Added initial screened field value.

The patch simply blacklists mechanisms from being advertised. This is good, but I would like to see if we could truly blacklist the mechanisms. Not all clients check the rootDSE to see what is supported first, and it would be nice to turn clients away who try to use a blacklisted mechanism (even if the SASL plug-in for that mechanism exists on the server).

To expand upon my previous comment, we should see if libsasl can be used to restrict the allowed mechanisms on the server side. By default, any available SASL plug-in library will be an allowed mechanism. You are supposed to have the ability to have an application specific config file located at /etc/sasl2/<app>.conf, where the mech_list setting can list the allowed mechanisms. I believe that the <app> name is the second parameter to sasl_server_init(), which is "iDS" in our current code. I tried getting this to work a few years back, and it didn't seem to work, but I didn't dig deeper at the time.

Aside from EXTERNAL, the mechanisms advertised in the root DSE are all dynamically provided by libsasl, so blacklisting at the library level would also fix the advertising issue in the root DSE.

Ok I've played around with the iDS.conf file under /etc/sasl2/, and I can see this being read in with strace at server startup:

open("/usr/lib64/sasl2/iDS.conf", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/sasl2/iDS.conf", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=43, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f606d4d1000
read(4, "mech_list: CRAM-MD5\n"..., 4096) = 43
read(4, "", 4096) = 0
close(4) = 0

However, this file does not appear to have any effect on DS, at least in regards to doing sasl binds.

I've set various values, and invalid values, and invalid combinations of settings/values, but it doesn't seem to effect anything. Searches work, and the returned list of supported mechanisms doesn't change.

This might be related to the fact that we have our own auxprop plug-in. We will probably have to look intot he cyrus-sasl code to figure it out.

is the "mech_list" option used internally by sasl to determine which mechanisms to support? I'm just wondering if the DS will continue to support the mechanisms supported by the library, even if they are not listed in the mech_list.

Replying to [comment:15 rmeggins]:

is the "mech_list" option used internally by sasl to determine which mechanisms to support? I'm just wondering if the DS will continue to support the mechanisms supported by the library, even if they are not listed in the mech_list.

Yes, sasl_server_start() and _sasl_server_listmech() all check the mech_list through the getopt callback. If none are returned(NULL), then it supports all the plugin mechanisms it can find from the OS. So the mech list is always empty, unless you specify which mechanisms to explicitly allow.

Added a new config setting under cn=config:

nsslapd-allowed-sasl-mechanisms

If you don't have this attribute then all the available mechanisms are allowed. Otherwise you can specify which sasl mechanisms you want to allow:

nsslapd-allowed-sasl-mechanisms: CRAM-MD5 GSSAPI PLAIN

git merge ticket395
Updating b3a2f40..e3aac66
Fast-forward
ldap/servers/slapd/configdse.c | 1 +
ldap/servers/slapd/libglobs.c | 36 ++++++++++++++++++++++++++++++++++++
ldap/servers/slapd/proto-slap.h | 2 ++
ldap/servers/slapd/saslbind.c | 2 ++
ldap/servers/slapd/slap.h | 2 ++
5 files changed, 43 insertions(+), 0 deletions(-)

git push origin master
Counting objects: 19, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (10/10), done.
Writing objects: 100% (10/10), 1.88 KiB, done.
Total 10 (delta 8), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds.git
b3a2f40..e3aac66 master -> master

Metadata Update from @nkinder:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.3.0

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/395

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata