Blog Post

Core Infrastructure and Security Blog
10 MIN READ

LDAP Channel Binding and LDAP Signing Requirements - March 2020 update final release

AlanLaPietra's avatar
AlanLaPietra
Icon for Microsoft rankMicrosoft
Nov 04, 2019
Hi All, Alan here again, this time trying to give some details on these two settings that are creating quite some confusion.   ATTENTION: before you continue reading I must emphasize that the MAR...
Updated Oct 06, 2023
Version 62.0
alanlapietra
AlanLaPietra's avatar
AlanLaPietra
Icon for Microsoft rankMicrosoft
Mar 19, 2020

For All,

good article related to Linux/RH and LDAP Signing/Channel Binding support. 

 

RED HAT source

Impact of Microsoft Security Advisory ADV190023 | LDAP Channel Binding and LDAP Signing on RHEL and AD integration: https://access.redhat.com/articles/4661861

PS: yes Open Source, but article is not public, you have to login

 

An extraction of the article so everyone can benefit:

 

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 using 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 (STARTTLS?). 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."

 

Hope this help with the many questions related to Linux systems

 

Alan @ PFE