[German]A brief information for administrators in the Windows environment. The changes planned for 2020 for accessing domain controllers via secure LDAP bindings will probably be updated in the ‘2nd half of 2020’. Here again a little sorted.
LDAP Channel Binding: What we are talking about?
I had already mentioned this at Christmas 2019 here in the blog in the article Microsoft enforces secure connections to the Domain Controller from January 2020. Already in August 2019 Microsoft published ADV190023 (Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing).
LDAP channel binding and LDAP signing provide ways to increase the security of communication between LDAP clients and Active Directory domain controllers. On Active Directory domain controllers, there are a number of unsafe default configurations for LDAP channel binding and LDAP signing that allow LDAP clients to communicate with them without forcing LDAP channel binding and LDAP signing. This allows Active Directory domain controllers to be opened to increase permission vulnerabilities.
Therefore, Microsoft wanted to address this issue by providing a new set of secure default configurations for LDAP channel binding and LDAP signature on Active Directory domain controllers, replacing the original insecure configuration.
The timetable is changing
I had pointed out this fact – see my blog post Microsoft Security Advisories Dez. 17, 2019. German blog readers pointed out to me around Christmas 2019 that the first changes would take effect in January 2020. I had mentioned this in my blog post Microsoft enforces secure connections to the Domain Controller from January 2020.
However, Microsoft has changed that plan and moved the date from January to March 2020. And I received some feedback to the German edition of my blog post Detect insecure LDAP bindings before March 2020 there were a number of misunderstandings and that Microsoft would not really change anything on this date. The there were a number of misunderstandings and that Microsoft would not really change anything on this date. The relevant passage in ADV190023 reads like this:
Windows Updates in March 2020 add new audit events, additional logging, and a remapping of Group Policy values that will enable hardening LDAP Channel Binding and LDAP Signing. The March 2020 updates do not make changes to LDAP signing or channel binding policies or their registry equivalent on new or existing domain controllers.
Updates will provide new audit events and logging capabilities in March 2020 to harden LDAP channel binding and LDAP signing. But the March 2020 updates will not change the channel binding policies.
Changes in 2nd half of 2020
That night I saw the following tweet from Woody Leonhard, in which he points out a ‘further shift’ in the LDAP channel binding and LDAP signing story.
Once again, Microsoft delays changes in LDAP channel binding – from January to March, and now “the second half of calendar year 2020.” Admins take note. https://t.co/qUcQT5kfan
— Woody Leonhard (@AskWoody) February 4, 2020
I never made a copy of the ADV190023 article. But after reading Woody Leonhard, Microsoft did not add the above clarification to the post until February 4, 2020, that the March 2020 update does not change anything in the LDAP channel binding and LDAP signing itself.
What is relevant for you is that with the March 2020 update, you can start checking the settings for LDAP Channel Binding and LDAP Signing and change them if necessary (see also my blog post Detect insecure LDAP bindings before March 2020). And keep the following sentence from Microsoft in mind.
A further future monthly update, anticipated for release the second half of calendar year 2020, will enable LDAP signing and channel binding on domain controllers configured with default values for those settings.
Sometime in the 2nd half of 2020 there will be an update which implements LDAP Channel Binding and LDAP Signing to Domain Controllers based on the default settings. By then administrators should have adjusted their configuration.
Addendum: In case you use SafeGuard Enterprise from Sophos, there is a community article explaining, what to do, if the patch arrives.
Cookies helps to fund this blog: Cookie settings