In August 2019, Microsoft released a very important security advisory about Lightweight Directory Access Protocol (LDAP).
LDAP has been around since 1993 and provides customers with the ability to open a simple bind to an Active Directory domain controller in order to establish an authenticated session. The major problem with this simple bind is that the initial credentials from the client to the domain controller are sent in clear text. This has created a vulnerability in Microsoft Windows that could allow a man-in-the-middle attacker to successfully forward an authentication request to a Windows LADP server that hasn’t been configured to required signing or sealing on incoming connections.
This update is extremely important and should not be ignored or delayed. Holistically, we need to ensure that all authentication traffic is fully encrypted and protected from man-in-the-middle attacks and tampering. So, how do we do that?
LDAP does offer the option to step up a Transport Layer Security (TLS) session, to encrypt traffic to and from the domain controller. You can also pair LDAP with Secure Sockets Layer (SSL) creating LDAPS, which also provides a more secure mechanism to bind to a domain controller.
LDAP with TLS, SSL or secure binding using LDAPv3 have been around for a decade and should be the current minimum standard for authentication traffic over the network. However, with the planned March security update, Windows servers and clients will no longer accept non-secure or non-signed LDAP binds. This means that LDAP and simple bind methods for authentication will stop working. This will apply to customers with existing and extended support. Don’t stress though, this is a good thing!
You may ask yourself, well I should not be affected as my endpoints (clients) are configured for LDAPS, so there should be no plain text passwords traversing the network right?
Well in theory, maybe. LDAPS will continue to work post March 2020, but what about those other services on the network that require authentication. Storage Area Network (SAN) management consoles, Remote Keyboard Video and Mouse (KVM) consoles for lights out management of server infrastructure, multi-function printers and many third party services. The only way to know for sure that your network is not vulnerable to credential sniffing and account breach is to enable event logging on your domain controllers to detect simple and non-secure binds.
This is a multi-stage detection and is conditional on Stage 1.
Firstly, you need to monitor for the existence of the following two event IDs in the Directory Service event log.
Event ID 2886 – LDAP Signing
If you find event ID 2886 then bad news, this means your domain controller or Lightweight Directory Services (LDS) instance is accepting non-signed LDAP binds. Below is an example of a domain controller that has no security baseline enabled. Event entries signify that the domain controller is capable of responding to non-signed LDAP connections.
Event ID 2887 – LDAP Signing
Event ID 2887 is generated every 24 hours and will provide the number of endpoints that are performing non-signed binds.
If you detect the above, then you need to move to Stage 2 which is identifying which endpoints are performing these connections.
Firstly, you need to enable a directory services diagnostics setting called “LDAP Interface Events”, which can be done via PowerShell or registry change. For details on the setting, refer to the event ID link below. I recommend enabling this setting prior to your monthly patching cycle as some events may not be triggered until the connecting services or hosts are restarted.
Once this change has been made then you will need to monitor for the event ID 2889.
Very important note, this setting should be enabled for any destination directory service including Active Directory Lightweight Directory Services (ADLDS) instances.
Event ID 2889 – LDAP Signing
Note, this setting has the potential to flood the Directory Service event log and should be used in short periods if you do not have a SEIM or event collector service in operation, your log may be rapidly cycled, and you could miss other critical events. I recommend performing this on a secondary domain controller initially to assess the event changes before moving to a primary domain controller.
For reference, below is a screenshot from my single domain controller with two Active Directory user accounts and three domain joined machines. Multiply this number of events by the number of users in your directory to see what I mean. Ensure you have enough log capacity prior to enabling this setting and do not forget to turn it back off when you have finished your investigation. Default log limit for the Directory Service event log is 1MB.
To test this out (because nothing in my home lab is configured for this type of LDAP bind), I used LDP.exe, which is a very useful tool for troubleshooting Active Directory and ADLDS connections.
After launching LDP.exe (I executed this locally on my domain controller as this tool is included when you enable the directory services or ADLDS service) and selected connect from the connection menu.
Once connected, select bind from the connection menu and use simple bind.
You can test without credentials to see how unsecure your domain controller is too!
Below is a successful connection and bind.
This event will be created per client connection to the directory servers and will provide the Source IP Address and the Username that performed the bind.
Congratulations, that was the easy part! Now for the hard stuff. Did you find more than a thousand events? Are your directory servers even configured to allow LDAPS binds?
Well, I would not be much of an Azure evangelist if I did not promote an Azure service to help out here, enter Azure Sentinel.
For this demonstration I enabled a Sentinel Workspace, using the free-tier of Log Analytics Workspace, downloaded the Microsoft Monitoring Agent and installed that on my domain controller using a generated Workspace ID and primary key. After adding the security event data connector, I enabled the collection of Directory Services events within the Log Analytics Workspace.
After a few minutes the Insecure Protocols Workbook had captured my test event. Other tools and log systems can be used of course, my preference happens to be Sentinel due to the presentation of these events straight out of the box.
Your next steps are to review and collate this information in Sentinel and then start targeting the source connections based on service, frequency and risk. The fun part will be reconfiguring systems to use LDAPS and secure binding. The ultimate goal here is to ensure that all authenticated traffic on the network is fully encrypted prior to the March security update.
For more information on Sentinel and how you can leverage the power of Azure and machine learning to protect your infrastructure both in the cloud and on-premises, contact myself or your account manager at Data#3.
Hopefully this advice has eased your insecurities about LDAP. Happy hunting!
