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 scenario 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. Samba currently does not support channel binding. Therefore customers are advised to not enforce channel binding when ldap ssl ads = yes is used in smb.conf. For details please see the samba bug report.
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 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.
Red Hat is working on an SSSD/adcli (RHEL8,RHEL7) enhancement that allows the use of ldaps protocol with the SSSD active directory provider. 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 (yet). The aforementioned RFE's will also set GSS-SPNEGO as default SASL mechanism in adcli. Currently GSSAPI is hardcoded in adcli and can not be changed. The adcli tool is used by SSSD to update the machine credentials in Active Directory for directly enrolled client systems.
NOTE: This information is preliminary and is subject to revision. This article is a living document, written over time and is subject to change.