Make It or Break It: Microsoft’s LDAP Security Update and the Impact on Financial Institutions Today
In January 2020, Microsoft announced it would release a security update on Windows that by default enables LDAP channel binding and LDAP signing hardening changes for Active Directory. LDAP (Lightweight Directory Access Protocol) is an open and cross platform protocol used for directory services authentication. LDAP provides the communication language that applications use to communicate with other Windows active directory (AD) servers which stores users, groups and passwords for many systems on an organization’s network. LDAP is the middle communication layer between the active directory and your business applications and systems.
LDAP channel binding and LDAP signing provide ways to increase the security for communications between LDAP clients and Active Directory domain controllers. However, there are a set of insecure default configurations for LDAP channel binding and LDAP signing on Active Directory domain controllers that let the LDAP communicate without enforcing secure LDAP channel binding and LDAP signing. Many organizations have not addressed this vulnerability by changing their default setting to make the LDAP more secure, so Microsoft is leading the charge to ensure network security for all users.
While originally slated for March 2020, Microsoft plans to release the update mid-year, giving organizations more time to proactively prepare for the change. This is because the patch will disable all insecure LDAP bindings, which has the potential to break many systems for several organizations. Financial institutions must look at their systems, determine insecure devices or applications, and fix them while there is still the option to switch back to the default setting.
The Problem
So why is Microsoft forcing this update on its users? The main concern is password protection. With Windows Server active directory, passwords are essentially allowed to be sent over the network in clear text (a non-TLS encrypted communication) by default. Microsoft’s patch is going to harden LDAP to essentially block the ability to send a password over the network using clear text. This is important because if a hacker is trying to intercept your organization’s passwords and encounters an insecure LDAP, they would be able to read the password and use this information to access your systems. LDAP needs to be hardened and changed from an insecure 0 to a secure 1 or 2 to ensure this doesn’t occur. When you harden LDAP, you’re improving the security posture of this protocol, so it has less vulnerabilities and less chances of being exploited.
Remember this is an “all or nothing” setting. You either make it secure or you don’t, but there are many consequences tied to the latter. Once this update is released, if you send a communication in clear text, the server will block it from being authenticated. If you are unable to send the communication securely by leveraging hardened LDAP, then it will likely break and no longer perform that function. This can affect any client, device, application, or system at your financial institution that interacts with the Windows server and needs to be authenticated (e.g., scanners that scan-to-folder or enumerate an address book.)
The Solution
So, what can you do to get ahead of this impending patch? Financial institutions can make this change early before the patch is released, by changing the registry setting forcing the LDAP to be more secure and causing everything that is going to break to break. Then they can change the setting back and fix whatever is broken. Again, the affected systems could be anything that authenticates with AD that uses the LDAP protocol. This is a process of trial and error and will require a lot of manual investigation to determine potential breaks.
A good place to start is to enable additional logging and collect all of your event logs and review the event IDs to see if you are affected. Start by looking for event ID 2889, 2886, and 2887 in your directory service log. If event ID 2886 is present, it indicates that LDAP signing is not being enforced by your domain controller. Event ID 2887 occurs every 24 hours and reports how many unsigned and clear text binds have occurred over the network. Then, event ID 2889 helps determine which IP addresses and accounts are making insecure LDAP channel binding requests so you can identify the correct devices and applications to fix. You can also review additional event IDs to gather more information or use a PowerShell command to help you track down insecure LDAP binding before the deadline later this year. If you have a managed services provider, they will be able to help you find the right solution.