Microsoft wants to break your network: ADV190023 LDAPS Changes

[leadeater]

This information came through a while ago, pretty much ignored it until now. Finally got round to actually reading it, wish I did it sooner! Initial information release was August 2019, so yea little late getting round to it.

 

Quote

LDAP channel binding and LDAP signing provide ways to increase the security of network communications between an Active Directory Domain Services (AD DS) or an Active Directory Lightweight Directory Services (AD LDS) and its clients. There is a vulerability in the default configuration for Lightweight Directory Access Protocol (LDAP) channel binding and LDAP signing and may expose Active directory domain controllers to elevation of privilege vulnerabilities.  Microsoft Security Advisory ADV190023 address the issue by recommending the administrators enable LDAP channel binding and LDAP signing on Active Directory Domain Controllers. This hardening must be done manually until the release of the security update that will enable these settings by default. 

 

Microsoft intends to release a security update on Windows Update to enable LDAP channel binding and LDAP signing hardening changes and anticipate this update will be available in March 2020.

 

Quote

Microsoft recommends administrators make the hardening changes described in ADV190023 because when using default settings, an elevation of privilege vulnerability exists in Microsoft Windows that could allow a man-in-the-middle attacker to successfully forward an authentication request to a Windows LDAP server, such as a system running AD DS or AD LDS, which has not configured to require signing or sealing on incoming connections.  The security of a directory server can be significantly improved by configuring the server to reject Simple Authentication and Security Layer (SASL) LDAP binds that do not request signing (integrity verification) or to reject LDAP simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection. SASLs may include protocols such as the Negotiate, Kerberos, NTLM, and Digest protocols. Unsigned network traffic is susceptible to replay attacks in which an intruder intercepts the authentication attempt and the issuance of a ticket. The intruder can reuse the ticket to impersonate the legitimate user. Additionally, unsigned network traffic is susceptible to man-in-the-middle attacks in which an intruder captures packets between the client and the server, changes the packets, and then forwards them to the server. If this occurs on an LDAP server, an attacker can cause a server to make decisions that are based on forged requests from the LDAP client.

 

Quote

We strongly advise administrators to enable LDAP channel binding and LDAP signing between now and March 2020 to find and fix any operating systems, applications or intermediate device compatibility issues in their environment.  If any compatibility issue is found, administrators will need to contact the manufacturer of that particular OS, application or device for support.

 

Important Any OS version, application and intermediate device that performs a man-in-the-middle inspection of LDAP traffic are most likely to be impacted by this hardening change.

https://support.microsoft.com/en-nz/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows

 

Effectively Microsoft is in the process of no longer supporting insecure LDAP completely. Handy table for those that just want a quick answer to what should be configured, you want a tick in LDAP signing required as anything not that will not be supported by the end of the year (you can disable it though).

 

 

Quote

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.

 

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.

 

Administrators can prevent the feature update from making those change either by enabling LDAP signing and channel binding NOW or by configuring non-default values prior to installing updates that enable LDAP signing and channel binding by default.

https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

 

For those that work in IT will likely realize the seriousness and consequence of this right away, this change has the potential to break many fundamental aspects of services. There is a wide array of software and services that rely on LDAP and have likely been in place for 10+ years not using secure LDAP (it ain't broke don't fix it, or the guy that did it left 10 years ago and nobody knows). Some fun examples: Printing authentication and accounting, sssd Linux group membership lookups (think nobody can login anymore), user account management software, Learning Management Systems, those awesome scripts that have been in place longer than anyone currently employed that are actually vital to the functioning of the entire network.

 

Authentication itself may not be LDAP but the secondary information lookups in the authentication chain usually are and if those fail to work you're going to have a bad day, a very bad day.

 

So for some of you the million dollar question is, "How do we identify everything that is using simple binds to LDAP".

Quote

Let’s start saying that since Windows Server 2008 we have events 2886,2887,2888 and 2889 logged every 24 hours on the Directory Services log that tells us we are using these unsecure protocols 

 

This information is preliminary and is subject to revision.
This article is a living document, written over time and is subject to change. When guidance presented in this article is in direct conflict with official documentation, one must defer to official documentation.

 

AUDITING LDAP Signing : 

To enable auditing we need to add the following registry key on each Domain Controller:

 Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2  

 

Once we add the key, no reboot required, the system will start logging the following event (Directory services log):

 

Event ID 2889

This is the Event ID you want to check in order to understand which IP Addresses and Accounts are making these requests.

Once you open Event 2889 in Details you will have

Client IP address: “Value”
Identity the client attempted to authenticate as: “Value”

 

You will also find these other events related to LDAP:

 

2886 

Telling us that our DCs are not requiring LDAP signing 

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd... 

  

2887 (already on by default and logged every 24 hours)

Telling us how many such binds occurred 

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd... 

The suggested path to resolve this error is do modify the registry of the DC to allow it log those failures. 

 

2888 

If the directory server is configured to reject unsigned SASL LDAP binds or LDAP simple binds over a non-SSL/TLS connection, the directory server will log a summary event 2888 one time every 24 hours when such bind attempts occur. 

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-update/ba-p/921536

 

VMware advice:

https://blogs.vmware.com/vsphere/2020/02/update-to-guidance-on-vmware-vsphere-microsoft-ad-ldap.html

https://blogs.vmware.com/vsphere/2020/01/microsoft-ldap-vsphere-channel-binding-signing-adv190023.html

 

Redhat advice (Customer login required so full post below):

Spoiler

Impact of this Advisory will enhance security measures between Active Directory and Client communication.

 

This advisory provided by Microsoft addresses the issue by recommending a new set of default configurations for LDAP channel binding and LDAP signing on Active Directory Domain Controllers that supersedes the original less secure configuration.

Red Hat has verified by enforcing LDAP channel binding and LDAP signing on Active Directory Domain on Active Directory domain 2016 with various scenarios and observed no impact on Red Hat Enterprise Linux 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 ldap ssl ads = yes and client ldap sasl wrapping = seal options

When SSSD is used for direct or indirect integration with Active Directory, the default configuration establishes an encrypted communication path using SASL GSSAPI and SASL GSS-SPNEGO on default LDAP port 389.

 

NOTE: This information is preliminary and is subject to revision. This article is a living document, written over time and is subject to change.

 

Citrix advice:

https://support.citrix.com/article/CTX269461

https://support.citrix.com/article/CTX269565

 

Netapp advice:

https://kb.netapp.com/app/answers/answer_view/a_id/1103575

 

Spoiler

 

[Samfisher]

Oh boy...  I can already imagine all the tickets I'll be getting....

 

Ticket 1 : FIX NAO

Ticket 2 : UNDO FIX NAO I CAN'T WORK

[Arika]

ELI5?

[Samfisher]

Just now, Arika S said:

ELI5?

Important stuff break.  Fix important stuff.  Other important stuff break cos of fix.  My head break cos job.

[leadeater]

6 minutes ago, Arika S said:

ELI5?

 

4 minutes ago, Samfisher said:

Important stuff break.  Fix important stuff.  Other important stuff break cos of fix.  My head break cos job.

100% correct answer ^

[LAwLz]

8 hours ago, Arika S said:

ELI5?

At home, your computer has locally stored usernames and passwords. In most enterprise networks, there is a centralized server which keeps track of your username and password.

 

For example at work I can login to my colleagues computer using my account even though his computer had no idea I was a legitimate user. When I try to login on his computer, that computer will send a message to the Active Directory (AD) server going "hey, this user with this password wants to login to this computer, is that allowed?". That communication is done with a protocol called LDAP (Lightweight Directory Access Protocol).

 

Having a centralized database of users where you can manage their user privileges is extremely handy at companies. And it's not just computer logins that does this either. For example all our managed network switches, routers, firewalls, etc also use LDAP against a Windows Active Directory to verify logins. When I want to login to our firewall, I just type in my Windows account, the firewall talks to the AD and checks if I am allowed to login. It means I have one account (username and password) for a ton of different devices, and as soon as I change password the new one is the current one for all those devices.

Ever logged into a wireless network where you have to type in both your username and password to gain access, rather than like at home with WPA2 where everyone who has the password can login? When you type in the username and password, the wireless controller checks if you're allowed to access the wireless network using LDAP against some directory service (probably Windows Active Directory).

 

Basically, LDAP is the underlying protocol used to manage a database of user accounts and privileges.

 

 

 

What these news are about is that Microsoft went "oh shit, our default settings in Windows Active Directory are kind of insecure. Let's change them!". When they change these settings, it might create mismatches between LDAP clients (like my job's routers and switches) and the settings on our Active Directory server. What this can result in is that when I try to login to my switch it might go "hey Windows AD, is LAwLz allowed to login to me with this password?" and the AD server replies "sorry but I refuse to talk to you now because it might not be safe".

 

 

If devices are not prepared for this change, login might stop working.