Microsoft LDAP Channel Binding and Signing Patch

Discovery Solution for Microsoft’s March 2020 Update

Lightweight Directory Access Protocol (LDAP) – How did we get here?

20 years ago, I embarked on the fantastical journey that was migrating from NT4 to Active Directory. This is also when I began learning the power of LDAP. While it was technically available, very few companies implemented secure LDAP in the early days. Most enterprise applications or internal applications took advantage of the directory (and in a wide variety of ways), but unfortunately, many of us focused on the “make it work” philosophy, rather than “make it secure”.

The Challenge with LDAP Channel Binding

Today, the idea of applications communicating over nonsecure channels is unthinkable to most. For the last 5-7 years, companies have been trying to put the genie of non-secured LDAP communication back in the bottle we opened at the dawn of Active Directory. The challenge is daunting because no one understands what siloed groups, applications, integrations, or teams are using the directory, how they use it, the frequency, and most importantly if their traffic is secure or not secure. While there are ways to audit LDAP traffic, it is rarely used due to performance reasons. As a result, organizations are blind to the problem as it has rapidly spread unchecked like weeds in a garden. 

Microsoft’s LDAP Channel Binding and Signing Requirement

In March 2020, Microsoft will release a patch to require LDAP channel binding by default. This change is to improve the security of network communications. When network traffic is sent with no signing, encryption, or network verification, it can be leveraged by an attacker to perform a man-in-the-middle attack. 

Yes, the genie will be back in the bottle! It’s just like when flash support was removed from browsers or Google Chrome began shaming websites for not using TLS. Admins are in a panic about being forced to rapidly fix a problem we let fester for far too long. Our fear is justifiable as we are all concerned about how this will impact the business because essentially, we don’t know what is going to break. 

Identify Insecure LDAP Binding and Signing

For those old enough, you may be having flashbacks of Y2K all over again. Luckily, Microsoft did provide some assistance to prepare for this change that allows you to detect non-signed LDAP binds via Event ID 2886. When configured, a Domain Controller will indicate how many unsigned binds it received (every 24 hours).  If you enable the diagnostic LDAP interface events, you can also get details on which clients the non-signed LDAP binds are coming from via event 2889.  Event 2889 includes the client IP and account name used for the connection.

What I have learned over the last several years in helping customers audit LDAP is that the goals (while broad) often center around improved security and performance:

• Top LDAP Traffic Sources – Where is all the LDAP traffic coming from?
• Hardcoded Server Traffic – Do we have any applications that are binding to only one server? (This often means downtime, maintenance, or hardware replacement could impact application availability)
• Excessive/Inefficient Searches – Where can we provide guidance to internal application teams about excessive traffic or expensive queries that many require referral chasing or targeting non-indexed attributes?
• Non-secured LDAP Traffic – What are the sources and types of activity transmitting in clear text?
• SSL Traffic – What are the sources and types of activity using SSL that can be transitioned to Kerberos or TLS?
• Groups Used for Membership Lookup – Which applications query the directory for user and group membership information? (This is a great way of identifying all the places a group is being used to provide access to organizational resources)

What really made the difference was the ability to show a customer the details of LDAP queries performed. The reason this is so valuable is because seeing what is being looked up specifically and the frequency of these lookups, points them to a specific application or resource much quicker. The directory team and server/application owners easily decipher what it is based on some known behavior (e.g. the query is only ever looking for Fax numbers, therefore it’s highly likely the requestor is the company’s Fax application).

With StealthINTERCEPT for LDAP, organizations looking to audit LDAP activity can achieve the level of visibility required to answer these questions quickly and efficiently.

We Can Help!… For FREE

With little time to spare, we’d like to offer a helping hand. Regardless of whether or not you’re a Stealthbits customer, visit us and let us know if you’d like to take advantage of StealthINTERCEPT and the visibility it can provide. There’s no obligation!