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 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.

6 Comments

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

Also looking for RHEL 6 status.

Is RHEL6 tested ?

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?

I would guess no, try:

uri ldaps://adldap.example.com/
port 636
ssl on
sslpath /path/to/your/ca-cert
# 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