Bug 1793709 - support GSS-SPNEGO ldap_sasl_mech type for RHEL6?
Summary: support GSS-SPNEGO ldap_sasl_mech type for RHEL6?
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.10
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Sumit Bose
QA Contact: sssd-qe
Depends On:
TreeView+ depends on / blocked
Reported: 2020-01-21 22:01 UTC by James Ralston
Modified: 2020-02-18 06:26 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2020-02-17 13:17:59 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description James Ralston 2020-01-21 22:01:50 UTC
Description of problem:

Microsoft has announced that as of March 2020, all supported versions of Active Directory will require LDAP channel binding and LDAP signing by default:


On RHEL7 and later, the sssd-ad provider can perform LDAP channel binding and LDAP signing by setting "ldap_sasl_mech = GSS-SPNEGO" in sssd.conf, overriding the default value of "GSSAPI" (which does not perform signing).

However, the latest sssd-ldap for RHEL6 is sssd-ldap-1.13.3-60.el6_10.2.x86_64, which only supports "GSSAPI" for ldap_sasl_mech.

Thus, when Microsoft releases the security update that requires LDAP channel binding and LDAP signing by default, unless Active Directory administrators specifically override it, this Microsoft change will break the ability for the RHEL6 sssd to use Active Directory as an identity provider. This will effectively break any RHEL6 host joined to Active Directory.

I would argue that breaking the ability for RHEL6 hosts to use Active Directory as an identity source unless a known attack vector (non-sealed LDAP binds) is enabled counts as an "Important" impact security fix under the "Maintenance Support 2" description and is thus appropriate to release for RHEL6.

Please consider backporting the GSS-SPNEGO ldap_sasl_mech option to the RHEL6 sssd, or providing some other mechanism for the RHEL6 sssd to satisfy Microsoft's requirements for LDAP channel binding and LDAP signing.

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


How reproducible:

Routine operations by the sssd-ldap identity provider against an Active Directory data provider will generate warnings in the Windows Event Log, although it may be necessary to enable more verbose log messages in order to see the warnings.

Steps to Reproduce:

1. On a RHEL6 host joined to Active Directory, perform some routine lookup operations (e.g., "getent passwd username").

2. On Windows, inspect the Windows Event Log.

Actual results:

There should be no warnings.

Expected results:

A warning something like the following will be logged:

Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Date:          12/23/2019 2:29:56 PM
Event ID:      2889
Task Category: LDAP Interface
Level:         Information
Keywords:      Classic
User:          ANONYMOUS LOGON
Computer:      server.example.org
The following client performed a SASL (Negotiate/Kerberos/NTLM/Digest) LDAP bind without requesting signing (integrity verification), or performed a simple bind over a clear text (non-SSL/TLS-encrypted) LDAP connection. 
Client IP address:
Identity the client attempted to authenticate as:
Binding Type:

Additional info:

I will anticipate a few counterarguments to this request.

Counterargument: "Migrate to RHEL7 or later."

While most sites are undoubtably in the process of migrating from RHEL6 (given that Support Phase 2 ends on 2020-11-30), Microsoft's change will land 8 months before RHEL6 goes EOL.

Even for sites whose migration to RHEL6 is well underway, shortening the migration timeline from 8 months to 2 months is not realistic.

Counterargument: "Override the [new] Microsoft default until you have migrated all hosts to RHEL6 or later."

For sites that are contractually required to adhere to various security guidelines (e.g., DISA STIGs), overriding a Microsoft security control may cause the host and/or site to fall out of conformance.

While I do not know if any such security guidelines currently require LDAP signing, especially once Microsoft changes the default to require signing, I would expect that most security guidelines would update to require the default setting (require signing) not be overridden. If this occurs before the site's migration to RHEL7 or later is complete, this will create a no-win scenario: override the Microsoft default and incur a potentially severe hit on security audits, or refrain from overriding the Microsoft default and break all RHEL6 hosts joined to Active Directory.

Comment 2 Sumit Bose 2020-01-22 07:42:45 UTC

adding support for the 'GSS-SPNEGO' option value to SSSD would not help much because OpenLDAP used by SSSD for the LDAP operations uses the cyrus-sasl library for the SASL operation and the cyrus-sasl in RHEL-6 does not support GSS-SPNEGO. So you have to start with cyrus-sasl and then make sure OpenLDAP can use it properly before SSSD can help.

Can you share a (sanitized) sssd.conf you are currently using on RHEL-6? Maybe it can be modified so that LDAPS is used instead of the plain LDAP port if your DC support LDAPS. If I understand the Microsoft advisory correctly LDAPS will works as well.


Comment 3 James Ralston 2020-02-14 05:15:44 UTC
Hi Sumit,

I agree that the lack of GSS-SPNEGO support in the RHEL6 cyrus-sasl is a dealbreaker.

From recent discussions on the sssd-users mailing list, it would appear that in at least some circumstances, it is possible to use GSSAPI authentication and not trigger Active Directory to complain that the LDAP SASL bind failed to use signing. I think pursuing that option is more promising, as it may be the case that (e.g.) only a very minor tweak is necessary to avoid the problem.

Thanks for the explanation; feel free to close this as Won't Fix.

Comment 5 James Ralston 2020-02-17 17:48:27 UTC
A clarification: it would appear that any GSSAPI authentication that negotiates a SASL SSF of 2 or greater will satisfy the forthcoming Microsoft requirement, despite the event log message that is generated (per the bug description). This includes the RHEL6 cyrus-sasl (and even the RHEL5 cyrus-sasl). For more information, see:




Comment 6 Sumit Bose 2020-02-18 06:26:49 UTC
(In reply to James Ralston from comment #5)
> A clarification: it would appear that any GSSAPI authentication that
> negotiates a SASL SSF of 2 or greater will satisfy the forthcoming Microsoft
> requirement, despite the event log message that is generated (per the bug
> description). This includes the RHEL6 cyrus-sasl (and even the RHEL5
> cyrus-sasl). For more information, see:
> https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.
> And:
> https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-
> channel-binding-and-ldap-signing-requirements-march-update/ba-p/921536/page/
> 4#comments


thank you for the clarification. This is my experience as well. Technically GSSAPI satisfies all requirements imo and SSSD is working as expected. But it is currently not clear to me why the event lgo message is shown and what this would mean for furute changes by Microsoft.


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