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.

Comments