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.
attachment 0001-Ticket-395-RFE-389-ds-shouldn-t-advertise-in-the-roo.patch
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]:
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
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=918703
Metadata Update from @nkinder: - Issue assigned to mreynolds - Issue set to the milestone: 1.3.0
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.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.