Bug 918703

Summary: [RFE] Add ability to configure allowed SASL mechanisms
Product: Red Hat Enterprise Linux 7 Reporter: Nathan Kinder <nkinder>
Component: 389-ds-baseAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Sankar Ramalingam <sramling>
Severity: unspecified Docs Contact:
Priority: high    
Version: 7.0CC: jgalipea, jrusnack, mkubik, mreynolds, nhosoi
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: 389-ds-base-1.3.1.2-1.el7 Doc Type: Enhancement
Doc Text:
Cause: Inability to control what sasl mechanisms the server will allow. Consequence: Unable to limit what mechanisms to allow. Change: A new configuration attribute was adding that sets the allowed mechanisms. Result: The server can now restrict certain mechanisms from authenticating.
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-06-13 11:44:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Nathan Kinder 2013-03-06 18:15:10 UTC
This bug is created as a clone of upstream ticket:
https://fedorahosted.org/389/ticket/395

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.

Comment 1 Rich Megginson 2013-10-01 23:24:15 UTC
moving all ON_QA bugs to MODIFIED in order to add them to the errata (can't add bugs in the ON_QA state to an errata).  When the errata is created, the bugs should be automatically moved back to ON_QA.

Comment 3 Ján Rusnačko 2013-11-11 15:53:50 UTC
[root@localhost jrusnack]# ldapsearch -D "cn=directory manager" -w Secret123 -b "cn=config" -s base | grep nsslapd-allowed-sasl-mechanisms
nsslapd-requiresrestart: cn=config:nsslapd-allowed-sasl-mechanisms
nsslapd-allowed-sasl-mechanisms:

[root@localhost jrusnack]# ldapmodify -D "cn=directory manager" -w Secret123 <<EOF
> dn: cn=config
> changetype: modify
> replace: nsslapd-allowed-sasl-mechanisms
> nsslapd-allowed-sasl-mechanisms: GSSAPI
> EOF
modifying entry "cn=config"

[root@localhost jrusnack]# ldapsearch -D "cn=directory manager" -w Secret123 -b "cn=config" -s base  nsslapd-allowed-sasl-mechanisms
# extended LDIF
#
# LDAPv3
# base <cn=config> with scope baseObject
# filter: (objectclass=*)
# requesting: nsslapd-allowed-sasl-mechanisms 
#

# config
dn: cn=config
nsslapd-allowed-sasl-mechanisms: GSSAPI

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

Feature is implemented in latest RHEL7 389, testing is yet to be done - bugs in this feature will be filed separately.

Comment 5 Ludek Smid 2014-06-13 11:44:26 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.