Impact of Microsoft Security Advisory ADV190023 | LDAP Channel Binding and LDAP Signing on RHEL and AD integration.

Updated -

This article describes the impact of the Microsoft Advisory ADV190023 on Red Hat Enterprise Linux systems either enrolled directly into Active Directory domains or using a Kerberos trust established between the realm provided by Identity Management on Red Hat Enterprise Linux and a realm provided by Active Directory. The advisory will provide additional logging for clients using insecure settings for LDAP channel binding and LDAP signing.

Important: Microsoft announced that the March 2020 advisory and also any updates in the foreseeable future will not make changes to LDAP signing or LDAP channel binding policies or their registry equivalent on new or existing domain controllers.

Red Hat has verified by enforcing LDAP channel binding and LDAP signing on Active Directory Domain domain 2016 with various scenarios and observed no impact on Red Hat Enterprise Linux 6, 7 and 8 client systems functionality. Following are the few scenarios we have tested and confirmed to work as expected.

  • IdM/AD cross forest trust
  • Direct integration of Red Hat Enterprise Linux machine as AD client with SSSD id_provider=ad
  • Direct integration of Red Hat Enterprise Linux machine as AD client with SSSD id_provider=ldap
  • Direct integration of Red Hat Enterprise Linux machine as AD client with samba/winbind is using the client ldap sasl wrapping = sign default option. The samba option ldap ssl ads has been deprecated with samba-4.8.0 and it will be completely removed with 4.13.0. For information about how to alternatively sign/encrypt LDAP traffic and further details, see the samba: removal of ldap ssl ads smb.conf option solution.

When SSSD is used for direct or indirect integration with Active Directory, the default configuration establishes an encrypted communication path using SASL GSSAPI or SASL GSS-SPNEGO on default LDAP port 389. We have identified an issue in Microsoft implementation that creates a log event with ID 2889 in cases where clients use SASL GSSAPI, using sign/seal option, to communicate with Active Directory domain controllers but where the operation itself is successful. This is currently under investigation. To prevent those false/positive log events in Active Directory, client applications that support GSS-SPNEGO can be configured to use this SASL mechanism instead of GSSAPI. In SSSD a configuration option called ldap_sasl_mech exists to define the SASL mechanism to be used.

Current versions of the SSSD active directory provider also support the use of SSL/TLS when talking to an Active Directory backend. This type of configuration is optional and only needed in environments where the default LDAP port 389 is closed. But in general we do not recommend to close the default LDAP port 389 because this might lead to problems when channel binding over SSL/TLS is enforced on AD side but the client does not support it.

In environments where SASL is used together with SSL/TLS and channel binding is enforced on AD side, it’s necessary to install latest versions from cyrus-sasl, openldap and krb5-libs shipped with Red Hat Enterprise Linux 8.3 and later. The channel binding type to use can be configured in /etc/openldap/ldap.conf. The new option SASL_CBINDING must be set to tls-endpoint in case channel bindings are enforced on AD side for all clients or the ones that support it (please also see man 5 ldap.conf). For more details about TLS channel bindings, please consult RfC 5929.

References

For more information, see the following articles:

NOTE: This information is preliminary and is subject to revision. This article is a living document, written over time and is subject to change.

8 Comments

Log in to comment
James Nauer's picture Guru 2488 points
17 January 2020 7:36 PM

Please mention which versions of RHEL were tested (all currently supported, i.e., RHEL 6, 7, and 8? or only the newer versions?).

AD Newbie 5 points
4 February 2020 7:20 PM

Also looking for RHEL 6 status.

UB Newbie 5 points
22 January 2020 9:15 AM

Is RHEL6 tested ?

PC Newbie 18 points
22 January 2020 7:43 PM

Does this apply to sudoers-ldap.conf as well?

For example, would this configuration be expected to work?

uri ldap://adldap.example.com/
ssl start_tls
tls_checkpeer no

Alternatively, would some combination of ldaps:, ssl on or tls_checkpeer be required?

PR Newbie 11 points
4 February 2020 12:06 PM

I would guess no, try:

uri ldaps://adldap.example.com/
port 636
ssl on
sslpath /path/to/your/ca-cert
GB Newbie 9 points
18 February 2020 10:54 PM 
# If you are trying to run ldapsearch using your Kerberos TICKET GRANTING
# SESSION KEY so you don't have to keep typing a password or even putting
# one on the command line, you need to do some extra work.

# First verify with klist you have obtained and cached a Kerberos ticket-granting ticket.
# If not, run kinit.
[betauser@betamaxhost %1] kinit

# If you are getting this error
[betauser@betamaxhost %2] ldapsearch -b "dc=acmead,dc=acme,dc=net" -H ldaps://ldap01.acmead.acme.net -LLL -o ldif-wrap=1024 -s sub "(CN=*Beta*User*)" | grep dn
SASL/GSSAPI authentication started
SASL username: betauser@acmead,dc=acme,dc=net
SASL SSF: 256
SASL data security layer installed.
ldap_result: Can't contact LDAP server (-1)

# Try it like this to get more information
[betauser@betamaxhost %3] KRB5_TRACE=/dev/stderr ldapsearch -d 1 -b "dc=acmead,dc=acme,dc=net" -H ldaps://ldap01.acmead.acme.net -LLL -o ldif-wrap=1024 -s sub "(CN=*Beta*User*)" | grep dn
...
** ld 0x55848698b060 Outstanding Requests:
 * msgid 5,  origid 5, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x55848698b060 request count 1 (abandoned 0)
** ld 0x55848698b060 Response Queue:
   Empty
  ld 0x55848698b060 response count 0
ldap_chkResponseList ld 0x55848698b060 msgid -1 all 0
ldap_chkResponseList returns ld 0x55848698b060 NULL
ldap_int_select
read1msg: ld 0x55848698b060 msgid -1 all 0
ber_get_next
sb_sasl_generic_pkt_length: received illegal packet length of 813957120 bytes
sb_sasl_cyrus_decode: failed to decode packet: generic failure
sb_sasl_generic_read: failed to decode packet
ldap_msgfree
ldap_err2string
ldap_result: Can't contact LDAP server (-1)
ldap_free_request (origid 5, msgid 5)
ldap_free_connection 1 1
ldap_free_connection: actually freed

# OK it should have worked!!!

# After much searching, reading comments, and commit messages I tried this.
[betauser@betamaxhost %4] ldapsearch -O "maxssf=256,minssf=256" -b "dc=acmead,dc=acme,dc=net" -H ldaps://ldap01.acmead.acme.net -LLL -o ldif-wrap=1024 -s sub "(CN=*Beta*User*)" | grep dn

# Actually I tried lots of integers and they all seemed to work the same.
# More code or comment reading required to find out how they are really
# used and what are their valid ranges.

# But I found I can take it off the command line and put this in /etc/openldap/ldap.conf
    # The <properties> can be specified as a comma-separated list
    SASL_SECPROPS   minssf=256,maxssf=256

[betauser@betamaxhost %4] ldapsearch -b "dc=acmead,dc=acme,dc=net" -H ldaps://ldap01.acmead.acme.net -LLL -o ldif-wrap=1024 -s sub "(CN=*Beta*User*)" | grep dn
SASL/GSSAPI authentication started
SASL username: betauser@acmead,dc=acme,dc=net
SASL SSF: 0
SASL data security layer installed.
dn: CN=Beta User,OU=People,DC=ACMEAD,DC=ACME,DC=NET        <<<<<===== And that is what I had expected
Thorsten Scherf's picture Red Hat Active Contributor 194 points
27 August 2020 11:16 AM

You can not use signing/sealing on the SASL layer when used through SSL/TLS. This is clearly stated on the Microsoft SASL implementation page where it says:

While Active Directory permits SASL binds to be performed on an SSL/TLS-protected connection, it does not permit the use of SASL-layer encryption/integrity verification mechanisms on such a connection.

That's why you explicitly have to set the ssf to 0.

JB Newbie 5 points
21 April 2023 7:35 AM

Regarding this sentence: "In environments where SASL is used together with SSL/TLS and channel binding is enforced on AD side, it’s necessary to install latest versions from cyrus-sasl, openldap and krb5-libs shipped with Red Hat Enterprise Linux 8.3 and later."

Should this be interpreted that you can´t use RHEL7 servers to authenticate to Active Directory when SASL and SSL/TLS channel bindings are enforced on the AD side?